From Wed, 18 Mar 2009 22:47:28 +0000 Bastien Nocera <hadess@xxxxxxxxxx> wrote: > I think that the main problem was because, at that time, there was no > such thing as the HID sub-system to avoid having to reimplement things > twice for Bluetooth and USB devices. Yes, that was the main problem and I hoped to discuss it with the bluetooth stack developers... The solution, as I was seeing it, is to make the bluetooth stack implement a "bluetooth bus": this would allow to emit udev events when devices are connected/disconnected, thus using the normal udev module autoloading stuff. However, I see that the bluetooth stuff chose another path, by using a user-space daemon. I'm very far from bluetooth developement to understand why this choice was made, however I'm pretty sure there were serious arguments in favour of that. > And it's a patch to input plugin for bluetoothd, not hidd. hidd is the > BlueZ 3.x daemon, we've been at BlueZ 4.x for a while. Aha, it's the stuff for low-level tablet protocol initialization. Why separating it from the driver itself? It's kind of tricky having hardware initialization in a user-space daemon, and working with hardware in the driver itself. Isn't there an analogue of the hidp_send_ctrl_message() call for the new hid driver architecture? -- Andrew
Attachment:
signature.asc
Description: PGP signature
