Retroarch: linux: udev input driver doesn't have permissions to function

[i30817]

Description

no movement even after deleting the directory at ~/.config/retroarch and letting it be recreated
retroarch started with -v says this interesting thing:

RetroArch [WARN] :: [udev]: Couldn't open any keyboard, mouse or touchpad. Are permissions set correctly for /dev/input/event*?

and if i do ls:
ls -l /dev/input/event*
crw-rw---- 1 root input 13, 64 Jun 6 07:47 /dev/input/event0
crw-rw---- 1 root input 13, 65 Jun 6 07:47 /dev/input/event1
crw-rw---- 1 root input 13, 74 Jun 6 07:48 /dev/input/event10
crw-rw---- 1 root input 13, 75 Jun 6 07:48 /dev/input/event11
crw-rw---- 1 root input 13, 66 Jun 6 07:47 /dev/input/event2
crw-rw---- 1 root input 13, 67 Jun 6 07:47 /dev/input/event3
crw-rw---- 1 root input 13, 68 Jun 6 07:47 /dev/input/event4
crw-rw---- 1 root input 13, 69 Jun 6 07:47 /dev/input/event5
crw-rw---- 1 root input 13, 70 Jun 6 07:48 /dev/input/event6
crw-rw---- 1 root input 13, 71 Jun 6 07:48 /dev/input/event7
crw-rw---- 1 root input 13, 72 Jun 6 07:48 /dev/input/event8
crw-rw---- 1 root input 13, 73 Jun 6 07:48 /dev/input/event9

Version/Commit

RetroArch version 1.6.0 (Git eee1ff7)

Environment information

Linux AIVAS 4.4.0-78-generic #99-Ubuntu SMP Thu Apr 27 15:29:09 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

[ghost]

should be similar to this https://github.com/libretro/RetroArch/issues/5016

[twinaphex]

@casdevel Seems we are getting more reports like this.

[i30817]

My keyboard and touchpad are from a 2008 portable, so i don't know if ps/2 has anything to do with it. I'll try to link a usb keyboard and see if something happens.

Nope, still doesn't work and has the same msg. However, alt-f4 to exit works (all the time) fortunately.

[i30817]

Worked around it by dropping to the config file and replacing the two instances of 'udev' for 'sdl' (aided by the names on the open pull request here).

[ghost]

Question from log is answer.

@i30817 Visit link that @retro-wertz suggested or go here and follow instructions or change input driver to X11 (I think it's named "x").

@twinaphex There will probably be more issues like this if we don't change default input driver on Linux.
EDIT: Short warning in menu after udev will also be useful.

[RobLoach]

Confirmed on Ubuntu 16.04 89fe5625.

1. Clear out configuration rm -rf ~/.config/retroarch
2. Run RetroArch ./retroarch
3. Unable to use the menu, since keyboard and mouse have no affect.

After RetroArch saves the config, it reports it's using the udev input driver.

EDIT: Changing to input_driver = "x" works.

[twinaphex]

@RobLoach Start doing a bisect.

[twinaphex]

@casdevel - So all these issue are because we were previously using the x11 input driver by default, and now it tries to default to udev instead?

[twinaphex]

@casdevel How about if we just change 'x' to be the default input driver, even before udev? That way, if somebody manually chooses 'udev' as the input driver, it was at least their choice and they can still continue on using the x input driver by default as normal.

[twinaphex]

Pushed this -

https://github.com/libretro/RetroArch/commit/96bfb35e0b5dc16da586ffdb674ae042bb0bae3b

Set input_driver = "x" in your retroarch.cfg and tell me if everything is back to normal then.

The way it will work now is that x11 will be used before udev by default. You can still change it to udev inside Settings -> Driver.

[ghost]

@twinaphex I doubt that anyone was actually using udev before #5010.

[bparker06]

@casdevel What about all the other context drivers that aren't X? Like DRM, Wayland etc.

[RobLoach]

Went through to find the afflicting commit.

1. Checked out https://github.com/libretro/RetroArch/commit/647dc488ffcd91d1f9a7da1c05518e9000fb1a32
2. Compiled
3. Ran and could move mouse/keyboard around
4. Checked out https://github.com/libretro/RetroArch/commit/a8f1831a62c82f2cb72d7e8b112d1ac7c7cf4e0f
5. Recompiled
6. Ran and could not move mouse/keyboard

So it seems like something in Add multiple mice support affects this.

[twinaphex]

I pushed some commits -

What it does now is -

1) It will default to the x input driver on first startup instead of udev. This is for builds that have been compiled with both udev and X11 support.
2) IF we select the DRM/KMS context driver, because this is an X11-less context, if the x11 input driver is selected, we default to udev instead. If that is not available, we default to linuxraw instead.

