Re: [PATCHes] Add sixpair

Hi Bastien,

quoted

quoted

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.

quoted

quoted

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?

quoted

quoted

- 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.

quoted

quoted

- Some minor niggles in the code itself (use D-Bus instead of parsing
command-line tools)

Of course.

quoted

- 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