12 lines
5.1 KiB
Markdown
12 lines
5.1 KiB
Markdown
# Blog
|
|
|
|
I have made a number of unfortunate decisions, with the ultimate consequence being that my work laptop is running Linux. While this is indeed a dire circumstance, it's far less objectionable than the alternative, which is to run [violent gagging noises] Windows 11. Due to what appears to be pure bandwagoneering induced by some sort of mass insanity, many modern laptops have touch screens built into them, a hardware feature which is not desirable except perhaps to some heretofore undiscovered variety of inscrutably stupid moron (editor's note: if you are reading this and you love using your touch screen on your desktop computer, the previous statement is definitely not targeting you. Also, there's no point in you continuing to read this. Please do not accidentally destroy your computer by drooling on it).
|
|
|
|
This wouldn't particularly be a problem on its own, except that the people who invest all of their time and energy into producing The Cheapest Operating System on the Planet™, in their infinite wisdom, seem to have forgotten to include a button that allows the user to shut off built-in hardware antifeatures. After discovering that setting my login shell to `fish` was causing the [display manager to simply die](https://github.com/sddm/sddm/issues/1768) instead of actually showing me my desktop, I was able to switch to Wayland. This was a general improvement in that it fixed the rather nasty tearing I was seeing with X11 running multiple monitors (though the feeling of victory is somewhat dulled by the fact that now the mouse cursor lags when hovering over application icons on the task bar). However, switching to Wayland meant that the quick and stupid `xinput`-based hack I was using to disable the touchscreen no longer worked. After trying a few `udev`-related configuration changes which did not work (I am willing to admit that it's likely this was due to operator error, since I was not particularly interested in actually reading the `udev` documentation), I stumbled across an alternative approach to disable a specific device with the `hid-multitouch` driver itself.
|
|
|
|
This new approach immediately passed the sniff test when running it from the terminal while logged in, but practical implementation problems immediately appeared when trying to run this automatically during computer boot. The first one is annoying: the kernel doesn't appear to deterministically label the various hardware components during boot, so you can't just drop in a static device path and get consistent results. It's not entirely clear exactly how nondeterministic the operating system's hardware initialization is, but for simplicity I have assumed that the PCI labels are deterministic, which has not yet been proven false. Anyway, instead of having a dumb single command line to disable the touchscreen, this approach required a program with logic to walk the device tree at boot to find the actual name of the device in question (please note: it's entirely possible, perhaps even likely, that there's a way to get the appropriate device name in a deterministic fashion from the operating system; however, at this point, I was not interested in trying to dig up more arcane device tree plumbing documentation).
|
|
|
|
The second problem is that the device cannot be disabled until after it has actually been enabled, which means that the command needs to be run fairly late in the boot process. Since the plan was to make disabling the touchscreen happen automatically during the boot process by using the init system (in my case, `systemd`), correct integration proved to be fiddly. At first, I thought I would integrate it as a user service, so that the script would be disabled as soon as I logged in. However, as far as I can tell, there's no way under `systemd` to run a user login service with elevated privileges without doing something stupid like removing the need to give `sudo` a password. Moving it to a system service would cause it to run too early if it were just included as an unordered service as part of `graphical.target` (I will admit to being willfully ignorant of the semantics of the different `systemd` runlevels, but I find it somewhat surprising that apparently HID initialization (at least for pointing devices) happens in `graphical.target` rather than before it). Anyway, to make a long story short, after several reboots while fiddling around with the unit file, I determined that specifying the service should run *after* `graphical.target` (while still being a dependency of `graphical.target`) actually worked.
|
|
|
|
As for the implementation choice, writing a shell script was right out. I hate bash with a passion (though it's obviously fine for writing dumb scripts like `echo nonsense >> file`), but using another scripting language was also unappealing due to the potential lack of stability in the interpreter or installation. After thinking about this for all of 30 seconds, I realized I could just make a standalone binary with no dependencies that would work. So I wrote it in Zig (targeting Zig 0.11). This program is obviously tuned to my system's hardware, though I expect it to be trivial to adapt to a different system.
|