* HoG uHID device not destroyed on disconnect
@ 2016-12-22 6:06 Juha Kuikka
2016-12-22 9:03 ` Luiz Augusto von Dentz
0 siblings, 1 reply; 4+ messages in thread
From: Juha Kuikka @ 2016-12-22 6:06 UTC (permalink / raw)
To: linux-bluetooth
Hi,
It seems that when an HID-over-GATT (HoG) device connects an uHID
devive is created for it. I would expect it to get destroyed upon
disconnect but it seems to linger around.
This can be demonstrated using bluetoothctl. Here I am using a
Microsoft Arc Touch Mouse.
Paired and connected:
[bluetooth]# pair C9:33:31:6B:03:A9
Attempting to pair with C9:33:31:6B:03:A9
[CHG] Device C9:33:31:6B:03:A9 Connected: yes
[CHG] Device C9:33:31:6B:03:A9 UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Device C9:33:31:6B:03:A9 UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Device C9:33:31:6B:03:A9 UUIDs: 0000180a-0000-1000-8000-00805f9b34fb
[CHG] Device C9:33:31:6B:03:A9 UUIDs: 0000180f-0000-1000-8000-00805f9b34fb
[CHG] Device C9:33:31:6B:03:A9 UUIDs: 00001812-0000-1000-8000-00805f9b34fb
[CHG] Device C9:33:31:6B:03:A9 ServicesResolved: yes
[CHG] Device C9:33:31:6B:03:A9 Paired: yes
[NEW] Primary Service
/org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0008
00001801-0000-1000-8000-00805f9b34fb
Generic Attribute Profile
[NEW] Characteristic
/org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0008/char0009
00002a05-0000-1000-8000-00805f9b34fb
Service Changed
[NEW] Descriptor
/org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0008/char0009/desc000b
00002902-0000-1000-8000-00805f9b34fb
Client Characteristic Configuration
[NEW] Primary Service
/org/bluez/hci0/dev_C9_33_31_6B_03_A9/service000c
0000180a-0000-1000-8000-00805f9b34fb
Device Information
[NEW] Characteristic
/org/bluez/hci0/dev_C9_33_31_6B_03_A9/service000c/char000d
00002a29-0000-1000-8000-00805f9b34fb
Manufacturer Name String
[NEW] Characteristic
/org/bluez/hci0/dev_C9_33_31_6B_03_A9/service000c/char000f
00002a50-0000-1000-8000-00805f9b34fb
PnP ID
[NEW] Primary Service
/org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0011
0000180f-0000-1000-8000-00805f9b34fb
Battery Service
[NEW] Characteristic
/org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0011/char0012
00002a19-0000-1000-8000-00805f9b34fb
Battery Level
[NEW] Descriptor
/org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0011/char0012/desc0014
00002902-0000-1000-8000-00805f9b34fb
Client Characteristic Configuration
Pairing successful
[CHG] Device C9:33:31:6B:03:A9 Modalias: usb:v045Ep0804d0001
[Arc Touch BT Mouse]# connect C9:33:31:6B:03:A9
Attempting to connect to C9:33:31:6B:03:A9
Connection successful
And here it is disconnected:
[CHG] Device C9:33:31:6B:03:A9 ServicesResolved: no
[CHG] Device C9:33:31:6B:03:A9 Connected: no
After disconnection, the HID device is still present:
$ ls -l /sys/class/hidraw/ /dev/hidraw*
crw------- 1 root root 244, 0 Dec 21 21:45 /dev/hidraw0
/sys/class/hidraw/:
total 0
lrwxrwxrwx 1 root root 0 Dec 21 21:52 hidraw0 ->
../../devices/virtual/misc/uhid/0005:0000:0000.0019/hidraw/hidraw0
The zero VID&PID of the HID device differ from the modalias due to
another bug I just posted about.
If I Remove() the the device, the HID device gets destroyed but it
lingers until then.
This behavior seems to be caused by the fact that the HoG service is
kept alive between connections and the lifetime of the included
bt_uhid is not limited between connections.
Cheers,
- Juha
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: HoG uHID device not destroyed on disconnect
2016-12-22 6:06 HoG uHID device not destroyed on disconnect Juha Kuikka
@ 2016-12-22 9:03 ` Luiz Augusto von Dentz
2016-12-22 17:34 ` Juha Kuikka
0 siblings, 1 reply; 4+ messages in thread
From: Luiz Augusto von Dentz @ 2016-12-22 9:03 UTC (permalink / raw)
To: Juha Kuikka; +Cc: linux-bluetooth
Hi Juha,
On Thu, Dec 22, 2016 at 8:06 AM, Juha Kuikka <juha.kuikka@gmail.com> wrote:
> Hi,
>
> It seems that when an HID-over-GATT (HoG) device connects an uHID
> devive is created for it. I would expect it to get destroyed upon
> disconnect but it seems to linger around.
>
> This can be demonstrated using bluetoothctl. Here I am using a
> Microsoft Arc Touch Mouse.
>
> Paired and connected:
>
> [bluetooth]# pair C9:33:31:6B:03:A9
> Attempting to pair with C9:33:31:6B:03:A9
> [CHG] Device C9:33:31:6B:03:A9 Connected: yes
> [CHG] Device C9:33:31:6B:03:A9 UUIDs: 00001800-0000-1000-8000-00805f9b34fb
> [CHG] Device C9:33:31:6B:03:A9 UUIDs: 00001801-0000-1000-8000-00805f9b34fb
> [CHG] Device C9:33:31:6B:03:A9 UUIDs: 0000180a-0000-1000-8000-00805f9b34fb
> [CHG] Device C9:33:31:6B:03:A9 UUIDs: 0000180f-0000-1000-8000-00805f9b34fb
> [CHG] Device C9:33:31:6B:03:A9 UUIDs: 00001812-0000-1000-8000-00805f9b34fb
> [CHG] Device C9:33:31:6B:03:A9 ServicesResolved: yes
> [CHG] Device C9:33:31:6B:03:A9 Paired: yes
> [NEW] Primary Service
> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0008
> 00001801-0000-1000-8000-00805f9b34fb
> Generic Attribute Profile
> [NEW] Characteristic
> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0008/char0009
> 00002a05-0000-1000-8000-00805f9b34fb
> Service Changed
> [NEW] Descriptor
> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0008/char0009/desc000b
> 00002902-0000-1000-8000-00805f9b34fb
> Client Characteristic Configuration
> [NEW] Primary Service
> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service000c
> 0000180a-0000-1000-8000-00805f9b34fb
> Device Information
> [NEW] Characteristic
> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service000c/char000d
> 00002a29-0000-1000-8000-00805f9b34fb
> Manufacturer Name String
> [NEW] Characteristic
> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service000c/char000f
> 00002a50-0000-1000-8000-00805f9b34fb
> PnP ID
> [NEW] Primary Service
> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0011
> 0000180f-0000-1000-8000-00805f9b34fb
> Battery Service
> [NEW] Characteristic
> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0011/char0012
> 00002a19-0000-1000-8000-00805f9b34fb
> Battery Level
> [NEW] Descriptor
> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0011/char0012/desc0014
> 00002902-0000-1000-8000-00805f9b34fb
> Client Characteristic Configuration
> Pairing successful
> [CHG] Device C9:33:31:6B:03:A9 Modalias: usb:v045Ep0804d0001
> [Arc Touch BT Mouse]# connect C9:33:31:6B:03:A9
> Attempting to connect to C9:33:31:6B:03:A9
> Connection successful
>
> And here it is disconnected:
>
> [CHG] Device C9:33:31:6B:03:A9 ServicesResolved: no
> [CHG] Device C9:33:31:6B:03:A9 Connected: no
>
> After disconnection, the HID device is still present:
>
> $ ls -l /sys/class/hidraw/ /dev/hidraw*
> crw------- 1 root root 244, 0 Dec 21 21:45 /dev/hidraw0
>
> /sys/class/hidraw/:
> total 0
> lrwxrwxrwx 1 root root 0 Dec 21 21:52 hidraw0 ->
> ../../devices/virtual/misc/uhid/0005:0000:0000.0019/hidraw/hidraw0
>
> The zero VID&PID of the HID device differ from the modalias due to
> another bug I just posted about.
>
> If I Remove() the the device, the HID device gets destroyed but it
> lingers until then.
>
> This behavior seems to be caused by the fact that the HoG service is
> kept alive between connections and the lifetime of the included
> bt_uhid is not limited between connections.
This is actually on purpose so we don't keep creating more and more
device nodes every time the device reconnects, but we should
definitely fix the problem with DIS and HoG.
--
Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: HoG uHID device not destroyed on disconnect
2016-12-22 9:03 ` Luiz Augusto von Dentz
@ 2016-12-22 17:34 ` Juha Kuikka
2016-12-22 18:21 ` Luiz Augusto von Dentz
0 siblings, 1 reply; 4+ messages in thread
From: Juha Kuikka @ 2016-12-22 17:34 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
Hi Luiz,
On Thu, Dec 22, 2016 at 1:03 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Juha,
>
> On Thu, Dec 22, 2016 at 8:06 AM, Juha Kuikka <juha.kuikka@gmail.com> wrote:
>> Hi,
>>
>> It seems that when an HID-over-GATT (HoG) device connects an uHID
>> devive is created for it. I would expect it to get destroyed upon
>> disconnect but it seems to linger around.
>>
>> This can be demonstrated using bluetoothctl. Here I am using a
>> Microsoft Arc Touch Mouse.
>>
>> Paired and connected:
>>
>> [bluetooth]# pair C9:33:31:6B:03:A9
>> Attempting to pair with C9:33:31:6B:03:A9
>> [CHG] Device C9:33:31:6B:03:A9 Connected: yes
>> [CHG] Device C9:33:31:6B:03:A9 UUIDs: 00001800-0000-1000-8000-00805f9b34fb
>> [CHG] Device C9:33:31:6B:03:A9 UUIDs: 00001801-0000-1000-8000-00805f9b34fb
>> [CHG] Device C9:33:31:6B:03:A9 UUIDs: 0000180a-0000-1000-8000-00805f9b34fb
>> [CHG] Device C9:33:31:6B:03:A9 UUIDs: 0000180f-0000-1000-8000-00805f9b34fb
>> [CHG] Device C9:33:31:6B:03:A9 UUIDs: 00001812-0000-1000-8000-00805f9b34fb
>> [CHG] Device C9:33:31:6B:03:A9 ServicesResolved: yes
>> [CHG] Device C9:33:31:6B:03:A9 Paired: yes
>> [NEW] Primary Service
>> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0008
>> 00001801-0000-1000-8000-00805f9b34fb
>> Generic Attribute Profile
>> [NEW] Characteristic
>> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0008/char0009
>> 00002a05-0000-1000-8000-00805f9b34fb
>> Service Changed
>> [NEW] Descriptor
>> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0008/char0009/desc000b
>> 00002902-0000-1000-8000-00805f9b34fb
>> Client Characteristic Configuration
>> [NEW] Primary Service
>> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service000c
>> 0000180a-0000-1000-8000-00805f9b34fb
>> Device Information
>> [NEW] Characteristic
>> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service000c/char000d
>> 00002a29-0000-1000-8000-00805f9b34fb
>> Manufacturer Name String
>> [NEW] Characteristic
>> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service000c/char000f
>> 00002a50-0000-1000-8000-00805f9b34fb
>> PnP ID
>> [NEW] Primary Service
>> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0011
>> 0000180f-0000-1000-8000-00805f9b34fb
>> Battery Service
>> [NEW] Characteristic
>> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0011/char0012
>> 00002a19-0000-1000-8000-00805f9b34fb
>> Battery Level
>> [NEW] Descriptor
>> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0011/char0012/desc0014
>> 00002902-0000-1000-8000-00805f9b34fb
>> Client Characteristic Configuration
>> Pairing successful
>> [CHG] Device C9:33:31:6B:03:A9 Modalias: usb:v045Ep0804d0001
>> [Arc Touch BT Mouse]# connect C9:33:31:6B:03:A9
>> Attempting to connect to C9:33:31:6B:03:A9
>> Connection successful
>>
>> And here it is disconnected:
>>
>> [CHG] Device C9:33:31:6B:03:A9 ServicesResolved: no
>> [CHG] Device C9:33:31:6B:03:A9 Connected: no
>>
>> After disconnection, the HID device is still present:
>>
>> $ ls -l /sys/class/hidraw/ /dev/hidraw*
>> crw------- 1 root root 244, 0 Dec 21 21:45 /dev/hidraw0
>>
>> /sys/class/hidraw/:
>> total 0
>> lrwxrwxrwx 1 root root 0 Dec 21 21:52 hidraw0 ->
>> ../../devices/virtual/misc/uhid/0005:0000:0000.0019/hidraw/hidraw0
>>
>> The zero VID&PID of the HID device differ from the modalias due to
>> another bug I just posted about.
>>
>> If I Remove() the the device, the HID device gets destroyed but it
>> lingers until then.
>>
>> This behavior seems to be caused by the fact that the HoG service is
>> kept alive between connections and the lifetime of the included
>> bt_uhid is not limited between connections.
>
> This is actually on purpose so we don't keep creating more and more
> device nodes every time the device reconnects, but we should
> definitely fix the problem with DIS and HoG.
I am not sure I understand the reasoning here, can you elaborate please?
If upon disconnect we close() the uhid device or use the UHID_DESTROY
that will remove the device nodes (/dev/hidraw*, /dev/input/event/*)
and conversely upon connection UHID_CREATE would indirectly create
them. This way there should be no accumulation of the device nodes.
This behavior would mimic the BT classic HID and any other devices
where the device node is only present when the device is present and
usable.
I could prepare a patch to demonstrate this if you'd like.
Cheers,
- Juha
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: HoG uHID device not destroyed on disconnect
2016-12-22 17:34 ` Juha Kuikka
@ 2016-12-22 18:21 ` Luiz Augusto von Dentz
0 siblings, 0 replies; 4+ messages in thread
From: Luiz Augusto von Dentz @ 2016-12-22 18:21 UTC (permalink / raw)
To: Juha Kuikka; +Cc: linux-bluetooth
Hi Juha,
On Thu, Dec 22, 2016 at 7:34 PM, Juha Kuikka <juha.kuikka@gmail.com> wrote:
> Hi Luiz,
>
> On Thu, Dec 22, 2016 at 1:03 AM, Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:
>> Hi Juha,
>>
>> On Thu, Dec 22, 2016 at 8:06 AM, Juha Kuikka <juha.kuikka@gmail.com> wrote:
>>> Hi,
>>>
>>> It seems that when an HID-over-GATT (HoG) device connects an uHID
>>> devive is created for it. I would expect it to get destroyed upon
>>> disconnect but it seems to linger around.
>>>
>>> This can be demonstrated using bluetoothctl. Here I am using a
>>> Microsoft Arc Touch Mouse.
>>>
>>> Paired and connected:
>>>
>>> [bluetooth]# pair C9:33:31:6B:03:A9
>>> Attempting to pair with C9:33:31:6B:03:A9
>>> [CHG] Device C9:33:31:6B:03:A9 Connected: yes
>>> [CHG] Device C9:33:31:6B:03:A9 UUIDs: 00001800-0000-1000-8000-00805f9b34fb
>>> [CHG] Device C9:33:31:6B:03:A9 UUIDs: 00001801-0000-1000-8000-00805f9b34fb
>>> [CHG] Device C9:33:31:6B:03:A9 UUIDs: 0000180a-0000-1000-8000-00805f9b34fb
>>> [CHG] Device C9:33:31:6B:03:A9 UUIDs: 0000180f-0000-1000-8000-00805f9b34fb
>>> [CHG] Device C9:33:31:6B:03:A9 UUIDs: 00001812-0000-1000-8000-00805f9b34fb
>>> [CHG] Device C9:33:31:6B:03:A9 ServicesResolved: yes
>>> [CHG] Device C9:33:31:6B:03:A9 Paired: yes
>>> [NEW] Primary Service
>>> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0008
>>> 00001801-0000-1000-8000-00805f9b34fb
>>> Generic Attribute Profile
>>> [NEW] Characteristic
>>> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0008/char0009
>>> 00002a05-0000-1000-8000-00805f9b34fb
>>> Service Changed
>>> [NEW] Descriptor
>>> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0008/char0009/desc000b
>>> 00002902-0000-1000-8000-00805f9b34fb
>>> Client Characteristic Configuration
>>> [NEW] Primary Service
>>> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service000c
>>> 0000180a-0000-1000-8000-00805f9b34fb
>>> Device Information
>>> [NEW] Characteristic
>>> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service000c/char000d
>>> 00002a29-0000-1000-8000-00805f9b34fb
>>> Manufacturer Name String
>>> [NEW] Characteristic
>>> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service000c/char000f
>>> 00002a50-0000-1000-8000-00805f9b34fb
>>> PnP ID
>>> [NEW] Primary Service
>>> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0011
>>> 0000180f-0000-1000-8000-00805f9b34fb
>>> Battery Service
>>> [NEW] Characteristic
>>> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0011/char0012
>>> 00002a19-0000-1000-8000-00805f9b34fb
>>> Battery Level
>>> [NEW] Descriptor
>>> /org/bluez/hci0/dev_C9_33_31_6B_03_A9/service0011/char0012/desc0014
>>> 00002902-0000-1000-8000-00805f9b34fb
>>> Client Characteristic Configuration
>>> Pairing successful
>>> [CHG] Device C9:33:31:6B:03:A9 Modalias: usb:v045Ep0804d0001
>>> [Arc Touch BT Mouse]# connect C9:33:31:6B:03:A9
>>> Attempting to connect to C9:33:31:6B:03:A9
>>> Connection successful
>>>
>>> And here it is disconnected:
>>>
>>> [CHG] Device C9:33:31:6B:03:A9 ServicesResolved: no
>>> [CHG] Device C9:33:31:6B:03:A9 Connected: no
>>>
>>> After disconnection, the HID device is still present:
>>>
>>> $ ls -l /sys/class/hidraw/ /dev/hidraw*
>>> crw------- 1 root root 244, 0 Dec 21 21:45 /dev/hidraw0
>>>
>>> /sys/class/hidraw/:
>>> total 0
>>> lrwxrwxrwx 1 root root 0 Dec 21 21:52 hidraw0 ->
>>> ../../devices/virtual/misc/uhid/0005:0000:0000.0019/hidraw/hidraw0
>>>
>>> The zero VID&PID of the HID device differ from the modalias due to
>>> another bug I just posted about.
>>>
>>> If I Remove() the the device, the HID device gets destroyed but it
>>> lingers until then.
>>>
>>> This behavior seems to be caused by the fact that the HoG service is
>>> kept alive between connections and the lifetime of the included
>>> bt_uhid is not limited between connections.
>>
>> This is actually on purpose so we don't keep creating more and more
>> device nodes every time the device reconnects, but we should
>> definitely fix the problem with DIS and HoG.
>
> I am not sure I understand the reasoning here, can you elaborate please?
>
> If upon disconnect we close() the uhid device or use the UHID_DESTROY
> that will remove the device nodes (/dev/hidraw*, /dev/input/event/*)
> and conversely upon connection UHID_CREATE would indirectly create
> them. This way there should be no accumulation of the device nodes.
If I recall correct it is exactly to cut time of recreating the device
that this was done, and if you take a look at the log you would
probably notice it was removing the device but someone at Google,
don't recall who now, had problem with that and they actually would
use UHID over HIDP even for classic because they don't want devices
being created/removed.
> This behavior would mimic the BT classic HID and any other devices
> where the device node is only present when the device is present and
> usable.
>
> I could prepare a patch to demonstrate this if you'd like.
>
> Cheers,
> - Juha
--
Luiz Augusto von Dentz
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-12-22 18:21 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-12-22 6:06 HoG uHID device not destroyed on disconnect Juha Kuikka
2016-12-22 9:03 ` Luiz Augusto von Dentz
2016-12-22 17:34 ` Juha Kuikka
2016-12-22 18:21 ` Luiz Augusto von Dentz
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.