Yes, you read it right, im still using ps/2 keyboard, and its not working if using udev driver which is the default used by retroarch.
if you run ra with "sudo", keyboard inputs works. not sure if this is expected but even if ra window is inactive, it captures all mouse movements/clicks and keyboard inputs.
it should work... without the need to run retroarch in "sudo" mode
not accepting inputs, even ESC to exit RA
partial log:
RetroArch [INFO] :: [udev] Adding device /dev/input/event4 as type ID_INPUT_KEYBOARD.
RetroArch [INFO] :: [udev] Adding device /dev/input/js0 as type ID_INPUT_KEYBOARD.
RetroArch [INFO] :: [udev] Adding device /dev/input/event2 as type ID_INPUT_KEYBOARD.
RetroArch [ERROR] :: [udev] Failed to open device: /dev/input/event2 (Permission denied).
RetroArch [INFO] :: [udev] Adding device /dev/input/event5 as type ID_INPUT_MOUSE.
RetroArch [ERROR] :: [udev] Failed to open device: /dev/input/event5 (Permission denied).
RetroArch [INFO] :: [udev] Adding device /dev/input/mouse0 as type ID_INPUT_MOUSE.
RetroArch [ERROR] :: [udev] Failed to open device: /dev/input/mouse0 (Permission denied).
RetroArch [INFO] :: [udev]: Plugged pad: Microsoft X-Box 360 pad (1118:654) on port #0.
RetroArch [INFO] :: [udev]: Pad #0 (/dev/input/event12) supports force feedback.
RetroArch [INFO] :: [udev]: Pad #0 (/dev/input/event12) supports 16 force feedback effects.
RetroArch [INFO] :: [Autodetect]: 181 profiles found.
RetroArch [INFO] :: [Autodetect]: selected configuration: /home/retro/.config/retroarch/autoconfig/udev/Microsoft_X-Box_360_pad.cfg
RetroArch [INFO] :: [udev]: Plugged pad: A4TECH USB Device (2522:37024) on port #1.
RetroArch [INFO] :: [udev]: Pad #1 (/dev/input/event4) supports 0 force feedback effects.
RetroArch [INFO] :: [Autodetect]: 181 profiles found.
RetroArch [INFO] :: [Autodetect]: no profiles found for A4TECH USB Device (2522/37024).
RetroArch [INFO] :: [Joypad]: Found joypad driver: "udev".
First bad commit - https://github.com/libretro/RetroArch/commit/11559f294af0a479c497ca0c6416059cd35bd0aa
You can find this information under Information/System Information
UPDATE:
keyboard with udev driver works if running retroarch in superuser(su) mode.
This is a normal issue and not our fault.
i don't understand. keyboard has running fine up to commit 647dc48 using udev(ra default) without needing (su)
Udev keyboard controls outside of X11 have always required chmod 666 or more. This is even explained when you press 'Select' on the udev input driver inside RA. It stems from years back, and you need to take that up with the developers of udev and Linux distributions in general. Nothing to do with us.
correct fix on distros that prevent reading from those devices:
sudo usermod -a -G input `whoami`
This should work on RH, ubuntu, debian, gentoo, and Arch for sure. If anyone can update the wiki i suggest it here https://forums.libretro.com/t/help-building-menu-no-input/10550/6
Can you do a bisect on this issue?
First bad commit - 11559f2
OK, paging @casdevel then - he might have an idea how to fix it.
I thought that this was explained by @twinaphex in one of his previous comments.
@retro-wertz Visit this page for more info. If it's working before it means that you didn't used udev input driver (regardless of menu selection), video driver was selected some other input driver (probably X11). If you are using OpenGL video driver than this is sure. Before commit 11559f2 udev input driver was unavailable with OpenGL video driver (it was fixed to use X11 input).
EDIT: To be more precise, #5010 introduced this changes.
if this is the explanation, then udev should not be default then, and set this to a more compatible input driver. how many casual linux users would know to navigate ra without inputs.
I agree, but it's not up to me to decide which input driver will be default.
@twinaphex X11 is probably the best candidate for default input driver now.
@twinaphex As I just wrote on https://github.com/libretro/RetroArch/issues/5033, it's not true that rw permissions are needed to the dev node, or sudo, if you use logind or ConsoleKit to manage seats and access the devices through libudev (as the udev driver does).
@twinaphex Giving uniform access to input nodes would allow all users to snoop on each other's input which would be serious security vulnerability and that's why distributions will never allow it, even on non-default capacity. You should follow what @sjnewbury says and properly use libudev or forget about udev input (or any raw, direct access, for that matter) altogether. Although, judging by how user-unfriendly, disjointed and bloated RA's UIs are, adding vulnerability that requires user-level authorization to be exploited isn't much worse for the course.
i have never used udev since, although if you can send PR about what you suggested without breaking stuff then it would be great.
This issue is essentially a permissions issue which is out of scope for this code base. Additionally the udev input driver is no longer default and its well documented on how to use it so I am going to close this issue.
@retro-wertz Please tell me if I am wrong?