Hi, Tomasz It seems that we will achieve an agreement soon. :) But I still have some issues which I want to make clear with you, please check my comments below.
> -----Original Message----- > From: Bursztyka, Tomasz > Sent: Tuesday, July 15, 2014 4:06 PM > To: Zhang, Zhengguang; [email protected] > Cc: [email protected]; C S BHARGAVA; [email protected]; > Laperie, Andrei; Patrik Flykt; Le Foll, Dominique; Liu, Bingwei; Zhu, Peter > J; Xu, > Martin; Yin, Yan; [email protected]; > [email protected] > Subject: Re: New CAPI Proposal for ConnMan based WiFi P2P Solution > > Hi Zhengguang, > > Still small issue on how to proceed on a outgoing connection and WPS choice. > Rest is fine. > > > > >>> > >} wifi_direct_error_e; > >> > > >> >Anyway, why not using standard linux errors? You add some complexity > >> >to yourself here. > >> >If every callback/functions are properly documented: dev will know > >> >what -EBUSY will mean in the context of a specific function etc... > >> > > > The reasons that we define the error enum are: > > 1. This enum is used by App, and we follow the general CAPI style to > > define it > > Ok this reason is sufficient. the 2 other ones are debatable ( 2 because you > will > not be able to get the true P2P errors since connman hides those, and 3 > because > it's a matter of documenting function/errors context meaning) > > > 2. Standard Linux error maybe can't cover all the wifi_direct_errors > > 3. Standard Linux error maybe not intuitive to apps So we prefer to > > define the error enum for wifi p2p errors in CAPI layer. > > > >> > > >> >Currently ConnMan does not provide peer's device type/secondary type. > >> >We have to figure out a way to do it properly. > >> > > > According to WiFi P2P spec, we think it is a basic interface that ConnMan > should support, and the use case is that applications get a remote peers' > category, and display a related icon of the Category. > > > > Although ConnMan doesn't support now, we think ConnMan will support it in > future. So we define it here for future use. So here I want to confirm with > you > that the device type/secondary type will be supported in future in ConnMan, > right? > > I think it will somehow yes. Martin and I had already discussed about it but > most probably through 1 string or something like that. > So we can confirm that ConnMan will support it, right? > >>> > >typedef enum { > >>> > > WIFI_DIRECT_WPS_TYPE_NONE = 0x00, /**< No WPS type */ > >>> > > WIFI_DIRECT_WPS_TYPE_PBC = 0x01, /**< Push Button > Configuration */ > >>> > > WIFI_DIRECT_WPS_TYPE_PIN_DISPLAY = 0x02, /**< Display PIN > code */ > >>> > > WIFI_DIRECT_WPS_TYPE_PIN_KEYPAD = 0x04, /**< Provide the > keypad > >> >to > >>> > >input the PIN */ > >> > > >> >Don't make such differentiation. It's up to the user to enter the PIN. > >> >(UI can propose a default one if necessary) We won't use PIN > >> >generation from wpa_supplicant. > >> > > > The key issue is about PIN_DISPLAY, our thinking is that we can > > generate the pin code in CAPI layer from wpa_supplicant, then pass it to > ConnMan, This enum is used when an incoming P2P connection request arrives > whose WPS method is PIN_DISPLAY. The information can support the > application to choose the proper handler function. for example: if it's > PIN_KEYPAD it will display a text input to receive user's input. if it is > PIN_DISPLAY, it will display a pin text. > > ConnMan supports WPS PIN only in outgoing connection. For incoming ones: > only WPS PBC is supported. > It's far easier for all: either you "accept" the incoming connection (and > thus run > the WPS PBC underneath) or you reject it. > So previous comment still applies. > We still feel confusing about it, do you mean that ConnMan will only support outgoing WPS PIN, but it won't support incoming WPS PIN? If it won't support incoming WPS PIN, it seems not make sense, for example, there are 2 devices with ConnMan running, one device can't setup connection with the other by WPS PIN? So we want to make clear that ConnMan will not support incoming WPS PIN in the first phase, or even in future by your design? > >>> > >typedef void (*wifi_direct_incoming_connection_cb) > >>> > >(wifi_direct_wps_type_e > >> >type, > >>> > > wifi_direct_peer_info_s *peer, void > >>> > > *user_data); > >> > > >> >What about out-going connection that needs a PIN input? > >> >Either add a new callback for PIN input for out-going connection, or > >> >try to mix both use case in one. > >> > > > Here we only care about the incoming case, out-going case will be done via > wifi_direct_connect_with_display_pin, wifi_direct_connect_with_enter_pin or > wifi_direct_connect based on difference wps type. > > Same thing as the enum, connman won't propose PIN for incoming connection. > > >>> > >int wifi_direct_unset_device_state_changed_cb(void); > >> > > >> >I would remove that function. Just allow > >> >wifi_direct_set_device_state_changed_cb() > >> >to accept a NULL pointer as a cb. Thus this will be your unset function as > well. > >> >It's just a matter of documenting the function so developer knows > >> >about that behavior. > >> > > > Yes, your suggestion to remove the unset related functions is good, and it > > can > simplify the callbacks. > > But here we follow the general CAPI code style not only for WiFi P2P, so we > prefer to keep the unset callbacks at this time. > > Ok, if CAPI has such style then. > > >>> > >int > wifi_direct_foreach_connected_peers(wifi_direct_connected_peer_cb cb, > >>> > > void *user_data); > >> > > >> >Hum here you work differently: no unset functions (which should be > >> >the way), but when does the dev needs to call that? The foreach is > >> >semantically a bit misleading, moreover if you compare with previous > functions. > >> >Instead of_foreach_ I would stick with_set_. > >> > > > The interface is used to get all the connected peers info, it can be > > called after ACTIVATED. We will optimize the function name in newer > > version, maybe wifi_direct_foreach_get_connected_peers() is better.:) > > No then first name is fine. You want to loop on all currently connected peers, > fair enough. > > >>> > >int wifi_direct_connect_with_display_pin(const > >>> > >wifi_direct_peer_info_s > >> >*peer, > >>> > > char **pin); > >> > > >> >You can remove that one since connman won't provide you a generated PIN. > >> > > > Here our thinking is that we will generate a PIN from CAPI layer, and then > pass it to ConnMan. > > Remember connman won't help you to differentiate a pin input or pin display. > Thus it's up to your lib or the ui to pre-generate one to propose to the user > (so > either he'll pick that one, or he will input the one he wants). > > So review the naming here. I think you can join all pin/pbc choice in one > unique > function. Unless CAPI style forces you to split as much as possible. > > Also when you say "wifi_direct_connect_with_pin" it's like you suppose to use > wps pin when connecting. > But you don't know that before hand. You will first ask connman to connect > this > peer, and only then: agent api might request you "pin/pbc" choice. Only at > this > stage you will be able to say "I want to connect with pin, here it is". > It's a 2 stages connection process. Tell me if I am wrong, but it looks like > you > API does not handle it this way. > Our previous thinking is that upper layer can get what config method(pbc/pin) peer supports before connecting it, then upper layer can select through which method to connect. Is it possible to add the config method in peer property and expose it? For example, in Tizen, when it will connect a service, it will firstly check whether the service is favorite, if yes, it will connect it directly, otherwise, it will request input via ConnMan agent, so here is it possible to get the config method(pbc/pin) before calling agent? > >>> > >int wifi_direct_set_device_name(const char *device_name); > >> > > >> >Remove it. We won't expose this from DBus. Currently, ConnMan sets > >> >the hostname as the device name or "ConnMan" (if the hostname is > >> >missing which _should not_ happen). > >> >We could get a /etc/main.conf entry to set a specific one if really > >> >necessary but I am not found of this either. > >> > > > For a smart device, user may change it to be the identifier of the device, > > just > like bluetooth. it is a reasonable requirement for it can be changed by user. > > But we don't suggest to change hostname, for it is a global setting of the > device, so we don't think it is a right way to change P2P device name via > changing hostname. > > Therefore, we really suggest ConnMan can expose it. Maybe we can use > hostname as a default value, but if user changes it, it won't change the > hostname. > > Still not convinced. If user set a proper hostname when he gets his smart > device, > that should be sufficient. > (At least for connman upstream I don't think it's useful.) > OK, we will use hostname at this time, but we still think it's not good to bind the WiFi P2P device name with hostname. :) > >>> > >int wifi_direct_get_device_state(wifi_direct_state_e *state); > >> > > >> >Why not just enum wifi_direct_state_e wifi_direct_get_state(void); ? > >> >Much simpler. > >> > > > OK, we will change the function name to wifi_direct_get_state, but here we > want to get the error as well from the return value. > > Ok you want to know if P2P technology is present at all then? > You could just add another specific state for it then, instead of an error. > As you prefer. > > >>> > >int wifi_direct_service_add(wifi_direct_service_type_e type, char > *data1, > >>> > > char *data2); > >> > > >> >What are data1 and data2? > >> > > > The parameters are related to command "p2p_service_add" > > e.g. > > p2p_service_add bonjour <query hexdump> <RDATA hexdump>: data1 is > <query hexdump>, and data2 is <RDATA hexdump>. > > p2p_service_add upne <version hex> <service> : data1 is <version hex> data2 > is <service>. > > Maybe getting better naming for these parameters would help then. > > >>> > >int wifi_direct_get_display_type(wifi_direct_display_type_e > >>> > >*type); > >> > > >> >All this last function are Wifi Display related, not sure at all you > >> >want to put it in the same basket as wifi direct library. > > There are no independent CAPI library about WiFi Display in current Tizen, > here we just keep it in wifi direct library as current tizen design. > > Here I want to confirm with you whether ConnMan WiFi P2P solution will > support WiFi Display related operations? > > There is nothing specific ConnMan needs to handle here. The wifi diplay stuff > will be merged in Peer's Services property that your lib will have to parse > (for > distant peer's info at least). > For local wifi display stuff, it's up to you to manage it, the only > requirement > about connman is that you register your wifi display stuff through > RegisterPeerService() Manager API. > > So your wifi display api seems ok to me here then. > It seems we have some misunderstanding about it before. Do you mean that we can only get some WiFi Display info through peer's services property, but we can't make some wifi display operations through ConnMan? For example, set wifi display port, type and so on. > > > > wifi-direct.h > > > > > > /* Data structure */ > > typedef enum { > > WIFI_DIRECT_ERROR_NONE = 0, /**< Successful */ > > WIFI_DIRECT_ERROR_NOT_PERMITTED = -EPERM, /** Operation not > permitted(1) */ > > WIFI_DIRECT_ERROR_OUT_OF_MEMORY = -ENOMEM, /** Out of > memory(12) */ > > WIFI_DIRECT_ERROR_RESOURCE_BUSY = -EBUSY, /** Device or > resource busy(16) */ > > WIFI_DIRECT_ERROR_INVALID_PARAMETER = -EINVAL, /** Invalid > function parameter(22) */ > > WIFI_DIRECT_ERROR_CONNECTION_TIME_OUT = -ETIMEDOUT, /**< > Connection timed out(110) */ > > WIFI_DIRECT_ERROR_NOT_INITIALIZED = -0x00008000|0x0201, /**< > Not initialized */ > > WIFI_DIRECT_ERROR_COMMUNICATION_FAILED = -0x00008000|0x0202, > /**< I/O error */ > > WIFI_DIRECT_ERROR_WIFI_USED = -0x00008000|0x0203, /**< WiFi is > being used */ > > WIFI_DIRECT_ERROR_MOBILE_AP_USED = -0x00008000|0x0204, /**< > Mobile AP is being used */ > > WIFI_DIRECT_ERROR_CONNECTION_FAILED = -0x00008000|0x0205, > /**< Connection failed */ > > WIFI_DIRECT_ERROR_OPERATION_FAILED = -0x00008000|0x0207, /**< > > Operation failed */ } wifi_direct_error_e; > > > > typedef enum { > > WIFI_DIRECT_STATE_DEACTIVATED, > > WIFI_DIRECT_STATE_ACTIVATED, > > WIFI_DIRECT_STATE_CONNECTED, > > } wifi_direct_state_e; > > > > typedef enum { > > WIFI_DIRECT_PEER_IDLE, > > WIFI_DIRECT_PEER_CONNECTING, > > WIFI_DIRECT_PEER_CONNECTED, > > WIFI_DIRECT_PEER_DISCONNECTING, > > WIFI_DIRECT_PEER_DISCONNECTED, > > } wifi_direct_peer_state_e; > > > > typedef enum { > > WIFI_DIRECT_CATEGORY_COMPUTER_PC, > > WIFI_DIRECT_CATEGORY_COMPUTER_SERVER, > > WIFI_DIRECT_CATEGORY_COMPUTER_MEDIA_CTR, > > WIFI_DIRECT_CATEGORY_COMPUTER_UMPC, > > WIFI_DIRECT_CATEGORY_COMPUTER_NOTEBOOK, > > WIFI_DIRECT_CATEGORY_COMPUTER_DESKTOP, > > WIFI_DIRECT_CATEGORY_COMPUTER_MID, > > WIFI_DIRECT_CATEGORY_COMPUTER_NETBOOK, > > > > WIFI_DIRECT_CATEGORY_INPUT_KEYBOARD, > > WIFI_DIRECT_CATEGORY_INPUT_MOUSE, > > WIFI_DIRECT_CATEGORY_INPUT_JOYSTICK, > > WIFI_DIRECT_CATEGORY_INPUT_TRACKBALL, > > WIFI_DIRECT_CATEGORY_INPUT_CONTROLLER, > > WIFI_DIRECT_CATEGORY_INPUT_REMOTE, > > WIFI_DIRECT_CATEGORY_INPUT_TOUCHSCREEN, > > WIFI_DIRECT_CATEGORY_INPUT_BIO_READER, > > WIFI_DIRECT_CATEGORY_INPUT_BAR_READER, > > > > WIFI_DIRECT_CATEGORY_PRINTER_PRINTER, > > WIFI_DIRECT_CATEGORY_PRINTER_SCANNER, > > WIFI_DIRECT_CATEGORY_PRINTER_FAX, > > WIFI_DIRECT_CATEGORY_PRINTER_COPIER, > > WIFI_DIRECT_CATEGORY_PRINTER_ALLINONE, > > > > WIFI_DIRECT_CATEGORY_CAMERA_DIGITAL_STILL, > > WIFI_DIRECT_CATEGORY_CAMERA_VIDEO, > > WIFI_DIRECT_CATEGORY_CAMERA_WEBCAM, > > WIFI_DIRECT_CATEGORY_CAMERA_SECONDARYURITY, > > > > WIFI_DIRECT_CATEGORY_STORAGE_NAS, > > > > WIFI_DIRECT_CATEGORY_NETWORK_INFRA_AP, > > WIFI_DIRECT_CATEGORY_NETWORK_INFRA_ROUTER, > > WIFI_DIRECT_CATEGORY_NETWORK_INFRA_SWITCH, > > WIFI_DIRECT_CATEGORY_NETWORK_INFRA_GATEWAY, > > > > WIFI_DIRECT_CATEGORY_DISPLAY_TV, > > WIFI_DIRECT_CATEGORY_DISPLAY_PIC_FRAME, > > WIFI_DIRECT_CATEGORY_DISPLAY_PROJECTOR, > > WIFI_DIRECT_CATEGORY_DISPLAY_MONITOR, > > > > WIFI_DIRECT_CATEGORY_MULTIMEDIA_DAR, > > WIFI_DIRECT_CATEGORY_MULTIMEDIA_PVR, > > WIFI_DIRECT_CATEGORY_MULTIMEDIA_MCX, > > WIFI_DIRECT_CATEGORY_MULTIMEDIA_STB, > > WIFI_DIRECT_CATEGORY_MULTIMEDIA_MSMAME, > > WIFI_DIRECT_CATEGORY_MULTIMEDIA_PVP, > > > > WIFI_DIRECT_CATEGORY_GAME_XBOX, > > WIFI_DIRECT_CATEGORY_GAME_XBOX_360, > > WIFI_DIRECT_CATEGORY_GAME_PS, > > WIFI_DIRECT_CATEGORY_GAME_CONSOLE, > > WIFI_DIRECT_CATEGORY_GAME_PORTABLE, > > > > WIFI_DIRECT_CATEGORY_PHONE_WM, > > WIFI_DIRECT_CATEGORY_PHONE_SINGLE, > > WIFI_DIRECT_CATEGORY_PHONE_DUAL, > > WIFI_DIRECT_CATEGORY_PHONE_SM_SINGLE, > > WIFI_DIRECT_CATEGORY_PHONE_SM_DUAL, > > > > WIFI_DIRECT_CATEGORY_AUDIO_TUNER, > > WIFI_DIRECT_CATEGORY_AUDIO_SPEAKER, > > WIFI_DIRECT_CATEGORY_AUDIO_PMP, > > WIFI_DIRECT_CATEGORY_AUDIO_HEADSET, > > WIFI_DIRECT_CATEGORY_AUDIO_HEADPHONE, > > WIFI_DIRECT_CATEGORY_AUDIO_MIC, > > } wifi_direct_category_e; > > > > typedef enum { > > WIFI_DIRECT_WPS_TYPE_NONE = 0x00, /**< No WPS type */ > > WIFI_DIRECT_WPS_TYPE_PBC = 0x01, /**< Push Button Configuration */ > > WIFI_DIRECT_WPS_TYPE_PIN_DISPLAY = 0x02, /**< Display PIN code */ > > WIFI_DIRECT_WPS_TYPE_PIN_KEYPAD = 0x04, /**< Provide the keypad > to > > input the PIN */ } wifi_direct_wps_type_e; > > > > typedef enum { > > WIFI_DIRECT_SERVICE_ALL, > > WIFI_DIRECT_SERVICE_BONJOUR, > > WIFI_DIRECT_SERVICE_UPNP, > > WIFI_DIRECT_SERVICE_WSDISCOVERY, > > WIFI_DIRECT_SERVICE_WIFIDISPLAY, > > WIFI_DIRECT_SERVICE_VENDORSPEC = 0xff, } wifi_direct_service_type_e; > > > > typedef enum { > > WIFI_DIRECT_DISPLAY_SOURCE, > > WIFI_DIRECT_DISPLAY_PRIMARY_SINK, > > WIFI_DIRECT_DISPLAY_SECONDARY_SINK, > > WIFI_DIRECT_DISPLAY_DUAL_ROLE, > > } wifi_direct_display_type_e; > > > > typedef struct { > > char *identify: > > char *name; > > char *ip_addr; > > char *netmask; > > wifi_direct_category_e category; > > wifi_direct_peer_state_e state; > > } wifi_direct_peer_info_s; > > > > /* Inteface */ > > > > > /**************************************************************** > ************** > > * This API will do some initialization the various variables > > * > > * > > */ > > int wifi_direct_initialize(void); > > > > > /**************************************************************** > ************** > > * This API will do some deinitialization. > > * > > * > > */ > > int wifi_direct_deinitialize(void); > > > > > /**************************************************************** > ************** > > * Notification callback function type > > * Activate notification can occurs at WiFi Direct state changed > > * > > */ > > typedef void (*wifi_direct_state_changed_cb) (int error_code, > > wifi_direct_state_e device_state, > > void *user_data); > > > > > /**************************************************************** > ************** > > * This API shall register a state changed callback function to monitor > > WiFi > > * Direct state. > > * > > */ > > int wifi_direct_set_state_changed_cb(wifi_direct_state_changed_cb cb, > > void *user_data); > > > > > /**************************************************************** > ************** > > * This API shall unregister a state changed callback function. > > * > > * > > */ > > int wifi_direct_unset_state_changed_cb(void); > > > > > /**************************************************************** > ************** > > * Notification callback function type > > * Connection notification can occurs at WiFi Direct connection state > changed > > * > > */ > > typedef void (*wifi_direct_peer_state_changed_cb) (int error_code, > > wifi_direct_peer_state_e peer_state, > > wifi_direct_peer_info_s *peer, void *user_data); > > > > > /**************************************************************** > ************** > > * This API shall register a peer state change callback function to monitor > WiFi > > * Direct peer state changed. > > * > > */ > > int wifi_direct_set_peer_state_changed_cb( > > wifi_direct_peer_state_changed_cb cb, > > void *user_data); > > > > > /**************************************************************** > ************** > > * This API shall unregister a peer state changed callback function. > > * > > * > > */ > > int wifi_direct_unset_peer_state_changed_cb(void); > > > > > /**************************************************************** > ************** > > * Notification callback function type > > * Peer changed notification can occurs at remote peers added or removed > > * > > */ > > typedef void (*wifi_direct_peers_changed_cb) (void *user_data); > > > > > /**************************************************************** > ************** > > * This API shall register the peers changed callback function to monitor > WiFi > > * Direct remote peers changed. the callback will be invoke after scan. > > * > > */ > > int wifi_direct_set_peers_changed_cb(wifi_direct_peers_changed_cb cb, > > void *user_data); > > > > > /**************************************************************** > ************** > > * This API shall unregister the peers changed callback function. > > * > > * > > */ > > > > int wifi_direct_unset_peers_changed_cb(void); > > > > > /**************************************************************** > ************** > > * Notification callback function type > > * Incoming connection notification can occurs at a incoming request > received > > * > > */ > > typedef void (*wifi_direct_incoming_connection_cb) (wifi_direct_wps_type_e > type, > > wifi_direct_peer_info_s *peer, void *user_data); > > So that fixes the issue about accepting/rejecting an incoming connection, but > what about outgoing connection on pbc/pin request that you cannot know > before hand? > > > > /**************************************************************** > ************** > > * This API shall register a incoming connection callback function. > > * The callback will be invoke when a incoming connection received. > > * > > */ > > int wifi_direct_set_incoming_connection_cb( > > wifi_direct_incoming_connection_cb cb, > > void *user_data); > > > > > /**************************************************************** > ************** > > * This API shall unregister a incoming connection callback function. > > * > > * > > */ > > int wifi_direct_unset_incoming_connection_cb(void); > > > > > /**************************************************************** > ************** > > * Iterates callback function type for discovered peers > > * This function will used by wifi_direct_foreach_get_discovered_peers > > * > > */ > > typedef bool (*wifi_direct_discovered_peer_cb) (wifi_direct_peer_info_s > *peer, > > void *user_data); > > > > > /**************************************************************** > ************** > > * This API shall get all the peers, and invoke the callback with the peers > > * as a parameters. > > * > > */ > > int > wifi_direct_foreach_get_discovered_peers(wifi_direct_discovered_peer_cb cb, > > void *user_data); > > > > > /**************************************************************** > ************** > > * Iterates callback function type for connected peers > > * This function will used by wifi_direct_foreach_get_connected_peers > > * > > */ > > typedef bool (*wifi_direct_connected_peer_cb) (wifi_direct_peer_info_s > *peer, > > void *user_data); > > > > > /**************************************************************** > ************** > > * This API shall get all the connect peers, and invoke the callback with > > the > > * peers as a parameters. > > * > > */ > > int wifi_direct_foreach_get_connected_peers(wifi_direct_connected_peer_cb > cb, > > void *user_data); > > > > > /**************************************************************** > ************** > > * This API shall activate WiFi direct > > * > > * > > */ > > int wifi_direct_activate(void); > > > > > /**************************************************************** > ************** > > * This API shall deactivate WiFi direct > > * > > * > > */ > > int wifi_direct_deactivate(void); > > > > > /**************************************************************** > ************** > > * This API shall start a P2P Scan process to find the peers > > * > > * > > */ > > int wifi_direct_start_discovery(void); > > > > > /**************************************************************** > ************** > > * This API shall start or accept a p2p request. > > * 1 Start a P2P outgoing request with PBC method. > > * 2 Accept a P2P incoming request with PBC method. > > * 3 Invite a peer into current P2P connection. > > */ > > int wifi_direct_connect(const wifi_direct_peer_info_s *peer); > > > > > /**************************************************************** > ************** > > * This API shall start a p2p request with PIN dispaly. Application will > > * get the PIN code form the*pin* parameters, and display to Users. > > * > > */ > > int wifi_direct_connect_with_display_pin(const wifi_direct_peer_info_s > *peer, > > char **pin); > > > > > /**************************************************************** > ************** > > * This API shall accept a p2p request with PIN keypad. Application should > > * set the PIN code which get from remote peer's display. > > * > > */ > > int wifi_direct_connect_with_enter_pin(const wifi_direct_peer_info_s *peer, > > const char *pin); > > So as said earlier, you don't need to differentiate on display/enter pin, but > you > need a way to tell that you want pbc instead of pin as well. > Note also that this cannot be called as is: first you call > wifi_direct_connect() and only then > you could have a callback of outgoing connecting requesting you the method > etc... > > > > > > /**************************************************************** > ************** > > * This API shall ending a P2P connection > > * 1 Reject a incoming P2P request. > > * 2 Cancel a outgoing connecting request. > > * 3 Destory a founded P2P connection with a peer. > > */ > > int wifi_direct_disconnect(const wifi_direct_peer_info_s *peer); > > > > > /**************************************************************** > ************** > > * This API shall ending all the P2P connection with local side. > > * > > * > > */ > > int wifi_direct_disconnect_all(void); > > > > > /**************************************************************** > ************** > > * This API shall set local device name > > * > > * > > */ > > int wifi_direct_set_device_name(const char *device_name); > > > > > /**************************************************************** > ************** > > * This API shall get local device name > > * > > * > > */ > > int wifi_direct_get_device_name(char **device_name); > > > > > /**************************************************************** > ************** > > * This API shall get state > > * > > * > > */ > > int wifi_direct_get_state(wifi_direct_state_e *state); > > > > > /**************************************************************** > ************** > > * This API shall register a WiFi Direct service > > * > > * > > */ > > int wifi_direct_service_add(wifi_direct_service_type_e type, char *data1, > > char *data2); > > > > > /**************************************************************** > ************** > > * This API shall unregister a WiFi Direct service > > * > > * > > */ > > int wifi_direct_service_del(wifi_direct_service_type_e type, char *data1, > > char *data2); > > > > > /**************************************************************** > ************** > > * This API shall do a WiFi Display initialization with type, port, hdcp > > * > > * > > */ > > int wifi_direct_init_wifi_display(wifi_direct_display_type_e type, int port, > > int hdcp); > > > > > /**************************************************************** > ************** > > * This API shall do a WiFi Display deinitialization. > > * > > * > > */ > > int wifi_direct_deinit_wifi_display(void); > > > > > /**************************************************************** > ************** > > * This API shall get WiFi Display port. > > * > > * > > */ > > int wifi_direct_get_display_port(int *port); > > > > > /**************************************************************** > ************** > > * This API shall get WiFi Display device type. > > * > > * > > */ > > int wifi_direct_get_display_type(wifi_direct_display_type_e *type); > > > > Ok besides this small issue with WPS, rest is fine to me. > > Tomasz _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
