USB device reset button (feature request)

[drws]

blueman: 2.3.1 BlueZ: 5.65 Distribution: Arch Desktop environment: MATE

Some buggy USB adapters occasionally need usbreset (USBDEVFS_RESET) to get them from an error state. I know this is a workaround, but that is the reality with some drivers. It would be great to have such functionality avaliable in Blueman. Namely a Reset USB device button in blueman-adapters in case of an USB device.

[cschramm]

I just had issue with my adapter not responding and successfully fixed it with fcntl.ioctl(open("/dev/bus/usb/003/008", "w"), ord('U') << 8 | 20, 0). I think this is a useful addition / tool.

A couple of observations:

• I currently have no straightforward idea how to get to an adapter's device file.
• The Python library does not provide a constant for the operation but we can hard-code it of course.
• Its a privileged operation, so we'd need to implement it in blueman-mechanism.

[drws]

What exactly does 'U' cause, unbind? In that case it is similar to but not completely the same as USBDEVFS_RESET as per the internets. If it happens again please try to reset your adapter also with usbreset (source code at link).

[cschramm]

ord('U') << 8 | 20 is exactly the definition of USBDEVFS_RESET. It's the character 'U', the magic value for USB IO opcodes, as the first byte and the serial number 20 for the specific operation (The decimal value is 21780). The call is exactly the same as in the usbreset tool.

[cschramm]

I currently have no straightforward idea how to get to an adapter's device file.

This is a blocker. Ideas welcome.

To illustrate: When we know about an adapter, we do have:

• D-Bus object path like /org/bluez/hci0
• Device name like hci0 (at least we can easily extract it from the object path)
• Bluetooth hardware address like 00:00:00:00:00:00
• Modalias like usb:v0000p0000d0000

We need to get to know the corresponding USB device file like /dev/bus/usb/003/008 in order to talk to it.

There might be some way via data linked to from /sys/class/bluetooth/hci0 but I did not find it yet. It might also boil down to iterating over USB devices and checking them against the data we know, especially the modalias - not a good identifier, though...