atar-axis / xpadneo

Advanced Linux Driver for Xbox One Wireless Controller (shipped with Xbox One S)
https://atar-axis.github.io/xpadneo/
GNU General Public License v3.0
1.87k stars 110 forks source link

Double Input / Ghost Input #460

Closed YoinkerBoinker closed 4 months ago

YoinkerBoinker commented 4 months ago

Version of xpadneo

0.9.6-1

Controller Model

Connection mode

Installed Software

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:

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

Severity / Impact

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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

kakra commented 4 months ago

@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.