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

[midwan]

@giantclambake
Does the commit above fix it for you?

[giantclambake]

Amiberry is no longer starting, be it double-click on config entry, or select->load->start....

...I'll attach logfile, but this is in trixie so I gotta check bookworm...

...not sure of the problem, but it seems to still work with floppy images, not a HDD setup...

amiberry.log.gz

[midwan]

You have an exception thrown when running 68k code. This looks irrelevant to the above commit, which only affects the GUI.

[giantclambake]

Yeah.... that'll take some finding.... but anyhow...

Testing against debian bookworm. same issue is still apparent ~ no change

Same for trixie (I can avoid the crash using floppy based config.uae and double-clicking on that) -- same issue is still apparent ~ no change

[giantclambake]

To reiterate, the above commit does not fix the MMB release issue...

You have an exception thrown when running 68k code. This looks irrelevant to the above commit, which only affects the GUI.

Oh, I agree, shouldn't have anything to do with it ~ on debian trixie, I rolled back to the v7.0.1 source release, where it's not crashing -- using the same config.uae, I get the following trace in logfile...

05-267 [7 067: FS: mounted HDF unit DH4 (0000-1f400000, /home/gcb/Amiberry/harddrives/hdf/CWB-P96.hdf)
05-267 [7 067: Partition 'DH4' Dostype=444F5301 (DOS\1) Flags: 00000000
05-267 [7 067: BlockSize: 512, Surfaces: 1, SectorsPerBlock 1
05-267 [7 067: SectorsPerTrack: 32, Reserved: 2, LowCyl 0, HighCyl 31999, Size 500M
05-267 [7 067: Buffers: 50, BufMemType: 00000001, MaxTransfer: 7fffffff, Mask: ffffffff, BootPri: 0
05-267 [7 067: Total blocks: 1024000, Total disk blocks: 1024000
05-267 [7 067: First block 0 dostype: 444F5301 (DOS\1)
05-267 [7 067: RDB: fakefilesys, trying to load '/home/gcb/Amiberry/roms/FastFileSystem', dostype 0x444F5301 (DOS\1)
05-267 [7 067: RDB: filesys not found, mounted without forced filesys
05-267 [7 003: Mounting uaehf.device:0 1 (0):

Using current master (where it is crashing), that same section of logfile reads....

05-675 [8 001: FS: mounted HDF unit DH4 (0000-1f400000, /home/gcb/Amiberry/harddrives/hdf/CWB-P96.hdf)
05-675 [8 001: Partition 'DH4' Dostype=444F5301 (DOS\1) Flags: 00000000
05-675 [8 001: BlockSize: 512, Surfaces: 1, SectorsPerBlock 1
05-675 [8 001: SectorsPerTrack: 32, Reserved: 2, LowCyl 0, HighCyl 31999, Size 500M
05-675 [8 001: Buffers: 50, BufMemType: 00000001, MaxTransfer: 7fffffff, Mask: ffffffff, BootPri: 0
05-675 [8 001: Total blocks: 1024000, Total disk blocks: 1024000
05-675 [8 001: First block 0 dostype: 444F5301 (DOS\1)
05-675 [8 001: RDB: fakefilesys, trying to load '/home/gcb/Amiberry/roms/FastFileSystem', dostype 0x444F5301 (DOS\1)
05-679 [8 001: An exception was thrown while running m68k_go!
05-679 [8 001: hdf_close_target

'For some reason' in current master , the logfile reveals RDB: filesys not found, mounted without forced filesys is missing in the crash-log, which at a guess is a clue to why m68k_go is hurling biscuits (no filesys associated with .hdf file?)

HTH

[giantclambake]

Additional: I'll recheck, but wrt the trixie crash, git bisect says...

5c193405f8e8d878c769a37b06cd3b2b30e46b14 is the first bad commit

edit: rechecked, same result ~ the above commit somehow unravels .hdf loading on debian trixie -- oddly enough, whdloading seems unaffected, and CD / floppy image loading are still working as expected.

[giantclambake]

Ugh...this is broken in debian Bookworm 12.9 wrt .hdf loading as well, so not just trixie ...

[midwan]

Seems like you're loading a hardfile with RDB info?

Is that the normal ClassicWB HDF? I think I have it around somewhere.

[giantclambake]

Not making sense here ~ I get the same git bisect result and error in m68k_go on debian 12.9.... and no, I'm not loading RDB info.... also, I cannot save a config.uae file, with .hdf files setup -- clicking on Save in configurations panel causes amiberry to bail abruptly...

[midwan]

@giantclambake there was a bug in the zfile changes I made recently, fix incoming...

[midwan]

Should be fixed with 30752bb

[midwan]

And for the record, I still cannot recreate the original issue on RPIOS here.

[giantclambake]

Should be fixed with 30752bb

Confirmed, no longer crashing when using .hdf files ~ I circled back and rechecked #1611 ... still good there, so we can finally put that one to rest me thinks... thanks ;)

And for the record, I still cannot recreate the original issue on RPIOS here.

Perhaps I would concur if I was testing on RPi hw with RPIOS ....but I'm not of course ~ I'm testing with debian bookworm 12.9 on x86-64, and debian trixie (testing) on amd64 ...maybe you should test against the same hw/OS type...(the platforms are markedly different ;)....

...that bug gave me pause to refine the test case here, and remove a lot of variables....

• Launch amiberry, GUI -> Configurations panel --> enter a Name: (ie; mmbtest) ---> Save ----> Quit amiberry (this is our test case, you only need boot kickstart to recreate the issue)

• Launch amiberry, GUI -> Configurations panel --> select mmbtest entry ---> Load ----> Start emulation

Wait for kick-1.3 insert disk screen -> MMB --> move mouse pointer outside emulation window, and click on desktop..

Result: works as expected, clicking on desktop grabs mouse focus and emulation window no longer 'active'

Quit amiberry....

• Launch amiberry, GUI -> Configurations panel --> double-click on mmbtest entry ---> emulation starts immediately

Wait for kick-1.3 insert disk screen -> MMB --> move mouse pointer outside emulation window, and click on desktop..

Result: emulation window 'steals' mouse the moment you click on desktop

Note: as above, removing changes associated with 7840919 and the issue is no longer present

HTH

[midwan]

I did a fresh round of tests:

• Debian12 (GNOME)
• Ubuntu 24.10 (GNOME)
• MacOS 15.x
• RPIOS Bookworm (XFCE)
• Fedora (GNOME)

I cannot recreate the problem, following your steps, in any of those.

[giantclambake]

Thanks for checking ~ I'll redo some tests here (I use XFCE exclusively), hopefully I can find the actual trigger...

[giantclambake]

Ahh.... could be xorg versus wayland ~ which were you using?

edit:

Confirmed on debian 12.9 using Gnome .... not installed, so sudo apt install gnome ...and that's when I noticed it was pulling in XWayland.... using the DM, one can choose between having Gnome on Xorg or Wayland...

• Gnome on Xorg //MMB issue is present

• Gnome on Wayland //MMB works as expected

Can you confirm?

[midwan]

• Debian12/GNOME -> X11
• Ubuntu24/GNOME -> X11
• MacOS 15 -> cocoa
• RPIOS/XFCE -> Wayland
• Fedora/GNOME -> Wayland
• CachyOS/KDE -> Wayland

There must be some other detail?

[giantclambake]

Hmmm..... try debian12/XFCE/X11 on x86-64?

[midwan]

Actually, the system back-end seems to be Wayland on Debian12, but SDL2 defaults to X11 - probably due to the known issue that we have in the wiki. I can try changing the priority to let it prefer Wayland, instead.

[midwan]

Changing SDL2 to Wayland did not change the behavior - it still works as expected for me.
The only difference is that now I get a warning on startup, that the application is trying to inhibit shortcuts (and if I should allow that or not), which again is expected.

[midwan]

I managed to recreate it under one scenario only:

• Debian 12, XFCE, X11

It seems that selecting XFCE uses X11 as the system compositor as well, in contrast with the other configurations, which prefer Wayland.

Additionally, if you do a left click inside the emulation after it has started, then releasing with the middle button does not cause the unexpected behavior either.

Not really sure where the problem is here, but it smells like an external bug (most likely something in x11?).
Considering things are moving to Wayland anyway, perhaps this is a non-issue in the end?

[giantclambake]

Thanks, just goes to show how elusive some bugs can be...(trust me to find the one scenario where this is an issue ;)

It seems that selecting XFCE uses X11 as the system compositor as well, in contrast with the other configurations, which prefer Wayland.

That would be the case ~ I've been loosely following XFCE development wrt wayland & friends, and that's the current situation afaik....

Additionally, if you do a left click inside the emulation after it has started, then releasing with the middle button does not cause the unexpected behavior either.

Confirmed --- MMB & RMB are mapped in XFCE to Workspace selector/paste & Menu list respectively -- hitting LMB (select/hold) before MMB in emulation, does release as expected....hard to say if it's X11 or within XFCE itself.

In any event, we now know what & where this issue is, and seemingly nobody else but me has run into it.... you get that ;) Like you say (and as I know wrt XFCE), linux desktop is headed for Wayland anyhow, so it's probably a non-issue ...given the fullness of time.

All things considered, I'll close this for now ~ if it rears it's ugly head in the future, we can open it again...

Kudos for spending time checking this, and having faith that I wasn't being stupid...lol B^)

[giantclambake]

Addendum: I went back to the LFS box, to fix problems that I'd caused and to see why the amiberry GUI was being so slow ~ turns out it was the SDL2_ttf v2.8.4 build behaving badly --- SDL2-2.30.6 I left in place, and recompiled amiberry, and that fixed the slow GUI issue. Alas, the MMB issue was still apparent...

That would infer it is indeed an X11 issue of some kind (not debian nor XFCE... the LFS system uses IceWM), and that SDL2-2.30.6 still works fine. The problem is still evident however, which infers something in X11 is responsible ~ so I agree the blame lay there somewhere, but as X11 is on the way out, it's not worth the effort/trouble to fix =)