Wayland context driver still uses its own Wayland input driver, so that continues to work fine.

I agree with @casdevel that nobody on Linux was properly using udev before, and that now we have an opportunity to properly flesh out the udev input driver instead.

@casdevel Maybe we can add multiple mice support, etc. to the x11 input driver too?

[ghost]

@bparker06 There may be few that still "don't allow" udev input driver, I will have to check sources again to be sure about that.

@RobLoach You are right, this is already discussed here.

[ghost]

@bparker06 DRM don't "force" input driver, Wayland prefers his own.

[ghost]

@twinaphex I don't think that multiple mice support is possible on any input driver that uses OS windowing system API. For Windows I'm sure, for X11 I will have to check.

[sjnewbury]

@casdevel https://en.wikipedia.org/wiki/Multi-Pointer_X It's a feature of the XInput2 API.

[ghost]

@sjnewbury I'll check it out.

[sjnewbury]

@casdevel There seems to be something fundamental missing from all this:

The udev driver should work fine under X or Wayland or bare DRM/KMS (under session management) for local input devices owned by the seat running the current session which haven't been claimed by the windowing system, and should still work even when it has been, although then there are arbitration issues.

RetroArch uses udev_device_new_from_syspath() which should return a udev_device object with access control to the device granted through logind/ConsoleKit. As I understand it, access to an underlying device with libudev can either go through the /dev node if user/group access is permitted, or though a fd created on the fly with appropriate ACLs if granted by the udev authorization mechanism.

Direct udev driver access to input devices such as joypads is VERY desirable, even when running under X due to the limitations of X input drivers such as force feedback/rumble support. Hopefully, under Wayland there will soon be a well designed protocol suitable for gaming devices.

[ghost]

@sjnewbury I'm not sure what you pointing out here. This was on setting up user permissions and that is solved.

[sjnewbury]

@casdevel Point is, user permissions don't need to be set because libudev is given access to devices attached to the local seat on which the session is running. This means remote logins do not get access to the resources, but any authorized local user can if the device is associated with the "seat" they are using; by default "seat0". Multiple seats can be configured and used simultaneously with different devices attached GPUs/soundcards input devices, or whole USB hubs etc. This could, for example be used to create a "seat" with just a GPU and joypad and have retroarch running standalone whilst allowing normal user logins on seat0.

[ghost]

If you think that user permissions don't need to be changed, then you should post a solution.

[ghost]

@twinaphex Regarding X11 input driver and multiple mice support, it should be possible.

I didn't tested anything, just done some reading and Xinput2 extension should make this possible. This functionality may be accessed with libxi library.

[RobLoach]

