Hi Marcel, Thanks for your reply. Please see inline. On Thu, Jan 16, 2014 at 2:30 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> wrote: > Hi Petri, > >> I'm running BlueZ 5.13 userland + backported BlueZ kernel modules on >> an embedded system that I'm working on. The kernel on the system is >> 2.6.37-based. I ported uhid driver manually from 3.12. >> >> I'm successfully using Bluetooth classic HID remote control and >> Bluetooth LE HoG remote control on this system. However, I have two >> questions: >> >> 1) The Bluetooth classic remote that I'm using is not discoverable. It >> is only connectable. When the remote is not paired, it sends its >> Bluetooth MAC address to the host via IR, and the host needs to add >> this device to BlueZ's discovered devices database. But, how can I do >> that via D-Bus API? BlueZ 5 porting guide specifically mentions that " >> ... we decided to simply get rid of explicit CreateDevice / >> CreatePairedDevice methods and instead dynamically create device >> objects as they are discovered during device discovery." >> >> So, is there no API available to add non-discoverable devices in BlueZ 5? >> >> I have worked around this issue by manually adding this remote to >> <storage path>, so that bluetoothd creates the device on reboot via >> device_create_from_storage(). But, I would prefer not to restart >> bluetoothd every time a non-discoverable device needs to be added. > > I have never heard of a remote that uses IR to setup the pairing. A creative way of doing out-of-band pairing. > > What I think you are looking for is what the PS3 controllers do when the share their details over USB and then after that connect over Bluetooth HID. Have a look at plugins/sixaxis.c to see how they do it. BlueZ has a plugin API for doing exactly these kind of automated setup/pairing type of cases. > > So you want to write a plugin for this remote. > > The other plugin you might want to look at is plugins/autopair.c if it actually requires to also create an encrypted link. > Thank you for this info. I will look into plugins/sixaxis.c and plugins/autopair.c. >> 2) There is a difference in HID vs HoG hid/input pipeline persistence. >> When the Bluetooth classic HID remote disconnects, the corresponding >> hid and input kernel devices are destroyed. And when it reconnects, >> hid and input devices are created again. This adds a lot of >> unnecessary delay at reconnect. And, the first keypress is always lost >> on reconnect. >> >> In contrast, for the Bluetooth LE HoG remote, the hid/input pipeline >> is persistent. When HoG remote disconnects, hid and input devices >> remain in the system and are reused when the HoG remote reconnects. >> >> Is there a way to make Bluetooth classic HID behave the same as HoG, >> i.e. retain the hid and input kernel devices on disconnect and reuse >> them on reconnect? > > HID and HoG work a little bit different. HID uses a kernel transport driver while HoG uses /dev/uhid to do the work. Porting HID over to use /dev/uhid is certainly a possibility. We have considered that, but nobody has done that work yet. > > Please remember that HID (with HIDP) is finding its right place in /sys device tree. While all HoG using /dev/uhid are considered virtual devices. There is a semi proposal that we agreed on New Orleans during the PlumbersConf, but I have no idea if David actually implemented it. > > Another option is to make the HIDP transport smarter and persistent by integrating it into BlueZ 5’s kernel mgmt support. That however means you will need a much more recent Bluetooth subsystem. So 2.6.37 is not getting you anywhere near that even if we change HIDP support. > > Regards > > Marcel > I'm using BlueZ kernel modules (bluetooth, hidp) from Linux backports-3.13-rc2-1, so that is pretty recent code. Works fine on top of 2.6.37. However, my HID and input drivers come from 2.6.37, as they are not available in backports-3.13-rc2-1. I understand the difference between HID and HoG. Both hidp and uhid are hid_ll_drivers. HID input reports stay entirely in kernel, whereas HoG is handled in bluetoothd and input reports are passed back to kernel via /dev/uhid. Assuming the latest HIDP code, what kind of effort would it be to make the hid/input pipeline persistent when HID remote disconnects and reconnects? -- Petri -- 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
