Help building menu; no input

RetroArch Linux devices
#1

i am trying to make changes to the frontend, not dealing with cores or anything. Not sure this is the right place…

i cloned libretro/RetroArch repo, and simply built it without any changes. i do not get any input working. I confirmed the resulting binary did create a valid default conf file in my home .config dir with proper input settings. I banged on all keyboard keys and the only one that works is the one that toggles frame rate. nothing else.

execution with -v shows:

RetroArch [INFO] :: [udev] Adding device /dev/input/event17 as type ID_INPUT_KEYBOARD.
RetroArch [ERROR] :: [udev] Failed to open device: /dev/input/event17 (Permission denied).
...
RetroArch [WARN] :: [udev]: Couldn't open any keyboard, mouse or touchpad. Are permissions set correctly for /dev/input/event*?

So, the error is kinda obvious. The question now, since a search for that failed showing that is not a common problem with users, is that requiring special dev access or running as root is not the way a proper build goes.

What am I doing wrong? Should I check a specific tag on git or master/HEAD is supposed to always be somewhat stable?

Build had nothing but a few format-truncation warnings.

Output of configure script:

Checking operating system ... Linux (Arch Linux rolling)
Checking for suitable working C compiler ... /usr/bin/gcc works
Checking for suitable working C++ compiler ... /usr/bin/g++ works
Checking for pkg-config ... /usr/bin/pkg-config
Checking for availability of switch -std=gnu99 in /usr/bin/gcc ... yes
Checking for availability of switch -Wno-unused-result in /usr/bin/gcc ... yes
Checking for availability of switch -Wno-unused-variable in /usr/bin/gcc ... yes
Checking function bcm_host_init in -lbcm_host ... no
Checking function sd_get_machine_names in -lsystemd ... yes
Checking presence of package egl ... 17.1.0
Checking function ass_library_init in -lass ... yes
Checking function pthread_create in -lpthread ... yes
Checking function pthread_key_create in -lpthread ... yes
Checking function dlopen in -ldl ... yes
Checking function socket in -lc ... yes
Checking function getaddrinfo in -lc ... yes
Checking existence of -lminiupnpc ... no
Checking function fcntl in -lc ... yes
Checking function getopt_long in -lc ... yes
Checking presence of package alsa ... 1.1.4
Checking presence of header file sys/soundcard.h ... yes
Checking presence of header file soundcard.h ... no
Checking existence of -lossaudio ... no
Checking function alcOpenDevice in -lopenal ... yes
Checking presence of package rsound >= 1.1 ... no
Checking presence of package libroar ... no
Checking presence of package jack >= 0.120.1 ... 0.125.0
Checking presence of package libpulse ... 10.0
Checking presence of package sdl >= 1.2.10 ... 1.2.15
Checking presence of package sdl2 >= 2.0.0 ... 2.0.5
Notice: SDL drivers will be replaced by SDL2 ones.
Checking presence of package libusb-1.0 >= 1.0.16 ... 1.0.21
Checking presence of header file GL/gl.h ... yes
Checking existence of -lGL ... yes
Checking function cgCreateContext in -lCg ... no
Checking presence of package zlib ... 1.2.11
Checking presence of package libavcodec >= 54 ... 57.89.100
Checking presence of package libavformat >= 54 ... 57.71.100
Checking presence of package libavdevice ... 57.6.100
Checking presence of package libswresample ... 2.7.100
Checking presence of package libavresample ... 3.5.0
Checking presence of package libavutil >= 51 ... 55.58.100
Checking presence of package libswscale >= 2.1 ... 4.6.100
Checking presence of header file libavutil/channel_layout.h ... yes
Checking function dlopen in -ldl ... yes
Checking presence of package gbm >= 9.0 ... 17.1.0
Checking presence of package libdrm ... 2.4.81
Checking presence of package libxml-2.0 ... 2.9.4
Checking presence of package vg ... no
Checking existence of -lOpenVG ... no
Checking presence of package libv4l2 ... 1.12.5
Checking function glFramebufferTexture2D in -lGL ... yes
Checking presence of package freetype2 ... 20.0.14
Checking presence of package x11 ... 1.6.5
Checking presence of package xcb ... 1.12
Checking presence of package wayland-egl ... 17.1.0
Checking presence of package wayland-cursor ... 1.13.0
Checking presence of package xkbcommon >= 0.3.2 ... 0.7.1
Checking presence of package dbus-1 ... 1.10.18
Checking presence of package xext ... 1.3.3
Checking presence of package xxf86vm ... 1.1.4
Checking presence of package xinerama ... 1.1.3
Checking presence of package xv ... 1.0.11
Checking presence of package libudev ... 232
Checking presence of header file linux/parport.h ... yes
Checking presence of header file linux/ppdev.h ... yes
Checking function strlcpy in -lc ... no
Checking function strcasestr in -lc ... yes
Checking function mmap in -lc ... yes
Checking function vkCreateInstance in -lvulkan ... no
#2

yep. I am a moron. Checking out tag ‘v1.6.0’ builds and i have input just fine.

…well, not that fine. it is refusing to use the settings values in the cfg file ‘-v’ says it is loading.

it says

RetroArch [INFO] :: [Config]: Loading default config.
RetroArch [INFO] :: [Config]: loading config from: (null).
RetroArch [INFO] :: Looking for config in: "/home/gcb/.config/retroarch/retroarch.cfg".
...
RetroArch [INFO] :: [Config]: Saved new config to "/home/gcb/.config/retroarch/retroarch.cfg".

I am pretty sure Enter is not used anywhere in that config:

input_player1_b = "z"
input_player1_b_btn = "nul"
input_player1_b_axis = "nul"
input_player1_y = "a"
input_player1_y_btn = "nul"
input_player1_y_axis = "nul"
input_player1_select = "rshift"
input_player1_select_btn = "nul"
input_player1_select_axis = "nul"
input_player1_start = "t"

even:

$ grep input_player1_ /home/gcb/.config/retroarch/retroarch.cfg | grep -i enter
(nothing)
$

But when menu shows up, all i can do is press Enter to select any highlighted option. Not “a” as I’d expect (or “t”, which is _start that was previously set to “enter”)

Ideas of what is going on?

#3

i have the same issue with my keyboard. recent update to udev changed this. Twinaphex this was normal and not retroarch’s fault(no idea what udev driver was suppose to do, but it worked before not sure why it should not now)

anyways running “sudo retroarch” should elevate the permission issue, or just use an older commit before the recent update to udev to that adds multiple mice support.

link github issue:https://github.com/libretro/RetroArch/issues/5016#issuecomment-305980931

#4

Hmm, always running as root as not a good solution. I’ll try to talk with the other guys and figure out what can be done.

#5

Yeah, elevating root should not be needed. this also makes retroarch react to keyboard an mouse inputs, even if its window is not active, not sure if this was intended. (not an accurate ss example but should be understandable :D)

Screenshot_2017-06-04_10-20-36.png818×632 119 KB

#6

Thanks for sharing this link! with issues disabled there is no way to search anymore.

That issue mentions that when you press select (when you have no input…ha!) it “says so”. I grep’ed the code for 666, udev, permission and all i found was the message i saw on the verbose log

RARCH_WARN("[udev]: Couldn't open any keyboard, mouse or touchpad. Are permissions set correctly for /dev/input/event*?\n");

doesn’t really says which file/permission it needs. Aparently it only needs read if the info here is correct: https://wiki.libretro.com/index.php?title=RetroArch#Setting_up_udev_permissions

that wiki should be updated, the suggestions there are way too complicated!

Here’s the correct text (I can’t post there since i get a PHP sendmail error for the email registration. The server can’t send email and I can’t confirm my mail because of it). If anyone is so inclined, here is the text i’d use:

Most new distros prevent users from capturing keyboard/mouse information by default. Only root and users in the group “input” are able to. This is a security feature in case the system is used by multiple users. For most desktops allowing your local user to capture events is fine (keep it in mind keylogger worms will have a easier time). The easiest way on most distros is to add your user to the group “input” with the command:

sudo usermod -a -G input `whoami`

And then log out and log in again. If that doesn’t work, try one of the methods [And here add all the old text on the wiki]

Might also add a warning about not running retroarch as root/sudo :slight_smile:

#7

And yet another issue after moving past this one.

It continues to ignore my input settings. I can navigate with arrow keys. I can select with Enter. But nothing else works.

if I navigate to input > user 1, i can see the usual Z and X. I can even press Enter and reset as Z and X or any other key… and I still can’t go back a level with Z or whatever i map.

Any ideas why that is? I am still on the v1.6.0 branch build.

#8

Hi Everyone. I still can’t get input to be read properly from my cfg file.

i am building from git, either the last tagged release (v1.6.0) or HEAD (85058fbe5c513a9e3018cf05ab3fd9b5708cfc7b). Same problem happens on both.

Both cases it will understand arrow keys for d-pad, Enter for A and backspace for B.

Even though my cfg files says otherwise. If i navigate using the menu to user 1 input, i can see my settings, Enter and Backspace are nowhere to be seen, but still are the only buttons that allows me to navigate the menu.

#9

hum. according to How to configure menu buttons (ok, cancel)?

menu keys are now hardcoded and not used from player 1 A/B buttons… sigh.

#10

You can go back to retropad A/B by going to settings > input > unified menu controls ON.

1 Like
#11

Most new distros prevent users from capturing keyboard/mouse information by default. Only root and users in the group “input” are able to. This is a security feature in case the system is used by multiple users. For most desktops allowing your local user to capture events is fine (keep it in mind keylogger worms will have a easier time). The easiest way on most distros is to add your user to the group “input” with the command:

sudo usermod -a -G input `whoami`

And then log out and log in again. If that doesn't work, try one of the methods [And here add all the old text on the wiki]

Thanks @gcb for this suggested new text for the docs. I made only a few alterations to your text and I have submitted it for approval.

You can see the PR on github with your change: https://github.com/libretro/docs/pull/103

If the PR is accepted it will become part of the Input Driver docs here: https://buildbot.libretro.com/docs/guides/input-drivers/