Project

General

Profile

Actions

Emulator Issues #13628

open

Linux evdev input devices - input name priority causes like-named buttons to not be detected

Added by ThatOneSeong about 1 month ago. Updated 8 days ago.

Status:
New
Priority:
Normal
Assignee:
-
% Done:

0%

Operating system:
N/A
Issue type:
Bug
Milestone:
Regression:
No
Relates to usability:
No
Relates to performance:
No
Easy:
No
Relates to maintainability:
No
Regression start:
Fixed in:

Description

Game Name?

Any (applies to Dolphin's input system in general)

What's the problem? Describe what went wrong.

With the OpenFIRE system, our lightguns expose three different devices - a mouse, keyboard, and gamepad. Most every other program can distinguish between a Left Click and the Keyboard Left Arrow key (which we don't use anymore in default configs), but Dolphin (currently) cannot if using the evdev/0/OpenFIRE [configured name] device.

I think part of this might be based on the order in which the Evdev controls list (e.g. what's shown in the advanced Configure Input window) generates the inputs - i.e., the gamepad is always the last device, which is fine, but the topmost set of inputs ends up being the Keyboard; from what I can tell, the topmost listing for whatever is, say, LEFT has absolute priority over any other inputs that are similarly named.

So, ergo, if the mouse is the first set of inputs detected by Dolphin for the event devices under my OpenFIRE gun (which I can somewhat reliably replicate only when the gun is plugged in while Dolphin is running), LEFT will equal Mouse Left Click, which is what I want. But the next time I load Dolphin while the gun is plugged in, the Keyboard inputs are listed first--and now all of a sudden, LEFT equals Keyboard Left Arrow, which means the mouse click now does nothing. This can be seen in the advanced Configure Inputs window - only the first/topmost instance of LEFT gets activated in the bottom section that correlates to what Dolphin sees as pressed based on the syntax, despite the second instance of LEFT actually correlating to the input I'm pressing. The effect of this is that the mouse buttons cannot be reliably used.
This can also happen when using the gun in gamepad output mode, where the camera outputs as either the left or right stick (Axis 0/1 or Axis 2/3) - because the mouse seems to always come first/above the gamepad, which has its own Full Axis 0-/+/Full Axis 1-/+ inputs, the left stick of the gamepad output (which is also labeled Full Axis 0-/+/Full Axis 1-/+) doesn't get recognized in actual play.

As far as I'm aware, this only applies to Linux, as it's specific to the evdev subsystem? Also this was only tested with OpenFIRE (full disclosure, am speaking as its maintainer), but should in theory also apply to the Sinden Lightguns, GUN4IR lightguns, and (eventually) Blamcon lightguns that use both multiple device outputs.

What steps will reproduce the problem?

  1. In Controllers->Wii Remotes, set an Emulated Wiimote in any slot, and open its configuration window.
  2. Plug in gun controller (OpenFIRE, GUN4IR, etc.), set the current device to evdev/0/[Name of gun controller]
  3. Right click a button setting to open the Configure Inputs window; note the order of inputs listed (sometimes when controller is plugged in at this point, mouse or gamepad inputs are listed first - else, keyboard is listed first).
  4. Map the current selected button to LEFT or RIGHT
  5. Observe how the input window reacts to buttons pressed depending on the order of inputs shown:
    • If gamepad or mouse inputs are listed first, pressing the button corresponding to left click will have the input tester react appropriately.
    • If ESC is the first input listed (meaning keyboard inputs are first), pressing the button corresponding to left click will have the input tester not react at all.
    • In either case, the LEFT input (corresponding to Mouse Left Click, not Keyboard Left Arrow) will still light up in the inputs list, but the current input parser will not react if keyboard takes priority for this device.

Is the issue present in the latest development version? For future reference, please also write down the version number of the latest development version.

Yes: 6851ed7 from master

Is the issue present in the latest release? For future reference, please also write down the version number of the latest release.

Yes: release 2409

What are your PC specifications? (CPU, GPU, Operating System, more)

OS: Arch Linux, using Dolphin installed from extra repo (release) and compiled from master via dolphin-emu-git AUR PKGBUILD (develop).

Actions #1

Updated by Billiard26 8 days ago

Can you please attach evtest command output for all three exposed devices?

Actions

Also available in: Atom PDF