udev fails to call hid2hci for Logitech USB Bluetooth adapter

Bug #658471 reported by Robert Lange
28
This bug affects 3 people
Affects Status Importance Assigned to Milestone
bluez (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: udev

This bug is related to Bug #444420, but I was told to file it as a new bug here.

Here are the rules I have for Logitech USB Bluetooth dongles in /lib/udev/rules.d/70-hid2hci.rules:

# Logitech devices
KERNEL=="hiddev*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[35e]", \
  RUN+="hid2hci --method=logitech-hid --devpath=%p"
KERNEL=="hidraw*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[4abc]|c71[34bc]", \
  RUN+="hid2hci --method=logitech-hid --devpath=%p"

This is an upgrade from Lucid (on which hid2hci was called) to Maverick (at which point, hid2hci was no longer called).

As seen in lsusb output, my adapter should have matched the second line:

Bus 001 Device 006: ID 046d:c70c Logitech, Inc. BT Mini-Receiver (HID proxy mode)
Bus 001 Device 005: ID 046d:c70b Logitech, Inc. BT Mini-Receiver (HID proxy mode)
Bus 001 Device 003: ID 046d:0b02 Logitech, Inc. BT Mini-Receiver (HID proxy mode)

I removed the KERNEL condition from the rules file:

# Logitech devices
ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[35e]", \
  RUN+="hid2hci --method=logitech-hid --devpath=%p"
ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[4abc]|c71[34bc]", \
  RUN+="hid2hci --method=logitech-hid --devpath=%p"

I restarted udev and re-inserted the adapter. While everything seems to work correctly now, I am told that this is wrong because it could somehow overmatch something.

Attached is the output of `udevadm monitor` when udev is running with the original Maverick 70-hid2hci.rules file and the adapter is inserted.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: udev 162-2
ProcVersionSignature: Ubuntu 2.6.35-22.33-generic 2.6.35.4
Uname: Linux 2.6.35-22-generic x86_64
NonfreeKernelModules: nvidia
Architecture: amd64
Date: Mon Oct 11 11:16:01 2010
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release amd64 (20100429)
MachineType: System manufacturer System Product Name
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.35-22-generic root=UUID=b8e395c0-dc79-4ec7-8100-3d7b33afb2e4 ro quiet splash
ProcEnviron:
 LC_COLLATE=C
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: udev
dmi.bios.date: 02/24/2010
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 0703
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: P6X58D PREMIUM
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0703:bd02/24/2010:svnSystemmanufacturer:pnSystemProductName:pvrSystemVersion:rvnASUSTeKComputerINC.:rnP6X58DPREMIUM:rvrRev1.xx:cvnChassisManufacture:ct3:cvrChassisVersion:
dmi.product.name: System Product Name
dmi.product.version: System Version
dmi.sys.vendor: System manufacturer

Revision history for this message
Robert Lange (rcl24) wrote :
Revision history for this message
Robert Lange (rcl24) wrote :

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.

Changed in udev (Ubuntu):
status: New → In Progress
tags: added: patch
Revision history for this message
Martin Pitt (pitti) wrote :

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

Changed in udev (Ubuntu):
status: In Progress → Triaged
Revision history for this message
Mario Limonciello (superm1) wrote :

Martin:

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

Revision history for this message
Martin Pitt (pitti) wrote :

Mario,

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

Revision history for this message
Robert Lange (rcl24) wrote :

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.

Revision history for this message
Robert Lange (rcl24) wrote :

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.

Revision history for this message
JasonPorter (jasonporter) wrote :

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.

Revision history for this message
JasonPorter (jasonporter) wrote :

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.

Revision history for this message
Martin Pitt (pitti) wrote :

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

affects: udev (Ubuntu) → bluez (Ubuntu)
Revision history for this message
Tyler Gates (tgates81) wrote :

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.

Revision history for this message
Konrad Zapałowicz (kzapalowicz) wrote :

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.

Changed in bluez (Ubuntu):
status: Triaged → Invalid
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers