Navigation Menu

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

uinput not getting through to game #4780

Closed
codecardinal opened this issue Mar 25, 2017 · 14 comments
Closed

uinput not getting through to game #4780

codecardinal opened this issue Mar 25, 2017 · 14 comments

Comments

@codecardinal
Copy link

codecardinal commented Mar 25, 2017

Description

Emulating keystrokes through uinput works in the EmulationStation interface, but the moment a game starts (GBA), then the uinput is not received anymore.
I've experimented with some stuff RetroPie/RetroPie-Setup#1936

Expected behavior

uinput should be a valid input/controller.

Actual behavior

No keystrokes are sent to the game.

Steps to reproduce the bug

Install python-uinput (https://github.com/tuomasjjrasanen/python-uinput)
Write small script that emulates keyboard (this is mine, it works great in the emulation station or terminal but fails in game https://github.com/codecardinal/gpio-to-keyboard-emulater-python)

Version/Commit

You can find this information under Information/System Information

  • RetroArch: latest

Environment information

  • OS: RetroPie
  • Compiler: [In case you are running local builds]

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@X30NS
Copy link

X30NS commented Jun 24, 2017

Had the same issue this week (with own python-script).
As a workaround, i was able to get it working using evdev instead of uinput to send keystrokes.

@ShoiX
Copy link

ShoiX commented Oct 19, 2017

@X30NS can you please explain how you made it work using evdev,
I too has the same problem, tried evdev but still I cannot send keystrokes once I run the ROM.

@NTBsMeep
Copy link

Hello, I built a portable raspberry pi gameboy. To get the buttons over GPIO to work, i wrote a python script. First I was using uinput, which doesn't worked. I changed to evdev an then it worked... I start the script when the system is starting.
I'll attach the python script for you. But never mind, it's pretty simple and ugly, since I usually don't use python.

buttons.zip

I hope this helps you...

@ShoiX
Copy link

ShoiX commented Nov 21, 2017 via email

@mdasifbinkhaled
Copy link

mdasifbinkhaled commented Jul 25, 2018

This program works fine while the retropie runs but it does not work when the game runs. @NTBsMeep can you please tell me what might be wrong?

from evdev import UInput,ecodes as e
import time

ui=UInput()

def hold(key):
ui.write(e.EV_KEY, key, 1)
ui.syn()
return 0

def release(key):
ui.write(e.EV_KEY, key, 0)
ui.syn()
return 0

hold(e.KEY_E)
time.sleep(1)
release(e.KEY_E)
#ui.close()

@codecardinal
Copy link
Author

codecardinal commented Aug 1, 2018 via email

@NTBsMeep
Copy link

NTBsMeep commented Aug 1, 2018

Hello

You're missing the code-line "device = uinput.Device([uinput.KEY_E])" right before "ui = UInput()". This creates a new input-device. Seems odd I know, but without this line I was getting strange behavior. I can't exactly remember how uinput work, but I had the issue that my keys only worked with connected keyboard. (Maybe the uinput-device is created different if no keyboard is connected...). Unfortunately, I was too lazy to take notes.

For my project, I wrote an additional script (launcher.sh) to start the python script attached in my previous post. The launcher-script is started by /etc/rc.local (simple "/boot/launcher.sh &" line).

############################
launcher.sh:
#!/bin/sh
# launcher.sh
cd /
cd boot
sudo python buttons.py
cd /
############################

I can't remember exactly why I wrote the launcher script (and not start the python script in rc.local), but I think it was a permission issue...

I hope this infos can help you with your issue.

@bmarquismarkail
Copy link

I have this problem. I just created X and Y axes to circumvent it

SDL2 itself only will acknowldge uinput devices as joysticks with the following criteria (as displayed on SDL2's source src/joystick/sysjoystick.c:

A non-null device name (Which would fail on UI_DEV_CREATE if you tried),
A struct input_id (Another given),
EV_KEY type and 1 EV_KEY code
EV_ABS type and ABS_X and ABS_Y set

Refer to above filename, in function IsJoystick(int fd, char *namebuf, const size_t namebuflen, SDL_JoystickGUID *guid)�.

If this is to your liking, you can buy me coffee.

@georgefst
Copy link

georgefst commented Aug 2, 2020

@bmarquismarkail After a few hours of trying to get a uinput device (from a project of mine) to be picked up by SDL2, I was prepared to buy you that coffee. But I just can't get it working.

As an example:

import libevdev
import time
from libevdev import InputEvent
from libevdev import InputAbsInfo

a = InputAbsInfo()
d = libevdev.Device()
d.enable(libevdev.EV_ABS.ABS_X, a)
d.enable(libevdev.EV_ABS.ABS_Y, a)
d.name = 'python test device'
d.enable(libevdev.EV_KEY.KEY_1)
uinput = d.create_uinput_device()

print('new device at {}'.format(uinput.devnode))

while True:
    events = [
        InputEvent(libevdev.EV_KEY.KEY_1, 1),
        InputEvent(libevdev.EV_KEY.KEY_1, 0),
        InputEvent(libevdev.EV_SYN.SYN_REPORT, 0),
    ]
    uinput.send_events(events)
    time.sleep(1)

creates a device that shows up with evtest but not with sdl2-jstest, gamepad-tool, or (the end goal) Steam.

I've looked at the C code and not found it very enlightening.

@bmarquismarkail

This comment has been minimized.

@bmarquismarkail
Copy link

Upon further inspection, you code doesn't work because a device with a key is not recognized as a joystick

Change KEY_1 to BTN_1 and see if that fixes the issue.

@georgefst
Copy link

georgefst commented Dec 20, 2020

Thanks! I eventually figured that out independently, but forgot that this was one of the places I'd posted.

On some systems, I also had to set the SDL_GAMECONTROLLERCONFIG environment variable to a suitable value.

@inactive123
Copy link
Contributor

We're a few months later, but can someone check if this PR -

#12830

resolves the issue?

@LibretroAdmin
Copy link
Contributor

Going to close it since no response.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants