Xbox 360 wireless controller stops working after returning from menu to game

salzix commented 1 month ago

Description I'm using XBox 360 wireless controller with dedicated USB receiver, on Raspberry Pi 5. Controller works fine after starting a game, but stops working completely after going to F12 menu and returning back to game. It is still selected in port 2 in menu as before, just unusable. Switching different modes, switching ports, disabling/enabling joystick, changing to keyboard and back doesn't help.

This controller with receiver works fine when I'm testing it using jstest tool.

To Reproduce Steps to reproduce the behavior:

After starting Amiberry start any game that uses joystick - controller works fine.
Click F12 to get to menu and return to game
Controller doesn't work at all. If you go to menu again, it's still selected but not working.
After exiting to command line and starting again Amiberry controller works again, until getting to menu (pt. 1 above).

Expected behavior Controller should still work after returning from menu.

Desktop:

OS: Raspberry Pi OS 12 (bookworm) 64bit on Raspberry Pi 5 64bit, 8GB
Version: 5.7.3 from binary
XBox 360 wireless controller
original Microsoft Xbox 360 Wireless Receiver USB

giantclambake commented 1 month ago

A few weeks ago, we did a lot of input controller testing ~ that said, I'm not certain if the wireless USB xbox controller was covered (I only have wired controllers, not sure about others' testing ;) That said, I cannot recreate this here using a RPi4 with bookworn, wrt amiberry v5.7.3 or Master ... with wired xbox controllers.

M'kay...lets try constrain the test example...(see attached) ... the whdloader will define controller mapping via the XML, giving us 'common ground' here. Could you please do the following test, and let us know the results?

Download/unzip the attached file, and launch the amiberry GUI --> go to Paths panel and Enable logging: Go to Quickstart panel, and select the StuntCarRacer_v1.3_0222.lha in WHDLoad auto-config: --> press Start This title will boot quickly to the game main menu (3 items)...you should be able to use dpad up/down to move selection Hit F12 ---> can you still use dpad up/down to select panel entries in the amiberry GUI? IF you click Resume, does the controller still work in the game menu or not?

Quit amiberry, gzip the resultant amiberry.log file, and attach it to your reply.

StuntCarRacer_v1.3_0222.lha.gz

salzix commented 1 month ago

Hello and thanks for quick reply!

I went through these test steps. Here's the result, and logs attached.

Tested on provided StuntCarRacer:
- I've started a game (with logging on), it loaded, I was able to use controller to move selection in in-game menu.
- After hitting F12 I was able to move through entries in amiberry GUI
- After selecting "Resume" it didn't return to game. Instead a command line showed up, with my ./amiberry command entered on start. It was unresponsive, frozen. I couldn't close it, so i killed process from another terminal session. It looks like another problem :(
Tested on ADF file with Rodland game:
- As before, I was able to run a game, use controller
- Also after going to Amiberry GUI I was able to use controller to move through menus
- After selecting "Resume" it returned to game, but controller wasn't working in game.
- After hitting F12 again the controller worked in Amiberry GUI - that's one thing I didn't try before.

I've attached separate logs of both runs.

wt., 16 lip 2024 o 12:36 giantclambake @.***> napisał(a):

A few weeks ago, we did a lot of input controller testing ~ that said, I'm not certain if the wireless USB xbox controller was covered (I only have wired controllers, not sure about others' testing ;) That said, I cannot recreate this here using a RPi4 with bookworn, wrt amiberry v5.7.3 or Master ... with wired xbox controllers.

M'kay...lets try constrain the test example...(see attached) ... the whdloader will define controller mapping via the XML, giving us 'common ground' here. Could you please do the following test, and let us know the results?

Download/unzip the attached file, and launch the amiberry GUI --> go to Paths panel and Enable logging: Go to Quickstart panel, and select the StuntCarRacer_v1.3_0222.lha in WHDLoad auto-config: --> press Start This title will boot quickly to the game main menu (3 items)...you should be able to use dpad up/down to move selection Hit F12 ---> can you still use dpad up/down to select panel entries in the amiberry GUI? IF you click Resume, does the controller still work in the game menu or not?

Quit amiberry, gzip the resultant amiberry.log file, and attach it to your reply.

StuntCarRacer_v1.3_0222.lha.gz https://github.com/user-attachments/files/16247177/StuntCarRacer_v1.3_0222.lha.gz

— Reply to this email directly, view it on GitHub https://github.com/BlitterStudio/amiberry/issues/1384#issuecomment-2230570804, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6MZJE6XXQZQNBOLCWLOGDZMTZRPAVCNFSM6AAAAABK6DMLGCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZQGU3TAOBQGQ . You are receiving this because you authored the thread.Message ID: @.***>

