There were no replies to this question two weeks ago, so I'm trying
again. If there exists documentation which I am missing, I'd be happy
to be directed to RTFM, but as far as I can tell, the Bluez 5 userspace
is undocumented. That would make this list my only recourse :(
--Mark
---
I've successfully attached a PS3 bluetooth remote to a Debian Jessie
system running bluez 5.23. In bluetoothctl it appears as
Device 00:21:4F:48:D1:D2
Name: BD Remote Control
Alias: BD Remote Control
Class: 0x00250c
Paired: no
Trusted: yes
Blocked: no
Connected: yes
LegacyPairing: no
UUID: Human Interface Device...
(00001124-0000-1000-8000-00805f9b34fb) UUID: PnP Information
(00001200-0000-1000-8000-00805f9b34fb) Modalias: usb:v054Cp0306d0100
(Note that it is not paired. I believe this is the normal, operational
state even though everyone refers to the setup process as "pairing."
See e.g. https://www.mythtv.org/wiki/Sony_PS3_BD_Remote)
Upon first connection, an input device is created:
[87044.559923] input: BD Remote Control as /devices/soc0/7d004000.usb/usb1/1-1/1-1:1.0/bluetooth/hci0/hci0:256/0005:054C:0306.0005/input/input7
[87044.573409] sony 0005:054C:0306.0005: input,hidraw1: BLUETOOTH HID v1.00 Gamepad [BD Remote Control] on ac:fd:ce:76:f2:4a
and I can watch keypresses using evemu-record. So far, so good.
I have set IdleTimeout=1 in /etc/bluetooth/input.conf. My
understanding is that this should disconnect from the remote after one
minute of inactivity. What I find, however, is that after exactly one
minute, the *input device* disappears (i.e. no longer listed
in /proc/bus/input/devices) but the connection to the remote remains
active. Ten or twenty minutes later, it still shows as "Connected" in
bluetoothctl or hcitool con:
Connections:
> ACL 00:21:4F:48:D1:D2 handle 256 state 1 lm MASTER
Pressing buttons on the remote at this stage does not bring back the
input device, although hciconfig shows that packets are being
received. If I forcibly disconnect (hcitool dc 00:21:4F:48:D1:D2), and
then press a button on the remote, the connection is automatically
re-established, along with the input device, and input events are
available until the next timeout.
Automatic disconnect is important due to limited battery life in the
remote. How can I achieve this? My recollection is that this worked in
older bluez releases (pre-5). For a long time there were patches
floating around, but I thought those found their way back to the
mainline.
Hi David,
On Mon, Aug 24, 2015 at 1:40 PM, David Herrmann <[email protected]> wrote:
> Hi
>
> On Mon, Aug 24, 2015 at 10:12 AM, Luiz Augusto von Dentz
> <[email protected]> wrote:
>> Hi David,
>>
>> On Fri, Aug 21, 2015 at 12:03 PM, David Herrmann <[email protected]> wrote:
>>> Hey
>>>
>>> On Thu, Aug 20, 2015 at 10:52 AM, Luiz Augusto von Dentz
>>> <[email protected]> wrote:
>>>> @David: Since apparently you was the author of the patch the remove
>>>> setting EUNATCH to sk_err can you tell if that was intentional or you
>>>> did not know that it could affect the timeout implementation? Btw, it
>>>> would nice if you could comment regarding moving the timeout policy to
>>>> the HID driver.
>>>
>>> This sounds like an oversight. From a quick look,
>>> hidp_session_terminate() should set these errors properly. I can try
>>> to craft a patch on Monday.
>>
>> I wonder if it isn't better to just call kernel_sock_shutdown directly
>> since either way we want to disconnect and the userspace is not really
>> doing anything special with EUNATCH either, it just see there is an
>> error and close its reference which happens to be the last one causing
>> it disconnect.
>
> I'm not very comfortable with -net internals, so not sure what
> behavior you want. Calling kernel_sock_shutdown() sounds fine, but
> that cannot be done from hidp_session_terminate(). Instead, you must
> call it from hidp_session_thread() somewhere near hidp_del_timer(),
> before hidp_session_put().
Then lets keep it simple and just set EUNATCH as it was before.
--
Luiz Augusto von Dentz
Hi
On Mon, Aug 24, 2015 at 10:12 AM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi David,
>
> On Fri, Aug 21, 2015 at 12:03 PM, David Herrmann <[email protected]> wrote:
>> Hey
>>
>> On Thu, Aug 20, 2015 at 10:52 AM, Luiz Augusto von Dentz
>> <[email protected]> wrote:
>>> @David: Since apparently you was the author of the patch the remove
>>> setting EUNATCH to sk_err can you tell if that was intentional or you
>>> did not know that it could affect the timeout implementation? Btw, it
>>> would nice if you could comment regarding moving the timeout policy to
>>> the HID driver.
>>
>> This sounds like an oversight. From a quick look,
>> hidp_session_terminate() should set these errors properly. I can try
>> to craft a patch on Monday.
>
> I wonder if it isn't better to just call kernel_sock_shutdown directly
> since either way we want to disconnect and the userspace is not really
> doing anything special with EUNATCH either, it just see there is an
> error and close its reference which happens to be the last one causing
> it disconnect.
I'm not very comfortable with -net internals, so not sure what
behavior you want. Calling kernel_sock_shutdown() sounds fine, but
that cannot be done from hidp_session_terminate(). Instead, you must
call it from hidp_session_thread() somewhere near hidp_del_timer(),
before hidp_session_put().
Thanks
David
Hi David,
On Fri, Aug 21, 2015 at 12:03 PM, David Herrmann <[email protected]> wrote:
> Hey
>
> On Thu, Aug 20, 2015 at 10:52 AM, Luiz Augusto von Dentz
> <[email protected]> wrote:
>> @David: Since apparently you was the author of the patch the remove
>> setting EUNATCH to sk_err can you tell if that was intentional or you
>> did not know that it could affect the timeout implementation? Btw, it
>> would nice if you could comment regarding moving the timeout policy to
>> the HID driver.
>
> This sounds like an oversight. From a quick look,
> hidp_session_terminate() should set these errors properly. I can try
> to craft a patch on Monday.
I wonder if it isn't better to just call kernel_sock_shutdown directly
since either way we want to disconnect and the userspace is not really
doing anything special with EUNATCH either, it just see there is an
error and close its reference which happens to be the last one causing
it disconnect.
--
Luiz Augusto von Dentz
Hey
On Thu, Aug 20, 2015 at 10:52 AM, Luiz Augusto von Dentz
<[email protected]> wrote:
> @David: Since apparently you was the author of the patch the remove
> setting EUNATCH to sk_err can you tell if that was intentional or you
> did not know that it could affect the timeout implementation? Btw, it
> would nice if you could comment regarding moving the timeout policy to
> the HID driver.
This sounds like an oversight. From a quick look,
hidp_session_terminate() should set these errors properly. I can try
to craft a patch on Monday.
Thanks
David
Hi,
I helped with the kernel HID driver, but I do not know much about the
bluetooth side of the story, some comments below tho.
On Thu, 20 Aug 2015 11:52:02 +0300
Luiz Augusto von Dentz <[email protected]> wrote:
> Hi Mark,
>
> On Thu, Aug 20, 2015 at 8:02 AM, Mark A. Haun <[email protected]> wrote:
> > Hi Luiz and the group,
> >
> > I captured a debug log from bluetoothd while testing the PS3 remote. I'm not
> > sure it sheds any light on what is happening though. When the timeout occurs
> > and the input device goes away, there is no log output from bluetoothd or the
> > kernel.
> >
> > Here is the same test sequence as in my original post, with the bluetoothd
> > lots interspersed:
> >
> > Press a key (or two) on the remote when it is not connected:
> >
> > Aug 19 21:04:13 kolonia bluetoothd[11186]: src/adapter.c:connected_callback() hci0 device 00:21:4F:48:D1:D2 connected eir_len 5
> > Aug 19 21:04:13 kolonia bluetoothd[11186]: profiles/input/server.c:connect_event_cb() Incoming connection from 00:21:4F:48:D1:D2 on PSM 17
> > Aug 19 21:04:13 kolonia bluetoothd[11186]: profiles/input/device.c:input_device_set_channel() idev 0x7ff49ff8 psm 17
> > Aug 19 21:04:13 kolonia bluetoothd[11186]: profiles/input/server.c:confirm_event_cb()
> > Aug 19 21:04:13 kolonia bluetoothd[11186]: profiles/input/server.c:connect_event_cb() Incoming connection from 00:21:4F:48:D1:D2 on PSM 19
> > Aug 19 21:04:13 kolonia bluetoothd[11186]: profiles/input/device.c:input_device_set_channel() idev 0x7ff49ff8 psm 19
> > Aug 19 21:04:13 kolonia bluetoothd[11186]: src/service.c:change_state() 0x7ff484a8: device 00:21:4F:48:D1:D2 profile input-hid state changed: disconnected -> connected (0)
> > Aug 19 21:04:13 kolonia bluetoothd[11186]: src/service.c:btd_service_ref() 0x7ff484a8: ref=3
> > Aug 19 21:04:13 kolonia bluetoothd[11186]: plugins/policy.c:service_cb() Added input-hid reconnect 0
> > Aug 19 21:04:13 kolonia kernel: [1244066.144277] input: BD Remote Control as /devices/soc0/7d004000.usb/usb1/1-1/1-1:1.0/bluetooth/hci0/hci0:256/0005:054C:0306.0006/input/input8
> > Aug 19 21:04:13 kolonia kernel: [1244066.158238] sony 0005:054C:0306.0006: input,hidraw1: BLUETOOTH HID v1.00 Gamepad [BD Remote Control] on ac:fd:ce:76:f2:4a
> >
> > Input device is created; can run evemu-record and watch keypress events on
> > the remote. After one minute of inactivity, the remote is still sending
> > packets (which can be seen in the hciconfig packet counter), but the kernel
> > input device has gone away. No new messages in dmesg or in the bluetoothd
> > log at this time :(
> >
> > <Time passes...>
> >
> > Remote is still connected. Forcibly disconnect using "hcitool dc 00:21:4f:48:d1:d2":
>
This makes me think that a udev rule can detect the kernel input device
disconnection, and then force the bluetooth disconnection.
[...]
> > and we can again see keypresses in evemu-record, until the next timeout.
> >
> > About your other questions,
> >
> >> > The PS3 remote is definitely one of those broken devices. During
> >> > bluez 4.xx there were a set of unofficial patches maintained at
> >> > kitlaan.twinaxis.com (now defunct).
> >>
> >> Patches to what exactly, BlueZ userspace, kernel?
> >
> > They were patches to the bluez userspace distribution. Much of it was
> > non-essential: timeout in seconds rather than minutes, and key-code
> > mapping for ease of integration with media software. Details here:
> > https://www.mythtv.org/wiki/Sony_PS3_BD_Remote
> >
> >> Note that using IdleTimeout affects every single HID that you connect
> >> over Bluetooth, which is why I think this is in the wrong place, it
> >> should probably be up to the PS3 remote driver to implement such
> >> policy to disconnect on idle. Either way I don't see another option
> >> other then to set the socket err so userspace can cleanup it own
> >> reference to the socket.
> >
> > By "PS3 remote driver" you mean adding an exception for the Sony remote
> > in the evdev driver? Because I don't think there is a PS3 remote driver
> > per se. It's just a generic HID.
>
> I think we might have a driver for PS3 after all, you can see from
> dmesg that it is detected as a Gamepad [BD Remote Control] or is that
> just the game of the device?
>
There is a HID driver, because the original descriptor had to be
overridden in order to get useful events, but it's just HID, no
explicit dependencies on input or bluetooth.
[...]
> > I don't know enough to understand what this was doing, but I see that
> > the source was heavily reworked in kernel 3.10... If someone could
> > craft a patch against recent kernels (4.2) I would be happy to test
> > it. As bluez 5 rolls out to more distros, I imagine there will be
> > more users wanting to know why their remote is broken :)
>
> Well you are the first one to complain, so either people are stuck
> with very only kernel or they don't care if the controller stay always
> connected.
>
Or they just remove the batteries when not using the remote, and are
even thinking about adding a physical ON/OFF switch to the remote...
Ciao,
Antonio
--
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?
Hi Mark,
On Thu, Aug 20, 2015 at 8:02 AM, Mark A. Haun <[email protected]> wrote:
> Hi Luiz and the group,
>
> I captured a debug log from bluetoothd while testing the PS3 remote. I'm not
> sure it sheds any light on what is happening though. When the timeout occurs
> and the input device goes away, there is no log output from bluetoothd or the
> kernel.
>
> Here is the same test sequence as in my original post, with the bluetoothd
> lots interspersed:
>
> Press a key (or two) on the remote when it is not connected:
>
> Aug 19 21:04:13 kolonia bluetoothd[11186]: src/adapter.c:connected_callback() hci0 device 00:21:4F:48:D1:D2 connected eir_len 5
> Aug 19 21:04:13 kolonia bluetoothd[11186]: profiles/input/server.c:connect_event_cb() Incoming connection from 00:21:4F:48:D1:D2 on PSM 17
> Aug 19 21:04:13 kolonia bluetoothd[11186]: profiles/input/device.c:input_device_set_channel() idev 0x7ff49ff8 psm 17
> Aug 19 21:04:13 kolonia bluetoothd[11186]: profiles/input/server.c:confirm_event_cb()
> Aug 19 21:04:13 kolonia bluetoothd[11186]: profiles/input/server.c:connect_event_cb() Incoming connection from 00:21:4F:48:D1:D2 on PSM 19
> Aug 19 21:04:13 kolonia bluetoothd[11186]: profiles/input/device.c:input_device_set_channel() idev 0x7ff49ff8 psm 19
> Aug 19 21:04:13 kolonia bluetoothd[11186]: src/service.c:change_state() 0x7ff484a8: device 00:21:4F:48:D1:D2 profile input-hid state changed: disconnected -> connected (0)
> Aug 19 21:04:13 kolonia bluetoothd[11186]: src/service.c:btd_service_ref() 0x7ff484a8: ref=3
> Aug 19 21:04:13 kolonia bluetoothd[11186]: plugins/policy.c:service_cb() Added input-hid reconnect 0
> Aug 19 21:04:13 kolonia kernel: [1244066.144277] input: BD Remote Control as /devices/soc0/7d004000.usb/usb1/1-1/1-1:1.0/bluetooth/hci0/hci0:256/0005:054C:0306.0006/input/input8
> Aug 19 21:04:13 kolonia kernel: [1244066.158238] sony 0005:054C:0306.0006: input,hidraw1: BLUETOOTH HID v1.00 Gamepad [BD Remote Control] on ac:fd:ce:76:f2:4a
>
> Input device is created; can run evemu-record and watch keypress events on
> the remote. After one minute of inactivity, the remote is still sending
> packets (which can be seen in the hciconfig packet counter), but the kernel
> input device has gone away. No new messages in dmesg or in the bluetoothd
> log at this time :(
>
> <Time passes...>
>
> Remote is still connected. Forcibly disconnect using "hcitool dc 00:21:4f:48:d1:d2":
So userspace doesn't notice anything until you disconnect, right?
> Aug 19 21:17:46 kolonia bluetoothd[11186]: src/adapter.c:dev_disconnected() Device 00:21:4F:48:D1:D2 disconnected, reason 2
> Aug 19 21:17:46 kolonia bluetoothd[11186]: src/adapter.c:adapter_remove_connection()
> Aug 19 21:17:46 kolonia bluetoothd[11186]: plugins/policy.c:disconnect_cb() reason 2
> Aug 19 21:17:46 kolonia bluetoothd[11186]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:21:4F:48:D1:D2 type 0 status 0xe
> Aug 19 21:17:46 kolonia bluetoothd[11186]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
> Aug 19 21:17:46 kolonia bluetoothd[11186]: src/device.c:device_bonding_failed() status 14
> Aug 19 21:17:46 kolonia bluetoothd[11186]: src/adapter.c:resume_discovery()
> Aug 19 21:17:46 kolonia bluetoothd[11186]: profiles/input/device.c:ctrl_watch_cb() Device 00:21:4F:48:D1:D2 disconnected
> Aug 19 21:17:46 kolonia bluetoothd[11186]: profiles/input/device.c:intr_watch_cb() Device 00:21:4F:48:D1:D2 disconnected
> Aug 19 21:17:46 kolonia bluetoothd[11186]: src/service.c:change_state() 0x7ff484a8: device 00:21:4F:48:D1:D2 profile input-hid state changed: connected -> disconnected (0)
> Aug 19 21:17:46 kolonia bluetoothd[11186]: profiles/input/device.c:input_device_enter_reconnect_mode() path=/org/bluez/hci0/dev_00_21_4F_48_D1_D2 reconnect_mode=device
>
> Now press keys on the remote, and it reconnects again:
>
> Aug 19 21:19:22 kolonia bluetoothd[11186]: src/adapter.c:connected_callback() hci0 device 00:21:4F:48:D1:D2 connected eir_len 5
> Aug 19 21:19:22 kolonia bluetoothd[11186]: profiles/input/server.c:connect_event_cb() Incoming connection from 00:21:4F:48:D1:D2 on PSM 17
> Aug 19 21:19:22 kolonia bluetoothd[11186]: profiles/input/device.c:input_device_set_channel() idev 0x7ff49ff8 psm 17
> Aug 19 21:19:22 kolonia bluetoothd[11186]: profiles/input/server.c:confirm_event_cb()
> Aug 19 21:19:22 kolonia bluetoothd[11186]: profiles/input/server.c:connect_event_cb() Incoming connection from 00:21:4F:48:D1:D2 on PSM 19
> Aug 19 21:19:22 kolonia bluetoothd[11186]: profiles/input/device.c:input_device_set_channel() idev 0x7ff49ff8 psm 19
> Aug 19 21:19:22 kolonia bluetoothd[11186]: src/service.c:change_state() 0x7ff484a8: device 00:21:4F:48:D1:D2 profile input-hid state changed: disconnected -> connected (0)
> Aug 19 21:19:22 kolonia bluetoothd[11186]: plugins/policy.c:service_cb() Added input-hid reconnect 0
> Aug 19 21:19:22 kolonia kernel: [1244975.379906] input: BD Remote Control as /devices/soc0/7d004000.usb/usb1/1-1/1-1:1.0/bluetooth/hci0/hci0:256/0005:054C:0306.0007/input/input9
> Aug 19 21:19:22 kolonia kernel: [1244975.393392] sony 0005:054C:0306.0007: input,hidraw1: BLUETOOTH HID v1.00 Gamepad [BD Remote Control] on ac:fd:ce:76:f2:4a
>
> and we can again see keypresses in evemu-record, until the next timeout.
>
> About your other questions,
>
>> > The PS3 remote is definitely one of those broken devices. During
>> > bluez 4.xx there were a set of unofficial patches maintained at
>> > kitlaan.twinaxis.com (now defunct).
>>
>> Patches to what exactly, BlueZ userspace, kernel?
>
> They were patches to the bluez userspace distribution. Much of it was
> non-essential: timeout in seconds rather than minutes, and key-code
> mapping for ease of integration with media software. Details here:
> https://www.mythtv.org/wiki/Sony_PS3_BD_Remote
>
>> Note that using IdleTimeout affects every single HID that you connect
>> over Bluetooth, which is why I think this is in the wrong place, it
>> should probably be up to the PS3 remote driver to implement such
>> policy to disconnect on idle. Either way I don't see another option
>> other then to set the socket err so userspace can cleanup it own
>> reference to the socket.
>
> By "PS3 remote driver" you mean adding an exception for the Sony remote
> in the evdev driver? Because I don't think there is a PS3 remote driver
> per se. It's just a generic HID.
I think we might have a driver for PS3 after all, you can see from
dmesg that it is detected as a Gamepad [BD Remote Control] or is that
just the game of the device?
> I agree that the blanket timeout is not a great solution but in my case
> it would be sufficient, *if* it worked. (I don't have any other
> bluetooth HIDs to worry about.)
>
>> >> Apparently the following lines were removed in the commit
>> >> 5205185d461d5902325e457ca80bd421127b7308:
>> >>
>> >> - /* Wakeup user-space polling for socket errors */
>> >> - session->intr_sock->sk->sk_err = EUNATCH;
>> >> - session->ctrl_sock->sk->sk_err = EUNATCH;
>> >>
>> >> Without this I doubt the userspace will realize that it should
>> >> release the sockets which means this as been broken for over 2
>> >> years and probably nobody realized up until today, it is probably
>> >> only useful when IdleTimeout is set since it is the only case
>> >> where the module itself device to remove the device and disconnect.
>
> I don't know enough to understand what this was doing, but I see that
> the source was heavily reworked in kernel 3.10... If someone could
> craft a patch against recent kernels (4.2) I would be happy to test
> it. As bluez 5 rolls out to more distros, I imagine there will be
> more users wanting to know why their remote is broken :)
Well you are the first one to complain, so either people are stuck
with very only kernel or they don't care if the controller stay always
connected.
@David: Since apparently you was the author of the patch the remove
setting EUNATCH to sk_err can you tell if that was intentional or you
did not know that it could affect the timeout implementation? Btw, it
would nice if you could comment regarding moving the timeout policy to
the HID driver.
--
Luiz Augusto von Dentz
Hi Luiz and the group,
I captured a debug log from bluetoothd while testing the PS3 remote. I'm not
sure it sheds any light on what is happening though. When the timeout occurs
and the input device goes away, there is no log output from bluetoothd or the
kernel.
Here is the same test sequence as in my original post, with the bluetoothd
lots interspersed:
Press a key (or two) on the remote when it is not connected:
Aug 19 21:04:13 kolonia bluetoothd[11186]: src/adapter.c:connected_callback() hci0 device 00:21:4F:48:D1:D2 connected eir_len 5
Aug 19 21:04:13 kolonia bluetoothd[11186]: profiles/input/server.c:connect_event_cb() Incoming connection from 00:21:4F:48:D1:D2 on PSM 17
Aug 19 21:04:13 kolonia bluetoothd[11186]: profiles/input/device.c:input_device_set_channel() idev 0x7ff49ff8 psm 17
Aug 19 21:04:13 kolonia bluetoothd[11186]: profiles/input/server.c:confirm_event_cb()
Aug 19 21:04:13 kolonia bluetoothd[11186]: profiles/input/server.c:connect_event_cb() Incoming connection from 00:21:4F:48:D1:D2 on PSM 19
Aug 19 21:04:13 kolonia bluetoothd[11186]: profiles/input/device.c:input_device_set_channel() idev 0x7ff49ff8 psm 19
Aug 19 21:04:13 kolonia bluetoothd[11186]: src/service.c:change_state() 0x7ff484a8: device 00:21:4F:48:D1:D2 profile input-hid state changed: disconnected -> connected (0)
Aug 19 21:04:13 kolonia bluetoothd[11186]: src/service.c:btd_service_ref() 0x7ff484a8: ref=3
Aug 19 21:04:13 kolonia bluetoothd[11186]: plugins/policy.c:service_cb() Added input-hid reconnect 0
Aug 19 21:04:13 kolonia kernel: [1244066.144277] input: BD Remote Control as /devices/soc0/7d004000.usb/usb1/1-1/1-1:1.0/bluetooth/hci0/hci0:256/0005:054C:0306.0006/input/input8
Aug 19 21:04:13 kolonia kernel: [1244066.158238] sony 0005:054C:0306.0006: input,hidraw1: BLUETOOTH HID v1.00 Gamepad [BD Remote Control] on ac:fd:ce:76:f2:4a
Input device is created; can run evemu-record and watch keypress events on
the remote. After one minute of inactivity, the remote is still sending
packets (which can be seen in the hciconfig packet counter), but the kernel
input device has gone away. No new messages in dmesg or in the bluetoothd
log at this time :(
<Time passes...>
Remote is still connected. Forcibly disconnect using "hcitool dc 00:21:4f:48:d1:d2":
Aug 19 21:17:46 kolonia bluetoothd[11186]: src/adapter.c:dev_disconnected() Device 00:21:4F:48:D1:D2 disconnected, reason 2
Aug 19 21:17:46 kolonia bluetoothd[11186]: src/adapter.c:adapter_remove_connection()
Aug 19 21:17:46 kolonia bluetoothd[11186]: plugins/policy.c:disconnect_cb() reason 2
Aug 19 21:17:46 kolonia bluetoothd[11186]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 00:21:4F:48:D1:D2 type 0 status 0xe
Aug 19 21:17:46 kolonia bluetoothd[11186]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
Aug 19 21:17:46 kolonia bluetoothd[11186]: src/device.c:device_bonding_failed() status 14
Aug 19 21:17:46 kolonia bluetoothd[11186]: src/adapter.c:resume_discovery()
Aug 19 21:17:46 kolonia bluetoothd[11186]: profiles/input/device.c:ctrl_watch_cb() Device 00:21:4F:48:D1:D2 disconnected
Aug 19 21:17:46 kolonia bluetoothd[11186]: profiles/input/device.c:intr_watch_cb() Device 00:21:4F:48:D1:D2 disconnected
Aug 19 21:17:46 kolonia bluetoothd[11186]: src/service.c:change_state() 0x7ff484a8: device 00:21:4F:48:D1:D2 profile input-hid state changed: connected -> disconnected (0)
Aug 19 21:17:46 kolonia bluetoothd[11186]: profiles/input/device.c:input_device_enter_reconnect_mode() path=/org/bluez/hci0/dev_00_21_4F_48_D1_D2 reconnect_mode=device
Now press keys on the remote, and it reconnects again:
Aug 19 21:19:22 kolonia bluetoothd[11186]: src/adapter.c:connected_callback() hci0 device 00:21:4F:48:D1:D2 connected eir_len 5
Aug 19 21:19:22 kolonia bluetoothd[11186]: profiles/input/server.c:connect_event_cb() Incoming connection from 00:21:4F:48:D1:D2 on PSM 17
Aug 19 21:19:22 kolonia bluetoothd[11186]: profiles/input/device.c:input_device_set_channel() idev 0x7ff49ff8 psm 17
Aug 19 21:19:22 kolonia bluetoothd[11186]: profiles/input/server.c:confirm_event_cb()
Aug 19 21:19:22 kolonia bluetoothd[11186]: profiles/input/server.c:connect_event_cb() Incoming connection from 00:21:4F:48:D1:D2 on PSM 19
Aug 19 21:19:22 kolonia bluetoothd[11186]: profiles/input/device.c:input_device_set_channel() idev 0x7ff49ff8 psm 19
Aug 19 21:19:22 kolonia bluetoothd[11186]: src/service.c:change_state() 0x7ff484a8: device 00:21:4F:48:D1:D2 profile input-hid state changed: disconnected -> connected (0)
Aug 19 21:19:22 kolonia bluetoothd[11186]: plugins/policy.c:service_cb() Added input-hid reconnect 0
Aug 19 21:19:22 kolonia kernel: [1244975.379906] input: BD Remote Control as /devices/soc0/7d004000.usb/usb1/1-1/1-1:1.0/bluetooth/hci0/hci0:256/0005:054C:0306.0007/input/input9
Aug 19 21:19:22 kolonia kernel: [1244975.393392] sony 0005:054C:0306.0007: input,hidraw1: BLUETOOTH HID v1.00 Gamepad [BD Remote Control] on ac:fd:ce:76:f2:4a
and we can again see keypresses in evemu-record, until the next timeout.
About your other questions,
> > The PS3 remote is definitely one of those broken devices. During
> > bluez 4.xx there were a set of unofficial patches maintained at
> > kitlaan.twinaxis.com (now defunct).
>
> Patches to what exactly, BlueZ userspace, kernel?
They were patches to the bluez userspace distribution. Much of it was
non-essential: timeout in seconds rather than minutes, and key-code
mapping for ease of integration with media software. Details here:
https://www.mythtv.org/wiki/Sony_PS3_BD_Remote
> Note that using IdleTimeout affects every single HID that you connect
> over Bluetooth, which is why I think this is in the wrong place, it
> should probably be up to the PS3 remote driver to implement such
> policy to disconnect on idle. Either way I don't see another option
> other then to set the socket err so userspace can cleanup it own
> reference to the socket.
By "PS3 remote driver" you mean adding an exception for the Sony remote
in the evdev driver? Because I don't think there is a PS3 remote driver
per se. It's just a generic HID.
I agree that the blanket timeout is not a great solution but in my case
it would be sufficient, *if* it worked. (I don't have any other
bluetooth HIDs to worry about.)
> >> Apparently the following lines were removed in the commit
> >> 5205185d461d5902325e457ca80bd421127b7308:
> >>
> >> - /* Wakeup user-space polling for socket errors */
> >> - session->intr_sock->sk->sk_err = EUNATCH;
> >> - session->ctrl_sock->sk->sk_err = EUNATCH;
> >>
> >> Without this I doubt the userspace will realize that it should
> >> release the sockets which means this as been broken for over 2
> >> years and probably nobody realized up until today, it is probably
> >> only useful when IdleTimeout is set since it is the only case
> >> where the module itself device to remove the device and disconnect.
I don't know enough to understand what this was doing, but I see that
the source was heavily reworked in kernel 3.10... If someone could
craft a patch against recent kernels (4.2) I would be happy to test
it. As bluez 5 rolls out to more distros, I imagine there will be
more users wanting to know why their remote is broken :)
Thanks,
Mark
Hi Mark,
On Wed, Aug 19, 2015 at 7:14 PM, Mark Haun <[email protected]> wrote:
> Hi Luiz,
>
> Luiz Augusto von Dentz [[email protected]] wrote:
>> >> I have set IdleTimeout=1 in /etc/bluetooth/input.conf. My
>> >> understanding is that this should disconnect from the remote after one
>> >> minute of inactivity. What I find, however, is that after exactly one
>> >> minute, the *input device* disappears (i.e. no longer listed
>> >> in /proc/bus/input/devices) but the connection to the remote remains
>> >> active. Ten or twenty minutes later, it still shows as "Connected" in
>> >> bluetoothctl or hcitool con:
>> >>
>> >> Connections:
>> >> > ACL 00:21:4F:48:D1:D2 handle 256 state 1 lm MASTER
>> >
>> > Yes, IdleTimeout should disconnect the device in case there is nothing
>> > else connect (no other sockets except HID), but note that IdleTimeout
>> > currently does not work with UserspaceHID.
> [...]
>> > Looks like the sockets are not really closed then thus keeping the ACL
>> > active which is probably a bug, does bluetoothd logs indicate a
>> > disconnection or it is just the input device that disappears?
>
> Thanks, it's good to know that this is the expected behavior. But what do
> you mean by "userspace HID"? I am only using evdev (via Python).
That is another option you can use in input.conf, so you are probably
no using if you didn't change anything.
> Tonight I will run the experiment again with "bluetoothd -n -d" and let you
> know what happens. I already see some errors about the sap driver
> initialization failing, but that may be unrelated.
>
>> > This depend from device to device, usually this policy is done by the
>> > device itself since it knows better when it should be disconnected so
>> > usually IdleTimeout is used only for *broken devices that don't
>> > implement any policy to conserve their own batteries most likely
>> > because windows driver have these policies built in, perhaps we also
>> > should have this kind of policy in the input driver but I don't know
>> > if there is any support to disconnect a device after a period of
>> > inactivity.
>>
>> Apparently the following lines were removed in the commit
>> 5205185d461d5902325e457ca80bd421127b7308:
>>
>> - /* Wakeup user-space polling for socket errors */
>> - session->intr_sock->sk->sk_err = EUNATCH;
>> - session->ctrl_sock->sk->sk_err = EUNATCH;
>>
>> Without this I doubt the userspace will realize that it should release
>> the sockets which means this as been broken for over 2 years and
>> probably nobody realized up until today, it is probably only useful
>> when IdleTimeout is set since it is the only case where the module
>> itself device to remove the device and disconnect.
>
> The PS3 remote is definitely one of those broken devices. During bluez 4.xx
> there were a set of unofficial patches maintained at kitlaan.twinaxis.com
> (now defunct). Not a long-term tenable solution, although I was never clear
> on whether all his changes were actually necessary in later bluez versions.
> It seems like IdleTimeout should be enough, if it can be made to disconnect.
> Reconnect and evdev init works just fine on the next keypress.
Patches to what exactly, BlueZ userspace, kernel? Note that using
IdleTimeout affects every single HID that you connect over Bluetooth,
which is why I think this is in the wrong place, it should probably be
up to the PS3 remote driver to implement such policy to disconnect on
idle. Either way I don't see another option other then to set the
socket err so userspace can cleanup it own reference to the socket.
--
Luiz Augusto von Dentz
Hi Luiz,
Luiz Augusto von Dentz [[email protected]] wrote:
> >> I have set IdleTimeout=1 in /etc/bluetooth/input.conf. My
> >> understanding is that this should disconnect from the remote after one
> >> minute of inactivity. What I find, however, is that after exactly one
> >> minute, the *input device* disappears (i.e. no longer listed
> >> in /proc/bus/input/devices) but the connection to the remote remains
> >> active. Ten or twenty minutes later, it still shows as "Connected" in
> >> bluetoothctl or hcitool con:
> >>
> >> Connections:
> >> > ACL 00:21:4F:48:D1:D2 handle 256 state 1 lm MASTER
> >
> > Yes, IdleTimeout should disconnect the device in case there is nothing
> > else connect (no other sockets except HID), but note that IdleTimeout
> > currently does not work with UserspaceHID.
[...]
> > Looks like the sockets are not really closed then thus keeping the ACL
> > active which is probably a bug, does bluetoothd logs indicate a
> > disconnection or it is just the input device that disappears?
Thanks, it's good to know that this is the expected behavior. But what do
you mean by "userspace HID"? I am only using evdev (via Python).
Tonight I will run the experiment again with "bluetoothd -n -d" and let you
know what happens. I already see some errors about the sap driver
initialization failing, but that may be unrelated.
> > This depend from device to device, usually this policy is done by the
> > device itself since it knows better when it should be disconnected so
> > usually IdleTimeout is used only for *broken devices that don't
> > implement any policy to conserve their own batteries most likely
> > because windows driver have these policies built in, perhaps we also
> > should have this kind of policy in the input driver but I don't know
> > if there is any support to disconnect a device after a period of
> > inactivity.
>
> Apparently the following lines were removed in the commit
> 5205185d461d5902325e457ca80bd421127b7308:
>
> - /* Wakeup user-space polling for socket errors */
> - session->intr_sock->sk->sk_err = EUNATCH;
> - session->ctrl_sock->sk->sk_err = EUNATCH;
>
> Without this I doubt the userspace will realize that it should release
> the sockets which means this as been broken for over 2 years and
> probably nobody realized up until today, it is probably only useful
> when IdleTimeout is set since it is the only case where the module
> itself device to remove the device and disconnect.
The PS3 remote is definitely one of those broken devices. During bluez 4.xx
there were a set of unofficial patches maintained at kitlaan.twinaxis.com
(now defunct). Not a long-term tenable solution, although I was never clear
on whether all his changes were actually necessary in later bluez versions.
It seems like IdleTimeout should be enough, if it can be made to disconnect.
Reconnect and evdev init works just fine on the next keypress.
Mark
Hi Mark,
On Wed, Aug 19, 2015 at 1:10 PM, Luiz Augusto von Dentz
<[email protected]> wrote:
> Hi Mark,
>
> On Wed, Aug 19, 2015 at 8:06 AM, Mark A. Haun <[email protected]> wrote:
>> There were no replies to this question two weeks ago, so I'm trying
>> again. If there exists documentation which I am missing, I'd be happy
>> to be directed to RTFM, but as far as I can tell, the Bluez 5 userspace
>> is undocumented. That would make this list my only recourse :(
>> --Mark
>>
>> ---
>>
>> I've successfully attached a PS3 bluetooth remote to a Debian Jessie
>> system running bluez 5.23. In bluetoothctl it appears as
>>
>> Device 00:21:4F:48:D1:D2
>> Name: BD Remote Control
>> Alias: BD Remote Control
>> Class: 0x00250c
>> Paired: no
>> Trusted: yes
>> Blocked: no
>> Connected: yes
>> LegacyPairing: no
>> UUID: Human Interface Device...
>> (00001124-0000-1000-8000-00805f9b34fb) UUID: PnP Information
>> (00001200-0000-1000-8000-00805f9b34fb) Modalias: usb:v054Cp0306d0100
>>
>> (Note that it is not paired. I believe this is the normal, operational
>> state even though everyone refers to the setup process as "pairing."
>> See e.g. https://www.mythtv.org/wiki/Sony_PS3_BD_Remote)
>>
>> Upon first connection, an input device is created:
>>
>> [87044.559923] input: BD Remote Control as /devices/soc0/7d004000.usb/usb1/1-1/1-1:1.0/bluetooth/hci0/hci0:256/0005:054C:0306.0005/input/input7
>> [87044.573409] sony 0005:054C:0306.0005: input,hidraw1: BLUETOOTH HID v1.00 Gamepad [BD Remote Control] on ac:fd:ce:76:f2:4a
>>
>> and I can watch keypresses using evemu-record. So far, so good.
>>
>> I have set IdleTimeout=1 in /etc/bluetooth/input.conf. My
>> understanding is that this should disconnect from the remote after one
>> minute of inactivity. What I find, however, is that after exactly one
>> minute, the *input device* disappears (i.e. no longer listed
>> in /proc/bus/input/devices) but the connection to the remote remains
>> active. Ten or twenty minutes later, it still shows as "Connected" in
>> bluetoothctl or hcitool con:
>>
>> Connections:
>> > ACL 00:21:4F:48:D1:D2 handle 256 state 1 lm MASTER
>
> Yes, IdleTimeout should disconnect the device in case there is nothing
> else connect (no other sockets except HID), but note that IdleTimeout
> currently does not work with UserspaceHID.
>
>> Pressing buttons on the remote at this stage does not bring back the
>> input device, although hciconfig shows that packets are being
>> received. If I forcibly disconnect (hcitool dc 00:21:4F:48:D1:D2), and
>> then press a button on the remote, the connection is automatically
>> re-established, along with the input device, and input events are
>> available until the next timeout.
>
> Looks like the sockets are not really closed then thus keeping the ACL
> active which is probably a bug, does bluetoothd logs indicate a
> disconnection or it is just the input device that disappears?
>
>> Automatic disconnect is important due to limited battery life in the
>> remote. How can I achieve this? My recollection is that this worked in
>> older bluez releases (pre-5). For a long time there were patches
>> floating around, but I thought those found their way back to the
>> mainline.
>
> This depend from device to device, usually this policy is done by the
> device itself since it knows better when it should be disconnected so
> usually IdleTimeout is used only for *broken devices that don't
> implement any policy to conserve their own batteries most likely
> because windows driver have these policies built in, perhaps we also
> should have this kind of policy in the input driver but I don't know
> if there is any support to disconnect a device after a period of
> inactivity.
Apparently the following lines were removed in the commit
5205185d461d5902325e457ca80bd421127b7308:
- /* Wakeup user-space polling for socket errors */
- session->intr_sock->sk->sk_err = EUNATCH;
- session->ctrl_sock->sk->sk_err = EUNATCH;
Without this I doubt the userspace will realize that it should release
the sockets which means this as been broken for over 2 years and
probably nobody realized up until today, it is probably only useful
when IdleTimeout is set since it is the only case where the module
itself device to remove the device and disconnect.
--
Luiz Augusto von Dentz
Hi Mark,
On Wed, Aug 19, 2015 at 8:06 AM, Mark A. Haun <[email protected]> wrote:
> There were no replies to this question two weeks ago, so I'm trying
> again. If there exists documentation which I am missing, I'd be happy
> to be directed to RTFM, but as far as I can tell, the Bluez 5 userspace
> is undocumented. That would make this list my only recourse :(
> --Mark
>
> ---
>
> I've successfully attached a PS3 bluetooth remote to a Debian Jessie
> system running bluez 5.23. In bluetoothctl it appears as
>
> Device 00:21:4F:48:D1:D2
> Name: BD Remote Control
> Alias: BD Remote Control
> Class: 0x00250c
> Paired: no
> Trusted: yes
> Blocked: no
> Connected: yes
> LegacyPairing: no
> UUID: Human Interface Device...
> (00001124-0000-1000-8000-00805f9b34fb) UUID: PnP Information
> (00001200-0000-1000-8000-00805f9b34fb) Modalias: usb:v054Cp0306d0100
>
> (Note that it is not paired. I believe this is the normal, operational
> state even though everyone refers to the setup process as "pairing."
> See e.g. https://www.mythtv.org/wiki/Sony_PS3_BD_Remote)
>
> Upon first connection, an input device is created:
>
> [87044.559923] input: BD Remote Control as /devices/soc0/7d004000.usb/usb1/1-1/1-1:1.0/bluetooth/hci0/hci0:256/0005:054C:0306.0005/input/input7
> [87044.573409] sony 0005:054C:0306.0005: input,hidraw1: BLUETOOTH HID v1.00 Gamepad [BD Remote Control] on ac:fd:ce:76:f2:4a
>
> and I can watch keypresses using evemu-record. So far, so good.
>
> I have set IdleTimeout=1 in /etc/bluetooth/input.conf. My
> understanding is that this should disconnect from the remote after one
> minute of inactivity. What I find, however, is that after exactly one
> minute, the *input device* disappears (i.e. no longer listed
> in /proc/bus/input/devices) but the connection to the remote remains
> active. Ten or twenty minutes later, it still shows as "Connected" in
> bluetoothctl or hcitool con:
>
> Connections:
> > ACL 00:21:4F:48:D1:D2 handle 256 state 1 lm MASTER
Yes, IdleTimeout should disconnect the device in case there is nothing
else connect (no other sockets except HID), but note that IdleTimeout
currently does not work with UserspaceHID.
> Pressing buttons on the remote at this stage does not bring back the
> input device, although hciconfig shows that packets are being
> received. If I forcibly disconnect (hcitool dc 00:21:4F:48:D1:D2), and
> then press a button on the remote, the connection is automatically
> re-established, along with the input device, and input events are
> available until the next timeout.
Looks like the sockets are not really closed then thus keeping the ACL
active which is probably a bug, does bluetoothd logs indicate a
disconnection or it is just the input device that disappears?
> Automatic disconnect is important due to limited battery life in the
> remote. How can I achieve this? My recollection is that this worked in
> older bluez releases (pre-5). For a long time there were patches
> floating around, but I thought those found their way back to the
> mainline.
This depend from device to device, usually this policy is done by the
device itself since it knows better when it should be disconnected so
usually IdleTimeout is used only for *broken devices that don't
implement any policy to conserve their own batteries most likely
because windows driver have these policies built in, perhaps we also
should have this kind of policy in the input driver but I don't know
if there is any support to disconnect a device after a period of
inactivity.
--
Luiz Augusto von Dentz
Hi Mark,
On Wed, Aug 19, 2015 at 8:06 AM, Mark A. Haun <[email protected]> wrote:
> There were no replies to this question two weeks ago, so I'm trying
> again. If there exists documentation which I am missing, I'd be happy
> to be directed to RTFM, but as far as I can tell, the Bluez 5 userspace
> is undocumented. That would make this list my only recourse :(
> --Mark
>
> ---
>
> I've successfully attached a PS3 bluetooth remote to a Debian Jessie
> system running bluez 5.23. In bluetoothctl it appears as
>
> Device 00:21:4F:48:D1:D2
> Name: BD Remote Control
> Alias: BD Remote Control
> Class: 0x00250c
> Paired: no
> Trusted: yes
> Blocked: no
> Connected: yes
> LegacyPairing: no
> UUID: Human Interface Device...
> (00001124-0000-1000-8000-00805f9b34fb) UUID: PnP Information
> (00001200-0000-1000-8000-00805f9b34fb) Modalias: usb:v054Cp0306d0100
>
> (Note that it is not paired. I believe this is the normal, operational
> state even though everyone refers to the setup process as "pairing."
> See e.g. https://www.mythtv.org/wiki/Sony_PS3_BD_Remote)
>
> Upon first connection, an input device is created:
>
> [87044.559923] input: BD Remote Control as /devices/soc0/7d004000.usb/usb1/1-1/1-1:1.0/bluetooth/hci0/hci0:256/0005:054C:0306.0005/input/input7
> [87044.573409] sony 0005:054C:0306.0005: input,hidraw1: BLUETOOTH HID v1.00 Gamepad [BD Remote Control] on ac:fd:ce:76:f2:4a
>
> and I can watch keypresses using evemu-record. So far, so good.
>
> I have set IdleTimeout=1 in /etc/bluetooth/input.conf. My
> understanding is that this should disconnect from the remote after one
> minute of inactivity. What I find, however, is that after exactly one
> minute, the *input device* disappears (i.e. no longer listed
> in /proc/bus/input/devices) but the connection to the remote remains
> active. Ten or twenty minutes later, it still shows as "Connected" in
> bluetoothctl or hcitool con:
>
> Connections:
> > ACL 00:21:4F:48:D1:D2 handle 256 state 1 lm MASTER
Yes, IdleTimeout should disconnect the device in case there is nothing
else connect (no other sockets except HID), but note that IdleTimeout
currently does not work with UserspaceHID.
> Pressing buttons on the remote at this stage does not bring back the
> input device, although hciconfig shows that packets are being
> received. If I forcibly disconnect (hcitool dc 00:21:4F:48:D1:D2), and
> then press a button on the remote, the connection is automatically
> re-established, along with the input device, and input events are
> available until the next timeout.
Looks like the sockets are not really closed then thus keeping the ACL
active which is probably a bug, does bluetoothd logs indicate a
disconnection or it is just the input device that disappears?
> Automatic disconnect is important due to limited battery life in the
> remote. How can I achieve this? My recollection is that this worked in
> older bluez releases (pre-5). For a long time there were patches
> floating around, but I thought those found their way back to the
> mainline.
This depend from device to device, usually this policy is done by the
device itself since it knows better when it should be disconnected so
usually IdleTimeout is used only for *broken devices that don't
implement any policy to conserve their own batteries most likely
because windows driver have these policies built in, perhaps we also
should have this kind of policy in the input driver but I don't know
if there is any support to disconnect a device after a period of
inactivity.
--
Luiz Augusto von Dentz