b0xx R2 with HayBox wakes Linux from suspend/sleep about haybox

[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.