Just upgraded bluez to 4.94-2 as it came into testing sometime this week, and my Logitech bluetooth keyboard and mouse combo (MX5500) stopped working again. I have rolled back to a known working version (4.66-3). I know there was an upgrade since 4.66-3 that was OK but I don't remember the version number. Rolling bluez only back to 4.66-3 fixes the problem. Please look into this guys, because wireless keyboard users like me really get hit hard when this keeps breaking. Please let me know if there's any more info I can provide that will help. I'm not sure what logs etc would be relevant. Fortunately I'm not as messed up by this this time as I learned the hard way how to find an old working version and roll back the last time this happened. What can we as a community do to help prevent the continuing recurrence of issues with Logitech keyboards? Is there something we can pressure the vendor to be more forthcoming on? Or testing of proposed upgrades we can participate in (I'm neither super technical nor awash with spare time, but I'm willing to help as much as I can if it will mean I can upgrade bluez without cringing in the future... :-) )
Bug #626975 may give you some ideas. The result from 'lsusb' paired with the rules in /lib/udev/rules.d/*hid2hci.rules may be a start point.
Well the first thing I notice is that the rules in that file in /lib/udev/rules.d are expressed completely differently between the two package versions. This is looking more like it was back in the 4.61 days (when nothing worked for this keyboard combo either). 4.66-3 (which works) specifies the path to the hid2hci executable, in /usr/sbin. Meanwhile, 4.94-2 doesn't specify the path to the hid2hci executable, and puts the executable in /lib/udev by the look of it. Any chance the hid2hci executable is not being found? I also notice the hid2hci executable has changed between the two versions, not just its path. The command line options etc are different. Any chance the new one just doesn't work properly? Overall I'm inclined to think the rule is firing but is either not able to find the hid2hci executable it is supposed to be running, or else that executable is not doing its job properly. I looked over the bug you pointed me at but I'm quickly getting out of my depth. I'll take a more detailed look later if I have time later this evening (in Japan, Sunday evening here). I'd like to be able to see some evidence of what's happening in the logs but I am not sure which logs I should be looking in -- I don't know my way around the debian logging arrangements well enough at the moment. If you can give me a pointer on that I can maybe gather some more useful information. And finally -- lsusb output (when 4.66-3 is installed -- ie working. Are you thinking it would be different when 4.94-2 is installed? No, right?) Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 004: ID 0d8c:000c C-Media Electronics, Inc. Audio Adapter Bus 008 Device 002: ID 046d:0b06 Logitech, Inc. Bus 008 Device 003: ID 046d:c71b Logitech, Inc. Bus 008 Device 004: ID 046d:c71c Logitech, Inc. You can see the keyboard / mouse are using c71b and c71c which are both covered in the udev rules. 0b06 is not, but that's also true in the working 4.66-3 version so I don't think that matters. C-Media is a USB headset I am using, which is not bluetooth and works fine. Mark
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
Please skip the html-formated message mime part (gmail sickness).
The text/plain is sufficient.
I wouldn't know anything about that. I jumped on that horse at 4.91-1 :)
I couldn't get my BT dongle working.
Bus 001 Device 004: ID 046d:0b04 Logitech, Inc.
Bus 001 Device 005: ID 046d:c713 Logitech, Inc.
Bus 001 Device 006: ID 046d:c714 Logitech, Inc. diNovo Edge Keyboard
Bus 001 Device 007: ID 046d:c709 Logitech, Inc. BT Mini-Receiver (HCI mode)
I know nothing about MX5500. Does it come with a dongle?
# dmesg
may reveal more details.
# lsusb -v
does that too.
# udevadm control --log-priority=debug
may also help. So may 'udevadm monitor ...'.
There's also the bluez-hcidump and bluez-tools packages with monitoring
tools.
udev, AFAIR, picks the executables (used in the "RUN" rules) from
/lib/udev. Whole path need to be specified for other locations.
Please run this:
# dpkg -S hid2hci
and show us the results. On my sid and testing installations it shows:
bluez: /usr/share/man/man8/hid2hci.8.gz
bluez: /lib/udev/hid2hci
bluez: /lib/udev/rules.d/62-bluez-hid2hci.rules
Those should be the only 'hid2hci' related files you should find on your
box. At some point there was:
udev: /lib/udev/hid2hci
udev: /lib/udev/rules.d/70-hid2hci.rules
bluez: /usr/sbin/hid2hci
bluez: /lib/udev/rules.d/62-bluez-hid2hci.rules
with 2 different command line options/arguments and somewhat different
rules. Recent udev versions don't ship hid2hci any more.
Yes. See above.
The bluez package /lib/udev/hid2hci used in
/lib/udev/rules.d/62-bluez-hid2hci.rules from 4.94-2 (look at the man page
too) is the correct one, AFAICT.
What does:
# hcitool dev
and:
# hcitool scan
show?
Yes. See above ('udevadm control ...'). You should be able to 'tail -f
/var/log/syslog' and find out more.
Shouldn't matter.
Cheers,
Came to think of it. There's also a /var/lib/bluetooth/ directory where the dbus-files are stored. I don't know if they're equivalent between bluez 4.66-3 and 4.94-2. You may want to try: * disconnect the USB Bluetooth mini-receiver * move away/rename /var/lib/bluetooth * recreate /var/lib/bluetooth * install 4.94-2 * connect the USB Bluetooth mini-receiver * re-pair Cheers,