Query: MMB does not release correctly when starting emulation by double-clicking on entry in Configurations panel?

[giantclambake]

This has been annoying me for a little while ~ just looking at it closely now, I believe the ticket title is correct (I had to double check that WM settings weren't at play)...and digging into this, I note the issue is not apparent when using floppy images or whdload.lha titles ~ it only manifests itself when a HDD based emulation is running... so I'm thinking bug?

To recreate:

• Launch amiberry, GUI -> Configurations panel --> select/load a HDD based config ---> Start emulation
• Allow emulation to boot to Workbench --> MMB //releases mouse, but emulation window still has focus
• Move mouse pointer outside emulation --> click on Desktop background

Observation: emulation window 'steals' the mouse back... follow on...

• Now that the emulation window has 'stolen' the mouse back, hit MMB again //releases mouse, but emulation window still has focus
• Move mouse pointer outside emulation --> click on Desktop background

Observation: Now it works as expected, with Desktop receiving focus as the emulation window loses focus.

Expected: MMB to release mouse pointer and emulation window, upon the first use of MMB (no repeated step)

I've attached the config.uae file used, so you can check the emulation setup.

Can this be fixed? It's annoying and really catches one out ;)

TIA

3000.uae.gz

[midwan]

I cannot recreate this, tried with both native modes and RTG modes.
WHDLoad titles are also HDD-based setups, btw.

[giantclambake]

Likely a bug then ;) .... visual demonstration using above 3000.uae config...

https://www.youtube.com/watch?v=reyTD-hNWOw

edit: I can recreate this on the LFS box as well, so it's not nvidia drivers, WM ... it's not something inane like moving the mouse pointer up (towards top) that triggers it?

[giantclambake]

Looking at this again, I found a slightly different approach that obviates what I'm referring to...

• Launch amiberry, GUI -> Configurations panel --> select/load a HDD based config ---> Start emulation
• Allow emulation to boot to Workbench --> MMB //releases mouse, but emulation window still has focus
• Move mouse pointer outside emulation
• Click RMB -- even though mouse pointer is outside emulation window, it's still 'connected' to emulation //workbench menu active
• Click LMB -- emulation window steals focus //mouse was not moved
• Click RMB again -- still 'connected' to emulation //workbench menu active
• Click MMB again -- releases mouse, but now it's 'inside' emulation window //mouse was not moved

To me, it looks as though the emulation is not tracking Host mouse position properly ...ie; it doesn't consider mouse pointer has moved outside emulation window?

https://www.youtube.com/watch?v=v9KgjS8sH2A

[giantclambake]

Digging this further, running a Save State created from the same 3000.uae config, works as expected ~ unlike test above, MMB releases mouse pointer from emulation window, and RMB is disconnected from emulation ...LMB works as expected, and does not get stolen back by emulation.

[giantclambake]

Final sanity check -- amiberry --config 3000.uae -G works as expected, with MMB releasing properly...ergo..

Problem is only apparent when starting emulation from the GUI.

TIA

[giantclambake]

Ah-ha! I found another machination here ~ I can't help but think this is the same bug?

To recreate;

• Launch amiberry, GUI -> Configurations panel --> select/load a HDD based config ---> Start emulation
• Allow emulation to boot to Workbench --> hit the F12 key.... //the Configurations panel is shown
• Click on the Display (or any other item) in the left GUI panel... //Note: nothing happens
• Click again on the Display (or any other item) in the left GUI panel... //Note: now the selected panel is displayed

This makes me consider that the mouse isn't being completely released from the GUI, when either the F12 key is used, or MMB is employed --- I can only imagine this is the same issue ie;.. first mouse click after using F12 or MMB, is not recognized as expected.

HTH

[midwan]

I still cannot recreate this in the environments I've tested it in: RPI-OS, WSL2, macOS.

I suspect it's related to the window manager or something else in the distro your testing with. I'll try it in more environments when I get a chance to see if that's the case.

[giantclambake]

Thanks ~ knowing what you've tested against helps clear a path forward for me...

...you should know by now, that my daily drive is debian current on amd64, where I first saw this issue ;)

...you'll see above I'd tested against the LFS build, and could recreate it there (so...IceWM not XFCE4, no debian...but still on x86-64, and in both cases x11 is used)....

....on the same hardware, I booted my USB stick build (based on CachyOS), and compiled/installed amiberry v7.0-RC3 there and retested the scenario -- this issue was not apparent there (using JWM and still on x11...this is Arch based)...working as expected...!!

