add Debian package sources for resetting USB after resume

[benedekkupper]

This is half of a complete solution to work around the scrolling issue on Linux after suspend. What I have prepared is a script and a systemd service to run this script after each wake from suspend. It works on my machine, but I'd like if others also tested this (@kareltucek would you?). The only part that can be wrong is the sleep 1.5, this might need adjustment based on more testers. What's still missing:

1. The creation of the Debian package itself, which should be done by the CI (dpkg-deb --build uhk-usb-service, resulting in uhk-usb-service.deb)
2. Performing the installation of this package once agent is installed, e.g. alongside the udev rules. Alternatively, the Debian package creation could be skipped, and agent could do the individual steps itself (copying the two files, starting systemd service).

[cla-sign-bot]

Thank you for your contribution!
Please sign the CLA.

[benedekkupper]

Related threads:
UltimateHackingKeyboard/firmware#1355
UltimateHackingKeyboard/firmware#1261
UltimateHackingKeyboard/firmware#1155

[rightaditya]

Just tested the script and systemd service—scrolling does work after suspend with it, but then Agent doesn't work unless I reboot (or unplug/replug) the UHK. It gets stuck on the "Searching" screen and cycles the following on stdout/stderr:

20:01:27.278 › [UhkHidDevice] Available devices unchanged
20:01:27.303 › [UhkHidDevice] Used device: {"vendorId":"0x37A8","productId":"0x1","path":"/dev/hidraw16","serialNumber":"1173789131","manufacturer":"Ultimate Gadget Laboratories","product":"UHK 60 v1","release":1,"interface":4,"usagePage":65280,"usage":1}
20:01:32.533 › [UhkHidDevice] Transfer error:  Error: Cannot write to hid device
20:01:32.534 › [UhkHidDevice] Device communication closing.
20:01:32.534 › [UhkHidDevice] Device communication closed.
20:01:32.534 › [DeviceService] Device connection state query error Error: Cannot write to hid device

[rightaditya]

RE: Debian package vs. manual files: obviously those not on a Debian-family distro won't be able to use it, so it'd be handy if the files were at least easily accessible so that we wouldn't have to manually extract them from the .deb. Using a real package does at least have the advantage that the user can uninstall it and the files will get removed. If it helps, I can make an Arch package (and optionally put it in the AUR), but in your shoes I think I'd want to avoid managing multiple package formats just for this...

If using a .deb (or equivalent for any other package manager), the systemd unit files should go in /usr/lib/systemd/system rather than /etc/systemd/system; but if using the systemd unit file directly then it should go /usr/local/lib/systemd/system. /etc/systemd is supposed to be for units created by (not just installed by) the administrator (in this case, the user), at least according to the docs (the systemd.unit manpage).¹

IMO it'd be prudent to add a prerm that runs systemctl disable uhk-usb-rebind.service to make sure the symlink gets cleaned up if the package is uninstalled.

Footnotes

1. I believe most distros follow this... I just checked and on my installations of CachyOS, Ubuntu 24.04, and Proxmox 9, the only package-manager-provided services in /etc/systemd/system are actually aliases to services that actually live in /usr/lib/systemd/system. ↩

[kareltucek]

Works with my system. Agent seems to work fine.

[benedekkupper]

I (and my LLM helper) have updated the branch to ship a manual installer script, instead of Debian package. Maybe this is simpler for the users overall. I couldn't test these changes, so please review in detail.

I don't know what is happening to the agent at @rightaditya, but restarting the agent is overall an easier approach, than plugging the keyboard in and out.

[rightaditya]

@benedekkupper IIRC I did try restarting Agent but got the same message 🤷‍♂️

[ert78gb]

Hi All,

What is the status of this PR? I mean is the OS service / systemd part done and need to finish the Agent side? Or have to work on both side?

The creation of the Debian package itself, which should be done by the CI (dpkg-deb --build uhk-usb-service, resulting in uhk-usb-service.deb)

If I read well then we will not create debian package to be compatible with non debian based images? And here my questions, which linux OS should run the scripts? What happening if someone uses other than systemd ?

Performing the installation of this package once agent is installed, e.g. alongside the udev rules. Alternatively, the Debian package creation could be skipped, and agent could do the individual steps itself (copying the two files, starting systemd service).

udev rules is 1 small file. If we modify it we notify the user about the upgrade. Should we track all of these new files or just a few? Agent has the --preserve-udev-rules that skip the udev rules check it is useful when the user manually manages the udev files. Shoudl we introduce command line argument to preserve these new files or we will use the --preserve-udev-rules or users can't ignore the update? If we will use the --preserve-udev-rules then should we rename it?

NixOs does not allow access to the udev files and I think it will block the access to systemd files too. How will we track these new files on NixOS? Currently if we could communicate with the keyboard but can't access to the udev files then we assume the user has special setup and we don't bother them with udev rule setup. How could Agent detect this new feature properly available on the OS with custom setup and we don't have to care about it?