giantclambake commented 1 month ago

Thanks for testing ;)

Can you retry attaching the logfiles again? For some reason, they're not attached to your reply. (use the 'click to add files' method)

salzix commented 1 month ago

I think they were blocked by antivirus when gzipped. I've decompressed them, they are small anyway.

Here you go.

wt., 16 lip 2024 o 14:32 giantclambake @.***> napisał(a):

Thanks for testing ;)

Can you retry attaching the logfiles again? For some reason, they're not attached to your reply. (use the 'click to add files' method)

— Reply to this email directly, view it on GitHub https://github.com/BlitterStudio/amiberry/issues/1384#issuecomment-2230773183, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6MZJHBHYSHPAMTAMSIWPTZMUHF5AVCNFSM6AAAAABK6DMLGCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZQG43TGMJYGM . You are receiving this because you authored the thread.Message ID: @.***>

giantclambake commented 1 month ago

//I live in AU and zulu +10 timezone puts me out of step with the EU ;)

Logfiles still not attached ~ I think it's because you're replying by email, and not replying to this github page directly ; when replying to this github page, the logfiles have to be gzipped =)

Tested on provided StuntCarRacer:

I've started a game (with logging on), it loaded, I was able to use controller to move selection in in-game menu.

After hitting F12 I was able to move through entries in amiberry GUI

After selecting "Resume" it didn't return to game. Instead a command line showed up, with my ./amiberry command entered on start. It was unresponsive, frozen. I couldn't close it, so i killed process from another terminal session.

This is an odd result ~ I'm presuming here you're using console only (no desktop environment)? If you've enabled logging in the GUI, that setting will stick (logging is always turned on). It would be interesting to know what happens if you redo this test, except direct launching the title instead of using GUI...ie; ./amiberry StuntCarRacer_v1.3_0222.lha (presumes the whdload.lha file is in same directory as amiberry, if not, ./amiberry path/to/StuntCarRacer_v1.3_0222.lha will work) A logfile of this might be handy.

Tested on ADF file with Rodland game:

As before, I was able to run a game, use controller

Also after going to Amiberry GUI I was able to use controller to move through menus

After selecting "Resume" it returned to game, but controller wasn't working in game.

After hitting F12 again the controller worked in Amiberry GUI - that's one thing I didn't try before.

This is interesting ~ I've got a hunch this is all somehow related to #1351 in some way....at least, the behavior roughly follows that pattern. I'll setup the RPi4 here today in console mode, and see if I can recreate it.

giantclambake commented 1 month ago

@salzix ~ I can recreate this on the RPi4 when booting to console (CLI) mode, using a USB wired Xbox controller. I'll have to do some more testing here to try isolate the cause, but my immediate appreciation is that this is some other machination of #1351 as well, as I'm seeing the same reticence wrt the F12 key action therein described.

Thanks for reporting this ~ as I can recreate the issue here, we no longer need your logfiles as such ;) I don't think it's related to the wireless xbox controller, but I do have a question --- are you using a USB wired, or wireless keyboard?

@midwan ~ I'll need to tease this out some more, as I don't use CLI mode on the RPi4 often, and I'll have to check how KMS/DRM are set. Further, I'm becoming suspicious of host-side kbd input wrt the F12 key action, particularly with USB wireless keyboards ; in layman's terms (laypersons? ;), it's as though hitting F12 once, results in multiple F12 keypress events being actioned (I got the same impression on the LFS x86-64 build in console mode using USB wireless KBD), so I'll need dig a bit deeper and swap hw around to get a better handle on it =)

salzix commented 1 month ago

Hi, // good morning from EU :)

I'm using USB wired keyboard, and booting to CLI mode. I'll check how it works under GUI. Let me know if you need anything more, I'll be happy to help to resolve these issues.

śr., 17 lip 2024 o 05:11 giantclambake @.***> napisał(a):

@salzix https://github.com/salzix ~ I can recreate this on the RPi4 when booting to console (CLI) mode, using a USB wired Xbox controller. I'll have to do some more testing here to try isolate the cause, but my immediate appreciation is that this is some other machination of #1351 https://github.com/BlitterStudio/amiberry/issues/1351 as well, as I'm seeing the same reticence wrt the F12 key action therein described.

Thanks for reporting this ~ as I can recreate the issue here, we no longer need your logfiles as such ;) I don't think it's related to the wireless xbox controller, but I do have a question --- are you using a USB wired, or wireless keyboard?

