Hi Bastien: Bastien Nocera wrote: > I really wonder how good an idea that is, given that, ultimately, we'd > want to remove hid2hci from everything, and handle the switching from > within bluetoothd. > This is a conflicting goal with the on-demand stuff I feel. You can't have the on-demand stuff and this working if the BT radio is only exposed after the device switches modes. > If we had specs for the devices (or at least rev-eng'ed specs), we'd > need to do link keys management, and switching the devices to hci mode > from within the same codebase. > I agree here, but I don't see the docs showing up anytime soon. > So I'd rather hid2hci didn't go into udev-extras, and stayed in bluez > until a better solution comes along. > Why? What's it's benefit living in the bluez tree? By moving to udev-extras, it now lives in /lib/udev and will work even if the /usr gets mounted on NFS late. > (Still no luck on getting specs from Broadcom about the Dell adapters at > least?) > I'll send another ping to ask about these again, but I wouldn't hold my breath. Regards -- Mario Limonciello *Dell | Linux Engineering* mario_limonciello@xxxxxxxx
Attachment:
signature.asc
Description: OpenPGP digital signature
