surface-dial-linux seems to be working just fine, and has been running
without fault for almost 2 weeks now with no issues.
I might revisit the project at some point over the holidays to add some
new features (notably, a more robust config file), but I very well might
not. Why know ¯\_(ツ)_/¯
This change has substantially bumped up the daemon's overall robustness,
as the code now ensures that the controller will only start once the
/dev/input/eventXX file is set up, which was causing all sorts of issues
in the past.
Additionally, this change enables the daemon to run as a proper
background task that _doesn't_ constantly die / need to be restarted,
which removes the need for any janky udev "on add" rules, and instead, a
simple systemd user service will suffice.
- fakeinput is now just a series of free functions that access the global
static, which makes more sense than having some arbitrary
zero-sized-struct with associated methods on it.
- instead of having the active notification run in its own thread, it
now runs on the main thread, and the controller runs in a separate
thread. This results in midly nicer code, at least IMO.
Also, I've had to disable optimizations on the evdev_rs crate, as it
seems to be segfaulting on release builds. Very spooky, but it's not
something I'm super interested in debugging right now, so I'll just work
around it. It's not like I need the _blazing fast performance_ from a
Rust wrapper around a C library anyways...
oooooh boy, this is looking pretty slick. I'm kind-of impressed I was
able to throw this together in ~2 days of post-work hacking (though I
guess they were some pretty late-nights...)
There's really only one feature left that I _need_ to implement, which
is the on-disk persistence for selected mode. That shouldn't be too
tricky though...
https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/radial-controller-protocol-implementation
With a little bit of trial and error (and a crash-course in how the heck
HID even works), I figured out how to get the dial to provide haptic
feedback!
Along the way, I also learned that you can take advantage of the
(incorrectly named) Resolution Multiplier field to customize how many
"steps" the dial should have, offloading the work to the device itself!
Very cool!!
