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...
I plan to refactor the code to have a single "fatal_error" channel that
all threads get a handle to, and `Box<dyn Error>` can't be sent between
threads safely.
high-resolution mouse wheels aren't supported in userland yet, so why
don't we fake a high resolution touchpad instead 😄
it's somewhat working, though it seems to crash on startup when
installed (among other weird bugs).
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!!
currently pinned to upstream master, which is ~0.4.0, modulo some minor
internal tweaks + my PR to implement Send on `Device` and
`UInputDevice`
https://github.com/ndesh26/evdev-rs/pull/55
It looks like there are some larger breaking changes coming down the
pipeline as well? Change is always good, so I'll update whenever 0.5.0
is released as well :)
