Hi,
with master (a267bc2) I am getting this in dmesg for Sixaxis
controllers:
input: PLAYSTATION(R)3 Controller as /devices/pci0000:00/0000:00:02.0/...
generic-bluetooth 0005:0000:0000.0018: input,hidraw1: BLUETOOTH HID v0.00 ...
^^^^^^^^^^^^^^^^^ ^^^^ ^^^^
generic driver is used because vendor_id and product_id are 0000!
while I would expect this:
input: PLAYSTATION(R)3 Controller as /devices/pci0000:00/0000:00:02.0/...
sony 0005:054C:0268.0017: input,hidraw1: BLUETOOTH HID v0.00 ...
^^^^ ^^^^ ^^^^
Having vendor_id and product_id set to 0000 was making the device not
working, the story is briefly like that:
- the hid-sony kernel driver makes the controller operational;
- devices are bound to hid drivers using vendor_id and product_id;
- with those set to 0000, hid-sony ends up not being used at all.
I bisected the problem to this commit:
73952ca597960043de7c32bd172bc5bc816b324e is the first bad commit
commit 73952ca597960043de7c32bd172bc5bc816b324e
Author: Luiz Augusto von Dentz <[email protected]>
Date: Thu Sep 22 18:51:51 2011 +0300
Remove use of read_device_id in input plugin
Make use of btd_device_get_vendor, btd_device_get_product and
btd_device_get_version intead.
Reverting it fixes the problem for me, but is a better fix possible?
Thanks,
Antonio
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
On Tue, 15 Nov 2011 11:59:12 +0200
Luiz Augusto von Dentz <[email protected]> wrote:
> Hi Antonio,
>
> On Tue, Nov 15, 2011 at 1:37 AM, Antonio Ospite
> <[email protected]> wrote:
> > Hi,
> >
> > with master (a267bc2) I am getting this in dmesg for Sixaxis
> > controllers:
> >
> > input: PLAYSTATION(R)3 Controller as /devices/pci0000:00/0000:00:02.0/...
> > generic-bluetooth 0005:0000:0000.0018: input,hidraw1: BLUETOOTH HID v0.00 ...
> > ^^^^^^^^^^^^^^^^^ ? ? ?^^^^ ^^^^
> >
> > generic driver is used because vendor_id and product_id are 0000!
> > while I would expect this:
> >
> > input: PLAYSTATION(R)3 Controller as /devices/pci0000:00/0000:00:02.0/...
> > sony 0005:054C:0268.0017: input,hidraw1: BLUETOOTH HID v0.00 ...
> > ^^^^ ? ? ?^^^^ ^^^^
> >
> > Having vendor_id and product_id set to 0000 was making the device not
> > working, the story is briefly like that:
> > ?- the hid-sony kernel driver makes the controller operational;
> > ?- devices are bound to hid drivers using vendor_id and product_id;
> > ?- with those set to 0000, hid-sony ends up not being used at all.
>
> That is probably a bug in the code, does the device properties got the
> right values?
>
Yes they do right after read_device_id_from_did(), I have investigated
a little more.
The 'did' file for the device contains:
00:1B:FB:XX:XX:XX FFFF 054C 0268 0000
Only now I realize that the source field (the one now set to FFFF)
is supposed to be either 0x0001 ore 0x0002 like said in [1, section
5.6] about VendorIDSource, so I was doing it wrong. Setting the value to
0x0002 (as the vendor is taken from the USB device) make the device
working.
But _maybe_ this error on my side exposed something inaccurate in BLueZ
too, please keep reading.
This is what was happening in device_cerate(): read_device_id() failed
and this block was never called.
if (read_device_id(srcaddr, address, NULL, &vendor, &product,
&version) == 0) {
device_set_vendor(device, vendor);
device_set_product(device, product);
device_set_version(device, version);
}
However, the values were taken correctly in read_device_id_from_did(),
but this snippet makes read_device_id() return with an error
regardeless:
err = read_device_id_from_did(srcaddr, dstaddr, &lsource,
vendor, product,version);
if (!err) {
if (lsource == 0xffff)
err = -ENOENT;
return err;
}
Now, the reference to the special value FFFF I can find in [1] is
about VendorID [1, section 5.2], NOT VendorIDSource, so my wrong value
in the 'did' file might have exposed a spec misinterpretation here.
Should the check be:
if (*vendor == 0xffff)
err = -ENOENT;
? Changing the other assignment of this value in the code too.
And what about issuing a warning if the 'source' field stored by
store_device_id() is not 0x0001 or 0x0002?
Thanks,
Antonio
[1]
https://developer.bluetooth.org/KnowledgeCenter/TechnologyOverview/Documents/DeviceID_SPEC.pdf
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
Hi Antonio,
On Tue, Nov 15, 2011 at 1:37 AM, Antonio Ospite
<[email protected]> wrote:
> Hi,
>
> with master (a267bc2) I am getting this in dmesg for Sixaxis
> controllers:
>
> input: PLAYSTATION(R)3 Controller as /devices/pci0000:00/0000:00:02.0/...
> generic-bluetooth 0005:0000:0000.0018: input,hidraw1: BLUETOOTH HID v0.00 ...
> ^^^^^^^^^^^^^^^^^ ? ? ?^^^^ ^^^^
>
> generic driver is used because vendor_id and product_id are 0000!
> while I would expect this:
>
> input: PLAYSTATION(R)3 Controller as /devices/pci0000:00/0000:00:02.0/...
> sony 0005:054C:0268.0017: input,hidraw1: BLUETOOTH HID v0.00 ...
> ^^^^ ? ? ?^^^^ ^^^^
>
> Having vendor_id and product_id set to 0000 was making the device not
> working, the story is briefly like that:
> ?- the hid-sony kernel driver makes the controller operational;
> ?- devices are bound to hid drivers using vendor_id and product_id;
> ?- with those set to 0000, hid-sony ends up not being used at all.
That is probably a bug in the code, does the device properties got the
right values?
--
Luiz Augusto von Dentz