Just tested the lastest master andudev` is still not working on Ubuntu 16.04.

1. rm ~/.config/retroarch/retroarch.cfg
2. Start RetroArch
3. Quit
4. Update ~/.config/retroarch/retroarch.cfg with input_driver = "udev"
5. Run RetroArch
6. Unable to move

Temporary work-around is to use input_driver = "x"

[ghost]

I can't reproduce this issue (same steps, same OS).

Did you check log for udev error(s)?

[RobLoach]

RetroArch [WARN] :: [udev]: Couldn't open any keyboard, mouse or touchpad. Are permissions set correctly for /dev/input/event*?

[ghost]

We already discussed how to solve permissions related issues.

[sjnewbury]

On Tue, 2017-06-20 at 15:51 -0700, Zoran Vuckovic wrote:

We already discussed how to solve permissions related issues.
I don't think it this is a permissions related issue. I gather the
current code doesn't now work with udev input devices under X, whereas
previously it did where permissions weren't a problem. [Because of
either logind or use of and "input" group policy.]

Whether it's appropriate to use the udev (driver) input devices under X
is another matter. I can't see why it would be a problem though if the
devices in question have been explicitly excluded from use by the Xorg
driver.

Maybe I'm completely off here.

[ghost]

@sjnewbury Why are permissions in play now and wasn't before should be clear if you start reading from top of this page (follow links too).

Whether changing permission for /dev/input/event is necessary you can find by compiling some simple program that reads/writes to/from one of these devices.

[sjnewbury]

@casdevel, except as I mentioned previously when you use libudev since it hands out a file descriptor if you have access to the /dev node OR authorisation through logind.

The simple program would have to utilise libudev. I did exactly this btw, and it worked fine here without explicit /dev node permissions.

[ghost]

@sjnewbury Like I said 8 days ago:

If you think that user permissions don't need to be changed, then you should post a solution.

[sjnewbury]

On Wed, 2017-06-21 at 11:20 -0700, Zoran Vuckovic wrote:

@sjnewbury Why are permissions in play now and wasn't before should
be clear if you start reading from top of this page (follow links
too).
Whether changing permission for /dev/input/event is necessary you can
find by compiling some simple program that reads/writes to/from one
of these devices.

But libudev isn't some simple program that accesses device nodes.
Device nodes themselves are managed by udev. libudev "talks" directly
to the udev daemon and negotiates access through other mechanisms like
logind and ConsoleKit.

I did write a simple program using libudev to test access to devices
which otherwise were not permitted through the device nodes, but were
allocated to "seat0" through loginctl, and it worked.

I don't think the problems people are seeing are due to permissions
but something that changed with respect to the udev driver when running
under X11. I could be completely off-base, but I too have to manually
set the driver to X to get any input working despite my libudev test
program working, which is why I commented.

[parkerlreed]

Arch, up to date, fresh git compile with a clean config folder and udev is working fine. My user is in the "input" group if that makes a difference.

Running in XFCE (so in X11)

[RobLoach]

Noting that this is still an issue with the udev input driver on Ubuntu 18.04.

[WARN] [udev]: Couldn't open any keyboard, mouse or touchpad. Are permissions set correctly for /dev/input/event*?

We've switched Linux's default input driver to be x, but it would be good to fix it up.

[orbea]

I can't reproduce this, but for those who can I would suggest looking into the system environment. Maybe it could be something with systemd permissions?

[i30817]

I changed to udev again and after adding my user to input things are sort of working.

Except in kms (where libinput is not loaded because there is no compositor loaded so all of the touchpad quirks are not handled so things like 'no right click' happen). In fact i changed back from sdl because i was trying to run retroarch in KMS which i found basically impossible without root (because of resolution changes requiring root and emulator cores changing resolution at will) except for pushing me to solve this problem.

Although, i don't think 'add your user to the input group' is a good solution to non-technical users. Clearly graphical environments are following a different indirection strategy now.

[i30817]

I've seen repeated suggestions that this permission issue can be avoided by using libudev instead of accessing the linux device files directly (much like supposedly the device quirks can be used by using libinput instead of having ghost/missing/distorted inputs in certain defective hardware).

I have no idea if that's true (especially on KMS that might 'avoid' the permission delegation that's obviously happening). But X11 is on life support and i really doubt that quirks drivers for new hardware will get written outside of libinput.

[orbea]

Although, i don't think 'add your user to the input group' is a good solution to non-technical users.

Its a single command.

usermod -a -G input user_name

Then log out and log back in, type groups to ensure it worked.

While I agree it could be easier, I think there is nothing that can be done about it inside RetroArch other than documentation.

I've seen repeated suggestions that this permission issue can be avoided by using libudev

I think we are already doing that?

$ ldd /usr/games/retroarch | grep udev
    libudev.so.1 => /lib64/libudev.so.1 (0x00007fa422a40000)

KMS also works fine with udev here.

Would it be possible to try a live environment for a distro without systemd to see if its any better with just eudev?

[i30817]

Eh, i should have mentioned 'libinput' instead of 'libudev'. AFAICT from internet information, the quirks are there.

But sure, testing on a live cd with or without systemd is a good idea - that i can't do right now - I have no idea how the permission design is supposed to work on distros now and a mangled system from dozens of little config hacks isn't the best testbed. I want to suspect that desktop compositors don't add the user to the input group automagically now, like i assume they did before, and do something with systemd seats that authorizes only certain libraries or types of access.

Basically you can close this issue like the other one with 'has a workaround' but i suspect some other shmuck will open a similar one sooner or later. It's simply not user friendly.

[orbea]

There still seems to be an unknown permissions problem that is worth investigating.

It doesn't affect me here so I am not in a good position to debug it however.

[bparker06]

@RobLoach Why don't you want to add yourself to the input group? This is completely normal and everyone else does it already, there is really no alternative besides making up a udev rule to change the group to something with a bit less permissions over other input devices, i.e. just for the pad(s) in question or something... but I think that's getting a bit silly.

[grant2258]

This is the way linux works for any lib to work the user would need to be in this group when running the lib. Im pretty lost at where all this is coming from. The mouse support was just broke i fixed this a while back for udev. Linux works with perimissions unless im missing something here

[grant2258]

also see https://github.com/libretro/RetroArch/issues/7748

[grant2258]

@bparker06 to you confused face udev mouse has been broken a long time it started working again here at this commit https://github.com/libretro/RetroArch/pull/7730 well the commit after that the review changes requested broke it again was fixed the commit after that ......

[Sunderland93]

Same for Debian 9 with RetroArch installed via Flatpak:

Couldn't open any keyboard, mouse or touchpad. Are permissions set correctly for /dev/input/event*?

even when input driver is set to X

[i30817]

Yep, this is back again, after a stable flatpak update. Now both using udev input driver or adding to the group (my user was already added) works to get input (strangely enough ALT+F4 and ALT+TAB work fine, though i suppose that is the window manager).

Also retroarch is starting a X session ([INFO] [Video]: Found display server: x11) when i'm in wayland.

The linuxraw, x or sdl2 input drivers continue to work, though i'm myself wanting to try retroarch without the x compatibility layer in wayland directly. edit: speaking of that I will just compile a barebones RA without those options and see what happens.

edit: ok the source build gave the probable reason stuff is fucked in wayland: ubuntu is lagging behind the required version for RA to be built with wayland support. Specifically "wayland-protocols" is too old.

This is super weird because 'wayland-protocols' is more than up to the required version if you check it on the distros in launchpad (i'm on 18.04 or 18.10). I downloaded the deb and installed manually and now i'm building. I don't know if this fail is generalized to the build bots or not, but i'd assume so, considering the stable flatpak i just downloaded has problems getting a non-x11 gl context.

[i30817]

Yupppp. After installing "wayland-protocols" manually, the build RA is using a wayland context... and much faster to boot... and can use the udev input driver...

The flatpak "stable" update is just as slow and has the same udev problem though. Fix the buildbots!

[orbea]

You need at least wayland-protocols-1.15.

[i30817]

Opened a issue https://github.com/flathub/org.libretro.RetroArch/issues/101

[realnc]

I'm not using wayland, just good old X11, butI have the same issue. udev doesn't work, neither for keyboard nor gamepad. It just prints the usual "check permissions" warning. My user is in the input group, which is the group the /dev/input/ files belong to.

The RetroArch documentation says that udev is the most full-featured input driver for gamepads, which is why I want to use it.

I installed RetroArch through flatpak (from flathub) on Gentoo Linux. Latest version:

org.libretro.RetroArch             x86_64       stable      flathub

[realnc]

Solved for me by running the flatpak RA binary outside of flatpak. See: https://github.com/libretro/RetroArch/issues/4664#issuecomment-510340394