...so... I followed that bread crumb ... there are so many differences between the 3 OS instances (but just as many likenesses), I think my time here has taught me to check the bleedingly obvious first.... (GUI -> About =)

debian Bookworm 12.6 -- SDL2 v2.26.5
LFS 11.3 -- SDL2 v2.28.5
CachyOS (Arch based) -- SDL2 v2.30.4

...."that is worth checking".... the LFS build lends itself to this ~ grabbed the SDL2-2.30.6.tar.gz (+ SDL_ttf-release-2.24.0 + SDL_image-release-2.8.4 just to keep in step), compiled and installed --- cleaned, recompile and install amiberry v7.0-RC3 against the newer SDL2 libraries ---> retest this issue ---> no longer apparent, now working as expected...well...

...not quite, the GUI is slow to the order of 1 to 2 seconds of lag to respond (emulation runs fine tho'), BUT, this MMB and mouse focus release issue no longer apparent after moving to the latest SDL2 offerings....(not sure why the GUI is being a dog....little doubt upgrading SDL2 libs with no regard of dependencies could be at play ; I'd need to back-track that locally to find the cause..)

BUT...right.... point is, that's all I did ('coz I can) -- move from SDL2-2.28.5 to SDL2-2.30.6, and recompile amiberry = issue no longer present... begs the question, SDL2 version is participle here?

HTH

[midwan]

WSL2 is Debian bookworm, so it uses the same SDL2 version you mentioned above: 2.26.5
macOS uses a newer version, as it comes from Homebrew: 2.30.x
RPI-OS is also based on Bookworm, and it uses v2.26.5 as well.

None of the above showed the problem to me :)

[giantclambake]

Thanks.... (although I don't particularly consider WSL2 in debian mode, to be a 'true' test of debian Bookworm ;)

I'll have to keep looking ~ at the end of the day, if nobody else runs into the on debian Bookworm amd64, then it's likely not going to effect anything....

...I took this instance from Bookworm -> Trixie and that didn't help any ....I guess I'm going to need use the m93p tiny, with a fresh debian Bookworm install, and see if I can nail this down =)

[giantclambake]

//...the good thing about living in the country, is you can go outside and scream ~ only the cows & goats look at you ;)

...this is mia culpa on my part ~ I had presumed that GUI -> Configurations panel -> select config entry -> Load ->Start was the exact equivalent to GUI -> Configurations panel -> double-click on a config entry to Start ... and I described the issue as I did ~ that was in error, I should have specified the procedure exactly ...

revised:

• Launch amiberry, GUI -> Configurations panel --> double-click on a config entry ---> emulation Start directly
• Allow emulation to boot --> MMB //releases mouse, but emulation window still has focus
• Move mouse pointer outside emulation --> click on Desktop background

Observation: emulation window 'steals' the mouse back...

This does not happen using the GUI -> Configurations panel -> select config entry -> Load ->Start route, it only manifests itself if you double-click on a config entry to 'quick load/start' the emulation...

...sorry for the confusion (I'm still serving penance taking the edges off Trixie and I've gotta revert changes in LFS..grrr.... ;)

[midwan]

Thanks for the extra information.
I'll have to re-test this then, based on the new findings. A quick test on macOS showed that it still works as expected (but since that's using SDL2 2.30.11 that's probably the expected result).

If this is fixed with a newer SDL2 version, it might indicate a bug there. But we'll see if there's a workaround, in that case.

[giantclambake]

This wouldn't be a throw back to #1316 by any chance?

[giantclambake]

I just confirmed my above speculation. Looking at src/osdep/gui/PanelConfig.cpp I construed it was safe to remove the if clause altogether....ie;

//              if (current_time - last_click_time <= 500)
//              {
                        if (emulating)
                        {
                                disable_resume();
                        }
                        target_cfgfile_load(&changed_prefs, ConfigFilesList[selected_item]->FullPath, CONFIG_TYPE_DEFAULT, 0);
                        strncpy(last_active_config, ConfigFilesList[selected_item]->Name, MAX_DPATH);
                        refresh_all_panels();

                        uae_reset(1, 1);
                        gui_running = false;
//              }
//              last_click_time = current_time;

Recompile and test ~ MMB release now works as expected (after starting emulation from double-clicking on config entry)

That would infer 7840919 is the actual cause here ~ perhaps that commit needs revisiting?

HTH