@midwan https://github.com/midwan ~ I'll need to tease this out some more, as I don't use CLI mode on the RPi4 often, and I'll have to check how KMS/DRM are set. Further, I'm becoming suspicious of host-side kbd input wrt the F12 key action, particularly with USB wireless keyboards ; in layman's terms (laypersons? ;), it's as though hitting F12 once, results in multiple F12 keypress events being actioned (I got the same impression on the LFS x86-64 build in console mode using USB wireless KBD), so I'll need dig a bit deeper and swap hw around to get a better handle on it =)

— Reply to this email directly, view it on GitHub https://github.com/BlitterStudio/amiberry/issues/1384#issuecomment-2232283472, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6MZJAWGFLJC4X7YKB3R5TZMXOEJAVCNFSM6AAAAABK6DMLGCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZSGI4DGNBXGI . You are receiving this because you were mentioned.Message ID: @.***>

giantclambake commented 1 month ago

I'm able to recreate this, using Preview/x86-64 ...so it's not just a RPi thing. I tested on the LFS build using i5-4690S CPU @ 3.20GHz ..I believe the CPU capabilities/speed maybe playing a part here.

-- After starting the emulation, controller input is active/working in the emulation -- After the first press of F12, controller still appears active in GUI -- pressing F12 again to return to emulation, results in all input being lost to the emulation (mouse & joystick) -- once this is so, F12 -> Reset does not return input to emulation -- once this is so, F12 -> Restart does not return input to emulation ---to revolve the loss of input to the emulation, you must Quit amiberry

Notes:

Once controller/kbd input is lost, repeatedly toggling the F12 key, and moving the mouse thereafter, may cause the GUI to reappear 'un-commanded' as it were...(that is, the mouse movement is somehow becoming a trigger to raise GUI)

Only once was I able to recreate the 'lock out' situation, wherein you're stuck with the emulation fullscreen, not accepting mouse/kbd input, and F12 is not responsive either. It appears all the world like everything has locked-up, but upon ssh'd into the machine the amiberry process seemed to be running normally...killing the amiberry process recovers situation.

giantclambake commented 1 month ago

Master / rpi4-64-sdl2 / bookworm/CLI boot .... for sake of sanity, the same 1280x1024@60Hz monitor was used as in the x86-64 test. I'm using the same tests cases, but observing slightly different results vs preview/x86-64...

Test 1: ./amiberry StuntCarRacer_v1.3_0222.lha

--title boots to game menu screen, controller works, F12 , controller works in GUI, F12 to return to emulation ---I get dropped to the console where I invoked the above command. Mouse pointer is still visible and responding, but clicking buttons does nothing ; kbd presses have no effect ..had to ssh in and kill the amiberry process. Attached logfile of this run ~ amiberry.log2.gz

Note: I don't encounter this impasse on x86-64, however, I do momentarily see the console window, as we flip between the GUI and emulation when toggling the F12 key in the x86-64 case...

Test 2: --launch amiberry, GUI->Quickstart->WHDload auto-config: -> select StuntCarRacer_v1.3_0222.lha -->Start --title boots to game menu screen, controller works, F12 , controller works in GUI, F12 to return to emulation ---controller input no longer works in emulation, hitting the F12 key may or may not raise the GUI. As described previously once in this state, you need to quit amiberry to clear it...ie; survives Reset & Restart. Attached logfile of this run ~ amiberry.log.gz

Note: This is more than less equivalent wrt the x86-64 case, however it's more noticeable on the RPi4, no doubt reflecting the lower platform performance at a guess.

Test 3: --launch amiberry, GUI->Quickstart->select AmigaTestKit.adf in DF0: --> Start --test keyboard/joystick/mouse inputs working -> F12 , controller works in GUI, F12 to return to emulation ---controller input no longer works in emulation, hitting the F12 key may or may not raise the GUI...but it appears to be a little more reliable in this situation, but still horrorshow ..keyboard & mouse still test as working in ATK.

Do Note: Only seems to happen in KMSDRM mode ~ in the desktop X/wayland arena, all working as expected AFAICT.

amiberry.log2.gz

amiberry.log.gz

@salzix

You taking the time to report issues like this, is already in itself of great help. As fixes like this tend to happen in real time as it were, you're basically left with three choices --- 1. wait for & test the next amiberry binary release, that contains the fix for this issue ... or ... 2. Become comfortable with compiling amiberry from the github sources, which gives you the opportunity to test any fix-ups, 'as they happen' so to speak (before the next binary is released). The latter case is of course often the most useful, as it gives you the chance to confirm the potential fix works as intended...wrt your usage & hardware setup case....and 3. you can always support midwan on his Kofi page, if you'd like to help that way...I know I do, any time I want to express a tangible thank you =^)

