evdev open is delayed

[stsp]

It seems, evdev is being opened not when SdlInitSubsystem() is called, but much later, eg when the window is created. Its a bit difficult to obtain a stack trace under kmsdrm, so I am just guessing.

The actual problem is that the access restrictions are enforced by an app after the init stage (eg landlock), and then sdl fails to open evdev.

Would it be possible to open evdev in the init function?

[slouken]

Can you add logging to the init? It should be initialized at startup, SDL_EVDEV_Init() is called within the video initialization routine.

[stsp]

Can it be that udev is trying to open things in a background until succeeds? This may also explain the missing error msg.

[stsp]

Quick look into SDL_udev.c suggests sdl fully relies on the hotplug. However, IMHO it should quit if some essential devs (like kbd) are missing at startup.

[stsp]

Or probably UDEV doesn't distinguish between no device and -EPERM? In which case its not an sdl fault?

[stsp]

From a quick look to udev code, it seems like errors are not propagated to udev monitor. So I suppose sdl can neither "undelay" the opening, nor detect the permission problem. :(

[stsp]

Ok, it seems the problem is much depper. I noticed that logind doesn't add ACLs to /dev/input/*, even though it is configured to, having DeviceAllow=char-input rw in /lib/systemd/system/systemd-logind.service

Google pointed to this thread: https://bbs.archlinux.org/viewtopic.php?pid=2015685#p2015685 Which points here: https://github.com/KillingSpark/HowLogindWorks This doc has a very detailed description of how to access the input devices, and it seems the mechanism that should now be used, is via the special logind API TakeDevice(). They suggest to use libinput, which allows the user (in this case sdl) to provide the custom open() call-back, that needs to get an fd from logind.

So I'd say sdl CAN actually fix this problem, but its not easy. :) It needs to adapt to the recent changes that deprecate the direct use of input nodes. And start using the libinput+logind APIs instead.

[stsp]

Please note that the current situation is actually quite bad:

• user needs to add himself to group input or he won't get keyboard
• when he doesn't, he also doesn't see any error, or any hint about what's going on