b0xx R2 with HayBox wakes Linux from suspend/sleep

[zzzachzzz]

I have a b0xx revision 2 that I recently flashed HayBox onto. Which has been great, thank you. I normally leave my b0xx plugged in with usb-c to my pc running Debian Linux. Something I've noticed after flashing HayBox is that with the b0xx plugged in, if I put the pc into suspend/sleep, the pc will wake up again after a couple seconds. I did not observe this behavior when I had stock b0xx firmware. My current solution is to unplug the b0xx before entering suspend.

One solution I tried to circumvent this was preventing the specific device from being able to wakeup the pc.

/etc/udev/rules.d/90-usb-wakeup.rules

# Disable waking up from b0xx
ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="2341", ATTRS{idProduct}=="8036", ATTR{power/wakeup}="disabled"

# Disable waking up from Logitech mouse usb receiver
ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c548", ATTR{power/wakeup}="disabled"

I got the vendor & product ids from the output of lsusb:

Bus 001 Device 011: ID 046d:c548 Logitech, Inc. Logi Bolt Receiver
Bus 001 Device 013: ID 2341:8036 Arduino SA Leonardo (CDC ACM, HID)
...

The rule to disable wakeup appears to be working for my Logitech mouse, but not the b0xx unfortunately. The wakeup of the pc after a couple seconds of entering suspend persists.

Let me know if there's logs or any additional info I could provide.

[JonnyHaystack]

Maybe a different udev event (other than "add") is triggering the wake-up? You can log udev events with udevadm monitor. Maybe give that a go while suspending with the controller plugged in.

I'm not sure I can really do anything about it from the firmware side. It's odd that you didn't have this issue on the B0XX firmware, because that should have the exact same endpoints.

[zzzachzzz]

Thanks for the tip and prompt response. First off, I don't expect support on this, so feel free to discard this comment and carry on, I'm just documenting what I tried. Thanks again for your work on this open source project.

I'm not super familiar with this area but I tried a number of things. As you suggested I watched udevadm monitor, and I added a rule to match ACTION=="change", no success. And yes I am reloading the rules with sudo udevadm control --reload-rules.

I tried making a broader rule with this:

ATTRS{idVendor}=="2341", ATTRS{idProduct}=="8036", ATTR{power/wakeup}="disabled"

I then tried testing the rule with udevadm test:

for x in /dev/input/by-id/usb-Arduino_LLC_Arduino_Leonardo_HIDPCHIDGF-if02-event-kbd /dev/input/by-id/usb-Arduino_LLC_Arduino_Leonardo_HIDPCHIDGF-if03-event-joystick /dev/input/by-id/usb-Arduino_LLC_Arduino_Leonardo_HIDPCHIDGF-if03-joystick; do sudo udevadm test $x; done

(I realize now those are likely the wrong paths to be supplying to udevadm test)

The output included:

js0: /etc/udev/rules.d/90-usb-wakeup.rules:7 ATTR '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.3/0003:2341:8036.003B/input/input85/js0/power/wakeup' writing 'disabled'
js0: /etc/udev/rules.d/90-usb-wakeup.rules:7 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.3/0003:2341:8036.003B/input/input85/js0/power/wakeup}, ignoring: No such file or directory

event13: /etc/udev/rules.d/90-usb-wakeup.rules:7 ATTR '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.3/0003:2341:8036.003B/input/input85/event13/power/wakeup' writing 'disabled'
event13: /etc/udev/rules.d/90-usb-wakeup.rules:7 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.3/0003:2341:8036.003B/input/input85/event13/power/wakeup}, ignoring: No such file or directory

event12: /etc/udev/rules.d/90-usb-wakeup.rules:7 ATTR '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.2/0003:2341:8036.003A/input/input84/event12/power/wakeup' writing 'disabled'
event12: /etc/udev/rules.d/90-usb-wakeup.rules:7 Failed to write ATTR{/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1:1.2/0003:2341:8036.003A/input/input84/event12/power/wakeup}, ignoring: No such file or directory

I identified that my b0xx was plugged into: /sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/

This led me to inspect the wakeup files:

$ cd /sys/devices/pci0000:00/0000:00:14.0
$ find . -type f -name 'wakeup' | xargs -I {} bash -c 'echo {} && cat {}'
./usb1/1-12/power/wakeup
disabled
./usb1/power/wakeup
disabled
./usb1/1-1/power/wakeup
disabled
./usb1/1-13/power/wakeup
disabled
./usb1/1-4/power/wakeup
disabled
./usb1/1-2/power/wakeup
disabled
./power/wakeup
enabled
./usb2/power/wakeup
disabled

I forget if I had manually intervened with some of these to disable them during my testing, but what I can say is that the only thing which solved the issue for me was disabling wakeup on the single enabled device seen there, the parent device:

echo disabled | sudo tee ./power/wakeup

Of course, this also disables my keyboard connected to the same device from waking up my pc.

It's strange that neither ./usb1/power/wakeup nor ./usb1/1-1/power/wakeup being disabled prevents the wakeup.

Random note, this command was also helpful in walking through the parent devices:

udevadm info --attribute-walk --path=$(udevadm info --query=path --name=/dev/input/by-id/usb-Arduino_LLC_Arduino_Leonardo_HIDPCHIDGF-if03-event-joystick)

[JonnyHaystack]

Hmm that's weird. Maybe the device is not directly triggering a wake-up but is triggering it through some other layer of software. Not sure how that would work though. Only other thing I can think to try right now is maybe comparing the udev events against the stock B0XX firmware to see if there's any noticeable differences.

[zzzachzzz]

Just wanted to note that I'm noticing the same issue on Windows 11, the immediate wake from suspend/sleep. I attempted to prevent the device from being allowed to wake the computer through Windows Device Manger, similar to my attempts with the udev rule in Linux, but to no avail. My solution in both OSs is to unplug my R2 b0xx.

[JonnyHaystack]

Windows is really bad with that. By default it lets pretty much any USB device or network interface wake the machine up (even from hibernation!) and it's really annoying to disable it for all the right device.

You can use some (iirc) powercfg commands to find out which devices have wake-up triggers enabled, and then disable them all. You can also write a little powershell script to disable all of them by using a loop.

FWIW I haven't experienced this issue with RP2040-based HayBox devices which I leave plugged into my PC pretty much constantly. Can't particularly recall if I experienced it with AVR-based devices either though.

[zzzachzzz]

I've got some interesting findings. So when I run powercfg -devicequery wake_armed, the output includes these 3 devices, where 1 and 2 are for my keyboard (not sure why it shows as 2 devices), and 3 is my b0xx.

HID Keyboard Device (001)
HID Keyboard Device (002)
HID Keyboard Device (003)

I tried disabling several combinations of devices, and also tested with a different keyboard as well. Only these two solutions stopped the pc from being immediately woken from sleep:

1. Disabling not just "HID Keyboard Device (003)" (b0xx), but ALL 3 of the HID Keyboard Devices.
2. Disabling only "HID Keyboard Device (003)" (b0xx), and unplugging my keyboard.

Pretty bizarre