udev fails to call hid2hci for Logitech USB Bluetooth adapter

I made the following change in /lib/udev/rules.d/70-hid2hci.rules and now it works.

KERNEL=="hidraw*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[4abc]|c71[34bc]", \

changed to:

KERNEL=="hiddev*|hidraw*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[4abc]|c71[34bc]", \

I don't understand this, because it seems from the `udevadm monitor` output that my adapter (c70[bc]) really was a hidraw device. However, the results speak for themselves and this change has fixed the problem for me, while maintaining a fairly tight KERNEL condition. I suspect that if other people's Logitech USB Bluetooth dongles are still not working with this patch, then they may want to make a similar change to the previous line in 70-hid2hci.rules, but I am not touching that for now, because it does not affect me.

I remember a while ago, there was only one Logitech rule, and it used the | (or) operator for the KERNEL condition, just like my fix does. Does anyone know why they were separated into different rules? Because, obviously, they were under-matching by doing so.

I have attached a proper diff patch for those who are interested.

Unfortunately this rule cause eternal grief. It seems now matter how we switch them around, something will always break for somebody :-(

We already tested the combined hiddev|hidraw rule in bug 550288 (comment 31 ff) and it broke stuff for other people.

Mario, since you wrote hid2hci, do you happen to have a clever idea about how to fix this for good?

Thanks, Martin

Martin:

What about instead settings KERNEL=="hid*"? That should cover both hiddev and hidraw devices without being too open.

Mario,

but that would again cause the regressions that we saw in bug 550288, when we already tried hiddev*|hidraw*

My problem with the KERNEL=="hidraw*" line was that it would not match for my adapter (even though my adapter appeared as a hidraw device). Was the problem encountered in bug #550288 that it would not match for KERNEL=="hiddev*|hidraw*" but it would match for KERNEL=="hidraw*"?

I ask this, because I tried adding a separate copy of the line for "hiddev*|hidraw*" before the original "hidraw*" line. This patch still fixes my problem. Is it possible to ask someone who had the problem with the | operator in bug #550288 to try out this new patch? If I am right, then it should work for them as well.

Ugh, an update to udev (without this patch) just overwrote my fix from comment #6.

Note to people using my fix: until my patch, or something equivalent, gets released, first copy /lib/udev/rules.d/70-hid2hci.rules to /etc/udev/rules.d/ and then apply the patch to that copy. Files in /etc/udev/rules.d/ are protected from updates.

Odd behavior is still present in Natty. I use the Logitech MX-5500 Revolution combo, and the bluetooth dongle does not show up as a Bluetooth device by default in Natty at all, though the keyboard/mouse do work by default in Logitech's "fallback" mode which connects the devices as pseudo-wired when the dongle is hotplugged.

The problem is that in fallback mode, I have been getting random disconnections with the standard Natty configuration, which still splits kernel conditions into hiddev and hidraw. The device does not stay connected for more than two hours or so, and I need to re-hotplug it.

By commenting out the leading kernel conditions entirely and leaving the two declarations starting with ATTRS, as suggested here and in the original bug report #444420, it is now being detected as a Bluetooth dongle and allows me to do a proper pairing with the devices from within Ubuntu. So far this has been MUCH more stable and gives me greater range as well.

Is the issue just that the default behavior desired by the devs was "just works" plug and play? Relying on Logitech's fallback functionality for standard keyboard/mouse connection is less than desirable for real daily use. Maybe a device-specific recommendation through the Additional Drivers detection process, along with an installable package to switch the default configuration for the dongle device to native Bluetooth functionality, would be a better way to approach it to "solve" the issue for everyone. It could even include a description of the pairing process for the two devices as part of the package install.

Additional info:

With default Natty configuration in /lib/udev/rules.d/70-hid2hci.rules, I get the following three devices reported by lsusb:

Bus 005 Device 025: ID 046d:c71c Logitech, Inc.
Bus 005 Device 024: ID 046d:c71b Logitech, Inc.
Bus 005 Device 023: ID 046d:0b06 Logitech, Inc.

After the change suggested by this bug report, I get all three of those devices plus an additional device that did not appear before at all:

Bus 005 Device 026: ID 046d:c709 Logitech, Inc. BT Mini-Receiver (HCI mode)
Bus 005 Device 025: ID 046d:c71c Logitech, Inc.
Bus 005 Device 024: ID 046d:c71b Logitech, Inc.
Bus 005 Device 023: ID 046d:0b06 Logitech, Inc.

It seems it's not just the mode that changes for the existing devices, but also involves the detection of additional hardware. I hope my suggestion about the Additional Drivers function in the previous comment is something that might have some appeal... it would preserve default "plug and play" functionality while allowing a clear and direct upgrade/configuration path to connect the devices properly via Bluetooth. This problem has been one of the top generators of "Logitech" related bugs in Ubuntu since 8.04, that's over seven major revisions of the OS, and I'm sure the devs are tired of seeing it crop up repeatedly.

Reassigning to bluez, as hid2hci stuff moved to the bluez project now and was dropped from udev.

What is the status on this bug? I would like to get this working but I have over a 150 other machines to deal with and I don't want to break other logitech devices just to get this keyboard to work.

This is reported against an old version of Ubuntu and many things has changed since then. Because of that we won't fix this issue however if this behavior repeats on a modern version please fill a bug report against it and we will take it from there.