Heya,
Here are the patches to get sixpair support built into BlueZ. It uses
libusb-1.0 as well as a yet to be merged libusb-1.0 patch to allow
re-attaching a driver to a device.
Problems left to solve:
- sixaxis enabler code (as seen in enable_sixaxis() in compat/hidd.c)
seems to have disappeared from the input plugin. Is that done in the
kernel now, or was it just removed?
- After "cable pairing" the device, I need to unplug/replug the adapter,
or restart bluetoothd. Can anyone think of a better way of getting the
list of devices updated?
- Some minor niggles in the code itself (use D-Bus instead of parsing
command-line tools)
- udev rule(s) and parsing only the selected device would be necessary
if not required
Cheers
Hi Bastien,
> > > Here are the patches to get sixpair support built into BlueZ. It uses
> > > libusb-1.0 as well as a yet to be merged libusb-1.0 patch to allow
> > > re-attaching a driver to a device.
> >
> > so I applied all patches except the changes for the build system. I am
> > not sure that this is the right way to go.
> >
> > If we require libusb-1.0, then we should just change our current code
> > that depends on libusb-0.1 and require libusb-1.0 for all of it.
>
> That'd mean porting:
> - dfutool
> - avctrl
> - bccmd's csr_usb code
> - hid2hci
>
> The code isn't too complicated, but I wouldn't be able to test any of
> the code (apart from maybe hid2hci). Is this something I can promise to
> do in the future? It's not very complicated, just time consuming.
once I upgraded my laptop with the next generation distros, I will start
porting dfutool, avctrl and bccmd over. Would be nice if you look at the
hid2hci.
> > > Problems left to solve:
> > > - sixaxis enabler code (as seen in enable_sixaxis() in compat/hidd.c)
> > > seems to have disappeared from the input plugin. Is that done in the
> > > kernel now, or was it just removed?
> >
> > The kernel is not doing it. Seems to be an oversight.
>
> OK. I'll re-add the code to the input plugin.
Any updates here?
> > > - After "cable pairing" the device, I need to unplug/replug the adapter,
> > > or restart bluetoothd. Can anyone think of a better way of getting the
> > > list of devices updated?
> >
> > We could use inotify or SIGUSR2 or something to re-read the database.
>
> There's a problem with the current method in that there might be data
> loss if we're adding data from both bluetoothd, and an external program
> (both processes writing the same file at the same time).
>
> We could solve the data loss, and update problem by having an internal,
> root only, dbus method available for cable pairing of that sort. For
> example, on org.bluez.Adapter:
> void AddCablePairedDevice (string name,
> string address,
> unsigned int vendor_id,
> unsigned int product_id,
> string pnp_record);
>
> The function would just need to do all the storage work sixpair
> currently does, and create the device internally similarly to
> create_stored_device_from_profiles().
>
> It might also be useful to have an internal (non-dbus) API at the
> manager level for hid proxy dongles (where the adapter wouldn't yet
> exist when we store the to-be-created devices, not sure how to be
> certain those devices will be temporary though).
I think the D-Bus one would be good enough. Check with Claudio and lets
come up with a patch proposal.
> > > - Some minor niggles in the code itself (use D-Bus instead of parsing
> > > command-line tools)
> >
> > Of course.
> >
> > > - udev rule(s) and parsing only the selected device would be necessary
> > > if not required
> >
> > If we can do this via the HID bus, then we can do it every time and it
> > would not affect the controller itself.
>
> Unless I misunderstood the feature, when claiming the interface, that
> would actually remove the pad as an input device.
Not with the HID bus and the HID raw support. In that case it should be
possible.
Regards
Marcel
On Thu, 2008-10-16 at 01:52 +0200, Marcel Holtmann wrote:
> Hi Bastien,
>
> > Here are the patches to get sixpair support built into BlueZ. It uses
> > libusb-1.0 as well as a yet to be merged libusb-1.0 patch to allow
> > re-attaching a driver to a device.
>
> so I applied all patches except the changes for the build system. I am
> not sure that this is the right way to go.
>
> If we require libusb-1.0, then we should just change our current code
> that depends on libusb-0.1 and require libusb-1.0 for all of it.
That'd mean porting:
- dfutool
- avctrl
- bccmd's csr_usb code
- hid2hci
The code isn't too complicated, but I wouldn't be able to test any of
the code (apart from maybe hid2hci). Is this something I can promise to
do in the future? It's not very complicated, just time consuming.
> > Problems left to solve:
> > - sixaxis enabler code (as seen in enable_sixaxis() in compat/hidd.c)
> > seems to have disappeared from the input plugin. Is that done in the
> > kernel now, or was it just removed?
>
> The kernel is not doing it. Seems to be an oversight.
OK. I'll re-add the code to the input plugin.
> > - After "cable pairing" the device, I need to unplug/replug the adapter,
> > or restart bluetoothd. Can anyone think of a better way of getting the
> > list of devices updated?
>
> We could use inotify or SIGUSR2 or something to re-read the database.
There's a problem with the current method in that there might be data
loss if we're adding data from both bluetoothd, and an external program
(both processes writing the same file at the same time).
We could solve the data loss, and update problem by having an internal,
root only, dbus method available for cable pairing of that sort. For
example, on org.bluez.Adapter:
void AddCablePairedDevice (string name,
string address,
unsigned int vendor_id,
unsigned int product_id,
string pnp_record);
The function would just need to do all the storage work sixpair
currently does, and create the device internally similarly to
create_stored_device_from_profiles().
It might also be useful to have an internal (non-dbus) API at the
manager level for hid proxy dongles (where the adapter wouldn't yet
exist when we store the to-be-created devices, not sure how to be
certain those devices will be temporary though).
> > - Some minor niggles in the code itself (use D-Bus instead of parsing
> > command-line tools)
>
> Of course.
>
> > - udev rule(s) and parsing only the selected device would be necessary
> > if not required
>
> If we can do this via the HID bus, then we can do it every time and it
> would not affect the controller itself.
Unless I misunderstood the feature, when claiming the interface, that
would actually remove the pad as an input device.
Cheers
Hi Bastien,
> Here are the patches to get sixpair support built into BlueZ. It uses
> libusb-1.0 as well as a yet to be merged libusb-1.0 patch to allow
> re-attaching a driver to a device.
so I applied all patches except the changes for the build system. I am
not sure that this is the right way to go.
If we require libusb-1.0, then we should just change our current code
that depends on libusb-0.1 and require libusb-1.0 for all of it.
> Problems left to solve:
> - sixaxis enabler code (as seen in enable_sixaxis() in compat/hidd.c)
> seems to have disappeared from the input plugin. Is that done in the
> kernel now, or was it just removed?
The kernel is not doing it. Seems to be an oversight.
> - After "cable pairing" the device, I need to unplug/replug the adapter,
> or restart bluetoothd. Can anyone think of a better way of getting the
> list of devices updated?
We could use inotify or SIGUSR2 or something to re-read the database.
> - Some minor niggles in the code itself (use D-Bus instead of parsing
> command-line tools)
Of course.
> - udev rule(s) and parsing only the selected device would be necessary
> if not required
If we can do this via the HID bus, then we can do it every time and it
would not affect the controller itself.
Regards
Marcel
Hi Bastien,
> Here are the patches to get sixpair support built into BlueZ. It uses
> libusb-1.0 as well as a yet to be merged libusb-1.0 patch to allow
> re-attaching a driver to a device.
with the 2.6.28 kernel we should get a better HID driver model (aka HID
bus) and then we might not need to libusb stuff anymore. We can go
directly to HID and read the descriptors and send vendor HID reports.
Regards
Marcel
On Sat, 2009-02-28 at 23:44 +0100, Marcel Holtmann wrote:
> Hi Bastien,
>=20
> > > We could solve the data loss, and update problem by having an interna=
l,
> > > root only, dbus method available for cable pairing of that sort. For
> > > example, on org.bluez.Adapter:
> > > void AddCablePairedDevice (string name,
> > > string address,
> > > unsigned int vendor_id,
> > > unsigned int product_id,
> > > string pnp_record);
> > >=20
> > > The function would just need to do all the storage work sixpair
> > > currently does, and create the device internally similarly to
> > > create_stored_device_from_profiles().
> >=20
> > Patch to do that attached.
> >=20
> > After setting the master bdaddr on the sixaxis using sixpair, I ran:
> > dbus-send --system --type=3Dmethod_call --print-reply --dest=3D"org.blu=
ez" /org/bluez/11043/hci0 org.bluez.Adapter.AddCablePairedDevice string:Foo=
bar string:00:19:C1:61:D6:62 uint32:0x054c uint32:0x0268 string:36019209000=
00A000100000900013503191124090004350D35061901000900113503190011090006350909=
656E09006A0901000900093508350619112409010009000D350F350D3506190100090013350=
31900110901002513576972656C65737320436F6E74726F6C6C65720901012513576972656C=
65737320436F6E74726F6C6C6572090102251B536F6E7920436F6D707574657220456E74657=
27461696E6D656E740902000901000902010901000902020800090203082109020428010902=
052801090206359A35980822259405010904A101A102850175089501150026FF00810375019=
513150025013500450105091901291381027501950D0600FF8103150026FF0005010901A100=
75089504350046FF0009300931093209358102C005017508952709018102750895300901910=
2750895300901B102C0A1028502750895300901B102C0A10285EE750895300901B102C0A102=
85EF750895300901B102C0C0090207350835060904090901000902082800090209280109020=
A280109020B09010009020C093E8009020D280009020E2800
> >=20
> > Which created the device in bluez. I'd leave it up to sixpair to remove
> > the device from other adapters, and setting the device as trusted
> > (though this didn't seem necessary for the pad to work).
>=20
> can this be made a little bit more generic. For example Bluetooth 2.1
> has the out-of-band (OOB) ways for Simple Pairing and if we can design
> something generic here that would help a lot.
What does it need for SP to work?
Hi Bastien,
> > We could solve the data loss, and update problem by having an internal,
> > root only, dbus method available for cable pairing of that sort. For
> > example, on org.bluez.Adapter:
> > void AddCablePairedDevice (string name,
> > string address,
> > unsigned int vendor_id,
> > unsigned int product_id,
> > string pnp_record);
> >
> > The function would just need to do all the storage work sixpair
> > currently does, and create the device internally similarly to
> > create_stored_device_from_profiles().
>
> Patch to do that attached.
>
> After setting the master bdaddr on the sixaxis using sixpair, I ran:
> dbus-send --system --type=method_call --print-reply --dest="org.bluez" /org/bluez/11043/hci0 org.bluez.Adapter.AddCablePairedDevice string:Foobar string:00:19:C1:61:D6:62 uint32:0x054c uint32:0x0268 string:3601920900000A000100000900013503191124090004350D35061901000900113503190011090006350909656E09006A0901000900093508350619112409010009000D350F350D350619010009001335031900110901002513576972656C65737320436F6E74726F6C6C65720901012513576972656C65737320436F6E74726F6C6C6572090102251B536F6E7920436F6D707574657220456E7465727461696E6D656E740902000901000902010901000902020800090203082109020428010902052801090206359A35980822259405010904A101A102850175089501150026FF00810375019513150025013500450105091901291381027501950D0600FF8103150026FF0005010901A10075089504350046FF0009300931093209358102C0050175089527090181027508953009019102750895300901B102C0A1028502750895300901B102C0A10285EE750895300901B102C0A10285EF750895300901B102C0C0090207350835060904090901000902082800090209280109020A280109020B09010009020C093E8009020D280009020E2800
>
> Which created the device in bluez. I'd leave it up to sixpair to remove
> the device from other adapters, and setting the device as trusted
> (though this didn't seem necessary for the pad to work).
can this be made a little bit more generic. For example Bluetooth 2.1
has the out-of-band (OOB) ways for Simple Pairing and if we can design
something generic here that would help a lot.
Regards
Marcel
On Thu, 2008-10-16 at 01:28 +0100, Bastien Nocera wrote:
<snip>
> We could solve the data loss, and update problem by having an internal,
> root only, dbus method available for cable pairing of that sort. For
> example, on org.bluez.Adapter:
> void AddCablePairedDevice (string name,
> string address,
> unsigned int vendor_id,
> unsigned int product_id,
> string pnp_record);
>
> The function would just need to do all the storage work sixpair
> currently does, and create the device internally similarly to
> create_stored_device_from_profiles().
Patch to do that attached.
After setting the master bdaddr on the sixaxis using sixpair, I ran:
dbus-send --system --type=method_call --print-reply --dest="org.bluez" /org/bluez/11043/hci0 org.bluez.Adapter.AddCablePairedDevice string:Foobar string:00:19:C1:61:D6:62 uint32:0x054c uint32:0x0268 string:3601920900000A000100000900013503191124090004350D35061901000900113503190011090006350909656E09006A0901000900093508350619112409010009000D350F350D350619010009001335031900110901002513576972656C65737320436F6E74726F6C6C65720901012513576972656C65737320436F6E74726F6C6C6572090102251B536F6E7920436F6D707574657220456E7465727461696E6D656E740902000901000902010901000902020800090203082109020428010902052801090206359A35980822259405010904A101A102850175089501150026FF00810375019513150025013500450105091901291381027501950D0600FF8103150026FF0005010901A10075089504350046FF0009300931093209358102C0050175089527090181027508953009019102750895300901B102C0A1028502750895300901B102C0A10285EE750895300901B102C0A10285EF750895300901B102C0C0090207350835060904090901000902082800090209280109020A280109020B09010009020C093E8009020D280009020E2800
Which created the device in bluez. I'd leave it up to sixpair to remove
the device from other adapters, and setting the device as trusted
(though this didn't seem necessary for the pad to work).
Cheers