[Feature Request] Nix Module: declare devices & fix naming

[74k1]

Superb work for all contributors to this Project in general! I am amazed how people can just do things. 😄

With the addition of 489bf1e I think it'd be nice if we could declare devices directly in nix to automatically bind it?
However I'm also not sure if they're already supposed to bind automatically.

Secondly, I find the naming of the parameters in Nix & the parameters in the app a bit confusing.
While the first few are pretty near 1:1 translations into nix, I marked the odd ones out with ❓.

YeetMouse GUI	NixOS option	translation
Mode Selection	AccelerationMode	✔️
Sensitivity	Sensitivity	✔️
Output Cap	OutputCap	✔️
Input Cap	InputCap	✔️
Offset	Offset	✔️
Pre-Scale	PreScale	✔️
Rotation Angle	RotationAngle	✔️
Acceleration	Acceleration	✔️
Start	Midpoint	❓
Smoothness	n/a	❓
Use Smoothing	UseSmoothing	✔️
n/a	ScrollsPerTick	❓
Use anisotropy	n/a	❓
Sensitivity X (if above enabled)	n/a	❓
Sensitivity Y (if above enabled)	n/a	❓

[kitten]

Devices would currently bind automatically, yes. The udev script basically matches and applies to all mice. Similarly, #5 would actually always apply to all mice (although we could have a way to filter them down there too)

I'll have to defer to @AndyFilter on the value mismatch. I based the names off of their config.h and PARAM names, but they don't actually match up with the UI, since e.g. Midpoint (as far as I understand) are not directly displayed in the UI, if I'm not mistaken (?)

I think ScrollsPerTick in particular is not being applied right now.
cc @AndyFilter: Should all references to ScrollsPerTick and wheel eventually be deleted? I don't think this feature makes much sense anyway imho, and the code for that parameter being applied is obviously commented out.

On a side-note, RotationAngle is an interesting one. For me at least, it seems like it either isn't being parsed correctly, or the UI displays the current value incorrectly (although it does apply it correctly, when changed)

[AndyFilter]

The uniform integration of features / names sounds great, however I can't help with the NixOS implementation. What I can say is that the device binding scripts are pretty simple, for binding it can look like so:

#!/bin/bash
DEVICE=$1
echo "Rebinding $DEVICE"
echo -n "$DEVICE" > /sys/bus/usb/drivers/usbhid/unbind
echo -n "$DEVICE" > /sys/bus/usb/drivers/leetmouse/bind

Same for unbinding just with the driver's names swapped.
(I can add these two files to the scripts/ on the next push)

As for the names, I have to admit they are not very good, so I'd would rather look at it both ways, as in "What name is better? And let's just stick to it" rather than "Let's change the NixOS names to what's in YeetMouse GUI". For example, I think Midpoint is more reasonable than Start, and I think it's what RawAccel uses too.

When it comes to Scrolls Per Tick I didn't remove it from the driver for "backwards compatibility"... I guess... (?)

YeetMouse/driver/accel.c

Lines 379 to 380 in ba430f6

	// I don't do wheel, sorry
	//delta_whl *= g_ScrollsPerTick/3.0f;

I'll remove it in the next push, it does nothing currently. I thought maybe someone would ask me to "add a mouse wheel acceleration", but it didn't happen, and I don't think it's going to happen. It's not that useful, and you probably can change that in the system settings either way (or you can't because of the driver, I don't know).

About the Rotation Angle. This feature also seems strange to me, but someone wanted it, so it's there. I've coded it up, tested it for a little while, to make sure it's working as it should, and never touched it again (until now, to make sure it's still working). The units might be a bit complicated, but it's not that bad; GUI uses degrees, to be user friendly, while the driver uses radians, to be math friendly. The conversion happens right before it gets written to a file:

YeetMouse/gui/DriverHelper.cpp

Line 272 in ba430f6

res &= SetParameterTy("RotationAngle", rotation * DEG2RAD);

And is explained a bit in the declaration:

YeetMouse/gui/DriverHelper.h

Line 177 in ba430f6

float rotation = 0; // Stored in degrees, converted to radians when writing out

(As you can see, there is only one conversion, meaning something is wrong...)
But you're right it's parsing the driver's radians as degrees and simply doesn't work, thanks for pointing that out. I probably didn't catch it because I was not able to close the program and then open it, while my mouse was going the opposite direction to where I wanted it to go. 😄

``
I think we could make a pool of some kind, to let the Users decide what names they think fit the best for specific purpose, but I don't really know how to do that. Maybe a Google Docs to collect ideas and then some online pool to collect the votes?

[kitten]

I've opted to file a PR (against driver/experimental) that basically discards the old structure of the Nix module options. Instead, it now opts to represent the Yeetmouse GUI options 1:1. This is simply more intuitive and maintainable. If we want to change any terms, we'd chagne them in both places.

The new implementation also separates all modes (into mutually exclusive submodles). This means that we can set more sensible defaults per mode and adjust the permitted ranges of float values per mode. We can always readd a more "raw" option, but for now, it seems more intuitive for me that we should match up the GUI with the Nix options.

This PR also adds anisotropy (which wasn't ported to Nix yet prior)

And re. Start/Smoothness/Midpoint, it accounts for these naming differences. Start is just an alias for Midpoint and Smoothness is for Exponent, but the parameters are reused under different names for their respective curves; just to clarify.