Double Input / Ghost Input

[YoinkerBoinker]

Version of xpadneo

0.9.6-1

Controller Model

• Xbox One S controller
• Xbox Elite 2 controller
• Xbox Series X|S controller
• Other:

Connection mode

• Bluetooth connection
• USB cable (not yet supported)
• Xbox Dongle connection (not yet supported)

Installed Software

• Anti-Micro (may affect button mappings)
• OpenRGB (may mess up mappings and rumble stability)
• Steam Input (enabled by default via Steam Desktop client)
• Steam Link (usually via Raspberry Pi or other micro computers)
• devices with QMK firmware (may affect udev rules, similar to OpenRGB)
• netstick (shares input devices via network similar to Steam Link)
• xboxdrv (user-space gamepad driver)
• xone (kernel-space gamepad driver using the Xbox dongle or USB)
• xow (alternative driver using the Xbox dongle)

Protocol Information

Please help us identify at which layer the problem can be found if you want
to report mapping errors or if the controller fails to be detected:

• Steam Proton games are having issues
• Steam Linux-native games are having issues
  • I don't use Steam or did not try
• games running through Lutris, wine and/or Bottles are having issues
  • I don't use Lutris, Bottles, wine or did not try
• Linux-native games are having issues
  • I don't use native games or did not try
• Other software is having issues (describe software and issues below)
• Running evtest is showing issues (describe the issues below)
  • Keep in mind that BTN_NORTH and BTN_WEST are intentionally swapped
• Running jstest is showing issues (describe the issues below)
  • I don't have this tool or don't know how to use it
• Running gamepad-tool is showing issues (post console output below)
  • I don't have this tool

Please describe how it is failing below in the next sections.

Severity / Impact

• I've read the docs and the bug reporting instructions
• I've applied the latest firmware update to the controller
• I've tried disabling or running without above mentioned software
• It does not work at all
• It used to work in a previous version
• It mostly works but sometimes it doesn't
• I found a work-around
• I probably didn't figure it all out but it's too early to give up
• I don't know how to ...
• It's too complicated
• Fantastic work but ...
• I can code and I want to help

Describe the Bug

I'm using the TP-Link UB400 Nano to connect the Pad via Bluetooth. Mostly it works fine and i don't notice any input lag or delay however pretty randomly it seems like there is happening some "double-input" or even what i'd call "contra-input" right after a Button-Press.
An example would be that after Pressing "A" it is again pressed in a very fast and unnatural way. Though i also witnessed that for example after pressing "B" - "A" will pressed right after. Same goes for different combinations. It mostly seems to be the case with the YXBA buttons. I have only saw it happening once on the D-Pad so far ( however that could be a coincidence).
So far i only saw this happening on Retroarch (Steam). With both Steam-Input enabled/disabled. I haven't yet noticed it in any bigger Games.. but the reason might be because these games aren't as sensitive to button Presses as some Retro-Games.

Steps to Reproduce

The best way to reproduce it is to play NES Game "Dr. Mario" with Retroarch/Mesen Core. I'd say it happens like once in a Hour of Playtime (though not always - can be more often or less). There it can be noticed pretty good since the Pill then will turn in a way that you don't want.

Expected Behavior

no random presses.

System Information

# uname -a
6.7.4-arch1-1 #1 SMP PREEMPT_DYNAMIC Mon, 05 Feb 2024 22:07:49 +0000 x86_64 GNU/Linux

Controller and Bluetooth Information

xpadneo-btmon.txt
xpadneo-dmesg.txt
xpadneo-lsusb.txt

Additional Context

My Firmware is up to date and the Pad is pretty new as well. I previously also used a 8Bitdo Controller in combination with that Bluetooth Dongle which didn't have the issue - though i didn't use xpadneo (it worked without any additional software). I'm like 30cm away from the Dongle during playing.
I know that this still might be a Connection related issue. Though i just want to get certain, since i'm already thinking about replacing the Pad since this can kinda annoying when playing Retro Games.

[kakra]

Please stop the Steam client before trying with one of the affected games (if they run outside of Steam). I suspect that the game may see inputs from the controller and the Steam Virtual controller.

Also, run evtest and click single buttons to see if they cause double input. Be sure to not touch the analog sticks otherwise it's not easy to see if there was a double input.

I've seen issues where Proton would see the controller twice, once via xpadneo directly, and once via SDL2 as Steam Virtual Controller, and transmit inputs from both copies to games... If this happens in Proton games, we need a wine log with specific settings (I'll have to figure this out first, let's see, if we need it).

I sometimes see double-input in Elite Dangerous but I always attributed it to the game: never seen in other games, and it happens for mouse clicks there (which actually puts you into open game mode because this button is on the next page after "play" in the same position). So I rather believe there's something in Proton or Steam Input causing it because it also affects other devices - at least for me. The effect is quite random, it rarely happens but it happens once in a while.

[YoinkerBoinker]

I'm using the Retroarch Version i can download from Steam. I might test the standalone and see if it happens there as well. Though i already disabled steam-input globaly and per game. Can't really reproduce this with Evtest since it happens randomly tough i might have it run next time i play so i can check out if the double input will get reported there as well.
But if steam is the root of this i wonder why this wasn't an issue with the 8bitdo Pad i had before?
Honestly i also doubt that xpadneo is the reason. My guess is that it's the Firmware since i found an old reddit thread which sounds familiar here

[kakra]

Okay, this is interesting. Does it affect "A" only? If this is a firmware bug, we may be able to work around it... like in "if it doubles within 5ms, don't send it again". I'm not sure how fast you can actually manually do a double tap, probably not below 10ms. evtest shows very granular timestamps, you could collect some statistics. ;-)

[YoinkerBoinker]

I'll try to gather more information on this. As i said due to its randomness it's kinda hard to reproduce. I had evtest on the last few times i played but it didn't happen yet so far. With just spaming it can't be reproduced. Or i'm then not able to notice it.I will now keep using evtest during every game and check it as soon as it happens. Dr. Mario is great for that since the input is fast but not too fast so i'll be able to spot any wrong input there although the game is getting annoying for me to play :D

[YoinkerBoinker]

Okay, so i now had a good look on evtest during it happend again. It seems like there is no actual input recorded on evtest. So my guess is that it is somewhat an issue with retroarch/steam. Or i'm just too stupid to spot the input on evtest. At this point i don't know what can be done about it. Steaminput has been disabled and enabled happens with both. I might now see if this is an issue of retroarch itself and try the non-steam version of it.

[kakra]

You could try grepping the evtest output for the button in question. Please also grep for the sync event because that is what completes the input data frame and sends its state to user space, or IOW, button release/press is only detected as a change between different frames, not within the same frame.

OTOH, you should never see the same button twice within one frame - the kernel code should already take care of it. You still see the sync event from the kernel, tho, but the kernel should deduplicate all key reports within the same frame. If this works, you can just grep ignoring the sync events.

[YoinkerBoinker]

Sorry but could you tell me how exactly i would grep for the sync event as well? I'm not really sure if i get you right on this. I'd assume you mean there shouldn't be more than one "Press" in each SYN_REPORT when using evtest. And i should get sure that each press also has a release reported?

[kakra]

You can use ... | grep -E '^Event: .*(SYN_REPORT|BTN_SOUTH|BTN_A)'.

[kakra]

@YoinkerBoinker I may have identified one cause of your observed behavior: When double input or ghost input occurs, do you move the analog sticks at the same time? Sometimes this is only visible in evtest because the sticks are very sensitive and even if you don't move a stick, hitting the button hard enough may create stick input. Stick movement may also be caused by rumble.

I'll be pushing a commit which may fix this issue. Feel free to re-open if the problem still exists with the latest git version.