You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Input device hotplugging and reading all keyboards/pointers on platform DRM
#6344
I'm using raylib with PLATFORM_DRM on an embedded device with a touchscreen UI, and I'm experiencing a couple of issues to due the lack of input device hotplugging. I'm aware that the topic has been discussed before in #4631 and that the request has been denied for reasons of code simplicity. However, even with a single input device (in the sense of a physical device) connected at startup, the current mechanism can fail.
Current behaviour
/dev/input is scanned once in InitEvdevInput(). Devices connected later are never read. A device whose read() fails with ENODEV is never closed or reopened.
Only one keyboard is used: the first device in readdir() order that passes the keyboard test.
Only one pointing device is used: a touchscreen replaces a mouse, and among equals the last one found wins.
Real-world cases where this breaks
I've seen cases where der kernel loses the touch device through a USB reset due to electromagnatic interference. On X11, the device appears again after re-enumeration, but in DRM mode, raylib keeps the dead file descriptor and the touchscreen stays dead until the application is restarted.
Some keyboards register themselves as multiple devices. E.g. a Logitech G610 provides two event devices that both classify as keyboards. One is the actual keyboard, the other is for the multimedia keys. Depending on the (random) order in which they are enumerated, raylib picks the multimedia device and thus has no keyboard input (or just via stdin, this is how I stumbled on #6342).
A keyboard with a trackpad competes with the touch input device. #5447 already fixed the case where the touchscreen also emulates a mouse. A similar issue was discussed in #4930 and fixed with a udev rule at that time.
Arrays of file descriptors for keyboards and mice/touchscreens. Non-blocking polling as before.
If a physical device has both a mouse and a touchscreen, the touchscreen is preferred (no double events).
Hotplugging:
inotify on /dev/input for IN_CREATE and IN_ATTRIB (udev makes the node readable only after creating it).
Also watch /dev, because /dev/input only exists if an input device is connected.
Configuration of the devices as before.
Removal: When a read() fails with ENODEV the fd is closed and removed, and its keys are released.
Everything is localized in rcore_drm.c, no new API is needed. No methods to tell devices apart. The idea is to make DRM input handling work as smoothly as on the desktop.
Note that this is still half-baked, not covering various corner cases. If you're interested, I'll put in more effort to address those.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I'm using raylib with
PLATFORM_DRMon an embedded device with a touchscreen UI, and I'm experiencing a couple of issues to due the lack of input device hotplugging. I'm aware that the topic has been discussed before in #4631 and that the request has been denied for reasons of code simplicity. However, even with a single input device (in the sense of a physical device) connected at startup, the current mechanism can fail.Current behaviour
/dev/inputis scanned once inInitEvdevInput(). Devices connected later are never read. A device whoseread()fails withENODEVis never closed or reopened.readdir()order that passes the keyboard test.Real-world cases where this breaks
Proposed changes
A working, but rudimentary, implementation based on raylib 6.0 is here:
https://github.com/maiphi/raylib/commits/6.0-drm-input-hotplug
/dev/inputforIN_CREATEandIN_ATTRIB(udev makes the node readable only after creating it)./dev, because/dev/inputonly exists if an input device is connected.read()fails withENODEVthe fd is closed and removed, and its keys are released.Everything is localized in
rcore_drm.c, no new API is needed. No methods to tell devices apart. The idea is to make DRM input handling work as smoothly as on the desktop.Note that this is still half-baked, not covering various corner cases. If you're interested, I'll put in more effort to address those.
All reactions