salzix commented 1 month ago

I've repeated tests on GUI/desktop mode of RPi OS, and there is no problem with controller! I was able to switch to Amiberry menu and back to game multiple times, and controller works.

śr., 17 lip 2024 o 14:27 giantclambake @.***> napisał(a):

Master / rpi4-64-sdl2 / bookworm/CLI boot .... for sake of sanity, the same @.*** monitor was used as in the x86-64 test. I'm using the same tests cases, but observing slightly different results vs preview/x86-64...

Test 1: ./amiberry StuntCarRacer_v1.3_0222.lha

--title boots to game menu screen, controller works, F12 , controller works in GUI, F12 to return to emulation ---I get dropped to the console where I invoked the above command. Mouse pointer is still visible and responding, but clicking buttons does nothing ; kbd presses have no effect ..had to ssh in and kill the amiberry process. Attached logfile of this run ~ amiberry.log.bz2

Note: I don't encounter this impasse on x86-64, however, I do momentarily see the console window, as we flip between the GUI and emulation when toggling the F12 key in the x86-64 case...

Test 2: --launch amiberry, GUI->Quickstart->WHDload auto-config: -> select StuntCarRacer_v1.3_0222.lha -->Start --title boots to game menu screen, controller works, F12 , controller works in GUI, F12 to return to emulation ---controller input no longer works in emulation, hitting the F12 key may or may not raise the GUI. As described previously once in this state, you need to quit amiberry to clear it...ie; survives Reset & Restart. Attached logfile of this run ~ amiberry.log.gz

Note: This is more than less equivalent wrt the x86-64 case, however it's more noticeable on the RPi4, no doubt reflecting the lower platform performance at a guess.

Test 3: --launch amiberry, GUI->Quickstart->select AmigaTestKit.adf in DF0: --> Start --test keyboard/joystick/mouse inputs working -> F12 , controller works in GUI, F12 to return to emulation ---controller input no longer works in emulation, hitting the F12 key may or may not raise the GUI...but it appears to be a little more reliable in this situation, but still horrorshow ..keyboard & mouse still test as working in ATK.

Do Note: Only seems to happen in KMSDRM mode ~ in the desktop X/wayland arena, all working as expected AFAICT.

@salzix https://github.com/salzix

You taking the time to report issues like this, is already in itself of great help. As fixes like this tend to happen in real time as it were, you're basically left with three choices --- 1. wait for & test the next amiberry binary release, that contains the fix for this issue ... or ... 2. Become comfortable with compiling amiberry from the github sources, which gives you the opportunity to test any fix-ups, 'as they happen' so to speak (before the next binary is released). The latter case is of course often the most useful, as it gives you the chance to confirm the potential fix works as intended...wrt your usage & hardware setup case....and 3. you can always support midwan on his Kofi page, if you'd like to help that way...I know I do, any time I want to express a tangible thank you =^)

— Reply to this email directly, view it on GitHub https://github.com/BlitterStudio/amiberry/issues/1384#issuecomment-2233201214, or unsubscribe https://github.com/notifications/unsubscribe-auth/AA6MZJBCZFS4JQSGJEOCZALZMZPKHAVCNFSM6AAAAABK6DMLGCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMZTGIYDCMRRGQ . You are receiving this because you were mentioned.Message ID: @.***>

midwan commented 1 month ago

I've made some changes in the controller initialization (which was triggered multiple times), so this might already be resolved in the latest sources. But I cannot recreate it here anyway, so it's hard to say for sure.

@salzix If you can compile the latest sources (that would be the upcoming v5.7.4) and test it there, it would help verify if it's fixed or not.

giantclambake commented 1 month ago

@midwan -- I can only recreate it here in Preview from cmdline ~ I'll recheck as it may have something to do with whether or not there's an associated config.uae file...(although it does also happen if direct-loading a whdload.lha file, which infers the builtin controller config is being dropped)...

giantclambake commented 1 month ago

Actually, mis-statement ~ only evident when launching in console (KMSDRM) ; not evident launched from an xterm.

Further, invoking ./amiberry conf/somename.uae from an xterm, will pop the GUI with that config loaded -> hit Start to continue (or use -G or nogui switches to launch direct into emulation).

However, invoking ./amiberry conf/somename.uae from the console, sees the emulation start immediately using that config.uae (NO -G or nogui switch required)...kind of strikes me as wrong ;) ..... Preview/x86-64

midwan commented 1 week ago

