* [PATCH BlueZ 4/9] android/hal-ipc-api: Add Get Player Attributes Response
From: Luiz Augusto von Dentz @ 2014-02-12 14:48 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392216494-30885-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
android/hal-ipc-api.txt | 12 +++++++++++-
android/hal-msg.h | 11 +++++++++++
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index 2e4ecbe..27060d5 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -1224,7 +1224,17 @@ Android HAL name: "avrcp" (BT_PROFILE_AV_RC_ID)
In case of an error, the error response will be returned.
- Opcode 0x04 - Get Player Application Values command/response
+ Opcode 0x04 - Get Player Values Response command/response
+
+ Command parameters: Number of attributes (1 octet)
+ Attribute # (1 octet)
+ Value # (1 octet)
+ ...
+
+ In case of an error, the error response will be returned.
+
+ Valid attributes: Same as in List Player Attributes
+
Opcode 0x05 - Get Player Application Attributes Text command/response
Opcode 0x06 - Get Player Application Values Text command/response
Opcode 0x07 - Get Element Attributes Text command/response
diff --git a/android/hal-msg.h b/android/hal-msg.h
index 2dcdafc..753f5a3 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -816,3 +816,14 @@ struct hal_cmd_avrcp_list_player_values {
uint8_t number;
uint8_t values[0];
} __attribute__((packed));
+
+struct hal_avrcp_player_attr_value {
+ uint8_t attr;
+ uint8_t value;
+} __attribute__((packed));
+
+#define HAL_OP_AVRCP_GET_PLAYER_ATTRS 0x04
+struct hal_cmd_avrcp_get_player_attrs {
+ uint8_t number;
+ struct hal_avrcp_player_attr_value attrs[0];
+} __attribute__((packed));
--
1.8.5.3
^ permalink raw reply related
* [PATCH BlueZ 5/9] android/hal-ipc-api: Add Get Player Attributes Text Response
From: Luiz Augusto von Dentz @ 2014-02-12 14:48 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392216494-30885-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
android/hal-ipc-api.txt | 13 ++++++++++++-
android/hal-msg.h | 11 +++++++++++
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index 27060d5..496851c 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -1235,7 +1235,18 @@ Android HAL name: "avrcp" (BT_PROFILE_AV_RC_ID)
Valid attributes: Same as in List Player Attributes
- Opcode 0x05 - Get Player Application Attributes Text command/response
+ Opcode 0x05 - Get Player Attributes Text Response command/response
+
+ Command parameters: Number of attributes (1 octet)
+ Attribute # (1 octet)
+ Attribute # text length (1 octet)
+ Attribute # text (variable)
+ ...
+
+ In case of an error, the error response will be returned.
+
+ Valid attributes: Same as in List Player Attributes
+
Opcode 0x06 - Get Player Application Values Text command/response
Opcode 0x07 - Get Element Attributes Text command/response
Opcode 0x08 - Set Player Attributes Value command/response
diff --git a/android/hal-msg.h b/android/hal-msg.h
index 753f5a3..2891a3a 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -827,3 +827,14 @@ struct hal_cmd_avrcp_get_player_attrs {
uint8_t number;
struct hal_avrcp_player_attr_value attrs[0];
} __attribute__((packed));
+
+struct hal_avrcp_player_setting_text {
+ uint8_t id;
+ uint8_t text[255];
+} __attribute__((packed));
+
+#define HAL_OP_AVRCP_GET_PLAYER_ATTRS_TEXT 0x05
+struct hal_cmd_avrcp_get_player_attrs_text {
+ uint8_t number;
+ struct hal_avrcp_player_setting_text attrs[0];
+} __attribute__((packed));
--
1.8.5.3
^ permalink raw reply related
* [PATCH BlueZ 6/9] android/hal-ipc-api: Add Get Player Values Text Response
From: Luiz Augusto von Dentz @ 2014-02-12 14:48 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392216494-30885-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
android/hal-ipc-api.txt | 10 +++++++++-
android/hal-msg.h | 6 ++++++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index 496851c..c8f5557 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -1247,7 +1247,15 @@ Android HAL name: "avrcp" (BT_PROFILE_AV_RC_ID)
Valid attributes: Same as in List Player Attributes
- Opcode 0x06 - Get Player Application Values Text command/response
+ Opcode 0x06 - Get Player Values Text Response command/response
+
+ Command parameters: Number of values (1 octet)
+ Value # (1 octet)
+ Value # text (255 octets)
+ ...
+
+ In case of an error, the error response will be returned.
+
Opcode 0x07 - Get Element Attributes Text command/response
Opcode 0x08 - Set Player Attributes Value command/response
Opcode 0x09 - Register Notification command/response
diff --git a/android/hal-msg.h b/android/hal-msg.h
index 2891a3a..280c28c 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -838,3 +838,9 @@ struct hal_cmd_avrcp_get_player_attrs_text {
uint8_t number;
struct hal_avrcp_player_setting_text attrs[0];
} __attribute__((packed));
+
+#define HAL_OP_AVRCP_GET_PLAYER_VALUES_TEXT 0x06
+struct hal_cmd_avrcp_get_player_values_text {
+ uint8_t number;
+ struct hal_avrcp_player_setting_text values[0];
+} __attribute__((packed));
--
1.8.5.3
^ permalink raw reply related
* [PATCH BlueZ 7/9] android/hal-ipc-api: Add Get Element Attributes Text Response
From: Luiz Augusto von Dentz @ 2014-02-12 14:48 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392216494-30885-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
android/hal-ipc-api.txt | 19 +++++++++++++++++--
android/hal-msg.h | 14 ++++++++++++++
2 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index c8f5557..7c90928 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -1256,8 +1256,23 @@ Android HAL name: "avrcp" (BT_PROFILE_AV_RC_ID)
In case of an error, the error response will be returned.
- Opcode 0x07 - Get Element Attributes Text command/response
- Opcode 0x08 - Set Player Attributes Value command/response
+ Opcode 0x07 - Get Element Attributes Text Response command/response
+
+ Command parameters: Number of elements (1 octet)
+ Element # (1 octet)
+ Element # text (255 octets)
+ ...
+
+ In case of an error, the error response will be returned.
+
+ Valid elements: 0x01 = Title
+ 0x02 = Artist
+ 0x03 = Album
+ 0x04 = Track Number
+ 0x05 = Number of Tracks
+ 0x06 = Genre
+ 0x06 = Duration
+
Opcode 0x09 - Register Notification command/response
Opcode 0x81 - Get Play Status notification
diff --git a/android/hal-msg.h b/android/hal-msg.h
index 280c28c..9f3c2a1 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -844,3 +844,17 @@ struct hal_cmd_avrcp_get_player_values_text {
uint8_t number;
struct hal_avrcp_player_setting_text values[0];
} __attribute__((packed));
+
+#define HAL_AVRCP_MEDIA_ATTR_TITLE 0x01
+#define HAL_AVRCP_MEDIA_ATTR_ARTIST 0x02
+#define HAL_AVRCP_MEDIA_ATTR_ALBUM 0x03
+#define HAL_AVRCP_MEDIA_ATTR_TRACK_NUM 0x04
+#define HAL_AVRCP_MEDIA_ATTR_NUM_TRACKS 0x05
+#define HAL_AVRCP_MEDIA_ATTR_GENRE 0x06
+#define HAL_AVRCP_MEDIA_ATTR_DURATION 0x07
+
+#define HAL_OP_AVRCP_GET_ELEMENT_ATTRS_TEXT 0x07
+struct hal_cmd_avrcp_get_element_attrs_text {
+ uint8_t number;
+ struct hal_avrcp_player_setting_text values[0];
+} __attribute__((packed));
--
1.8.5.3
^ permalink raw reply related
* [PATCH BlueZ 8/9] android/hal-ipc-api: Add Set Player Attributes Value Response
From: Luiz Augusto von Dentz @ 2014-02-12 14:48 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392216494-30885-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
android/hal-ipc-api.txt | 8 ++++++++
android/hal-msg.h | 5 +++++
2 files changed, 13 insertions(+)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index 7c90928..b977957 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -1273,6 +1273,14 @@ Android HAL name: "avrcp" (BT_PROFILE_AV_RC_ID)
0x06 = Genre
0x06 = Duration
+ Opcode 0x08 - Set Player Attributes Value Response command/response
+
+ Command parameters: Status (1 octet)
+
+ In case of an error, the error response will be returned.
+
+ Valid status values: Same as in Get Play Status Response
+
Opcode 0x09 - Register Notification command/response
Opcode 0x81 - Get Play Status notification
diff --git a/android/hal-msg.h b/android/hal-msg.h
index 9f3c2a1..42b08cd 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -858,3 +858,8 @@ struct hal_cmd_avrcp_get_element_attrs_text {
uint8_t number;
struct hal_avrcp_player_setting_text values[0];
} __attribute__((packed));
+
+#define HAL_OP_AVRCP_SET_PLAYER_ATTRS_VALUE 0x08
+struct hal_cmd_avrcp_set_player_attrs_value {
+ uint8_t status;
+} __attribute__((packed));
--
1.8.5.3
^ permalink raw reply related
* [PATCH BlueZ 9/9] android/hal-ipc-api: Add Register Notification Response
From: Luiz Augusto von Dentz @ 2014-02-12 14:48 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392216494-30885-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
android/hal-ipc-api.txt | 19 ++++++++++++++++++-
android/hal-msg.h | 18 ++++++++++++++++++
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index b977957..c1609c9 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -1281,7 +1281,24 @@ Android HAL name: "avrcp" (BT_PROFILE_AV_RC_ID)
Valid status values: Same as in Get Play Status Response
- Opcode 0x09 - Register Notification command/response
+ Opcode 0x09 - Register Notification Response command/response
+
+ Command parameters: Event (1 octet)
+ Type (1 octet)
+ Data length (1 octet)
+ Data (variable)
+
+ In case of an error, the error response will be returned.
+
+ Valid event values: 0x01 = Status Changed
+ 0x02 = Track Changed
+ 0x03 = Track Reached End
+ 0x04 = Track Reached Start
+ 0x05 = Position Changed
+ 0x08 = Setting Changed
+
+ Valid type values : 0x00 = Interim
+ 0x01 = Changed
Opcode 0x81 - Get Play Status notification
Opcode 0x82 - List Player Application Attributes notification
diff --git a/android/hal-msg.h b/android/hal-msg.h
index 42b08cd..ca1f6b5 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -863,3 +863,21 @@ struct hal_cmd_avrcp_get_element_attrs_text {
struct hal_cmd_avrcp_set_player_attrs_value {
uint8_t status;
} __attribute__((packed));
+
+#define HAL_AVRCP_EVENT_STATUS_CHANGED 0x01
+#define HAL_AVRCP_EVENT_TRACK_CHANGED 0x02
+#define HAL_AVRCP_EVENT_TRACK_REACHED_END 0x03
+#define HAL_AVRCP_EVENT_TRACK_REACHED_START 0x04
+#define HAL_AVRCP_EVENT_POSITION_CHANGED 0x05
+#define HAL_AVRCP_EVENT_SETTING_CHANGED 0x08
+
+#define HAL_AVRCP_EVENT_TYPE_INTERIM 0x00
+#define HAL_AVRCP_EVENT_TYPE_CHANGED 0x01
+
+#define HAL_OP_AVRCP_REGISTER_NOTIFICATION 0x09
+struct hal_cmd_avrcp_register_notification {
+ uint8_t event;
+ uint8_t type;
+ uint8_t len;
+ uint8_t data[0];
+} __attribute__((packed));
--
1.8.5.3
^ permalink raw reply related
* Re: [PATCH BlueZ 1/9] android/hal-ipc-api: Add Get Play Status Response
From: Szymon Janc @ 2014-02-12 18:29 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1392216494-30885-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Wednesday 12 of February 2014 16:48:06 Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>
> ---
> android/hal-ipc-api.txt | 30 +++++++++++++++++++++++++++++-
> android/hal-msg.h | 16 ++++++++++++++++
> 2 files changed, 45 insertions(+), 1 deletion(-)
>
> diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
> index ad5d192..01c2e81 100644
> --- a/android/hal-ipc-api.txt
> +++ b/android/hal-ipc-api.txt
> @@ -1174,7 +1174,35 @@ Bluetooth Remote Control HAL (ID 8)
> Android HAL name: "avrcp" (BT_PROFILE_AV_RC_ID)
>
> Opcode 0x00 - Error response
> - Opcode 0x01 - Get Play Status command/response
> +
> + Response parameters: Status (1 octet)
> +
> + Valid status values: 0x01 = Fail
> + 0x02 = Not ready
> + 0x03 = No memory
> + 0x04 = Busy
> + 0x05 = Done (already completed)
> + 0x06 = Unsupported
> + 0x07 = Parameter invalid
> + 0x08 = Unhandled
> + 0x09 = Authentication failure
> + 0x0a = Remote device down
> +
> + Opcode 0x01 - Get Play Status Response command/response
> +
> + Command parameters: Status (1 octet)
> + Duration (4 octets)
> + Position (4 octets)
> +
> + In case of an error, the error response will be returned.
> +
> + Valid status values: 0x00 = Stopped
> + 0x01 = Playing
> + 0x02 = Paused
> + 0x03 = Fwd seek
> + 0x04 = Rev seek
> + 0xff = Error
> +
> Opcode 0x02 - List Player Application Attributes command/response
> Opcode 0x03 - List Player Application Values command/response
> Opcode 0x04 - Get Player Application Values command/response
> diff --git a/android/hal-msg.h b/android/hal-msg.h
> index 6ef00f9..82cd3f5 100644
> --- a/android/hal-msg.h
> +++ b/android/hal-msg.h
> @@ -783,3 +783,19 @@ struct hal_ev_handsfree_unknown_at {
> } __attribute__((packed));
>
> #define HAL_EV_HANDSFREE_HSP_KEY_PRESS 0x90
> +
> +/* AVRCP HAL API */
> +
> +#define HAL_AVRCP_PLAY_STATUS_STOPPED 0x00
> +#define HAL_AVRCP_PLAY_STATUS_PLAYING 0x01
> +#define HAL_AVRCP_PLAY_STATUS_PAUSED 0x02
> +#define HAL_AVRCP_PLAY_STATUS_FWD_SEEK 0x03
> +#define HAL_AVRCP_PLAY_STATUS_REV_SEEK 0x04
> +#define HAL_AVRCP_PLAY_STATUS_ERROR 0xff
> +
> +#define HAL_OP_AVRCP_GET_PLAY_STATUS 0x01
> +struct hal_cmd_avrcp_get_play_status {
> + uint8_t status;
> + uint32_t duration;
> + uint32_t position;
> +} __attribute__((packed));
All patches in this set have been applied, thanks.
--
BR
Szymon Janc
^ permalink raw reply
* Re: [PATCH 4/6] shared: Add support for shutdown to IO
From: Szymon Janc @ 2014-02-12 18:38 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: bluez mailin list (linux-bluetooth@vger.kernel.org)
In-Reply-To: <301FB290-56A1-404A-9A79-62F360D9DA9A@holtmann.org>
Hi Marcel,
On Tuesday 11 of February 2014 09:02:15 Marcel Holtmann wrote:
> Hi Szymon,
>
> > This allows to locally shutdown IO.
> > ---
> > src/shared/io-glib.c | 9 +++++++++
> > src/shared/io-mainloop.c | 9 +++++++++
> > src/shared/io.h | 2 ++
> > 3 files changed, 20 insertions(+)
> >
> > diff --git a/src/shared/io-glib.c b/src/shared/io-glib.c
> > index a4f982d..8290745 100644
> > --- a/src/shared/io-glib.c
> > +++ b/src/shared/io-glib.c
> >
> > @@ -320,3 +320,12 @@ done:
> > return true;
> >
> > }
> > +
> > +bool io_shutdown(struct io *io)
> > +{
> > + if (!io || !io->channel)
> > + return false;
> > +
> > + return g_io_channel_shutdown(io->channel, TRUE, NULL)
> > + == G_IO_STATUS_NORMAL;
> > +}
> > diff --git a/src/shared/io-mainloop.c b/src/shared/io-mainloop.c
> > index 14ab128..f1e3b3b 100644
> > --- a/src/shared/io-mainloop.c
> > +++ b/src/shared/io-mainloop.c
> > @@ -26,6 +26,7 @@
> > #endif
> >
> > #include <unistd.h>
> > +#include <sys/socket.h>
> >
> > #include "monitor/mainloop.h"
> > #include "src/shared/util.h"
> > @@ -294,3 +295,11 @@ bool io_set_disconnect_handler(struct io *io,
> > io_callback_func_t callback,>
> > return true;
> >
> > }
> > +
> > +bool io_shutdown(struct io *io)
> > +{
> > + if (!io || io->fd < 0)
> > + return false;
> > +
> > + return shutdown(io->fd, SHUT_RDWR) == 0;
> > +}
>
> I have no problem doing this, but why is this actually needed? Is not
> closing the socket good enough? Or would be better also add a
> shutdown_on_unref option?
This is to allow to read from the socket in case there is some data already
received (FWIW). I also plan to add 'flush' or similar flag to it to allow
graceful disconnect i.e. make something like this work as expected
hfp_gw_send_result(device.gw, HFP_RESULT_ERROR);
hfp_gw_disconnect(device.gw);
but this can be added later on if needed and we could go with close() for now
as you suggested.
--
BR
Szymon Janc
^ permalink raw reply
* Re: [PATCH 3/6] shared: Add support for disconnect handler in HFP
From: Szymon Janc @ 2014-02-12 18:40 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: bluez mailin list (linux-bluetooth@vger.kernel.org)
In-Reply-To: <FB263FEA-C682-448B-9DE4-D289CDDBDB5C@holtmann.org>
Hi Marcel,
On Tuesday 11 of February 2014 09:00:27 Marcel Holtmann wrote:
> Hi Szymon,
>
> > It is no longer possible to send any data after disconnection.
> > Extra reference is taken for disconnect watch to allow users to drop
> > own reference in disconnect callback.
>
> I am not sure that is the best way to do it. I get the feeling that we might
> better have an internal bool that is tracking if we are
> connected/disconnected. Thoughts?
You mean don't have a public HFP disconnect handler and just fail on write()
or use bool instead of io pointer for state tracking?
--
BR
Szymon Janc
^ permalink raw reply
* Re: [PATCH 1/6] shared: Add support for disonnect handler to GLib based IO handling
From: Szymon Janc @ 2014-02-12 18:42 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: bluez mailin list (linux-bluetooth@vger.kernel.org)
In-Reply-To: <D4957F12-AE54-43F2-A9EE-859676DE055E@holtmann.org>
Hi Marcel,
On Tuesday 11 of February 2014 08:57:25 Marcel Holtmann wrote:
> Hi Szymon,
>
> > ---
> > src/shared/io-glib.c | 59
> > +++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 58
> > insertions(+), 1 deletion(-)
> >
> > diff --git a/src/shared/io-glib.c b/src/shared/io-glib.c
> > index 77ba19e..a4f982d 100644
> > --- a/src/shared/io-glib.c
> > +++ b/src/shared/io-glib.c
> > @@ -40,6 +40,10 @@ struct io {
> >
> > io_callback_func_t write_callback;
> > io_destroy_func_t write_destroy;
> > void *write_data;
> >
> > + guint disconnect_watch;
> > + io_callback_func_t disconnect_callback;
> > + io_destroy_func_t disconnect_destroy;
> > + void *disconnect_data;
> > };
> >
> > static struct io *io_ref(struct io *io)
> >
> > @@ -258,8 +262,61 @@ done:
> > return true;
> >
> > }
> >
> > +static void disconnect_watch_destroy(gpointer user_data)
> > +{
> > + struct io *io = user_data;
> > +
> > + if (io->disconnect_destroy)
> > + io->disconnect_destroy(io->disconnect_data);
> > +
> > + io->disconnect_watch = 0;
> > + io->disconnect_callback = NULL;
> > + io->disconnect_destroy = NULL;
> > + io->disconnect_data = NULL;
> > +
> > + io_unref(io);
> > +}
> > +
> > +static gboolean disconnect_callback(GIOChannel *channel, GIOCondition
> > cond, + gpointer user_data)
> > +{
> > + struct io *io = user_data;
> > + bool result;
> > +
> > + if (io->disconnect_callback)
> > + result = io->disconnect_callback(io, io->disconnect_data);
> > + else
> > + result = false;
> > +
> > + return result ? TRUE : FALSE;
> > +}
> > +
> > bool io_set_disconnect_handler(struct io *io, io_callback_func_t callback,
> >
> > void *user_data, io_destroy_func_t destroy)
> >
> > {
> > - return false;
> > + if (!io)
> > + return false;
> > +
> > + if (io->disconnect_watch > 0) {
> > + g_source_remove(io->disconnect_watch);
> > + io->disconnect_watch = 0;
> > + }
> > +
> > + if (!callback)
> > + goto done;
> > +
> > + io->disconnect_watch = g_io_add_watch_full(io->channel,
> > + G_PRIORITY_DEFAULT,
> > + G_IO_HUP | G_IO_ERR | G_IO_NVAL,
>
> If we are using G_IO_HUP here, we should remove it from the other callback
> handling?
We should, will fix that in next version.
> > + disconnect_callback, io_ref(io),
> > + disconnect_watch_destroy);
> > + if (io->disconnect_watch == 0)
> > + return false;
> > +
> > + io->disconnect_destroy = destroy;
> > + io->disconnect_data = user_data;
>
> we normally have an extra empty line here. You might also fix the previous
> patch then.
I'll fix that as well.
> > +done:
> > + io->disconnect_callback = callback;
> > +
> > + return true;
> > }
--
BR
Szymon Janc
^ permalink raw reply
* Re: [PATCH 4/6] shared: Add support for shutdown to IO
From: Marcel Holtmann @ 2014-02-12 18:45 UTC (permalink / raw)
To: Szymon Janc; +Cc: bluez mailin list (linux-bluetooth@vger.kernel.org)
In-Reply-To: <4170119.cK3WpejJYp@leonov>
Hi Szymon,
>>> This allows to locally shutdown IO.
>>> ---
>>> src/shared/io-glib.c | 9 +++++++++
>>> src/shared/io-mainloop.c | 9 +++++++++
>>> src/shared/io.h | 2 ++
>>> 3 files changed, 20 insertions(+)
>>>
>>> diff --git a/src/shared/io-glib.c b/src/shared/io-glib.c
>>> index a4f982d..8290745 100644
>>> --- a/src/shared/io-glib.c
>>> +++ b/src/shared/io-glib.c
>>>
>>> @@ -320,3 +320,12 @@ done:
>>> return true;
>>>
>>> }
>>> +
>>> +bool io_shutdown(struct io *io)
>>> +{
>>> + if (!io || !io->channel)
>>> + return false;
>>> +
>>> + return g_io_channel_shutdown(io->channel, TRUE, NULL)
>>> + == G_IO_STATUS_NORMAL;
>>> +}
>>> diff --git a/src/shared/io-mainloop.c b/src/shared/io-mainloop.c
>>> index 14ab128..f1e3b3b 100644
>>> --- a/src/shared/io-mainloop.c
>>> +++ b/src/shared/io-mainloop.c
>>> @@ -26,6 +26,7 @@
>>> #endif
>>>
>>> #include <unistd.h>
>>> +#include <sys/socket.h>
>>>
>>> #include "monitor/mainloop.h"
>>> #include "src/shared/util.h"
>>> @@ -294,3 +295,11 @@ bool io_set_disconnect_handler(struct io *io,
>>> io_callback_func_t callback,>
>>> return true;
>>>
>>> }
>>> +
>>> +bool io_shutdown(struct io *io)
>>> +{
>>> + if (!io || io->fd < 0)
>>> + return false;
>>> +
>>> + return shutdown(io->fd, SHUT_RDWR) == 0;
>>> +}
>>
>> I have no problem doing this, but why is this actually needed? Is not
>> closing the socket good enough? Or would be better also add a
>> shutdown_on_unref option?
>
> This is to allow to read from the socket in case there is some data already
> received (FWIW). I also plan to add 'flush' or similar flag to it to allow
> graceful disconnect i.e. make something like this work as expected
>
> hfp_gw_send_result(device.gw, HFP_RESULT_ERROR);
> hfp_gw_disconnect(device.gw);
>
> but this can be added later on if needed and we could go with close() for now
> as you suggested.
then lets just go with io_shutdown() for now. We can change this at any time once we know what other users really need. In the long run I want everything in android/ use the IO framework.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 3/6] shared: Add support for disconnect handler in HFP
From: Marcel Holtmann @ 2014-02-12 18:47 UTC (permalink / raw)
To: Szymon Janc; +Cc: bluez mailin list (linux-bluetooth@vger.kernel.org)
In-Reply-To: <92817127.UgR6P4lKdQ@leonov>
Hi Szymon,
>>> It is no longer possible to send any data after disconnection.
>>> Extra reference is taken for disconnect watch to allow users to drop
>>> own reference in disconnect callback.
>>
>> I am not sure that is the best way to do it. I get the feeling that we might
>> better have an internal bool that is tracking if we are
>> connected/disconnected. Thoughts?
>
> You mean don't have a public HFP disconnect handler and just fail on write()
> or use bool instead of io pointer for state tracking?
we should still have a disconnect handler. However we should not take these extra reference and have these extra checks for something.
I rather see us tracking the actual state of the IO and not trying to reference count our way into something insane. It is dangerous to have to many indirect reference counts.
Regards
Marcel
^ permalink raw reply
* [PATCH BlueZ] android/test-ipc: Use correct boolean values for glib functions
From: Anderson Lizardo @ 2014-02-12 19:13 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
---
android/test-ipc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/android/test-ipc.c b/android/test-ipc.c
index 3a0729e..2def97b 100644
--- a/android/test-ipc.c
+++ b/android/test-ipc.c
@@ -263,8 +263,8 @@ static void execute_context(struct context *context)
{
g_main_loop_run(context->main_loop);
- g_io_channel_shutdown(context->notif_io, true, NULL);
- g_io_channel_shutdown(context->cmd_io, true, NULL);
+ g_io_channel_shutdown(context->notif_io, TRUE, NULL);
+ g_io_channel_shutdown(context->cmd_io, TRUE, NULL);
g_io_channel_unref(context->cmd_io);
g_io_channel_unref(context->notif_io);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH BlueZ] android/test-ipc: Use correct boolean values for glib functions
From: Szymon Janc @ 2014-02-12 19:21 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <1392232401-26119-1-git-send-email-anderson.lizardo@openbossa.org>
Hi Anderson,
On Wednesday 12 of February 2014 15:13:21 Anderson Lizardo wrote:
> ---
> android/test-ipc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/android/test-ipc.c b/android/test-ipc.c
> index 3a0729e..2def97b 100644
> --- a/android/test-ipc.c
> +++ b/android/test-ipc.c
> @@ -263,8 +263,8 @@ static void execute_context(struct context *context)
> {
> g_main_loop_run(context->main_loop);
>
> - g_io_channel_shutdown(context->notif_io, true, NULL);
> - g_io_channel_shutdown(context->cmd_io, true, NULL);
> + g_io_channel_shutdown(context->notif_io, TRUE, NULL);
> + g_io_channel_shutdown(context->cmd_io, TRUE, NULL);
> g_io_channel_unref(context->cmd_io);
> g_io_channel_unref(context->notif_io);
Applied, thanks.
--
BR
Szymon Janc
^ permalink raw reply
* [PATCH] android/README: Add note on libglib under Valgrind
From: Andrzej Kaczmarek @ 2014-02-12 19:23 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Andrzej Kaczmarek
---
android/README | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/android/README b/android/README
index 75b0a83..3095383 100644
--- a/android/README
+++ b/android/README
@@ -124,6 +124,12 @@ After changing property value Bluetooth need to be restarted to apply changes
(this can be done using UI, just disable and enable it again). Property is
persistent, i.e. there's no need to enable Valgrind again after reboot.
+It's recommended to have unstripped libglib.so installed which will enable
+complete backtraces in Valgrind output. Otherwise, in many cases backtrace
+will break at e.g. g_free() function without prior callers. It's possible to
+have proper library installed automatically by appropriate entry in Android.mk,
+see https://code.google.com/p/aosp-bluez.glib/ for an example.
+
=============================
Building and running on Linux
=============================
--
1.8.5.4
^ permalink raw reply related
* partial success with PS3 sixaxis
From: Andrea @ 2014-02-12 21:31 UTC (permalink / raw)
To: linux-bluetooth
Hi,
I've been trying to pair a PS3 sixaxis controller using bluez 5.14
I've had so far only partial success.
It connects, creates js0 and event0 devices, but after a few seconds it removes them.
The lights are always flashing.
I am on a Raspberry running ArchLinux.
This is the output of bluetoothctl
...
[bluetooth]# disconnect
[CHG] Device 00:0B:EB:63:F2:62 Connected: yes
[bluetooth]# disconnect show
[bluetooth]# disconnect 00:0B:EB:63:F2:62
Attempting to disconnect from 00:0B:EB:63:F2:62
Successful disconnected
[CHG] Device 00:0B:EB:63:F2:62 Connected: no
[CHG] Device 00:0B:EB:63:F2:62 Connected: yes
then in dmesg I can see
[ 2745.435967] sony 0005:054C:0268.0008: Fixing up Sony Sixaxis report descriptor
[ 2745.452105] sony 0005:054C:0268.0008: unknown main item tag 0x0
[ 2745.471504] input: PLAYSTATION(R)3 Controller as
/devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.0/bluetooth/hci0/hci0:11/input7
[ 2745.472795] sony 0005:054C:0268.0008: input,hidraw0: BLUETOOTH HID v1.00 Joystick
[PLAYSTATION(R)3 Controller] on 00:0b:0d:4c:94:a6
[ 2755.472242] sony: probe of 0005:054C:0268.0008 failed with error -5
the hardware should be ok as it works using sixad & sixpair.
any idea what could be going wrong?
I am not even sure if I am doing the right thing to pair, trust, connect etc... as I cannot google
anything using bluez 5 + ps3. All the howtos are for sixad.
Andrea
^ permalink raw reply
* Re: [PATCH 00/24] rfcomm fixes
From: Marcel Holtmann @ 2014-02-12 22:58 UTC (permalink / raw)
To: Peter Hurley
Cc: Gustavo F. Padovan, Johan Hedberg, Gianluca Anzolin,
Alexander Holler, Andrey Vihrov, Sander Eikelenboom,
bluez mailin list (linux-bluetooth@vger.kernel.org), linux-kernel
In-Reply-To: <52F95A10.5010507@hurleysoftware.com>
Hi Peter,
>>> This patch series addresses a number of previously unknown issues
>>> with the RFCOMM tty device implementation, in addition to
>>> addressing the locking regression recently reported [1].
>>>
>>> As Gianluca suggested and I agree, this series first reverts
>>> 3 of the 4 patches of 3.14-rc1 for bluetooth/rfcomm/tty.c.
>>
>> so for 3.14 we should revert 3 patches. And then the other 21 are
> > intended for 3.15 merge window.
>
> Yep, this is probably best. At least 3.13 & 3.14 will behave the
> same wrt rfcomm.
>
>> I realize that we still have to deal with some breakage, but we
> > do not want regressions and I clearly not going to take 24 patches
> > for 3.14 at this point in time.
>
> Yeah, I wasn't expecting you to.
>
>> What I can do is take all 24 patches into bluetooth-next and let
> > them sit for 1 week and have people test them. And then we go ahead
> > with reverting 3 patches from 3.14. Does that make sense?
>
> Yep, that's fine with me. Thanks.
we might also want to add some end-to-end test cases to rfcomm-tester that covers this behavior.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix channel check when binding RFCOMM sock
From: Marcel Holtmann @ 2014-02-12 23:01 UTC (permalink / raw)
To: Andrzej Kaczmarek; +Cc: bluez mailin list (linux-bluetooth@vger.kernel.org)
In-Reply-To: <CAF3PWx0PkL8fQ2ypsU24xM1HveQAia19OFDLcX9D=90_Oo9Vig@mail.gmail.com>
Hi Andrzej,
>>> When binding RFCOMM socket we should only check if there is another
>>> socket bound or listening on the same channel number. In other case,
>>> it won't be possible to bind/listen on a channel in case we have
>>> connection made to remote device on the same channel number.
>>
>> since this has been used for years now, you need to be more specific on when this fails.
>
> It's quite simple: create one socket and connect on channel X, then
> create another socket and try to bind on channel X. Event though we
> don't have listening socket on channel X yet, it will fail with
> EADDRINUSE since rfcomm_sock_bind looks for *any* socket on specified
> channel and doesn't care if it's bound/listening on local channel or
> just connected to remote channel (in which case it should not fail).
>
> Is it specific enough?
can we add a test case to rfcomm-tester for this first.
>>> Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
>>> ---
>>> net/bluetooth/rfcomm/sock.c | 5 ++++-
>>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
>>> index 00573fb..9912e23 100644
>>> --- a/net/bluetooth/rfcomm/sock.c
>>> +++ b/net/bluetooth/rfcomm/sock.c
>>> @@ -331,6 +331,7 @@ static int rfcomm_sock_bind(struct socket *sock, struct sockaddr *addr, int addr
>>> {
>>> struct sockaddr_rc *sa = (struct sockaddr_rc *) addr;
>>> struct sock *sk = sock->sk;
>>> + struct sock *sk1;
>>> int err = 0;
>>>
>>> BT_DBG("sk %p %pMR", sk, &sa->rc_bdaddr);
>>> @@ -352,7 +353,9 @@ static int rfcomm_sock_bind(struct socket *sock, struct sockaddr *addr, int addr
>>>
>>> write_lock(&rfcomm_sk_list.lock);
>>>
>>> - if (sa->rc_channel && __rfcomm_get_sock_by_addr(sa->rc_channel, &sa->rc_bdaddr)) {
>>> + sk1 = __rfcomm_get_sock_by_addr(sa->rc_channel, &sa->rc_bdaddr);
>>> + if (sa->rc_channel && sk1 && (sk1->sk_state == BT_BOUND ||
>>> + sk1->sk_state == BT_LISTEN)) {
>>> err = -EADDRINUSE;
>>
>> can we find a better name than sk1 here.
>
> Something like 'existing_sk'? Or just 'oldsk'? I have no clue how to
> make a meaningful name here.
I wonder if you should not just fix __rfcomm_get_sock_by_addr to check only for BT_BOUND and BT_LISTEN.
Regards
Marcel
^ permalink raw reply
* Re: [PATCHv3] hog: Use HoG device name as uHID input device name
From: Petri Gynther @ 2014-02-13 0:29 UTC (permalink / raw)
To: linux-bluetooth
Any comments on this patch?
In uHID kernel driver, uhid_dev_create() does:
...
strncpy(hid->name, ev->u.create.name, 127);
hid->name[127] = 0;
strncpy(hid->phys, ev->u.create.phys, 63);
hid->phys[63] = 0;
strncpy(hid->uniq, ev->u.create.uniq, 63);
hid->uniq[63] = 0;
Also, BlueZ already does this with HID input devices.
input_device_new() copies Bluetooth device name into idev->name. And
then, hidp_add_connection() copies idev->name to req->name and passes
it to kernel. In kernel, hidp_setup_hid() populates hid->name,
hid->phys, and hid->uniq.
On Wed, Jan 29, 2014 at 7:55 PM, Petri Gynther <pgynther@google.com> wrote:
> If HoG BLE device name is known, use it when creating uHID input device.
> Pass adapter and device addresses to uHID as well.
> ---
> profiles/input/hog.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/profiles/input/hog.c b/profiles/input/hog.c
> index ded6303..030dc91 100644
> --- a/profiles/input/hog.c
> +++ b/profiles/input/hog.c
> @@ -392,7 +392,15 @@ static void report_map_read_cb(guint8 status, const guint8 *pdu, guint16 plen,
> /* create uHID device */
> memset(&ev, 0, sizeof(ev));
> ev.type = UHID_CREATE;
> - strcpy((char *) ev.u.create.name, "bluez-hog-device");
> + if (device_name_known(hogdev->device)) {
> + device_get_name(hogdev->device, (char *) ev.u.create.name,
> + sizeof(ev.u.create.name) - 1);
> + } else {
> + strcpy((char *) ev.u.create.name, "bluez-hog-device");
> + }
> + ba2str(btd_adapter_get_address(device_get_adapter(hogdev->device)),
> + (char *) ev.u.create.phys);
> + ba2str(device_get_address(hogdev->device), (char *) ev.u.create.uniq);
> ev.u.create.vendor = vendor;
> ev.u.create.product = product;
> ev.u.create.version = version;
> --
> 1.8.5.3
>
^ permalink raw reply
* Re: [PATCH 00/24] rfcomm fixes
From: Peter Hurley @ 2014-02-13 0:38 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Gustavo F. Padovan, Johan Hedberg, Gianluca Anzolin,
Alexander Holler, Andrey Vihrov, Sander Eikelenboom,
bluez mailin list (linux-bluetooth@vger.kernel.org), linux-kernel
In-Reply-To: <433F6D97-A126-4F9F-96AC-4385575E005E@holtmann.org>
Hi Marcel,
On 02/12/2014 05:58 PM, Marcel Holtmann wrote:
> we might also want to add some end-to-end test cases to rfcomm-tester that covers this behavior.
Are there some docs for the linux-bluetooth test harness?
I have some unit tests that I can port but I should probably understand
the bluetooth test framework first. A lot of my unit tests are designed
to test races with the ioctl interface, device creation and initialization,
teardown, tty open, close, etc.
Would that kind of unit test fit in the test harness design?
Regards,
Peter Hurley
^ permalink raw reply
* [PATCH] adapter: Handle MGMT_SETTING_LE change
From: Petri Gynther @ 2014-02-13 1:45 UTC (permalink / raw)
To: linux-bluetooth
On some BLE-capable adapters, BLE is not enabled by default. When BLE is
enabled after the adapter is already powered up, we need to call
trigger_passive_scanning() so that paired BLE devices (e.g. HoG devices)
are able to reconnect back to host.
bluetoothd[1087]: src/adapter.c:adapter_start() adapter /org/bluez/hci0 has been enabled
bluetoothd[1087]: src/adapter.c:load_link_keys_complete() link keys loaded for hci0
bluetoothd[1087]: src/adapter.c:load_ltks_complete() LTKs loaded for hci0
bluetoothd[1087]: src/adapter.c:get_connections_complete() Connection count: 0
bluetoothd[1087]: src/adapter.c:new_settings_callback() Settings: 0x000000c1
bluetoothd[1087]: src/adapter.c:settings_changed() Changed settings: 0x00000040
bluetoothd[1087]: src/adapter.c:new_settings_callback() Settings: 0x000002c1
bluetoothd[1087]: src/adapter.c:settings_changed() Changed settings: 0x00000200
=> BLE got enabled, adapter already up, need to call trigger_passive_scanning()
bluetoothd[1087]: src/adapter.c:new_settings_callback() Settings: 0x000002d1
bluetoothd[1087]: src/adapter.c:settings_changed() Changed settings: 0x00000010
bluetoothd[1087]: src/adapter.c:new_settings_callback() Settings: 0x000002d3
bluetoothd[1087]: src/adapter.c:settings_changed() Changed settings: 0x00000002
---
src/adapter.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/src/adapter.c b/src/adapter.c
index 18601ea..01006f2 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -405,6 +405,7 @@ static void store_adapter_info(struct btd_adapter *adapter)
static void trigger_pairable_timeout(struct btd_adapter *adapter);
static void adapter_start(struct btd_adapter *adapter);
static void adapter_stop(struct btd_adapter *adapter);
+static void trigger_passive_scanning(struct btd_adapter *adapter);
static void settings_changed(struct btd_adapter *adapter, uint32_t settings)
{
@@ -434,6 +435,13 @@ static void settings_changed(struct btd_adapter *adapter, uint32_t settings)
}
}
+ if (changed_mask & MGMT_SETTING_LE) {
+ if ((adapter->current_settings & MGMT_SETTING_POWERED) &&
+ (adapter->current_settings & MGMT_SETTING_LE)) {
+ trigger_passive_scanning(adapter);
+ }
+ }
+
if (changed_mask & MGMT_SETTING_CONNECTABLE)
g_dbus_emit_property_changed(dbus_conn, adapter->path,
ADAPTER_INTERFACE, "Connectable");
--
1.9.0.rc1.175.g0b1dcb5
^ permalink raw reply related
* Re: [PATCH 1/4] android/haltest: Remove unneeded assignment
From: Andrei Emeltchenko @ 2014-02-13 8:21 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <CABBYNZJq3wWht-Jk7BP=dkEnsTG2o8fXiF8JycJr_prMvQe0NA@mail.gmail.com>
Hi Luiz,
On Mon, Feb 10, 2014 at 02:16:09PM +0200, Luiz Augusto von Dentz wrote:
> Hi Andrei,
>
> On Fri, Feb 7, 2014 at 2:11 PM, Andrei Emeltchenko
> <Andrei.Emeltchenko.news@gmail.com> wrote:
> > From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
> >
> > ---
> > android/client/if-audio.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/android/client/if-audio.c b/android/client/if-audio.c
> > index 8c640a1..5ab11a6 100644
> > --- a/android/client/if-audio.c
> > +++ b/android/client/if-audio.c
> > @@ -225,10 +225,8 @@ static void *playback_thread(void *data)
> > pthread_mutex_unlock(&outstream_mutex);
> > } while (len && w_len > 0);
> >
> > - if (in) {
> > + if (in)
> > fclose(in);
> > - in = NULL;
> > - }
> >
> > pthread_cleanup_pop(1);
> > return NULL;
> > --
> > 1.8.3.2
>
> Pushed, note that I did move the changes from audio to android since
> the audio code will be dropped as it is not unit tested.
I still think that those patches needs to applied otherwise we have
following warnings:
...
CC profiles/audio/bluetoothd-avdtp.o
profiles/audio/avdtp.c:2735:2: warning: Null pointer passed as an argument
to a 'nonnull' parameter
memcpy(req->data, buffer, size);
^ ~~~~~~
profiles/audio/avdtp.c:3290:2: warning: Null pointer passed as an argument
to a 'nonnull' parameter
memcpy(cap->data, data, length);
^ ~~~~
2 warnings generated.
...
You may choose to fix those warns other ways though.
Best regards
Andrei Emeltchenko
^ permalink raw reply
* Re: [PATCHv3] hog: Use HoG device name as uHID input device name
From: Johan Hedberg @ 2014-02-13 9:19 UTC (permalink / raw)
To: Petri Gynther; +Cc: linux-bluetooth
In-Reply-To: <20140130035506.2A034100F4B@puck.mtv.corp.google.com>
Hi Petri,
On Wed, Jan 29, 2014, Petri Gynther wrote:
> If HoG BLE device name is known, use it when creating uHID input device.
> Pass adapter and device addresses to uHID as well.
Could you perhaps elaborate a bit what exactly the "uniq" and "phys"
members are in the request (possibly with a reference to the uHID
documentation). That would make it easier to verify that the content
you're adding to them makes sense.
> + if (device_name_known(hogdev->device)) {
> + device_get_name(hogdev->device, (char *) ev.u.create.name,
> + sizeof(ev.u.create.name) - 1);
> + } else {
> + strcpy((char *) ev.u.create.name, "bluez-hog-device");
> + }
We don't use { } for single line branches, so you can drop these here.
> + ba2str(btd_adapter_get_address(device_get_adapter(hogdev->device)),
> + (char *) ev.u.create.phys);
This is getting a bit messy with the nested function calls. I'd add
separate adapter variable here to make this a bit more readable.
Also note our coding style wrt split lines: indent the continuation
lines as much as you can (with tabs) as long as it's under 80 chars.
Also, it might be good to split this up into two patches since you've
essentially got two independent improvements here. One is making sure
the name member contains something more useful and the other is adding
some content to the uniq and phys members.
Johan
^ permalink raw reply
* Re: partial success with PS3 sixaxis
From: Szymon Janc @ 2014-02-13 9:25 UTC (permalink / raw)
To: Andrea; +Cc: linux-bluetooth
In-Reply-To: <52FBE820.6050701@gmail.com>
Hi Andrea,
On Wednesday 12 of February 2014 21:31:12 Andrea wrote:
> Hi,
>
> I've been trying to pair a PS3 sixaxis controller using bluez 5.14
> I've had so far only partial success.
>
> It connects, creates js0 and event0 devices, but after a few seconds it removes them.
>
> The lights are always flashing.
>
> I am on a Raspberry running ArchLinux.
>
> This is the output of bluetoothctl
>
> ...
> [bluetooth]# disconnect
> [CHG] Device 00:0B:EB:63:F2:62 Connected: yes
> [bluetooth]# disconnect show
> [bluetooth]# disconnect 00:0B:EB:63:F2:62
> Attempting to disconnect from 00:0B:EB:63:F2:62
> Successful disconnected
> [CHG] Device 00:0B:EB:63:F2:62 Connected: no
> [CHG] Device 00:0B:EB:63:F2:62 Connected: yes
>
> then in dmesg I can see
>
> [ 2745.435967] sony 0005:054C:0268.0008: Fixing up Sony Sixaxis report descriptor
> [ 2745.452105] sony 0005:054C:0268.0008: unknown main item tag 0x0
> [ 2745.471504] input: PLAYSTATION(R)3 Controller as
> /devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.0/bluetooth/hci0/hci0:11/input7
> [ 2745.472795] sony 0005:054C:0268.0008: input,hidraw0: BLUETOOTH HID v1.00 Joystick
> [PLAYSTATION(R)3 Controller] on 00:0b:0d:4c:94:a6
> [ 2755.472242] sony: probe of 0005:054C:0268.0008 failed with error -5
>
> the hardware should be ok as it works using sixad & sixpair.
>
> any idea what could be going wrong?
> I am not even sure if I am doing the right thing to pair, trust, connect etc... as I cannot google
> anything using bluez 5 + ps3. All the howtos are for sixad.
This should "just work". Since 5.14 there is authorization needed when DS3 is
connecting (device is not marked as trusted when connected on USB) so please
make sure you have default agent registered.
I assume you are using bluetoothctl so do:
agent on
default-agent
Then you should get authorization request in bluetoothctl when DS3 is connecting.
--
Best regards,
Szymon Janc
^ permalink raw reply
* [PATCH] android: Fix for BT Turn off while pairing
From: Lukasz Rymanowski @ 2014-02-13 10:51 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Lukasz Rymanowski
This patch fix an issue when Android disables BT during ongoing
paring. In this case mgmt did not accept any commands and BT gets
in some unknown state.
Since Android turns off BT anyway, it is ok to just cancel all
the mgmt requests before send power off command.
---
android/bluetooth.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/android/bluetooth.c b/android/bluetooth.c
index ff41627..ad8cfec 100644
--- a/android/bluetooth.c
+++ b/android/bluetooth.c
@@ -2907,6 +2907,9 @@ static void handle_disable_cmd(const void *buf, uint16_t len)
goto reply;
}
+ /* Cancel all pending requests. Need it in case of ongoing paring */
+ mgmt_cancel_index(mgmt_if, adapter.index);
+
if (!set_mode(MGMT_OP_SET_POWERED, 0x00)) {
status = HAL_STATUS_FAILED;
goto reply;
--
1.8.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox