Re: [PATCH] Remove hid2hci from bluez

[Marcel Holtmann <marcel@holtmann.org>]

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