On Sun, Jul 24, 2011 at 8:36 PM, Mark Fletcher <[email protected]> wrote:
> > > On Sat, Jul 23, 2011 at 5:57 PM, Cristian Ionescu-Idbohrn < > [email protected]> 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
