[Dev] New CAPI Proposal for ConnMan based WiFi P2P Solution

Zhang, Zhengguang zhengguang.zhang at intel.com
Mon Jul 14 14:52:33 GMT 2014


Hi, Tomasz
Thanks for your feedback about the WiFi P2P CAPI proposal.

Please check my comments below.
Besides, we have updated the CAPI proposal according to your suggestions and added it in the attachment, please review it again, any suggestions, feel free to let me know, thanks in advance!

> -----Original Message-----
> From: Bursztyka, Tomasz
> Sent: Friday, July 11, 2014 8:47 PM
> To: Zhang, Zhengguang; Dev at lists.tizen.org
> Cc: steve.jun at samsung.com; C S BHARGAVA; taesub.kim at samsung.com;
> Laperie, Andrei; Patrik Flykt; Le Foll, Dominique; Liu, Bingwei; Zhu, Peter J; Xu,
> Martin; Yin, Yan; guoqiang.liu at archermind.com;
> chengyi1.zhao at archermind.com
> Subject: Re: New CAPI Proposal for ConnMan based WiFi P2P Solution
> 
> Hi,
> 
> Very sorry for the delay. Patrik is on vacation, and on my side I forgot this
> thread.
> 
> Your API looks like a good start, but there is room for simplification:
> less callbacks mostly,
> and functions etc...
> 
> >
> > /* 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_AUTH_FAILED = -0x00008000|0x0206,  /**<
> > Authentication failed */
> 
> How will you know that authentication has failed? ConnMan will just tell you
> "Failed" that's it.
> 
Agree, we will delete it.

> > 	WIFI_DIRECT_ERROR_OPERATION_FAILED = -0x00008000|0x0207,  /**<
> Operation failed */
> > 	WIFI_DIRECT_ERROR_ALREADY_INITIALIZED = -0x00008000|0x0209,
> /**<
> > Already initialized client */
> 
> So it's not an error then ;)
> You wifi_direct_init(), if already called once, should just return successfully
> without doing anything.
> 
Agree, we will delete it.

> > 	WIFI_DIRECT_ERROR_CONNECTION_CANCELED,	/**< Connection
> canceled by local device */
> 
> If something/someone is canceling a connection, it's not an error.
> 
Agree, we will delete it.

> > } 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
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.

> > typedef enum {
> > 	WIFI_DIRECT_DEVICE_STATE_ACTIVATED,
> > 	WIFI_DIRECT_DEVICE_STATE_DEACTIVATED,
> > } wifi_direct_device_state_e;
> 
> You mean the technology here, since you don't have any access to any "device".
> Just remove "device" from the name.
> 
Agree, we will update it.

> > typedef enum {
> > 	WIFI_DIRECT_CONNECTION_IDLE,
> > 	WIFI_DIRECT_CONNECTION_CONNECTING,
> > 	WIFI_DIRECT_CONNECTION_CONNECTED,
> > 	WIFI_DIRECT_CONNECTION_IPASSIGNED,
> 
> Connected/Ipassigned are equal. There is no proper P2P connection without an
> IP.
> ConnMan will drop the connection request if it cannot get any IP.
> 
OK, we will update it.

> > 	WIFI_DIRECT_CONNECTION_DISCONNECTING,
> > 	WIFI_DIRECT_CONNECTION_DISCONNECTED,
> > } wifi_direct_connection_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;
> 
> 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?

> > 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.

> > } 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;
> 
> You will have to parse the IE's of each peer service. That's ok, apps needs a
> proper peer service library.
> 
> > 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;
> >
> >
> /****************************************************************
> **************
> >   * Notification callback function type
> >   * Discover notification can occurs at peers are found
> >   *
> >   */
> > typedef bool (*wifi_direct_discovered_peer_cb) (wifi_direct_peer_info_s
> *peer,
> > 				void *user_data);
> 
> What's the difference with wifi_direct_peers_changed_cb below?
> You might drop that one.
> 
This will be a parameter of the function wifi_direct_foreach_discovered_peers() to get the all the discovered peers.
> >
> /****************************************************************
> **************
> >   * Notification callback function type
> >   * Connected peer notification can occurs at a peers connected
> >   *
> >   */
> > typedef bool (*wifi_direct_connected_peer_cb) (wifi_direct_peer_info_s
> *peer,
> > 				void *user_data)
> 
> Maybe you don't want such callback also.
> Again wifi_direct_connection_state_changed_cb is good enough here
> 
Similar to wifi_direct_discovered_peer_cb(), it will be a parameter of the function wifi_direct_foreach_connected_peers().
> >
> /****************************************************************
> **************
> >   * Notification callback function type
> >   * Activate notification can occurs at WiFi Direct activated
> >   *
> >   */
> > typedef void (*wifi_direct_device_state_changed_cb) (int error_code,
> > 				wifi_direct_device_state_e device_state,
> > 				void *user_data);
> 
> You mean the technology here, since you don't have any access to any "device".
> Just remove "device" from the name.
> 
OK, we will remove "device" from the name.
> >
> /****************************************************************
> **************
> >   * Notification callback function type
> >   * Connection notification can occurs at WiFi Direct connection state
> changed
> >   *
> >   */
> > typedef void (*wifi_direct_connection_state_changed_cb) (int error_code,
> > 				wifi_direct_connection_state_e connection_state,
> > 				wifi_direct_peer_info_s *peer, void *user_data);
> >
> >
> /****************************************************************
> **************
> >   * 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);
> >
> >
> /****************************************************************
> **************
> >   * 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);
> 
> 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.

> > /* 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);
> >
> >
> /****************************************************************
> **************
> >   * This API shall register the activation callback function to monitor WiFi
> >   * Direct state.
> >   *
> >   */
> > int wifi_direct_set_device_state_changed_cb(
> > 				wifi_direct_device_state_changed_cb cb,
> > 				void *user_data);
> >
> >
> /****************************************************************
> **************
> >   * This API shall unregister the activation callback function.
> >   *
> >   *
> >   */
> > 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.

