Firmware Improvement: Separated KB + Mouse For More Precise Wakeup Control

MNT Pocket Reform
1

wanted to post to ask if the Pocket Reform firmware could be updated to make the keyboard and mouse appear as two separate devices for use with things like /proc/acpi/wakeup and similar things, or if anyone had any ideas how to do this myself?

the reason i really want this is i find when the Pocket Reform is, well, in my pocket, the trackball keeps jiggling, enough to wake the screen with pretty much every step, meaning the screen is always on, killing the battery. it’d be awesome if the Pocket Reform could be setup with the mouse being unable to wake the screen so keystrokes are needed, saving battery while on the move.

2

This is definitely something that should be fixed, and will be at the latest when Quasar is shipping (as it is expected that suspend/resume has to work well). I’ve thought about your report a bit this morning. The devices should already be split though, as it’s virtually both a keyboard and a mouse HID device (and potentially more). They can’t be split into separate USB devices though because there’s no hub in the keyboard.

On the other hand it might be worthwhile to look into general USB suspend support in the firmware, so that it can detect if the system is suspended/locked and then no longer send mouse movements, for example.

3

A recipe would roughly be like this:

  1. Make sure that linux is actually putting the USB device in Suspend State in the locked state, even if the system itself is not going to full suspend (I think this is called “device suspend” in Linux power mgmt).
  2. Confirm that the keyboard detects this state by doing something in tud_suspend_cb() in the firmware (and tud_resume_cb(). USB Concepts - TinyUSB
  3. If this is the case, I can introduce a new global state variable in the firmware that would prevent mouse reports from being generated. This variable would be toggled on and off in tud_suspend_cb() and tud_resume_cb(), respectively.
1 Like
4

Actually, 3. won’t work that easily if USB is suspended. Instead, we should then introduce a special mode that calls tud_remote_wakeup() when keys are pressed: USB Concepts - TinyUSB

5

for this to work it’d need to apply to both the lock screen for things like gnome and also suspend (though maybe you’re considering those to be the same thing? i imagine suspend to be a bit more)

the issue is precisely that they can’t be separated into different devices on the USB level, since while evtest sees mouse and KB separate, lsusb does not, and in all my research it needs to be at the usb device level, but maybe it could be configured where evtest pulls from? evtest pulls from /dev/input, so maybe it can be configured there somehow? but i think /dev’s stuff pull from other places. i haven’t dug around in the lower levels of Linux just yet like how the device trees work and are structured, but maybe someone else knows better about the differences between how lsusub and /dev/input work?

that could also work, but will that be configurable by the user still? since this may not apply to all use cases, or will it be able to pull from a user configurable place in the OS? or maybe could (if only temporarly) it be configurable with the new fancy syscontroller CLI built into the OLED menu as a workaround?

6

Sure, that is only a design question (easy). Lets focus on a technical path / proof of concept first (harder).

1 Like
7

note that this research/legwork was done on debian trixie but i imagine this is something that’s the same on Trixie and unstable.

ok read that arch user article more (i constantly underestimate how information dense the arch manual is, wow) i find section 1.4 which states the following paths will have wakeup triggers

/sys/class/wakeup/*/device/physical_node/power/wakeup
/sys/class/wakeup/*/device/power/wakeup

catting the second one i get 3 “enabled” returns. manually going in i checked the directories and get this

nebula@The-Reform-False-God-Of-The-Abyss-Entropys-Paradox-Conqueror-Of:/sys/class/wakeup$ ls -la
total 0
drwxr-xr-x  2 root root 0 Aug 27 15:34 .
drwxr-xr-x 69 root root 0 Aug 27 15:34 ..
lrwxrwxrwx  1 root root 0 Aug 27 15:34 wakeup0 -> ../../devices/virtual/wakeup/wakeup0
lrwxrwxrwx  1 root root 0 Aug 27 15:34 wakeup1 -> ../../devices/virtual/wakeup/wakeup1
lrwxrwxrwx  1 root root 0 Aug 27 15:34 wakeup2 -> ../../devices/platform/soc/ff800000.bus/ff8000a8.rtc/wakeup/wakeup2
lrwxrwxrwx  1 root root 0 Aug 27 15:34 wakeup3 -> ../../devices/platform/soc/ff800000.bus/ff8000a8.rtc/rtc/rtc1/alarmtimer.0.auto/wakeup/wakeup3
lrwxrwxrwx  1 root root 0 Aug 27 15:34 wakeup4 -> ../../devices/virtual/wakeup/wakeup4
lrwxrwxrwx  1 root root 0 Aug 27 15:34 wakeup5 -> ../../devices/platform/spi/spi_master/spi0/spi0.0/power_supply/BAT0/wakeup5

checking them each i get

nebula@The-Reform-False-God-Of-The-Abyss-Entropys-Paradox-Conqueror-Of:/sys/class/wakeup$ cat wakeup0/device/power/wakeup
cat: wakeup0/device/power/wakeup: No such file or directory
nebula@The-Reform-False-God-Of-The-Abyss-Entropys-Paradox-Conqueror-Of:/sys/class/wakeup$ cat wakeup1/device/power/wakeup
cat: wakeup1/device/power/wakeup: No such file or directory
nebula@The-Reform-False-God-Of-The-Abyss-Entropys-Paradox-Conqueror-Of:/sys/class/wakeup$ cat wakeup2/device/power/wakeup
enabled
nebula@The-Reform-False-God-Of-The-Abyss-Entropys-Paradox-Conqueror-Of:/sys/class/wakeup$ cat wakeup3/device/power/wakeup
enabled
nebula@The-Reform-False-God-Of-The-Abyss-Entropys-Paradox-Conqueror-Of:/sys/class/wakeup$ cat wakeup4/device/power/wakeup
cat: wakeup4/device/power/wakeup: No such file or directory
nebula@The-Reform-False-God-Of-The-Abyss-Entropys-Paradox-Conqueror-Of:/sys/class/wakeup$ cat wakeup5/device/power/wakeup
enabled

so 2, 3, and 5 all have wakeup triggers. all are symlinks, 2 goes to soc components, so not sure i want that, 3 leads to soc alarmtimer so i don’t think i want that either, and 5 is listed as power supply, i definitely don’t think i want that. using section 3.2’s command, grep -F "" /sys/class/wakeup/*/device/power/wakeup_count, gets zeroes across the board, before and after lock and unlock.

bouncing back to section 1.2, it says that /sys/module/acpi/parameters/ec_no_wakeup would have the data for the acpi kernel module. searching with apt and installing acpi isn’t what i’m after i don’t think, but maybe it’s another package since it’s a kernel module?

now if this is gonna be a fully FW based solution, will there be a way to trigger that state on screen lock as well? perhaps one of the above locations can be used for ease of access with the feature integrated into the driver?

hope that if nothing else some of this poking around helps give some data to work with.

8

Sorry but I don’t really understand what you’re doing there in the sysfs, but I can tell you that as we’re not on PC platform there’s no ACPI.

1 Like
9

i see, my mistake, didn’t realise that was why.

what i was doing was trying to see if any of the locations the arch manual pointed to could be edited to do what i want in the interim until the FW is updated (and because i am inexperienced in FW so help i can provide is limited), but it seems like that’s a no so i’ll try looking more into the FW then and seeing about learning that

1 Like