* [PATCH v4 00/17] Heart Rate Profile plugin
From: Andrzej Kaczmarek @ 2012-09-13 12:13 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Andrzej Kaczmarek
Hi,
Changes since v3:
* rebased due to profile code moved to separate files
Andrzej Kaczmarek (6):
heartrate: Add attio callbacks
heartrate: Enable measurement when watchers are registered
heartrate: Read Heart Rate Control Point characteristics
heartrate: Handle characteristics value changed notification
heartrate: Process Heart Rate Measurement characteristics
heartrate: Add Reset method
Rafal Garbat (10):
heartrate: Add Heart Rate Profile client
heartrate: Discover characteristics
heartrate: Process characteristics
heartrate: Discover characteristics descriptors
heartrate: Process characteristics descriptors
heartrate: Add HeartRateManager interface
heartrate: Read Body Sensor Location characteristics
heartrate: Add GetProperties method
heartrate: Add HeartRateWatcher interface to default policy
heartrate: Add test script
Santiago Carot-Nemesio (1):
Heart Rate Profile API
Makefile.am | 9 +-
Makefile.tools | 4 +-
doc/heartrate-api.txt | 80 ++++
lib/uuid.h | 5 +
profiles/heartrate/heartrate.c | 969 +++++++++++++++++++++++++++++++++++++++++
profiles/heartrate/heartrate.h | 27 ++
profiles/heartrate/main.c | 52 +++
profiles/heartrate/manager.c | 96 ++++
profiles/heartrate/manager.h | 24 +
src/bluetooth.conf | 1 +
test/test-heartrate | 101 +++++
11 files changed, 1364 insertions(+), 4 deletions(-)
create mode 100644 doc/heartrate-api.txt
create mode 100644 profiles/heartrate/heartrate.c
create mode 100644 profiles/heartrate/heartrate.h
create mode 100644 profiles/heartrate/main.c
create mode 100644 profiles/heartrate/manager.c
create mode 100644 profiles/heartrate/manager.h
create mode 100755 test/test-heartrate
--
1.7.11.3
^ permalink raw reply
* Re: [PATCH 02/10] battery: Implement Generic device battery
From: Chen Ganir @ 2012-09-13 11:32 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: Joao Paulo Rechi Vita, linux-bluetooth
In-Reply-To: <CAJdJm_NNR86qNnxm-CPFqfuu0sPkoQhqAZY6nGUKB6GYeJ2HAw@mail.gmail.com>
Anderson,
On 09/12/2012 01:57 PM, Anderson Lizardo wrote:
> Hi Chen,
>
> On Wed, Sep 12, 2012 at 6:30 AM, Chen Ganir <chen.ganir@ti.com> wrote:
>>> Both BtIO and GAttrib intend to mimic GLib-like libraries where this is
>>> the convention. The plan is not to let this spread to the entire code
>>> base (particularly with the likely move to libell in the long run), so
>>> please don't use CamelCase.
>>>
>> Ok. So for the battery options i'll simply change it to battery_option. What
>> about the convention for defining a function pointer ?
>
> See the result of:
>
> grep -r 'typedef.*(' *
>
> on your bluez tree. As Johan mentioned, you should ignore the (few)
> occurrences of camel case typedef declarations.
>
> Regards,
>
Thanks.
--
BR,
Chen Ganir
^ permalink raw reply
* Re: [PATCH 09/10] battery: Add support for notifications
From: Chen Ganir @ 2012-09-13 11:27 UTC (permalink / raw)
To: Joao Paulo Rechi Vita; +Cc: linux-bluetooth
In-Reply-To: <5050167A.8020400@ti.com>
Joao,
On 09/12/2012 07:58 AM, Chen Ganir wrote:
> Joao,
> On 09/12/2012 01:08 AM, Joao Paulo Rechi Vita wrote:
>> On Tue, Sep 11, 2012 at 4:38 AM, <chen.ganir@ti.com> wrote:
>>> From: Chen Ganir <chen.ganir@ti.com>
>>>
>>> Add support for emitting PropertyChanged when a battery level
>>> characteristic notification is sent from the peer device.
>>> ---
>>> profiles/battery/battery.c | 95
>>> +++++++++++++++++++++++++++++++++++++++++++-
>>> 1 file changed, 93 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/profiles/battery/battery.c b/profiles/battery/battery.c
>>> index a93b352..95f548e 100644
>>> --- a/profiles/battery/battery.c
>>> +++ b/profiles/battery/battery.c
>>> @@ -43,6 +43,7 @@ struct battery {
>>> GAttrib *attrib; /* GATT connection */
>>> guint attioid; /* Att watcher id */
>>> struct att_range *svc_range; /* Battery range */
>>> + guint attnotid; /* Att notifications
>>> id */
>>> GSList *chars; /* Characteristics */
>>> };
>>>
>>> @@ -56,6 +57,7 @@ struct characteristic {
>>> uint8_t ns; /* Battery Namespace */
>>> uint16_t description; /* Battery
>>> description */
>>> uint8_t level;
>>> + gboolean canNotify;
>>> };
>>>
>>> struct descriptor {
>>> @@ -86,6 +88,14 @@ static void char_free(gpointer user_data)
>>> g_free(c);
>>> }
>>>
>>> +static gint cmp_char_val_handle(gconstpointer a, gconstpointer b)
>>> +{
>>> + const struct characteristic *ch = a;
>>> + const uint16_t *handle = b;
>>> +
>>> + return ch->attr.value_handle - *handle;
>>> +}
>>> +
>>> static void battery_free(gpointer user_data)
>>> {
>>> struct battery *batt = user_data;
>>> @@ -99,6 +109,10 @@ static void battery_free(gpointer user_data)
>>> if (batt->attrib != NULL)
>>> g_attrib_unref(batt->attrib);
>>>
>>> + if (batt->attrib != NULL) {
>>> + g_attrib_unregister(batt->attrib, batt->attnotid);
>>> + g_attrib_unref(batt->attrib);
>>> + }
>>
>> You're using the same condition twice here (batt->attrib != NULL).
>> Looks like a copy & paste error. Make sure you check for attnotid
>> before checking attrib, and that you don't unref attrib twice.
>>
> Correct. I'll fix this and check for attnotid.
>
>>> btd_device_unref(batt->dev);
>>> g_free(batt->svc_range);
>>> g_free(batt);
>>> @@ -140,6 +154,18 @@ static void process_batteryservice_char(struct
>>> characteristic *ch)
>>> }
>>> }
>>>
>>> +static void batterylevel_enable_notify_cb(guint8 status, const
>>> guint8 *pdu,
>>> + guint16 len, gpointer
>>> user_data)
>>> +{
>>> + struct characteristic *ch = (struct characteristic *)user_data;
>>> +
>>> + if (status != 0) {
>>> + error("Could not enable batt level notification.");
>>> + ch->canNotify = FALSE;
>>> + process_batteryservice_char(ch);
>>
>> I don't think is necessary to call process_batteryservice_char() here,
>> since you already called it during the characteristics discovery.
>>
> I'll remove the unnecessary call here.
>
>
After checking this again, this call should not be removed. The reason
for that is simple - if a characteristic can not be notified, and we
read its initial value from file, we need to make sure we refresh the
battery level from the peer device automatically (since we will not get
notified when level changes).
>>> + }
>>> +}
>>> +
>>> static gint device_battery_cmp(gconstpointer a, gconstpointer b)
>>> {
>>> const struct characteristic *ch = a;
>>> @@ -178,6 +204,19 @@ static void batterylevel_refresh_cb(struct
>>> device_battery *batt)
>>> process_batteryservice_char(ch);
>>> }
>>>
>>> +static void enable_battery_notification(struct characteristic *ch,
>>> +
>>> uint16_t handle)
>>> +{
>>> + uint8_t atval[2];
>>> + uint16_t val;
>>> +
>>> + val = GATT_CLIENT_CHARAC_CFG_NOTIF_BIT;
>>> +
>>> + att_put_u16(val, atval);
>>> + gatt_write_char(ch->batt->attrib, handle, atval, 2,
>>> + batterylevel_enable_notify_cb, ch);
>>> +}
>>> +
>>> static void batterylevel_presentation_format_desc_cb(guint8 status,
>>> const guint8 *pdu,
>>> guint16 len,
>>> gpointer user_data)
>>> @@ -207,13 +246,20 @@ static void
>>> batterylevel_presentation_format_desc_cb(guint8 status,
>>> desc->ch->description = att_get_u16(&value[5]);
>>> }
>>>
>>> -
>>> static void process_batterylevel_desc(struct descriptor *desc)
>>> {
>>> struct characteristic *ch = desc->ch;
>>> char uuidstr[MAX_LEN_UUID_STR];
>>> bt_uuid_t btuuid;
>>>
>>> + bt_uuid16_create(&btuuid, GATT_CLIENT_CHARAC_CFG_UUID);
>>> +
>>> + if (bt_uuid_cmp(&desc->uuid, &btuuid) == 0 &&
>>> g_strcmp0(ch->attr.uuid,
>>> + BATTERY_LEVEL_UUID)
>>> == 0) {
>>> + enable_battery_notification(ch, desc->handle);
>>> + return;
>>> + }
>>> +
>>> bt_uuid16_create(&btuuid, GATT_CHARAC_FMT_UUID);
>>>
>>> if (bt_uuid_cmp(&desc->uuid, &btuuid) == 0) {
>>> @@ -319,12 +365,54 @@ static void configure_battery_cb(GSList
>>> *characteristics, guint8 status,
>>> }
>>> }
>>>
>>> +static void proc_batterylevel(struct characteristic *c, const
>>> uint8_t *pdu,
>>> + uint16_t len,
>>> gboolean final)
>>> +{
>>> + if (!pdu) {
>>> + error("Battery level notification: Invalid pdu length");
>>> + return;
>>> + }
>>> +
>>> + c->level = pdu[1];
>>> +
>>> + btd_device_set_battery_opt(c->devbatt, BATTERY_OPT_LEVEL,
>>> c->level,
>>> +
>>> BATTERY_OPT_INVALID);
>>> +}
>>> +
>>> +static void notif_handler(const uint8_t *pdu, uint16_t len, gpointer
>>> user_data)
>>> +{
>>> + struct battery *batt = user_data;
>>> + struct characteristic *ch;
>>> + uint16_t handle;
>>> + GSList *l;
>>> +
>>> + if (len < 3) {
>>> + error("notif_handler: Bad pdu received");
>>> + return;
>>> + }
>>> +
>>> + handle = att_get_u16(&pdu[1]);
>>> + l = g_slist_find_custom(batt->chars, &handle,
>>> cmp_char_val_handle);
>>> + if (l == NULL) {
>>> + error("notif_handler: Unexpected handle 0x%04x",
>>> handle);
>>> + return;
>>> + }
>>> +
>>> + ch = l->data;
>>> + if (g_strcmp0(ch->attr.uuid, BATTERY_LEVEL_UUID) == 0) {
>>> + proc_batterylevel(ch, pdu, len, FALSE);
>>> + }
>>> +}
>>> +
>>> static void attio_connected_cb(GAttrib *attrib, gpointer user_data)
>>> {
>>> struct battery *batt = user_data;
>>>
>>> batt->attrib = g_attrib_ref(attrib);
>>>
>>> + batt->attnotid = g_attrib_register(batt->attrib,
>>> ATT_OP_HANDLE_NOTIFY,
>>> + notif_handler, batt,
>>> NULL);
>>> +
>>> if (batt->chars == NULL) {
>>> gatt_discover_char(batt->attrib,
>>> batt->svc_range->start,
>>> batt->svc_range->end, NULL,
>>> @@ -333,7 +421,8 @@ static void attio_connected_cb(GAttrib *attrib,
>>> gpointer user_data)
>>> GSList *l;
>>> for (l = batt->chars; l; l = l->next) {
>>> struct characteristic *c = l->data;
>>> - process_batteryservice_char(c);
>>> + if (!c->canNotify)
>>> + process_batteryservice_char(c);
>>> }
>>> }
>>> }
>>> @@ -342,6 +431,8 @@ static void attio_disconnected_cb(gpointer
>>> user_data)
>>> {
>>> struct battery *batt = user_data;
>>>
>>> + g_attrib_unregister(batt->attrib, batt->attnotid);
>>> + batt->attnotid = 0;
>>> g_attrib_unref(batt->attrib);
>>> batt->attrib = NULL;
>>> }
>>> --
>>> 1.7.9.5
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe
>>> linux-bluetooth" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>
> Thanks,
>
--
BR,
Chen Ganir
^ permalink raw reply
* Re: Dropping connection (bit off-topic)
From: Anderson Lizardo @ 2012-09-13 10:53 UTC (permalink / raw)
To: John Tobias; +Cc: Vinicius Costa Gomes, linux-bluetooth
In-Reply-To: <CACUGKYN-+AKvVOZwxR7b6cvSujBMRHnjzNGcGezYynP2gTm6KA@mail.gmail.com>
Hi John,
On Wed, Sep 12, 2012 at 10:52 PM, John Tobias <john.tobias.ph@gmail.com> wrote:
> Hello again,
>
> I enabled the GATT in my bluetoothd and found out that there was an
> unimplemented attribute (below) and might be the reason why the iPhone
> connection got disconnected after 30 secs.
>
> 2012-09-12 15:36:55.419980 > ACL data: handle 76 flags 0x02 dlen 9
> ATT: Error (0x01)
> Error: Attribute not found (10)
> Read By Type req (0x08) on handle 0x0039
>
> I would like to know if anyone here has a patch?.
Just this snippet does not say much. "Attribute not found" errors are
common during service/characteristic discovery because they indicate
that the discovery has finished.
Could you post the whole hcidump since the connection establishment up
to the disconnection? That should help detecting the problem.
Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [PATCH obexd 3/3] MAP: Add set delete status function
From: Luiz Augusto von Dentz @ 2012-09-13 8:39 UTC (permalink / raw)
To: Sunil Kumar Behera; +Cc: linux-bluetooth
In-Reply-To: <1347516432-28414-1-git-send-email-sunil.behera@samsung.com>
Hi Sunil,
On Thu, Sep 13, 2012 at 9:07 AM, Sunil Kumar Behera
<sunil.behera@samsung.com> wrote:
> This function will inform MAP server to modify
> the delete status of a given message.
> ---
> plugins/mas.c | 18 ++++++++++++++++++
> plugins/messages-dummy.c | 8 ++++++++
> plugins/messages-tracker.c | 8 ++++++++
> plugins/messages.h | 17 +++++++++++++++++
> 4 files changed, 51 insertions(+)
>
> diff --git a/plugins/mas.c b/plugins/mas.c
> index 182dc6b..b0b1e22 100644
> --- a/plugins/mas.c
> +++ b/plugins/mas.c
> @@ -47,6 +47,7 @@
> #include "messages.h"
>
> #define READ_STATUS_REQ 0
> +#define DELETE_STATUS_REQ 1
>
> /* Channel number according to bluez doc/assigned-numbers.txt */
> #define MAS_CHANNEL 16
> @@ -515,6 +516,20 @@ static void set_read_status_cb(void *session, int err, void *user_data)
> obex_object_set_io_flags(mas, G_IO_OUT, 0);
> }
>
> +static void set_delete_status_cb(void *session, int err, void *user_data)
> +{
> + struct mas_session *mas = user_data;
> +
> + DBG("");
> +
> + mas->finished = TRUE;
> +
> + if (err < 0)
> + obex_object_set_io_flags(mas, G_IO_ERR, err);
> + else
> + obex_object_set_io_flags(mas, G_IO_OUT, 0);
> +}
> +
> static int mas_setpath(struct obex_session *os, void *user_data)
> {
> const char *name;
> @@ -696,6 +711,9 @@ static void *message_set_status_open(const char *name, int oflag, mode_t mode,
> if (indicator == READ_STATUS_REQ)
> *err = messages_set_read_status(mas->backend_data, name,
> value, set_read_status_cb, mas);
> + else if (indicator == DELETE_STATUS_REQ)
> + *err = messages_set_delete_status(mas->backend_data, name,
> + value, set_delete_status_cb, mas);
> else
> *err = -EBADR;
>
> diff --git a/plugins/messages-dummy.c b/plugins/messages-dummy.c
> index 627f87a..c2f7f6c 100644
> --- a/plugins/messages-dummy.c
> +++ b/plugins/messages-dummy.c
> @@ -361,6 +361,14 @@ int messages_set_read_status(void *session, const char *handle,
> return -ENOSYS;
> }
>
> +int messages_set_delete_status(void *session, const char *handle,
> + uint8_t value,
> + messages_set_delete_status_cb callback,
> + void *user_data)
> +{
> + return -ENOSYS;
> +}
> +
> void messages_abort(void *s)
> {
> struct session *session = s;
> diff --git a/plugins/messages-tracker.c b/plugins/messages-tracker.c
> index 13c113e..99ecae3 100644
> --- a/plugins/messages-tracker.c
> +++ b/plugins/messages-tracker.c
> @@ -335,6 +335,14 @@ int messages_set_read_status(void *session, const char *handle,
> return -ENOSYS;
> }
>
> +int messages_set_delete_status(void *session, const char *handle,
> + uint8_t value,
> + messages_set_delete_status_cb callback,
> + void *user_data)
> +{
> + return -ENOSYS;
> +}
> +
> void messages_abort(void *session)
> {
> }
> diff --git a/plugins/messages.h b/plugins/messages.h
> index 02d4f37..8890ace 100644
> --- a/plugins/messages.h
> +++ b/plugins/messages.h
> @@ -297,6 +297,23 @@ int messages_set_read_status(void *session, const char *handle,
> messages_set_read_status_cb callback,
> void *user_data);
>
> +/* Informs Message Server to modify delete status of a given message.
> + *
> + * session: Backend session.
> + * handle: Unique identifier to the message.
> + * value: Indicates the new value of the delete status for a given message.
> + * Callback shall be called for every delete status update request
> + * recieved from MCE.
> + * user_data: User data if any to be sent.
> + */
> +typedef void (*messages_set_delete_status_cb)(void *session, int err,
> + void *user_data);
> +
> +int messages_set_delete_status(void *session, const char *handle,
> + uint8_t value,
> + messages_set_delete_status_cb callback,
> + void *user_data);
> +
Same here, name it messages_set_delete and messages_set_delete_cb.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH obexd 2/3] MAP: Add set read status function
From: Luiz Augusto von Dentz @ 2012-09-13 8:37 UTC (permalink / raw)
To: Sunil Kumar Behera; +Cc: linux-bluetooth
In-Reply-To: <1347516406-28378-1-git-send-email-sunil.behera@samsung.com>
Hi Sunil,
On Thu, Sep 13, 2012 at 9:06 AM, Sunil Kumar Behera
<sunil.behera@samsung.com> wrote:
> This function will inform MAP server to modify the
> read status of a given message.
> ---
> plugins/mas.c | 25 +++++++++++++++++++++++++
> plugins/messages-dummy.c | 8 ++++++++
> plugins/messages-tracker.c | 8 ++++++++
> plugins/messages.h | 17 +++++++++++++++++
> 4 files changed, 58 insertions(+)
>
> diff --git a/plugins/mas.c b/plugins/mas.c
> index f2ff9e6..182dc6b 100644
> --- a/plugins/mas.c
> +++ b/plugins/mas.c
> @@ -46,6 +46,8 @@
>
> #include "messages.h"
>
> +#define READ_STATUS_REQ 0
> +
> /* Channel number according to bluez doc/assigned-numbers.txt */
> #define MAS_CHANNEL 16
>
> @@ -499,6 +501,20 @@ static void update_inbox_cb(void *session, int err, void *user_data)
> obex_object_set_io_flags(mas, G_IO_OUT, 0);
> }
>
> +static void set_read_status_cb(void *session, int err, void *user_data)
> +{
> + struct mas_session *mas = user_data;
> +
> + DBG("");
> +
> + mas->finished = TRUE;
> +
> + if (err < 0)
> + obex_object_set_io_flags(mas, G_IO_ERR, err);
> + else
> + obex_object_set_io_flags(mas, G_IO_OUT, 0);
> +}
> +
> static int mas_setpath(struct obex_session *os, void *user_data)
> {
> const char *name;
> @@ -677,6 +693,15 @@ static void *message_set_status_open(const char *name, int oflag, mode_t mode,
> return NULL;
> }
>
> + if (indicator == READ_STATUS_REQ)
> + *err = messages_set_read_status(mas->backend_data, name,
> + value, set_read_status_cb, mas);
> + else
> + *err = -EBADR;
> +
> + if (*err < 0)
> + return NULL;
> +
> return mas;
> }
>
> diff --git a/plugins/messages-dummy.c b/plugins/messages-dummy.c
> index a47f143..627f87a 100644
> --- a/plugins/messages-dummy.c
> +++ b/plugins/messages-dummy.c
> @@ -353,6 +353,14 @@ int messages_update_inbox(void *session, messages_update_inbox_cb callback,
> return -ENOSYS;
> }
>
> +int messages_set_read_status(void *session, const char *handle,
> + uint8_t value,
> + messages_set_read_status_cb callback,
> + void *user_data)
> +{
> + return -ENOSYS;
> +}
> +
> void messages_abort(void *s)
> {
> struct session *session = s;
> diff --git a/plugins/messages-tracker.c b/plugins/messages-tracker.c
> index 92c1767..13c113e 100644
> --- a/plugins/messages-tracker.c
> +++ b/plugins/messages-tracker.c
> @@ -327,6 +327,14 @@ int messages_update_inbox(void *session, messages_update_inbox_cb callback,
> return -ENOSYS;
> }
>
> +int messages_set_read_status(void *session, const char *handle,
> + uint8_t value,
> + messages_set_read_status_cb callback,
> + void *user_data)
> +{
> + return -ENOSYS;
> +}
> +
> void messages_abort(void *session)
> {
> }
> diff --git a/plugins/messages.h b/plugins/messages.h
> index 669f7c2..02d4f37 100644
> --- a/plugins/messages.h
> +++ b/plugins/messages.h
> @@ -280,6 +280,23 @@ typedef void (*messages_update_inbox_cb)(void *session, int err,
> int messages_update_inbox(void *session, messages_update_inbox_cb callback,
> void *user_data);
>
> +/* Informs Message Server to modify read status of a given message.
> + *
> + * session: Backend session.
> + * handle: Unique identifier to the message.
> + * value: Indicates the new value of the read status for a given message.
> + * Callback shall be called for every read status update request
> + * recieved from MCE.
> + * user_data: User data if any to be sent.
> + */
> +typedef void (*messages_set_read_status_cb)(void *session, int err,
> + void *user_data);
> +
> +int messages_set_read_status(void *session, const char *handle,
> + uint8_t value,
> + messages_set_read_status_cb callback,
> + void *user_data);
We can simplify here and just name this function messages_set_read and
messages_set_read_cb for the callbackl. Also I noticed that you are
not aligning to the right when you need to split due to 80 columns,
can you fix that as well?
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH obexd 3/3] MAP: Add set delete status function
From: Sunil Kumar Behera @ 2012-09-13 6:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Sunil Kumar Behera
This function will inform MAP server to modify
the delete status of a given message.
---
plugins/mas.c | 18 ++++++++++++++++++
plugins/messages-dummy.c | 8 ++++++++
plugins/messages-tracker.c | 8 ++++++++
plugins/messages.h | 17 +++++++++++++++++
4 files changed, 51 insertions(+)
diff --git a/plugins/mas.c b/plugins/mas.c
index 182dc6b..b0b1e22 100644
--- a/plugins/mas.c
+++ b/plugins/mas.c
@@ -47,6 +47,7 @@
#include "messages.h"
#define READ_STATUS_REQ 0
+#define DELETE_STATUS_REQ 1
/* Channel number according to bluez doc/assigned-numbers.txt */
#define MAS_CHANNEL 16
@@ -515,6 +516,20 @@ static void set_read_status_cb(void *session, int err, void *user_data)
obex_object_set_io_flags(mas, G_IO_OUT, 0);
}
+static void set_delete_status_cb(void *session, int err, void *user_data)
+{
+ struct mas_session *mas = user_data;
+
+ DBG("");
+
+ mas->finished = TRUE;
+
+ if (err < 0)
+ obex_object_set_io_flags(mas, G_IO_ERR, err);
+ else
+ obex_object_set_io_flags(mas, G_IO_OUT, 0);
+}
+
static int mas_setpath(struct obex_session *os, void *user_data)
{
const char *name;
@@ -696,6 +711,9 @@ static void *message_set_status_open(const char *name, int oflag, mode_t mode,
if (indicator == READ_STATUS_REQ)
*err = messages_set_read_status(mas->backend_data, name,
value, set_read_status_cb, mas);
+ else if (indicator == DELETE_STATUS_REQ)
+ *err = messages_set_delete_status(mas->backend_data, name,
+ value, set_delete_status_cb, mas);
else
*err = -EBADR;
diff --git a/plugins/messages-dummy.c b/plugins/messages-dummy.c
index 627f87a..c2f7f6c 100644
--- a/plugins/messages-dummy.c
+++ b/plugins/messages-dummy.c
@@ -361,6 +361,14 @@ int messages_set_read_status(void *session, const char *handle,
return -ENOSYS;
}
+int messages_set_delete_status(void *session, const char *handle,
+ uint8_t value,
+ messages_set_delete_status_cb callback,
+ void *user_data)
+{
+ return -ENOSYS;
+}
+
void messages_abort(void *s)
{
struct session *session = s;
diff --git a/plugins/messages-tracker.c b/plugins/messages-tracker.c
index 13c113e..99ecae3 100644
--- a/plugins/messages-tracker.c
+++ b/plugins/messages-tracker.c
@@ -335,6 +335,14 @@ int messages_set_read_status(void *session, const char *handle,
return -ENOSYS;
}
+int messages_set_delete_status(void *session, const char *handle,
+ uint8_t value,
+ messages_set_delete_status_cb callback,
+ void *user_data)
+{
+ return -ENOSYS;
+}
+
void messages_abort(void *session)
{
}
diff --git a/plugins/messages.h b/plugins/messages.h
index 02d4f37..8890ace 100644
--- a/plugins/messages.h
+++ b/plugins/messages.h
@@ -297,6 +297,23 @@ int messages_set_read_status(void *session, const char *handle,
messages_set_read_status_cb callback,
void *user_data);
+/* Informs Message Server to modify delete status of a given message.
+ *
+ * session: Backend session.
+ * handle: Unique identifier to the message.
+ * value: Indicates the new value of the delete status for a given message.
+ * Callback shall be called for every delete status update request
+ * recieved from MCE.
+ * user_data: User data if any to be sent.
+ */
+typedef void (*messages_set_delete_status_cb)(void *session, int err,
+ void *user_data);
+
+int messages_set_delete_status(void *session, const char *handle,
+ uint8_t value,
+ messages_set_delete_status_cb callback,
+ void *user_data);
+
/* Aborts currently pending request.
*
* session: Backend session.
--
1.7.9.5
^ permalink raw reply related
* [PATCH obexd 2/3] MAP: Add set read status function
From: Sunil Kumar Behera @ 2012-09-13 6:06 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Sunil Kumar Behera
This function will inform MAP server to modify the
read status of a given message.
---
plugins/mas.c | 25 +++++++++++++++++++++++++
plugins/messages-dummy.c | 8 ++++++++
plugins/messages-tracker.c | 8 ++++++++
plugins/messages.h | 17 +++++++++++++++++
4 files changed, 58 insertions(+)
diff --git a/plugins/mas.c b/plugins/mas.c
index f2ff9e6..182dc6b 100644
--- a/plugins/mas.c
+++ b/plugins/mas.c
@@ -46,6 +46,8 @@
#include "messages.h"
+#define READ_STATUS_REQ 0
+
/* Channel number according to bluez doc/assigned-numbers.txt */
#define MAS_CHANNEL 16
@@ -499,6 +501,20 @@ static void update_inbox_cb(void *session, int err, void *user_data)
obex_object_set_io_flags(mas, G_IO_OUT, 0);
}
+static void set_read_status_cb(void *session, int err, void *user_data)
+{
+ struct mas_session *mas = user_data;
+
+ DBG("");
+
+ mas->finished = TRUE;
+
+ if (err < 0)
+ obex_object_set_io_flags(mas, G_IO_ERR, err);
+ else
+ obex_object_set_io_flags(mas, G_IO_OUT, 0);
+}
+
static int mas_setpath(struct obex_session *os, void *user_data)
{
const char *name;
@@ -677,6 +693,15 @@ static void *message_set_status_open(const char *name, int oflag, mode_t mode,
return NULL;
}
+ if (indicator == READ_STATUS_REQ)
+ *err = messages_set_read_status(mas->backend_data, name,
+ value, set_read_status_cb, mas);
+ else
+ *err = -EBADR;
+
+ if (*err < 0)
+ return NULL;
+
return mas;
}
diff --git a/plugins/messages-dummy.c b/plugins/messages-dummy.c
index a47f143..627f87a 100644
--- a/plugins/messages-dummy.c
+++ b/plugins/messages-dummy.c
@@ -353,6 +353,14 @@ int messages_update_inbox(void *session, messages_update_inbox_cb callback,
return -ENOSYS;
}
+int messages_set_read_status(void *session, const char *handle,
+ uint8_t value,
+ messages_set_read_status_cb callback,
+ void *user_data)
+{
+ return -ENOSYS;
+}
+
void messages_abort(void *s)
{
struct session *session = s;
diff --git a/plugins/messages-tracker.c b/plugins/messages-tracker.c
index 92c1767..13c113e 100644
--- a/plugins/messages-tracker.c
+++ b/plugins/messages-tracker.c
@@ -327,6 +327,14 @@ int messages_update_inbox(void *session, messages_update_inbox_cb callback,
return -ENOSYS;
}
+int messages_set_read_status(void *session, const char *handle,
+ uint8_t value,
+ messages_set_read_status_cb callback,
+ void *user_data)
+{
+ return -ENOSYS;
+}
+
void messages_abort(void *session)
{
}
diff --git a/plugins/messages.h b/plugins/messages.h
index 669f7c2..02d4f37 100644
--- a/plugins/messages.h
+++ b/plugins/messages.h
@@ -280,6 +280,23 @@ typedef void (*messages_update_inbox_cb)(void *session, int err,
int messages_update_inbox(void *session, messages_update_inbox_cb callback,
void *user_data);
+/* Informs Message Server to modify read status of a given message.
+ *
+ * session: Backend session.
+ * handle: Unique identifier to the message.
+ * value: Indicates the new value of the read status for a given message.
+ * Callback shall be called for every read status update request
+ * recieved from MCE.
+ * user_data: User data if any to be sent.
+ */
+typedef void (*messages_set_read_status_cb)(void *session, int err,
+ void *user_data);
+
+int messages_set_read_status(void *session, const char *handle,
+ uint8_t value,
+ messages_set_read_status_cb callback,
+ void *user_data);
+
/* Aborts currently pending request.
*
* session: Backend session.
--
1.7.9.5
^ permalink raw reply related
* [PATCH obexd 1/3] MAP: Add binding to support SetMessageStatus function
From: Sunil Kumar Behera @ 2012-09-13 6:06 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Sunil Kumar Behera
Add message_set_status_open binding in MIME driver
to support SetMessageStatus function.
---
plugins/mas.c | 33 ++++++++++++++++++++++++++++++++-
1 file changed, 32 insertions(+), 1 deletion(-)
diff --git a/plugins/mas.c b/plugins/mas.c
index 1c9199d..f2ff9e6 100644
--- a/plugins/mas.c
+++ b/plugins/mas.c
@@ -649,6 +649,37 @@ static void *message_update_open(const char *name, int oflag, mode_t mode,
return mas;
}
+static void *message_set_status_open(const char *name, int oflag, mode_t mode,
+ void *driver_data, size_t *size,
+ int *err)
+
+{
+ struct mas_session *mas = driver_data;
+ uint8_t indicator;
+ uint8_t value;
+
+ DBG("");
+
+ if (oflag == O_RDONLY) {
+ *err = -EBADR;
+ return NULL;
+ }
+
+ if (!g_obex_apparam_get_uint8(mas->inparams, MAP_AP_STATUSINDICATOR,
+ &indicator)) {
+ *err = -EBADR;
+ return NULL;
+ }
+
+ if (!g_obex_apparam_get_uint8(mas->inparams, MAP_AP_STATUSVALUE,
+ &value)) {
+ *err = -EBADR;
+ return NULL;
+ }
+
+ return mas;
+}
+
static ssize_t any_get_next_header(void *object, void *buf, size_t mtu,
uint8_t *hi)
{
@@ -784,7 +815,7 @@ static struct obex_mime_type_driver mime_message_status = {
.target = MAS_TARGET,
.target_size = TARGET_SIZE,
.mimetype = "x-bt/messageStatus",
- .open = any_open,
+ .open = message_set_status_open,
.close = any_close,
.read = any_read,
.write = any_write,
--
1.7.9.5
^ permalink raw reply related
* Re: Wii Balance Board vs. bluez
From: Florian Echtler @ 2012-09-13 5:59 UTC (permalink / raw)
To: David Herrmann; +Cc: linux-bluetooth
In-Reply-To: <CANq1E4RYuVy2b1GD2E4MsErbkGZgD6gnDaYeDmyWyYnKaze0Jg@mail.gmail.com>
David Herrmann <dh.herrmann@googlemail.com> wrote:
>"backported"? Why would you backport the hid-wiimote driver? Or do you
>mean "forwardport"? Anyway, the hid-wiimote driver does not have
>support for the wii-balance board as I do not have access to them.
By "backport", I just meant that I recompiled the driver from 3.5 for my 3.2 kernel :-)
>However, if you are willing to test it, I will send some patches which
>will implement it.
Absolutely, I'd be happy to test.
>Ouh, I see. I will send a patch fixing this to the BlueZ mailing list.
>I will put you on CC if you don't mind.
Thanks, I'll test this later today.
One additional question: it looks like this problem with the pairing is going
to pop up again with 3rd-party controllers, the new Wii U controller etc.
Would it make sense to create a new PIN option which users can select
explicitly?
Florian
--
SENT FROM MY PDP-11
^ permalink raw reply
* Re: Dropping connection (bit off-topic)
From: John Tobias @ 2012-09-13 2:52 UTC (permalink / raw)
To: Vinicius Costa Gomes; +Cc: linux-bluetooth
In-Reply-To: <CACUGKYMP7YRu1=P4Uf9T_RfOKQFPvZq8sK+GGi0T1jB6GDXcDQ@mail.gmail.com>
Hello again,
I enabled the GATT in my bluetoothd and found out that there was an
unimplemented attribute (below) and might be the reason why the iPhone
connection got disconnected after 30 secs.
2012-09-12 15:36:55.419980 > ACL data: handle 76 flags 0x02 dlen 9
ATT: Error (0x01)
Error: Attribute not found (10)
Read By Type req (0x08) on handle 0x0039
I would like to know if anyone here has a patch?.
Regards,
john
On Mon, Sep 10, 2012 at 5:45 PM, John Tobias <john.tobias.ph@gmail.com> wrote:
> thanks for the info.
>
> Regards,
>
> john
>
> On Mon, Sep 10, 2012 at 4:58 PM, Vinicius Costa Gomes
> <vinicius.gomes@openbossa.org> wrote:
>> Hi John,
>>
>> On 16:34 Mon 10 Sep, John Tobias wrote:
>>> Just to follow up, I used hcidump and found out an interesting info:
>>>
>>> bdaddr 5C:35:3C:72:B2:AF type 1
>>> > HCI Event: Command Status (0x0f) plen 4
>>> LE Create Connection (0x08|0x000d) status 0x00 ncmd 1
>>> > HCI Event: LE Meta Event (0x3e) plen 19
>>> LE Connection Complete
>>> status 0x00 handle 77, role master
>>> bdaddr 5C:35:3C:72:B2:AF (Random)
>>> > ACL data: handle 77 flags 0x02 dlen 11
>>> ATT: Read By Type req (0x08)
>>> start 0x0001, end 0xffff
>>> type-uuid 0x2a00
>>> > HCI Event: Disconn Complete (0x05) plen 4
>>> status 0x00 handle 77 reason 0x13
>>> Reason: Remote User Terminated Connection
>>>
>>>
>>> The iPhone was requesting for "ATT: Read By Type req (0x08)" and the
>>> gatttool seems not reponding. So, after 30 secs the iPhone dropped the
>>> connection.
>>>
>>> Any idea how the gatttool could respond to the said request?.
>>
>> The problem is that gatttool still hasn't any support for sending
>> responses. bluetoothd has, if you enable GATT support, 'EnableGatt' in
>> '/etc/bluetooth/main.conf' (usual location).
>>
>> But using 'bluetoothd' means that will need to use the D-Bus API, which
>> makes me wonder that having a simple GATT server inside gatttool makes
>> some sense, for some use cases.
>>
>>>
>>> Regards,
>>>
>>> john
>>>
>>>
>>> On Mon, Sep 10, 2012 at 2:35 PM, John Tobias <john.tobias.ph@gmail.com> wrote:
>>> > Hello Guys,
>>> >
>>> > I am using pandaboard with USB BLE dongle and an apps in iPhone that
>>> > do the advertising. I was able to connect to the said device from my
>>> > pandaboard using the following commands:
>>> >
>>> > gatttool -i hci1 -m 27 -I -b 74:xx:xx:xx:xx:xx
>>> > connect
>>> >
>>> > But, I've noticed that after 30 secs, the iPhone dropped off the
>>> > connection. I am just wondering if anyone here have tried playing with
>>> > the iPhone using the ble connection?.
>>> >
>>> > Regards,
>>> >
>>> > John
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>> Cheers,
>> --
>> Vinicius
^ permalink raw reply
* Re: [PATCH] Add support for Logitech Harmony Adapter for PS3
From: Antonio Ospite @ 2012-09-12 22:36 UTC (permalink / raw)
To: David Herrmann
Cc: Luiz Augusto von Dentz, Bastien Nocera, David Dillow,
linux-bluetooth
In-Reply-To: <CANq1E4SDXVHcumBbEA-4xpeuOQ0SjDxxtL_RqAiNYRPj6ccagQ@mail.gmail.com>
On Wed, 12 Sep 2012 22:26:04 +0200
David Herrmann <dh.herrmann@googlemail.com> wrote:
> Hi all
>
> On Wed, Sep 12, 2012 at 4:32 PM, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
> > Hi Bastien
> >
> > Getting the device does not seems to be a problem and we have a
> > similar driver already in the kernel, so Im really optimistic that it
> > will not take long to have this implemented in the kernel.
>
> Please, just redirect me to the information of the device protocols.
> It is pretty simple to make the kernel drivers work with these kinds
> of HID devices. There is no need to look at the wiimote driver as this
> one is pretty complex and does something totally different than normal
> HID drivers.
>
> I am willing to write the kernel drivers, but I need a short
> introduction or some pointers on how these devices work. I cannot
> afford buying these (yeah, not even 30$...) so I also need people
> willing to test these. This should be pretty easy, though.
>
> Also Jiri Kosina (the HID maintainer) is willing to accept any weird
> quirks we need for these devices. But please stop using fakehid. The
> idea is wrong and hidraw should be used to write userspace HID
> drivers. (uhid is only for transport side! So cannot be used here).
> The kernel HID community is also very active and helps a lot on
> maintaining the drivers.
>
> So if the devices only need some short setup-command during
> initialization and then they send HID reports whenever a button is
> pressed, then everything should be very easy to get working. Even
> auto-reconnect and 10min idle-disconnect are _very_ easy to get
> working in the kernel with the current HID infrastructure.
>
I too will take a look during the week-end about writing a kernel
driver, if it's not that much of an effort I might take the project
(no promises yet). I have a PS3 BD remote Bastien donated.
David AFAICS from profiles/input/fakehid.c[1], a custom report has to be
decoded and appropriate input events have to be sent.
Regards,
Antonio
[1]
http://git.kernel.org/?p=bluetooth/bluez.git;a=blob;f=profiles/input/fakehid.c;h=05f5894c7bd537d78a010b3905af9f98c0364002;hb=96f60e1411514fb4b0d8690aca1c02b3c6b32b9c
--
Antonio Ospite
http://ao2.it
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
^ permalink raw reply
* [PATCH] wiimote: add Wii Balance Board detection
From: David Herrmann @ 2012-09-12 21:32 UTC (permalink / raw)
To: linux-bluetooth; +Cc: dh.herrmann, johan.hedberg, floe
Add the name of the Wii Balance Board so it can be paired with BlueZ like
any other Wii Remote. Reported by Florian Echtler.
---
plugins/wiimote.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/plugins/wiimote.c b/plugins/wiimote.c
index 337d408..3d16966 100644
--- a/plugins/wiimote.c
+++ b/plugins/wiimote.c
@@ -76,6 +76,7 @@ static ssize_t wii_pincb(struct btd_adapter *adapter, struct btd_device *device,
name[sizeof(name) - 1] = 0;
if (g_str_equal(name, "Nintendo RVL-CNT-01") ||
+ g_str_equal(name, "Nintendo RVL-WBC-01") ||
(vendor == 0x057e && product == 0x0306)) {
DBG("Forcing fixed pin on detected wiimote %s", addr);
memcpy(pinbuf, &sba, 6);
--
1.7.12
^ permalink raw reply related
* Re: Wii Balance Board vs. bluez
From: David Herrmann @ 2012-09-12 21:10 UTC (permalink / raw)
To: Florian Echtler; +Cc: linux-bluetooth
In-Reply-To: <5050F5A9.5090401@butterbrot.org>
Hi Florian
On Wed, Sep 12, 2012 at 10:50 PM, Florian Echtler <floe@butterbrot.org> wrote:
> Hello everyone,
>
> I'm having some issues getting the Wii Balance Board to work with a recent
> Linux Bluetooth stack (Ubuntu 12.04, Kernel 3.2, bluez-4.101).
>
> After some minor patching [1], I've successfully paired the board with my
> machine. Automatic reconnect (when hitting the large front button) is also
> working.
Awesome. Automatic reconnect was a horrible mess to get working under
Linux but great to hear it works for others, too.
> However, the hid-wiimote driver, even the one I "backported" from kernel
> 3.5, apparently doesn't really support the balance board so far. I do get 5
> new device nodes as /dev/input/event*, but none of them actually report any
> data from the weight sensors.
"backported"? Why would you backport the hid-wiimote driver? Or do you
mean "forwardport"? Anyway, the hid-wiimote driver does not have
support for the wii-balance board as I do not have access to them.
However, if you are willing to test it, I will send some patches which
will implement it.
> Alternatively, I've tried the cwiid userspace library. This does work,
> however, I have to un-pair the board from bluetoothd first and put it into
> discoverable mode using the button on the bottom side, which is pretty
> inconvenient. If I keep the pairing active, the board will reconnect to
> bluetoothd itself and cwiid can't open a second L2CAP connection, AFAICT.
Yes, cwiid includes support for it but it is horribly written and a
3rd party application which doesn't utilize the kernel HID or bluez
infrastructure.
> So, my two questions are:
>
> - Is anybody currently working on integrating the balance board into
> hid-wiimote?
I am maintaining the hid-wiimote driver, but I am not particularly
working on balance-board support, yet. I am willing to do that, though
;)
> - Is there a way to retrieve the existing automatic connection from
> bluetoothd and pass it to a second userspace process (i.e., cwiid)?
No. No way. This is why I have written hid-wiimote.
>
> [1] https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1049266
Ouh, I see. I will send a patch fixing this to the BlueZ mailing list.
I will put you on CC if you don't mind.
Thanks for the report!
David
^ permalink raw reply
* Wii Balance Board vs. bluez
From: Florian Echtler @ 2012-09-12 20:50 UTC (permalink / raw)
To: linux-bluetooth
Hello everyone,
I'm having some issues getting the Wii Balance Board to work with a
recent Linux Bluetooth stack (Ubuntu 12.04, Kernel 3.2, bluez-4.101).
After some minor patching [1], I've successfully paired the board with
my machine. Automatic reconnect (when hitting the large front button) is
also working.
However, the hid-wiimote driver, even the one I "backported" from kernel
3.5, apparently doesn't really support the balance board so far. I do
get 5 new device nodes as /dev/input/event*, but none of them actually
report any data from the weight sensors.
Alternatively, I've tried the cwiid userspace library. This does work,
however, I have to un-pair the board from bluetoothd first and put it
into discoverable mode using the button on the bottom side, which is
pretty inconvenient. If I keep the pairing active, the board will
reconnect to bluetoothd itself and cwiid can't open a second L2CAP
connection, AFAICT.
So, my two questions are:
- Is anybody currently working on integrating the balance board into
hid-wiimote?
- Is there a way to retrieve the existing automatic connection from
bluetoothd and pass it to a second userspace process (i.e., cwiid)?
Thanks!
Florian
[1] https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/1049266
--
SENT FROM MY DEC VT50 TERMINAL
^ permalink raw reply
* Re: [PATCH] Add support for Logitech Harmony Adapter for PS3
From: David Herrmann @ 2012-09-12 20:26 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Bastien Nocera, David Dillow, linux-bluetooth
In-Reply-To: <CABBYNZLwXhF0gixPGKUTJY4sZ7EHynTYmHzGtiZsoRGXgeEFaw@mail.gmail.com>
Hi all
On Wed, Sep 12, 2012 at 4:32 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Bastien
>
> Getting the device does not seems to be a problem and we have a
> similar driver already in the kernel, so Im really optimistic that it
> will not take long to have this implemented in the kernel.
Please, just redirect me to the information of the device protocols.
It is pretty simple to make the kernel drivers work with these kinds
of HID devices. There is no need to look at the wiimote driver as this
one is pretty complex and does something totally different than normal
HID drivers.
I am willing to write the kernel drivers, but I need a short
introduction or some pointers on how these devices work. I cannot
afford buying these (yeah, not even 30$...) so I also need people
willing to test these. This should be pretty easy, though.
Also Jiri Kosina (the HID maintainer) is willing to accept any weird
quirks we need for these devices. But please stop using fakehid. The
idea is wrong and hidraw should be used to write userspace HID
drivers. (uhid is only for transport side! So cannot be used here).
The kernel HID community is also very active and helps a lot on
maintaining the drivers.
So if the devices only need some short setup-command during
initialization and then they send HID reports whenever a button is
pressed, then everything should be very easy to get working. Even
auto-reconnect and 10min idle-disconnect are _very_ easy to get
working in the kernel with the current HID infrastructure.
Thanks!
David
^ permalink raw reply
* Re: Removal of fakehid support
From: Jeff Hansen @ 2012-09-12 19:51 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth, Johan Hedberg
In-Reply-To: <CABBYNZL8r5EM4FpkUMLzMfuD3AtQqmu5LEwCbXTu=h+sxEntmQ@mail.gmail.com>
Sure, I can for now, but please don't release 4.102 until the kernel
driver is ready !! I don't want any distros picking up a bluez with
*less* functionality than before (as you can imagine)!
-Jeff
On 09/12/2012 01:45 PM, Luiz Augusto von Dentz wrote:
> Hi Jeff,
>
> On Wed, Sep 12, 2012 at 10:23 PM, Jeff Hansen <x@jeffhansen.com> wrote:
>> Johan,
>>
>> AFAICT there is no actual implementation for the PS3 remote in the
>> kernel. How can I use my PS3 remote now that fakehid has been removed?
> Check the thread about logitech armony, we will have to write the
> driver. While we are doing that can't you use some older version of
> BlueZ?
>
>
>
--
---------------------------------------------------
"If someone's gotta do it, it might as well be me."
x@jeffhansen.com
^ permalink raw reply
* Re: Removal of fakehid support
From: Luiz Augusto von Dentz @ 2012-09-12 19:45 UTC (permalink / raw)
To: Jeff Hansen; +Cc: linux-bluetooth, Johan Hedberg
In-Reply-To: <5050E143.4010400@jeffhansen.com>
Hi Jeff,
On Wed, Sep 12, 2012 at 10:23 PM, Jeff Hansen <x@jeffhansen.com> wrote:
> Johan,
>
> AFAICT there is no actual implementation for the PS3 remote in the
> kernel. How can I use my PS3 remote now that fakehid has been removed?
Check the thread about logitech armony, we will have to write the
driver. While we are doing that can't you use some older version of
BlueZ?
--
Luiz Augusto von Dentz
^ permalink raw reply
* Removal of fakehid support
From: Jeff Hansen @ 2012-09-12 19:23 UTC (permalink / raw)
To: linux-bluetooth, Johan Hedberg
Johan,
AFAICT there is no actual implementation for the PS3 remote in the
kernel. How can I use my PS3 remote now that fakehid has been removed?
-Jeff
--
---------------------------------------------------
"If someone's gotta do it, it might as well be me."
x@jeffhansen.com
^ permalink raw reply
* Re: pull request: bluetooth 2012-09-08
From: Johan Hedberg @ 2012-09-12 18:31 UTC (permalink / raw)
To: John W. Linville
Cc: Gustavo Padovan, linux-wireless, linux-bluetooth, linux-kernel
In-Reply-To: <20120912181309.GB28823@tuxdriver.com>
Hi John,
On Wed, Sep 12, 2012, John W. Linville wrote:
> "Bluetooth: mgmt: Implement support for passkey notification" doesn't
> look like a fix at all.
This fixes pairing with keyboards that have a "KeyboardOnly" IO
capability. This used to work previously in a world where user space
spoke HCI directly to the Bluetooth controller but is broken with any
user space version using the recently introduced management interface.
> "Bluetooth: Update management interface revision" is suspect. It kinda
> makes sense, but if it is so important than it should have been merged
> much earlier, no?
This patch is due to the first one. We increment the revision every time
something gets added to the management interface. FWIW, I've tested that
pairing now works with keyboards of this kind with these patches.
Johan
^ permalink raw reply
* Re: pull request: bluetooth 2012-09-08
From: Gustavo Padovan @ 2012-09-12 18:30 UTC (permalink / raw)
To: John W. Linville; +Cc: linux-wireless, linux-bluetooth, linux-kernel
In-Reply-To: <20120912181309.GB28823@tuxdriver.com>
Hi John,
* John W. Linville <linville@tuxdriver.com> [2012-09-12 14:13:10 -0400]:
> On Sat, Sep 08, 2012 at 06:59:56PM -0300, Gustavo Padovan wrote:
> > Hi John,
> >
> > A few more fixes to 3.6, here we have four important fix to the MGMT interface,
> > two from Johan Hedberg and Andrzej Kaczmarek. Andrei fixed a free on
> > uninitialized memory and I added support for Broadcom/Foxconn devices.
>
> "Bluetooth: mgmt: Implement support for passkey notification" doesn't
> look like a fix at all.
It is a fix in the sense that we were failing to work with some keyboards out
there that only support Bluetooth SSP KeyboardOnly IO capability and there are
few of those in the market now. But yes, we are not fix any crash, etc in the
kernel, not critical though. It is just improving compatibility of the
Bluetooth stack (which is important too). It's up to you merge this or not.
>
> "Bluetooth: Update management interface revision" is suspect. It kinda
> makes sense, but if it is so important than it should have been merged
> much earlier, no?
Not really, but we like to bump version when we do significative changes to
MGMT like the above.
>
> "Bluetooth: Add USB_VENDOR_AND_INTERFACE_INFO() for Broadcom/Foxconn"
> might normally be OK, but it is getting late enough in the cycle
> that I would prefer to delay any device ID patches until the next
> merge window.
Ok.
>
> The others look fine. Do you want me to merge them directly?
> Or would you rather respin your pull request?
You can pull them directly, I'll redo my tree once they get pulled.
Thanks, John.
Gustavo
^ permalink raw reply
* Re: pull request: bluetooth 2012-09-08
From: John W. Linville @ 2012-09-12 18:13 UTC (permalink / raw)
To: Gustavo Padovan, linux-wireless, linux-bluetooth, linux-kernel
In-Reply-To: <20120908215956.GP5788@joana>
On Sat, Sep 08, 2012 at 06:59:56PM -0300, Gustavo Padovan wrote:
> Hi John,
>
> A few more fixes to 3.6, here we have four important fix to the MGMT interface,
> two from Johan Hedberg and Andrzej Kaczmarek. Andrei fixed a free on
> uninitialized memory and I added support for Broadcom/Foxconn devices.
"Bluetooth: mgmt: Implement support for passkey notification" doesn't
look like a fix at all.
"Bluetooth: Update management interface revision" is suspect. It kinda
makes sense, but if it is so important than it should have been merged
much earlier, no?
"Bluetooth: Add USB_VENDOR_AND_INTERFACE_INFO() for Broadcom/Foxconn"
might normally be OK, but it is getting late enough in the cycle
that I would prefer to delay any device ID patches until the next
merge window.
The others look fine. Do you want me to merge them directly?
Or would you rather respin your pull request?
John
> Please pull, or let me know of any problems. Thanks.
>
> Gustavo
>
> The following changes since commit f10723841e624c0726c70356b31d91befed01dd6:
>
> libertas sdio: fix suspend when interface is down (2012-09-05 14:53:36 -0400)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth master
>
> for you to fetch changes up to b6f04c364ef853d8baa8949be20ef708000bcb97:
>
> Bluetooth: Fix freeing uninitialized delayed works (2012-09-08 17:27:52 -0300)
>
> ----------------------------------------------------------------
> Andrei Emeltchenko (1):
> Bluetooth: Fix freeing uninitialized delayed works
>
> Andrzej Kaczmarek (2):
> Bluetooth: mgmt: Fix enabling SSP while powered off
> Bluetooth: mgmt: Fix enabling LE while powered off
>
> Gustavo Padovan (1):
> Bluetooth: Add USB_VENDOR_AND_INTERFACE_INFO() for Broadcom/Foxconn
>
> Johan Hedberg (2):
> Bluetooth: mgmt: Implement support for passkey notification
> Bluetooth: Update management interface revision
>
> drivers/bluetooth/btusb.c | 2 +-
> include/net/bluetooth/hci.h | 18 ++++++++++++
> include/net/bluetooth/hci_core.h | 5 ++++
> include/net/bluetooth/mgmt.h | 7 +++++
> net/bluetooth/hci_event.c | 67 ++++++++++++++++++++++++++++++++++++++++++
> net/bluetooth/l2cap_core.c | 2 +-
> net/bluetooth/mgmt.c | 35 +++++++++++++++++++++-
> 7 files changed, 133 insertions(+), 3 deletions(-)
>
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH] Add support for Logitech Harmony Adapter for PS3
From: Luiz Augusto von Dentz @ 2012-09-12 14:32 UTC (permalink / raw)
To: Bastien Nocera; +Cc: David Dillow, linux-bluetooth
In-Reply-To: <1347456657.23874.29.camel@sirocco.hadess.net>
Hi Bastien,
On Wed, Sep 12, 2012 at 4:30 PM, Bastien Nocera <hadess@hadess.net> wrote:
> Em Wed, 2012-09-12 às 13:56 +0300, Luiz Augusto von Dentz escreveu:
>> Hi Bastien,
>>
>> On Tue, Sep 11, 2012 at 11:17 PM, Bastien Nocera <hadess@hadess.net> wrote:
>> > Em Tue, 2012-09-11 às 17:21 +0300, Luiz Augusto von Dentz escreveu:
>> >> Hi Bastien,
>> >>
>> >> On Mon, Sep 10, 2012 at 10:03 PM, Luiz Augusto von Dentz
>> >> <luiz.dentz@gmail.com> wrote:
>> >> > Hi Bastien,
>> >> >
>> >> > On Mon, Sep 10, 2012 at 4:58 PM, Luiz Augusto von Dentz
>> >> > <luiz.dentz@gmail.com> wrote:
>> >> >> Hi Bastien,
>> >> >>
>> >> >> On Mon, Sep 10, 2012 at 4:47 PM, Bastien Nocera <hadess@hadess.net> wrote:
>> >> >>> Em Mon, 2012-09-10 às 16:11 +0300, Luiz Augusto von Dentz escreveu:
>> >> >>>> Hi David, Bastien,
>> >> >>>>
>> >> >>>> So we are plannin to rid of the fakehid.c in favor of implementing it
>> >> >>>> properly inside the kernel similarly to what was done to wiimote, so
>> >> >>>> is there any obstacle for doing that?
>> >> >>>>
>> >> >>>> The kernel seems to already have some support for sixaxis in
>> >> >>>> drivers/hid/hid-sony.c, so I suppose the following would enable us to
>> >> >>>> use it:
>> >> >>>
>> >> >>> It won't. They're not the same hardware.
>> >> >>
>> >> >> What hardware is that then? And why wouldn't the kernel be able to
>> >> >> support even if it is a different driver?
>> >> >
>> >> > So what exactly are the difference between 0x0268 and 0x0306? And why
>> >> > sixpair.c save as 0x0268 while fakeinput.c uses 0x0306?
>> >> >
>> >> > Also, after fixing sixpair.c to be able to compile it does add to the
>> >> > storage but it does not create any object until bluetoothd is
>> >> > restarted and even after restart it does not allow the device to
>> >> > connect because it does has the record (although this can be fixed by
>> >> > automatically add the UUID once we find out it is attempt to connect).
>> >>
>> >> So apparently the 0x0306 device is the br remote controller, not the
>> >> sixaxis joystick, sorry about the confusion.
>> >
>> > Completely different protocols for the devices, indeed.
>> >
>> >> Anyway regardless of
>> >> being a different device I thing we should move this code to kernel as
>> >> it was done for wiimote.
>> >
>> > Certainly, but until somebody writes the code (I already have at least 3
>> > drivers to submit to the kernel that I've not had time to handle,
>> > include one Bluetooth device), I think it would be nice not to drop
>> > support for the existing hardware. The cost of David's patch is close to
>> > none.
>>
>> Do you have any code already?
>
> Why would I? I don't have time to handle the 3 other drivers, and my BD
> remote is now in a shipping container.
>
>> Anyway it is now removed from upstream,
>
> Why would you want to do that when we don't have a replacement in the
> kernel yet? I just spent time getting that timeout patch upstreamed,
> Johan even merged up David's patch, and 3 days after you remove the
> whole functionality.
Actually it wasn't me who removed:
commit 2e16cbf32569d834750f47107ee9c19954dd28bf
Author: Johan Hedberg <johan.hedberg@intel.com>
Date: Mon Sep 10 15:51:23 2012 +0300
input: Remove fakhid functionality
The HSP code conflicts with a real HSP implementation and the PS3
support should be done through the kernel.
So Johan supports the decision as well.
>> I will try to get one of these devices myself and start writing some
>> code if you don't have it done already.
>
> Around $20:
> http://www.amazon.com/Media-Blu-ray-Remote-Control-Playstation-3/dp/B0050SX9I2/
>
> Really not happy we're removing the functionality without having
> adequate replacement. That's not something you do with hardware
> enablement. I'm ready to take bets on the length of time where there's
> no support for the remote in distributions because it was removed in
> bluez, and not supported in the kernel.
In one way or the other the changes wouldn't be perfectly aligned, but
we need to move ahead with 5.0 release which probably has higher
priority than just 1 or 2 devices. Now don't get me wrong, I do think
having support for as many devices as possible is great but there is a
much bigger effort in doing the necessary changes for 5.0 and the
fakeinput was in the way of that so we had to make the decision to
remove it since the kernel driver we can do in parallel. Im not sure
how would you do it differently, if we had to wait until the kernel
has the driver we would have to test it against patched BlueZ which is
not that great either.
Getting the device does not seems to be a problem and we have a
similar driver already in the kernel, so Im really optimistic that it
will not take long to have this implemented in the kernel.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] Add support for Logitech Harmony Adapter for PS3
From: Bastien Nocera @ 2012-09-12 13:30 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: David Dillow, linux-bluetooth
In-Reply-To: <CABBYNZ+gpheC9sNeTp2uvDFBV-yPs+cY4PUR2omPt_kLTCafKw@mail.gmail.com>
Em Wed, 2012-09-12 às 13:56 +0300, Luiz Augusto von Dentz escreveu:
> Hi Bastien,
>
> On Tue, Sep 11, 2012 at 11:17 PM, Bastien Nocera <hadess@hadess.net> wrote:
> > Em Tue, 2012-09-11 às 17:21 +0300, Luiz Augusto von Dentz escreveu:
> >> Hi Bastien,
> >>
> >> On Mon, Sep 10, 2012 at 10:03 PM, Luiz Augusto von Dentz
> >> <luiz.dentz@gmail.com> wrote:
> >> > Hi Bastien,
> >> >
> >> > On Mon, Sep 10, 2012 at 4:58 PM, Luiz Augusto von Dentz
> >> > <luiz.dentz@gmail.com> wrote:
> >> >> Hi Bastien,
> >> >>
> >> >> On Mon, Sep 10, 2012 at 4:47 PM, Bastien Nocera <hadess@hadess.net> wrote:
> >> >>> Em Mon, 2012-09-10 às 16:11 +0300, Luiz Augusto von Dentz escreveu:
> >> >>>> Hi David, Bastien,
> >> >>>>
> >> >>>> So we are plannin to rid of the fakehid.c in favor of implementing it
> >> >>>> properly inside the kernel similarly to what was done to wiimote, so
> >> >>>> is there any obstacle for doing that?
> >> >>>>
> >> >>>> The kernel seems to already have some support for sixaxis in
> >> >>>> drivers/hid/hid-sony.c, so I suppose the following would enable us to
> >> >>>> use it:
> >> >>>
> >> >>> It won't. They're not the same hardware.
> >> >>
> >> >> What hardware is that then? And why wouldn't the kernel be able to
> >> >> support even if it is a different driver?
> >> >
> >> > So what exactly are the difference between 0x0268 and 0x0306? And why
> >> > sixpair.c save as 0x0268 while fakeinput.c uses 0x0306?
> >> >
> >> > Also, after fixing sixpair.c to be able to compile it does add to the
> >> > storage but it does not create any object until bluetoothd is
> >> > restarted and even after restart it does not allow the device to
> >> > connect because it does has the record (although this can be fixed by
> >> > automatically add the UUID once we find out it is attempt to connect).
> >>
> >> So apparently the 0x0306 device is the br remote controller, not the
> >> sixaxis joystick, sorry about the confusion.
> >
> > Completely different protocols for the devices, indeed.
> >
> >> Anyway regardless of
> >> being a different device I thing we should move this code to kernel as
> >> it was done for wiimote.
> >
> > Certainly, but until somebody writes the code (I already have at least 3
> > drivers to submit to the kernel that I've not had time to handle,
> > include one Bluetooth device), I think it would be nice not to drop
> > support for the existing hardware. The cost of David's patch is close to
> > none.
>
> Do you have any code already?
Why would I? I don't have time to handle the 3 other drivers, and my BD
remote is now in a shipping container.
> Anyway it is now removed from upstream,
Why would you want to do that when we don't have a replacement in the
kernel yet? I just spent time getting that timeout patch upstreamed,
Johan even merged up David's patch, and 3 days after you remove the
whole functionality.
> I will try to get one of these devices myself and start writing some
> code if you don't have it done already.
Around $20:
http://www.amazon.com/Media-Blu-ray-Remote-Control-Playstation-3/dp/B0050SX9I2/
Really not happy we're removing the functionality without having
adequate replacement. That's not something you do with hardware
enablement. I'm ready to take bets on the length of time where there's
no support for the remote in distributions because it was removed in
bluez, and not supported in the kernel.
^ permalink raw reply
* Re: [PATCH] Add support for Logitech Harmony Adapter for PS3
From: David Dillow @ 2012-09-12 13:17 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Bastien Nocera, linux-bluetooth
In-Reply-To: <CABBYNZ+gpheC9sNeTp2uvDFBV-yPs+cY4PUR2omPt_kLTCafKw@mail.gmail.com>
On Wed, 2012-09-12 at 13:56 +0300, Luiz Augusto von Dentz wrote:
> Hi Bastien,
>
> On Tue, Sep 11, 2012 at 11:17 PM, Bastien Nocera <hadess@hadess.net> wrote:
> > Certainly, but until somebody writes the code (I already have at least 3
> > drivers to submit to the kernel that I've not had time to handle,
> > include one Bluetooth device), I think it would be nice not to drop
> > support for the existing hardware. The cost of David's patch is close to
> > none.
>
> Do you have any code already? Anyway it is now removed from upstream,
> I will try to get one of these devices myself and start writing some
> code if you don't have it done already.
I first looked to the kernel for support, but found it in user space and
stopped. I'll take a stab a it, with wiimote as a reference -- it really
shouldn't be too hard.
But it'll take a little time -- the device is in use for MythTV, so I
risk a mutiny if I try to test before bedtime... ;)
^ permalink raw reply
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