[Pkg-bluetooth-maintainers] Bug#631620: there may be things you could help with

[Mark Fletcher]

On Sun, Jul 24, 2011 at 8:36 PM, Mark Fletcher <mark27q1 at gmail.com> wrote:

>
>
> On Sat, Jul 23, 2011 at 5:57 PM, Cristian Ionescu-Idbohrn <
> cristian.ionescu-idbohrn at axis.com> wrote:
>
>> Bug #626975 may give you some ideas.
>>
>>
Further follow-up. I've just found something very interesting indeed.

Using 4.66-3, which works, I followed through the process you documented in
bug 626975. So I lifted out of syslog the device path being used for the
keyboard part of my keyboard / mouse combo. Checked the vendor and product
matched up with the output of lsusb as you did -- they do. Next I used
udevadm test and if I'm reading that output right, only one rule matches the
keyboard / mouse combo and that is the generic  RUN
'socket:@/org/freedesktop/hal/udev_event'
/lib/udev/rules.d/90-hal.rules:2. No sign of hid2hci being called _in the
version that works!!!_

That prompted me to look harder at the structure of the rules in the bluez
package in 4.66-3. The rule for the keyboard is: ACTION=="add",
ENV{ID_VENDOR}=="046d", ENV{ID_MODEL}=="c71b" RUN+="/usr/sbin/hid2hci
--method logitech -v $env{ID_VENDOR} -p $env{ID_MODEL} --mode hci"

Now, I'm making a leap here, but I'm wondering if the "Vendor" and "Product"
of /sys/devices/yahdahyahdahyahdah/input/inputX/id should match up with the
variables used in that statement. If so, there is no "model" -- it's
"Vendor" which could match with ENV{ID_VENDOR} and "Product" which doesn't
match with anything. That might explain why this udev rule is not firing in
4.66-3.

In 4.94-2, the equivalent rule is: KERNEL=="hiddev*",
ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[345abce]|c71[34bc]", \
  RUN+="hid2hci --method=logitech-hid --devpath=%p"

Now this one uses "idVendor" and "idProduct" which match up with what I see
under /sys/devices, so I'm thinking this has a better chance of getting run.
So now I am wondering if this rule IS firing in 4.94-2 and the fact that its
firing is what is messing me up. Would imply the solution, somewhat
counterintuitively, is to SUPPRESS the matching of this rule somehow. I'm
not sure how I'd do that though, short of removing c71b and c71c from the
matching list, which might work for me but break someone else with similar
but slightly different hardware.

I haven't actually tried re-installing 4.94-2 and running udevadm test
again, because doing so will essentially break the computer and I need to
find a window for that when it's not doing anything important (it's tonight
or not until next weekend, because I can't afford for it to be broken during
the week). I'll try to do that before going to bed tonight.

Reckon I'm barking up the right tree with this, or merely barking? :-)

Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-bluetooth-maintainers/attachments/20110724/a553034b/attachment.html>