You are not logged in.
Hi,
Need some help with a MX5000 C-UV35 bluetooth Logitech adapter not passing to HCI only after resume.
When I boot the adapter goes in HCI without problem.
But when I suspend the machine and resume it the adapter is stuck in HID mode.
In HID mode lsusb :
Bus 002 Device 065: ID 046d:c70a Logitech, Inc. MX5000 Cordless Desktop
Bus 002 Device 064: ID 046d:c70e Logitech, Inc. MX1000 Bluetooth Laser Mouse
Bus 002 Device 063: ID 046d:0b02 Logitech, Inc. C-UV35 [Bluetooth Mini-Receiver] (HID proxy mode)In HCI mode lsusb :
Bus 002 Device 065: ID 046d:c70a Logitech, Inc. MX5000 Cordless Desktop
Bus 002 Device 064: ID 046d:c70e Logitech, Inc. MX1000 Bluetooth Laser Mouse
Bus 002 Device 073: ID 046d:c709 Logitech, Inc. BT Mini-Receiver (HCI mode)
Bus 002 Device 063: ID 046d:0b02 Logitech, Inc. C-UV35 [Bluetooth Mini-Receiver] (HID proxy mode)I'm using the bluez-hid2hci package, and the udev rule is present in /usr/lib/udev/rules.d/97-hid2hci.rules
# do not edit this file, it will be overwritten on update
ACTION=="remove", GOTO="hid2hci_end"
SUBSYSTEM!="usb*", GOTO="hid2hci_end"
# Variety of Dell Bluetooth devices - match on a mouse device that is
# self powered and where a HID report needs to be sent to switch modes
# Known supported devices: 413c:8154, 413c:8158, 413c:8162
ATTR{bInterfaceClass}=="03", ATTR{bInterfaceSubClass}=="01", ATTR{bInterfaceProtocol}=="02", \
ATTRS{bDeviceClass}=="00", ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0", \
RUN+="hid2hci --method=dell --devpath=%p", ENV{HID2HCI_SWITCH}="1"
# Logitech devices
KERNEL=="hiddev*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[345abce]|c71[34bc]", \
RUN+="hid2hci --method=logitech-hid --devpath=%p"
ENV{DEVTYPE}!="usb_device", GOTO="hid2hci_end"
# When a Dell device recovers from S3, the mouse child needs to be repoked
# Unfortunately the only event seen is the BT device disappearing, so the mouse
# device needs to be chased down on the USB bus.
ATTR{bDeviceClass}=="e0", ATTR{bDeviceSubClass}=="01", ATTR{bDeviceProtocol}=="01", ATTR{idVendor}=="413c", \
ENV{REMOVE_CMD}="/sbin/udevadm trigger --action=change --subsystem-match=usb --property-match=HID2HCI_SWITCH=1"
# CSR devices
ATTR{idVendor}=="0a12|0458|05ac", ATTR{idProduct}=="1000", RUN+="hid2hci --method=csr --devpath=%p"
LABEL="hid2hci_end"I'm pretty sure this a recent "bug" because I haven't change the configuration of my setup and this behavior is appear recently about a month ago.
I confirm when I do
/usr/bin/hid2hci --method=logitech-hid --devpath=/devices/pci0000:00/0000:00:14.0/usb2/2-14/2-14.3/2-14.3:1.0/usbmisc/hiddev0The adapter goes back to HCI. The other way to re-trigger is to unplug the adapter and re-plug it.
Do I have to do something special to trigger udev rules after suspend for this device ?
How can I confirm the udev rule is triggered ? maybe a raise condition with the bluetooth config ?
Is there a issue with systemd ?
My configuration is OK ?
I'm not a expert of udev and how it interact with systemd maybe I missing something obvious.
Last edited by hugopoi (2019-10-20 22:25:22)
Offline
After more digging with
journalctl -u systemd-udevd.service -fI get some error with multiple udev rules when I unplug / replug this device.
oct. 18 23:43:38 Hugo-WS systemd-udevd[285120]: 2-14.1: Failed to process device, ignoring: No such file or directory
oct. 18 23:44:25 Hugo-WS mtp-probe[285225]: checking bus 2, device 123: "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-10/2-10.1"
oct. 18 23:44:25 Hugo-WS mtp-probe[285225]: bus: 2, device: 123 was not an MTP device
oct. 18 23:44:25 Hugo-WS mtp-probe[285252]: checking bus 2, device 123: "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-10/2-10.1"
oct. 18 23:44:25 Hugo-WS mtp-probe[285252]: bus: 2, device: 123 was not an MTP device
oct. 18 23:45:45 Hugo-WS systemd-udevd[285322]: 2-14.2: Failed to process device, ignoring: No such file or directory
oct. 18 23:45:45 Hugo-WS systemd-udevd[285322]: 2-14.3: Failed to process device, ignoring: No such file or directory
oct. 18 23:45:45 Hugo-WS systemd-udevd[285322]: 2-14: Failed to process device, ignoring: No such file or directory
oct. 18 23:45:59 Hugo-WS mtp-probe[285350]: checking bus 2, device 125: "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-14/2-14.2"
oct. 18 23:45:59 Hugo-WS mtp-probe[285350]: bus: 2, device: 125 was not an MTP device
oct. 18 23:45:59 Hugo-WS mtp-probe[285351]: checking bus 2, device 126: "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-14/2-14.3"
oct. 18 23:45:59 Hugo-WS mtp-probe[285351]: bus: 2, device: 126 was not an MTP device
oct. 18 23:45:59 Hugo-WS systemd-udevd[285353]: hiddev0: Process 'hid2hci --method=logitech-hid --devpath=/devices/pci0000:00/0000:00:14.0/usb2/2-14/2-14.3/2-14.3:1.0/usbmisc/hiddev0' failed with exit code 1.
oct. 18 23:45:59 Hugo-WS mtp-probe[285358]: checking bus 2, device 125: "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-14/2-14.2"
oct. 18 23:45:59 Hugo-WS mtp-probe[285358]: bus: 2, device: 125 was not an MTP device
oct. 18 23:45:59 Hugo-WS mtp-probe[285359]: checking bus 2, device 126: "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-14/2-14.3"
oct. 18 23:45:59 Hugo-WS mtp-probe[285359]: bus: 2, device: 126 was not an MTP deviceAnd I have this message every time I leave suspend
Bluetooth: hci0: command 0x0804 tx timeoutWhich make sense because the adapter is no longer in HCI mode.
I start to suspect this adapter never worked after suspend and fallback to hid mode but sometimes the keyboard unpaired in hid.
Offline
I think I hit an unrelated bug in udev :
When I unplug an usb device I get this for every usb device
systemd-udevd[285322]: 2-14.2: Failed to process device, ignoring: No such file or directoryI don't know how Udev handle the usb and bluetooth remove tree but it seems that some devices remove action are skipped by udev, I confirm that this morning. But I don't know if it's the expected behavior or a bug ?
Offline
I "fixed" the issue by re-triggering the udev rule after suspend.
The script to be place in `/usr/lib/systemd/system-sleep/hid2hci-trigger` don't miss the chmod +x
#!/bin/bash
# Trigger udev rules to force Logitech going back to hci mode
if [ "${1}" == "post" ]; then
/sbin/udevadm trigger --action=change --property-match="DEVNAME=/dev/usb/hiddev0"
fiit's pretty ugly fix because I learn a lot and :
* the KERNEL=="hiddev*" udev rule can ONLY be triggered by kernel with device path hiddev* and IGNORE all the attrs check (so I think the rule is maybe triggered for all hiddev through the trigger command).
* I think there is an issue in btusb driver for this specific logitech hardware but not worth patching a 10 years old device
Offline