Hi:
Since hid2hci has been accepted into udev-extras, I'd like to remove it
from bluez source. Attached is a patch.
Regards
Hi Marcel:
Marcel Holtmann wrote:
> Hi Bastien,
>
>
>
> 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
Kay has merged this into mainline udev (all the stuff in extras was
moved there). Since another release is due out today, can this be
removed from bluez before that release?
Thanks,
--
Mario Limonciello
*Dell | Linux Engineering*
[email protected]
Hi Marcel:
Marcel Holtmann wrote:
> Hi Bastien,
>
> 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
Kay has merged this into mainline udev (all the stuff in extras was
moved there). Since another release is due out today, can this be
removed from bluez before that release?
Thanks,
--
Mario Limonciello
*Dell | Linux Engineering*
[email protected]
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
Bastien Nocera wrote:
> On Mon, 2009-06-15 at 09:20 +0100, Simon Kenyon wrote:
>
>> [email protected] wrote:
>>
>>> Hi:
>>>
>>> Since hid2hci has been accepted into udev-extras, I'd like to remove it
>>> from bluez source. Attached is a patch.
>>>
>>> Regards
>>>
>>>
>> am i correct in thinking that this is a fedora package?
>>
>
> No.
>
>
>> what about all the other distributions out there?
>>
>
> N/A.
>
apologies
i see it on git.kernel.org
--
simon
Hi Bastien:
Bastien Nocera wrote:
> On Mon, 2009-06-15 at 09:13 -0500, Mario Limonciello wrote:
>
>
> Why? Instead of calling hid2hci, it would launch bluetoothd --udev, like
> the other rules. Problem solved.
>
Good point, that's sensible enough.
>
>
> 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.
>
>
Eh, direct commit access? You submit it to this mailing list and Marcel
has to ack it, you submit it to linux-hotplug and Kay or Martin acks
it. Seems to be 6 eggs in one hand, half a dozen in the other. Look
over the history, and those hacking on hid2hci have been me and Marcel:
http://git.kernel.org/?p=bluetooth/bluez.git;a=history;f=tools/hid2hci.c;h=11d707fd76e940b884c9078907ab1
504cd7350d4;hb=HEAD
--
Mario Limonciello
*Dell | Linux Engineering*
[email protected]
On Mon, 2009-06-15 at 09:13 -0500, Mario Limonciello wrote:
> 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.
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.
> > (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
>
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*
[email protected]
On Mon, 2009-06-15 at 09:20 +0100, Simon Kenyon wrote:
> [email protected] wrote:
> > Hi:
> >
> > Since hid2hci has been accepted into udev-extras, I'd like to remove it
> > from bluez source. Attached is a patch.
> >
> > Regards
> >
> am i correct in thinking that this is a fedora package?
No.
> what about all the other distributions out there?
N/A.
[email protected] wrote:
> Hi:
>
> Since hid2hci has been accepted into udev-extras, I'd like to remove it
> from bluez source. Attached is a patch.
>
> Regards
>
am i correct in thinking that this is a fedora package?
what about all the other distributions out there?
--
simon
On Sun, 2009-06-14 at 17:54 -0500, [email protected] wrote:
> Hi:
>
> Since hid2hci has been accepted into udev-extras, I'd like to remove it
> from bluez source. Attached is a patch.
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.
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.
So I'd rather hid2hci didn't go into udev-extras, and stayed in bluez
until a better solution comes along.
(Still no luck on getting specs from Broadcom about the Dell adapters at
least?)
Cheers