Hi Petri,
On Mon, Apr 20, 2015 at 7:34 PM, Petri Gynther <pgynther@xxxxxxxxxx> wrote:
> Hi Luiz,
>
> On Mon, Apr 20, 2015 at 7:50 AM, Luiz Augusto von Dentz
> <luiz.dentz@xxxxxxxxx> wrote:
>> Hi Petri,
>>
>> On Sat, Apr 18, 2015 at 1:00 AM, Petri Gynther <pgynther@xxxxxxxxxx> wrote:
>>> On HoG device reconnect, re-enable HoG report notifications every
>>> time by writing the client characteristic configuration attribute
>>> of each HoG report.
>>>
>>> Doing this on every reconnect:
>>> 1. ensures that HoG report notifications are always enabled
>>> (e.g. lost report notification state in battery swap).
>>> 2. signals to HoG device that it can start sending HoG reports
>>> (e.g. buffered keypresses while the reconnect is still pending).
>>
>> Is that happening for a specific device? For 1 I suppose it would
>> loose the paring keys as well which means we would not be able to
>> connect at all as HoG mandates pairing, or does it loose only the CCC
>> configuration? Reason 2 is not necessary the behavior every device
>> would have, for example I don't expect a mouse to buffer anything and
>> even a keyboard may buffer only the last key pressed since it might
>> have very little memory to spend in buffering, anyway I suppose reason
>> 1 is what you should really concentrate to tell us what is going on.
>>
>
> On the device that I'm working on, pairing info is stored in
> persistent storage, so it survives battery swap. However, I'm not sure
> yet about HoG report notification enable/disable state. Waiting for
> confirmation from vendor.
I would expect it to store the CCC state as well in the persistent
storage if one exists.
> Anyways, we are seeing (2). The first keypress from HoG device is
> getting lost on reconnect, leading to bad user experience. The device
> is sending the keypress immediately when the connection is good, but
> too early before BlueZ has managed to re-register the handler with
> g_attrib_register(). During the reconnect, the HoG device has no way
> of knowing when BlueZ is ready and has registered the handler. So, to
> provide this indication, I propose to re-enable the HoG report
> notification every time.
But I already fixed this problem not long ago:
commit 14569a33418a4c1dc07cca090b9336373d63a085
Author: Luiz Augusto von Dentz <luiz.von.dentz@xxxxxxxxx>
Date: Wed Mar 11 21:23:55 2015 +0200
core/device: Fix not handling notification
attio callbacks needs to be triggered as soon as possible once connected
otherwise profiles such as HoG may miss notification that are sent while
bt_gatt_client is doing MTU exchange.
Perhaps you don't have this patch?
>>> ---
>>> profiles/input/hog.c | 5 +----
>>> 1 file changed, 1 insertion(+), 4 deletions(-)
>>>
>>> diff --git a/profiles/input/hog.c b/profiles/input/hog.c
>>> index c55443c..690fd43 100644
>>> --- a/profiles/input/hog.c
>>> +++ b/profiles/input/hog.c
>>> @@ -842,10 +842,7 @@ static void attio_connected_cb(GAttrib *attrib, gpointer user_data)
>>> for (l = hogdev->reports; l; l = l->next) {
>>> struct report *r = l->data;
>>>
>>> - r->notifyid = g_attrib_register(hogdev->attrib,
>>> - ATT_OP_HANDLE_NOTIFY,
>>> - r->decl->value_handle,
>>> - report_value_cb, r, NULL);
>>> + enable_report_notification(r);
>>> }
>>> }
>>>
>>> --
>>> 2.2.0.rc0.207.ga3a616c
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>> --
>> Luiz Augusto von Dentz
--
Luiz Augusto von Dentz
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
