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