Enhancement: rootless YeetmouseGui

[systemofapwne]

I think it would make sense to enable rootless mode for YeetMouseGui.
I could imagine several ways:

1. Set permissions to the module parameters to 666.
   Pros: No modification of YeetMouseGui required
   Cons: Too permissive. Module parameters should not be writable by all users

2. Set permissions to the modules parameters 664 and change owner to e.g. root:yeetmouse. Add user to yeetmouse group
   Pros: No modification of YeetMouseGui required and not too permissive
   Cons: User needs to logout and log back in. From then on, he can change the mouse settings

3. Use an intermediate control deamon. Similar permissions like in 2) could be used. That deamon then runs as yeetmouse:yeetmouse. YeetMouseGui then speaks to the deamon directly
   Pros: The deamon can do so much more like loading persistent config files (no need to recompile config.h into the module to have persistent mouse settings)
   Cons: Needs slight rewrite of YeetMouseGui. Would still be permissive (everyone could just talk to the deamon, if no ACLs are added).

I like option 3 because it offers a way to set parameters in a config file and reload them on boot from e.g. /etc/yeetmouse.conf
However, the same would be possible with option 2) & 1) but here, each user can load his own preferred settings when he logs in e.g. with a simple script.
Also option 1) and 2) are least invasive (just change permissions e.g. via udev rules and thats it).

What do you think?

[AndyFilter]

I like the idea, as running GUI (OpenGL + glfw and stuff) as sudo with some distros seem to be quite (very) troublesome.

About the different approaches:

1. I don't think that being too permissive is really that problematic. It's not a critical system driver or anything, the worst someone could do is probably set the sensitivity to 0.0001 and lock the mouse in place (or perhaps cause a kernel panic...). But it's not a security threat.

2. Logging out and in is quite annoying, not gonna lie. But I think the users would be able to deal with that. I think maccel is using this method, and it works quite well there. It's probably a good compromise a decent approach overall.

3. I'm always sceptical about things like daemons, as they run in the background, and God knows what they might be doing. Obviously - I know exactly what it would be doing this time, but I still think some users might not want to have a service running in the background at all times (even tho it's not really "running" afaik). But if I misunderstood how the daemon would function, please correct me. Obviously one approach would be to just install the daemon, and never tell the user about it... As sometimes it is better not to know, haha.
   When it comes to stuff like loading the parameter presets on the fly I think the approach discussed here is quite interesting: Reinstall driver button and save file directory change #63 (comment) (I really need to get back to that PR at some point). I tried it, and it works between reboots (on Ubuntu at least). The daemon is useful for things like quick changes, eg. command like dyeetmouse sensitivity 0.5 which would set the sensitivity to 0.5 on the fly (if that's possible with daemons, but I assume it is).
   Also - making changes to the GUI code is not really an issue, as I assume it shouldn't be too difficult especially in the era of AI.

[systemofapwne]

1. I don't think that being too permissive is really that problematic. It's not a critical system driver or anything, the worst someone could do is probably set the sensitivity to 0.0001 and lock the mouse in place (or perhaps cause a kernel panic...). But it's not a security threat.
2. Logging out and in is quite annoying, not gonna lie. But I think the users would be able to deal with that. I think maccel is using this method, and it works quite well there. It's probably a good compromise a decent approach overall.
3. I'm always sceptical about things like daemons, as they run in the background, and God knows what they might be doing. Obviously - I know exactly what it would be doing this time, but I still think some users might not want to have a service running in the background at all times (even tho it's not really "running" afaik). But if I misunderstood how the daemon would function, please correct me. Obviously one approach would be to just install the daemon, and never tell the user about it... As sometimes it is better not to know, haha.

After thinking about this for a few more moments, option 2 might be the best solution here. It does not open the kernel paramters too much. Setting the permissions to 664 could be achieved directly from within the driver - Setting the group might require something else. Maybe a udev rule can do this.

When it comes to stuff like loading the parameter presets on the fly I think the approach discussed here is quite interesting: Reinstall driver button and save file directory change #63 (comment) (I really need to get back to that PR at some point). I tried it, and it works between reboots (on Ubuntu at least).

Changing the default acceleration paramters via a triggered recompilation is a bit ugly in my opinion but will of course work.
When I started added module parameters for LEETMOUSE, my intention at some point was to deprecate the config.h method. Maybe not remove the config.h but having a default "do nothing" setting there and then motivate the user to have some kind of config file / script in place, that applies the curve he likes. E.g. via a oneshot systemd user service or similar on login.

The daemon is useful for things like quick changes, eg. command like dyeetmouse sensitivity 0.5 which would set the sensitivity to 0.5 on the fly (if that's possible with daemons, but I assume it is).

Yes, but in the end, the deamon I previously suggested is then nothing else but an extra layer on top of of an echo 0.5 > /sys/module/yeetmouse/parameters/Sensitivity. Thats why I shifted back to the option 2. Its easy, its elegant and integrates with least invasive changes.