Hi Bastien, > > > 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. > > Why? Instead of calling hid2hci, it would launch bluetoothd --udev, like > the other rules. Problem solved. > > > > 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. > > If that's the only benefit, then, frankly, who cares. > > The main point is that people with an interested in Bluetooth will need > to go and fetch the code, and ask for patches to be committed. > > We're losing direct commit access to the code, and gaining something > that could have been achieved in the distro package. that is non-sense. Kay is quick with pulling/merging patches and we could get commit access if we really wanted to. I just don't bother since it works good enough for me. Regards Marcel -- 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