> >
> /****************************************************************
> **************
> >   * This API shall register the connection callback function to monitor WiFi
> >   * Direct connection state.
> >   *
> >   */
> > int wifi_direct_set_connection_state_changed_cb(
> > 				wifi_direct_connection_state_changed_cb cb,
> > 				void *user_data);
> >
> >
> /****************************************************************
> **************
> >   * This API shall unregister the connection callback function.
> >   *
> >   *
> >   */
> > int wifi_direct_unset_connection_state_changed_cb(void);
> 
> Same here.
> 
> >
> /****************************************************************
> **************
> >   * 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);
> 
> Same here
> 
> >
> /****************************************************************
> **************
> >   * 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 the incoming connection callback function.
> >   *
> >   *
> >   */
> > int wifi_direct_unset_incoming_connection_cb(void);
> 
> Same here.
> 
> >
> >
> /****************************************************************
> **************
> >   * This API shall get all the peers, and invoke the callback with the peers
> >   * as a parameters.
> >   *
> >   */
> > int wifi_direct_foreach_discovered_peers(wifi_direct_discovered_peer_cb cb,
> > 				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_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. :)
> >
> >
> /****************************************************************
> **************
> >   * This API shall activate WiFi direct
> >   *
> >   *
> >   */
> > int wifi_direct_activate(void);
> >
> >
> /****************************************************************
> **************
> >   * This API shall deactivate WiFi direct
> >   *
> >   *
> >   */
> > int wifi_direct_deactivate(void);
> 
> See, here you did not put "device" which is the way to go ;)
> 
OK :)
> >
> >
> /****************************************************************
> **************
> >   * 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 mothod.
> >   * 2 Accept a P2P incoming request with PBC mothod.
> s/mothod/method
> 
Sure, thanks!
> >   * 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);
> 
> 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.

> >
> /****************************************************************
> **************
> >   * 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);
> >
> >
> /****************************************************************
> **************
> >   * 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 device.
> 
> Remove "with local device". It's P2P so it's with local device.
> 
what I mean here is "local side", I will update it.

> >   *
> >   *
> >   */
> > int wifi_direct_disconnect_all(void);
> >
> >
> /****************************************************************
> **************
> >   * This API shall set local device name
> >   *
> >   *
> >   */
> > 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.

> >
> >
> /****************************************************************
> **************
> >   * This API shall get local device name
> >   *
> >   *
> >   */
> > int wifi_direct_get_device_name(char **device_name);
> 
> Remove it as well. App should get the hostname.
> 
Same as above.
> >
> /****************************************************************
> **************
> >   * This API shall set local device category
> >   *
> >   *
> >   */
> > int wifi_direct_set_category(wifi_direct_category_e category);
> >
> >
> /****************************************************************
> **************
> >   * This API shall get local device category
> >   *
> >   *
> >   */
> 
> Remove those both. The device category is something related to system
> configuration and integration.
> No app will ever need to set this, and getting it either won't help much for
> anything.
> 
Agree, we will delete it.

> > int wifi_direct_get_category(wifi_direct_category_e *category);
> >
> >
> /****************************************************************
> **************
> >   * This API shall get local device state
> 
> No device word here, just the state.
> 
Agree, we will update it.

> >   *
> >   *
> >   */
> > 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.
> >
> /****************************************************************
> **************
> >   * This API shall get local device connection state
> >   *
> >   *
> >   */
> > int
> > wifi_direct_get_device_connect_state(wifi_direct_connection_state_e
> > *state);
> 
> Same issue with signature.
> Btw, you get the technology state here, but is it that important? Isn't it better
> for the app to get the peer list as usual and check the state. I don't see a use
> case currently where an app would be happy just to know p2p tech is connected,
> without knowing to which peer.
> Just wondering.
> 
We will check whether we can remove it.

> >
> >
> /****************************************************************
> **************
> >   * This API shall register a WiFi Direct service
> >   *
> >   *
> >   */
> > 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>.
> >
> >
> /****************************************************************
> **************
> >   * This API shall unregister a WiFi Direct service
> >   *
> >   *
> >   */
> > int wifi_direct_service_del(wifi_direct_service_type_e type, char *data1,
> > 				char *data2);
> 
> Same here
> 
Same as above.

> >
> >
> /****************************************************************
> **************
> >   * 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);
> 
> 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?

> 
> Tomasz
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: wifi-direct.h
URL: <http://lists.tizen.org/pipermail/dev/attachments/20140714/bfb68a64/attachment-0001.h>


More information about the Dev mailing list