search

end-4 / dots-hyprland

Modern, feature-rich and accessible desktop configuration.
https://end-4.github.io/dots-hyprland-wiki/en/
GNU General Public License v3.0
3.34k stars 218 forks source link

Missing permissions for uinput device #382

Closed Cu3PO42 closed 3 months ago

Cu3PO42 commented 3 months ago

I have read the wiki and in particular the usage and troubleshooting page. I am running a recent NixOS Unstable.

The issue

When starting AGS with your config installed, the following error is logged:


_init/GLib.MainLoop.prototype.runAsync/</<@resource:///org/gnome/gjs/modules/core/overrides/GLib.js:266:34

failed to open uinput device: Permission denied

My user is in the input and video group, but the above error still occurs. Clearly there is some permission problem here. Unfortunately, I was not able to pinpoint where in the configuration the offending promise is created. Since there is no callstack at all, I assume it is at the top-level in some file, but I don't know where exactly. I'm hoping you might point me in that direction.

Once I know what exactly is failing, I'm happy to debug the permission problem myself and potentially contribute a fix or more detailed error message.

end-4 commented 3 months ago

beightness control stuff probably are you sure it isn't a nix moment?

end-4 commented 3 months ago

my groups, if they matter:

$ groups
sys network plugdev rfkill users video storage lp input audio wheel end
Cu3PO42 commented 3 months ago

Thank you for the reply! I'm relatively certain this isn't related to Nix, but more the general configuration of my system. This is after I have patched any file paths that aren't writable.

I don't believe brightnessctl has given me trouble in the past, but I'll make sure the error message isn't coming from it. Since uinput is specifically mentioned, I'm more inclined to believe it's related to the on-screen keyboard or any special gesture handling or something along those lines. I just didn't find any OSK code that I thought wouldn't have a callstack. Maybe it's coming from ydotool... I'll check that tonight.

Cu3PO42 commented 3 months ago

As far as I can tell right now, this is most likely a udev issue and chances are high it's related to ydotool. I'll confirm this later and hopefully add a check and better error message.

Cu3PO42 commented 3 months ago

Sorry this took a while. I unfortunately got sick. The error message is indeed coming from ydotoold, because the udev rule that is supposed to give my user access to /dev/uinput wasn't/isn't working. However, rather than give all applications running as my user permissions to write to /dev/uinput, I'd rather run ydotool as a service. It ships with a systemd service that should "just work". Is this something you would be open to?

end-4 commented 3 months ago

arch package doesn't include the service?

end-4 commented 3 months ago

I guess this means we'll have to add yet another manual install func in the install script that gets the service file from ydotool repo

Cu3PO42 commented 3 months ago

arch package doesn't include the service?

Hmm. I just checked this and it seems the Arch package includes a user service only. That is, it can be run by systemd, but in the context of the user, which still means giving them /dev/uinput permissions. This doesn't really influence my use case one way or the other.

That said, it might be the "cleaner" solution to run it as the user service anyway. Maybe there could just be a config option to start ydotoold automatically (as it currently is) or to not do that and assume it will be spawned by a service. That way the config will continue working as is for everyone and people who want to run ydotoold differently can.

end-4 commented 3 months ago

ydotool should now run as a user service

Cu3PO42 commented 3 months ago

Lovely! Thanks so much! This makes it significantly easier to fix my use case on my system.