RetroArch reads keyboard input when not focused with the udev input driver.

[orbea]

Description

If RetroArch is opened and then the user changes to another workspace where RetroArch is not focused and then presses f (Fullscreen) it will move RetroArch to a new workspace as if its still focused. This only occurs with the udev input driver and possibly only some DE/WMs.

This can be worked around by using the x input driver instead.

Expected behavior

RetroArch should only read keyboard input when focused.

Actual behavior

When the udev input driver is used it will read keyboard input at all times.

Steps to reproduce the bug

1. Open RetroArch and select the udev input driver.
2. Change to a different workspace.
3. Press f on your keyboard.

Bisect Results

2056ebc80378fabf1f96883de3c7c930c809d101 is the first bad commit
commit 2056ebc80378fabf1f96883de3c7c930c809d101
Author: Zoran Vuckovic <casdevel@gmail.com>
Date:   Fri Jun 2 01:08:28 2017 +0200

    Allow udev input to be used with X11 context

:040000 040000 73351e8a90dbd19dc573b1ae9e57304fda761f98 162cbac6462954d191373fbf0ba14ad0456cb1d8 M  gfx

2056ebc80378fabf1f96883de3c7c930c809d101

Version/Commit

You can find this information under Information/System Information

• RetroArch: RetroArch-1.6.1-x86_64-1_SBo
• window manager: spectrwm-2017.06.29_1b7dffb_master-x86_64-1_git

Environment information

• OS: Slackware64-current
• Compiler: gcc-7.1.0

@casdevel Can you take a look at this please?

[orbea]

Linking this here since its related. https://github.com/libretro/RetroArch/issues/5120

[ghost]

confirmed this, when udev was first updated. it reads mouse/keyboard inputs even if window is not active(i work usually in window mode).

On Tue, Jul 11, 2017 at 8:35 AM, orbea notifications@github.com wrote:

Linking this here since its related.

5120 https://github.com/libretro/RetroArch/issues/5120

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/libretro/RetroArch/issues/5162#issuecomment-314288787, or mute the thread https://github.com/notifications/unsubscribe-auth/AWPDthf7TQpcJk3whD5mhkyzYWmIr6Prks5sMsNXgaJpZM4OTbF9 .

[ghost]

@orbea I'll look into it in the next few days.

[orbea]

Thanks, I will be out of town for a while without access to a computer starting sometime tomorrow. So if I go silent that is why. :)

[ghost]

PR #5184 should fix this.

[orbea]

I can confirm this is fixed, thanks!!!

[orbea]

@casdevel I can still reproduce this with the udev input driver if Unified Menu Controls is enabled. No issues if the setting is disabled or with the x input driver.

Can you please take a look when you have a chance?

[orbea]

@casdevel Additionally this was only fixed if the RetroArch menu is open. I can still reproduce it if the game is running without the menu opened.

[ghost]

confirmed here that retroarch is accepting keyboard input when a game is running even if its not the active window.

On Tue, Aug 8, 2017 at 2:28 PM, orbea notifications@github.com wrote:

@casdevel https://github.com/casdevel Additionally this was only fixed if the RetroArch menu is open. I can still reproduce it if the game is running without the menu opened.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/libretro/RetroArch/issues/5162#issuecomment-320862917, or mute the thread https://github.com/notifications/unsubscribe-auth/AWPDttLFLhjbMSMnn3WL_aR1cQQ3e8tIks5sWAAEgaJpZM4OTbF9 .

[ghost]

@orbea and @retro-wertz just to let you know that I didn't forget about this, but I have few other things to deal with before I can start working on this ...

[orbea]

@casdevel Thanks for the heads up and no great rush, I was just unsure if you noticed this or not. :)

[ghost]

@orbea @retro-wertz I added more restrictions to user input when window is not active. Code is at https://github.com/casdevel/RetroArch/tree/fix-5162.

Note that I didn't disabled all input, and that I'm not sure what input is expected to be disabled when window is not active. Try it an let me know what you think.

[orbea]

@casdevel I tested the fix and I can no longer control RetroArch with the keyboard or mouse whether Unified Menu Controls is on, off or if the game is running. Thanks!

This however introduces a potential regression. If Don't run in background is disabled so the game can no longer be controlled with a gamepad while the window is not focused. It could be potentially useful to be able to be focused on an unrelated window while still using a gamepad to play the game.

[ghost]

OK, let's deal with this in tree steps: keyboard, then mouse, and touch-pad at the end, and leave code related to other devices unchanged.

I created another branch for this: https://github.com/casdevel/RetroArch/tree/issue5162. This time keyboard input changes only.

@orbea I couldn't reproduce that kind of input driver behavior on my machine. The only thing I noticed is that backspace and enter keys don't work with unified menu controls set to on (same thing with x input driver).

[orbea]

@casdevel Those changes resolve all the keyboard issues for me.

1. The keyboard does not affect the menu when its not focused.
2. The keyboard does not affect RA when in a game that is not focused.
3. Unified Menu Controls doesn't change this behavior anymore.
4. I can still use my gamepad to play a game while using the keyboard to type in another program.

Unless someone else can spot anything problematic I would consider that commit to be working fix. That said I do not usually test mouse or touchpad with RetroArch and do not know what issues are associated with that nor can I find them with quick testing.

Also, that is expected behavior of Unified Menu Controls. It should change the enter and backspace back to the old defaults of x and z. I've noticed it sometimes has unexpected behavior not everyone can reproduce however...

[ghost]

@orbea OK, I created a PR #5426. I'll change mouse and/or touch-pad code if someone report a issue.

[orbea]

Thanks! I will close this until if/when someone finds another issue associated with these commits.

[ghost]

its looks ok here too. thanks.