Closed YoinkerBoinker closed 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.
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
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. ;-)
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
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.
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.
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?
You can use ... | grep -E '^Event: .*(SYN_REPORT|BTN_SOUTH|BTN_A)'
.
@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.
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:
evtest
is showing issues (describe the issues below)BTN_NORTH
andBTN_WEST
are intentionally swappedjstest
is showing issues (describe the issues below)gamepad-tool
is showing issues (post console output below)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
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.