Further, invoking ./amiberry conf/somename.uae from an xterm, will pop the GUI with that config loaded -> hit Start to continue (or use -G or nogui switches to launch direct into emulation).

However, invoking ./amiberry conf/somename.uae from the console, sees the emulation start immediately using that config.uae (NO -G or nogui switch required)...kind of strikes me as wrong ;) ..... Preview/x86-64

That's not the case when I'm testing here. It works exactly the same way, regardless if I started it under KMSDRM or X/Wayland.

midwan commented 1 week ago

I don't have the exact same setup here, but I tested the following setups:

Steam controller with dongle = works normally, both under X and under KMSDRM
XBox One with dongle = doesn't seem to be recognized at all in the system, so I can't really test (works wired though)

giantclambake commented 1 week ago

Had to retest this lot, as my supposition was correct wrt our problem child, the F12 key, was getting in the way, and tainting results. Now that #1401 is completed, the bad F12 behavior in tests is gone ~ however, loss of controller input after resuming from GUI is still apparent.

Tested with .... RPi4/bookworm/KMSDRM/Master and the following wired controllers....(I doubt wireless matters here)

Xbox 360 Controller RetroFlag Wired Controller USB gamepad //same SFC pad I sent you Gasia Co.,Ltd Game Controller for Android

Test 1: ./amiberry StuntCarRacer_v1.3_0222.lha --title boots to game menu screen, controller works in game, F12 , controller works in GUI, F12 to return to emulation ---controller input no longer works in emulation, but kbd inputs do work. Hitting the F12 key to enable GUI again, and controller still works in GUI. Press Resume instead to return to emulation, same result -- controller input not working.

Test 2: -launch amiberry, GUI->Quickstart->WHDload auto-config: -> select StuntCarRacer_v1.3_0222.lha -->Start --title boots to game menu screen, controller works, F12 , controller works in GUI, F12 to return to emulation ---controller input no longer works in emulation, but kbd inputs do work. Hitting the F12 key to enable GUI again, and controller still works in GUI. Press Resume instead to return to emulation, same result -- controller input not working.

Test 3: --launch amiberry, GUI->Quickstart->select AmigaTestKit.adf in DF0: --> Start --test keyboard/joystick/mouse inputs working -> F12 , controller works in GUI, F12 to return to emulation ---sames results as above -- returning to emulation, kbd & mouse work, but controller input not working.

This wouldn't happen to be something to do with https://github.com/BlitterStudio/amiberry/commit/8bf3de79d5999394dfe485262149b303050b9d05 would it? Perhaps one of the input (re)initialization steps we climbed over there, is causing this?

midwan commented 1 week ago

whoops, I can recreate this now. Will get this fixed before the next release.

midwan commented 1 week ago

@giantclambake it doesn't seem to be related to the above commit, as from what I can see, it doesn't even pick up the button event at all. This still works fine under X, only happens under KMSDRM.

It may be losing the input altogether, and failing to grab it when it returns to the emulation screen. I've had a few cases where even keyboard input stopped working.

midwan commented 1 week ago

The problem is caused by having multiple windows under KMSDRM. It seems that somewhere along the way of switching from one window to the other (GUI to emulation), SDL loses the input focus (?). Not sure exactly why at this point, and this doesn't happen under X, so it was not detected sooner.

If I change the window handling to only use a single window between emulation and GUI under KMSDRM, the issue seems to be resolved.

midwan commented 1 week ago

This is hopefully fixed in preview now. Please test and verify if it works properly on your end as well, so I can merge things to master before the next release.

giantclambake commented 1 week ago

Retested all 3 scenarios using RPi4/bookworm/KMSDRM/Preview (current) ~ this seems to be fixed now wrt game-controller input, which now works as expected when using F12 to return to emulation.

@midwan -- can you merge this into Master please, I need recheck something(*) against that branch.

(*)...towards the bottom of #1401 I make note of some odd behavior wrt Correct Aspect Ratio when toggling between emulation & GUI using the F12 key. I had thought this was something to do with the NV driver/G-Sync monitor setup on my 'main' system, but just now testing this, I see Correct Aspect Ratio is doing something similarly wrong when enabled, using Preview on the RPi4 in KMSDRM mode....I need to check if it's evident or not in Master after this fix.

midwan commented 1 week ago

@giantclambake Merged into master

giantclambake commented 1 week ago

@midwan Confirming that fix against Master

...there is some bug wrt Correct Aspect Ratio as mentioned ~ I'll need investigate it further....

BlitterStudio / amiberry

Xbox 360 wireless controller stops working after returning from menu to game #1384