Menu-Screen Problem since amiberry v5.7.2

[Retro1968]

System: Raspberry Pi 4B. Problem exists with amiberry on RaspiOS 64 Bit and RetroPie.

Hello Dimitris, first of all, i thank you for your consistently reliable work for the excellent amiberry project! 👍

I have the following problem since amiberry v5.7.2. I am currently using amiberry v5.7.3.

I use a 4:3 monitor. In amiberry I set a resolution of 800x600.

Since amiberry v5.7.2. I have the problem as soon as I go into the Amiberry menu using the F12 key that the screen keeps "wobbling" there, as if there were difficulties fitting the screen into the 800x600 resolution. I have also experienced under retropie that sometimes F12 led to amiberry crashing immediately. But when you are in the menu with F12, the screen keeps wobbling.

I am attaching my configuration file. Please test with a 4:3 monitor in 800x600. conf.zip

[giantclambake]

I just tested Master/debian bookworm/RPi4B -- there seems to be an issue here, but AFAICT it has to do with Fullscreen mode.

Could you try something please? Instead of using Fullscreen and setting 800x600, try Full-window (it will default to 800x600 and appear fullscreen), and see if things work properly like that?

[Retro1968]

As you can see on this unsharp photo the menu screen now appears as a small windows on the workbench. Using RaspiOS 64 Bit.

[giantclambake]

Okay, thank you ~ that coincides with my results here (I don't have a RetroPie setup ;) You can use that approach as a work-around perhaps, until this gets looked at?

@midwan I can recreate this here in Preview/x86-64 ... looks like (yet another) machination of the F12 <-> GUI reticence, but this case of having Fullscreen mode selected, was possibly overlooked (certainly was by myself ;), as we tend to avoid Fullscreen and use Full-window instead (due to oddities with Fullscreen etc et al)

To recreate: launch amiberry, GUI -> Display -> select Fullscreen (Res. doesn't matter) --> Start //just need kickstart

Once kickstart loads, try hitting F12 to pop GUI ...releases mouse, flips and pops emulation window to front again (if you alt-tab at this point, GUI will appear). Same thing on the RPi4 with 5:4 display & Master.

I seem to recall you mentioning long ago, the thought of dropping Fullscreen mode altogether had floated to the top once or twice. I tend to agree in a lot of ways, considering Full-window does present itself as fullscreen anyhow, and the fact it pops WM decorations as well as the GUI (with emulation window paused in the background) when F12 is hit, I sort of like =) Food for thought... not sure about the 'wobble' description (might be retro-pie related on top of this issue?)

HTH

[midwan]

I can only guess the "wobble" mentioned is regarding the resolution change on the monitor? If it's doing a re-sync, it might show some kind of effect like that (but in that case, it's caused by the monitor).

I'm not sure Fullscreen mode is very useful in this way also, considering the issues it causes. I'll have to think about removing it and only leaving Full-window (which is essentially Borderless window, scaled to full screen), instead.

[giantclambake]

//...at least this new monitor lets me poke at stuff like this pretty easily ;)

Jelly wobbles, it can also be described as 'shakes' ...the latter is more what I see, in that moment of indecision just after hitting F12 ... (as a language, English is very bad for this =). but as you say it might be the display hardware trying to figure out what to sync to....because...

...the actual problem here, is that the GUI window is somehow inexorably linked to the current resolution of the Xdisplay from which it was launched, regardless of what resolution the emulation is started at with ie; Fullscreen/800x600. If in emulation like that and you hit the F12, the GUI window is still in the native Xdisplay resolution...ie; 1280x1024_60 ...so when you hit F12, effectively it's trying to do this....

...which won't happen without Alt-Tab, Maximize window, because WM (ymmv there) ~ either way you look at it, it's one of the GUI not starting in/switching to Fullscreen mode...OR....when in Fullscreen mode (emulation) and the F12 key is pressed, the GUI should switch to Full-window mode @ the same resolution the emulation is at (not the desktop resolution)....and by the time you get to that point, one has to question if there's any actual usage case, for which Fullscreen mode is absolutely required?

I don't know that answer, but if not, having Fullscreen mode is always going to invoke the Xserver to change screenmodes (which is annoying) and not having it.... in essence... fixes more things than it breaks I think (especially if there's no absolute requirement to have any Fullscreen mode)

[Retro1968]

I can only guess the "wobble" mentioned is regarding the resolution change on the monitor? If it's doing a re-sync, it might show some kind of effect like that (but in that case, it's caused by the monitor).

I'm not sure Fullscreen mode is very useful in this way also, considering the issues it causes. I'll have to think about removing it and only leaving Full-window (which is essentially Borderless window, scaled to full screen), instead.

This assumption is not plausible to me, as I had no problem with the fullscreen until version 5.7.1.

[giantclambake]

@Retro1968 -- If as you say you're using Fullscreen mode @ 800x600, exactly how does Full-window mode (800x600) negatively impact your usage of amiberry?...ie; does using Full-window mode stop you from doing something? Or are you concerned about the GUI size when in/using Full-window mode and tapping the F12 key?

[Retro1968]

The problem bothers me so much that I have reported it as a bug and will probably fallback to v.5.7.1 until it is fixed.

[midwan]

I can only guess the "wobble" mentioned is regarding the resolution change on the monitor? If it's doing a re-sync, it might show some kind of effect like that (but in that case, it's caused by the monitor). I'm not sure Fullscreen mode is very useful in this way also, considering the issues it causes. I'll have to think about removing it and only leaving Full-window (which is essentially Borderless window, scaled to full screen), instead.

This assumption is not plausible to me, as I had no problem with the fullscreen until version 5.7.1.

Ah right, I missed that part. I'll take a look at the changes between 5.7.1 -> 5.7.2 and see what could cause this, then.

[midwan]

It was the gfx-rewrite, which included the multi-window code from preview. This won't be going back, so one possible solution would be to remove/replace Fullscreen mode with Full-window instead.

That is, assuming Full-window works fine in these conditions. @Retro1968 can you confirm that is the case, please?

[giantclambake]

Yeah, I traced it back to 070e193 as well (specifically gui_renderer), but for the life of me I can't find any instance wherein I actually need Fullscreen mode (as opposed to Full-window mode) ; both modes seem functionally equivalent.

I did think that (perhaps) the GUI presenting itself somewhat smaller in Full-window mode may have caused some contention (hence my question above), but one can address that in amiberry.conf by using the window_scaling= param (1.2 to 1.4 works best)....

...elsewise, I cannot discern a need for Fullscreen mode really.

[Retro1968]

It was the gfx-rewrite, which included the multi-window code from preview. This won't be going back, so one possible solution would be to remove/replace Fullscreen mode with Full-window instead.

That is, assuming Full-window works fine in these conditions. @Retro1968 can you confirm that is the case, please?

I am at the moment very busy an try later. What i do not understand (maybe my english is too bad) that you say the error wont go back. In v5.7.1 everything worked perfect for me. So it must be something you changed form v.5.7.1 to v.5.7.2. problems began with 5.7.2. It should be possible to fix that. :)

[midwan]

@Retro1968 No, I meant the multi-window changes are not going to be reverted, as they are quite extensive and I want to keep them, as it syncs the code between the branches.

Either we try to find the specific issue with full-screen mode under the scenario you had, or we skip fullscreen altogether and replace it with full-window. The second is easier, which is why I asked if that works OK for you.

[giantclambake]

@midwan

I had a deeper look at the goings-ons wrt the WM (XFCE4) ~ what I say above is true ; if you change the window focus settings in XFCE4 to calm it down....this works by setting the WM to give focus to Desktop the moment it appears, before the amiberry GUI window is spawn (in a different screenmode res)...

...in amiberry after hitting F12 results in this...

As far as the WM is concerned, the amiberry process has spawned 2 windows (amiberry, amiberry GUI), but it is the case that the 'amiberry' window is Fullscreen 800x600, but the 'amiberry GUI' window is @ 1280x1024. Due to the fact the window focus settings in the WM no longer trigger (the need) for a screen resolution change, the WM itself has inherited the 800x600 resolution (even though by default the desktop res is set to 1280x1024)....

...what I noticed was, when clicking on the amiberry menu-bar icon....

....the amiberry process itself, is indicating to the WM (bold italics) that the GUI window IS being presented as active ...although clearly, that is not the case ;) Ergo...this then becomes a window promotion thang, m'kay....but if you let the WM do that, it's going to flip screen resolution at the Xserver to do it, and so the amiberry process must promote the GUI window itself...we can do that.... GUI -> Miscellaneous --> GUI Always on top ...with that set, hitting F12 reliably does this...

User must remember to use F12/Resume to return to the emulation (not close the window itself =), and it effectively leaves the Xserver in the same screenmode resolution. For mine, that's a pretty gracious work-around here all things considered, but usual caveats apply...ie; RPi4B, debian bookworm, Master... and XFCE4 version 4.18 (it's improved a lot in recent releases)...probably works on this x86-64 rig as well...//two minutes later//...yeah, same on this box.... it's functionally identical more or less to the previous gfx code, it's just you inherit the WM window decorations at the same time (that somehow presents as 'sane' considering we are in an X environment ;)

Not sure how this pans out wrt other WMs... but wrt XFCE4 & RaspOS current, this seems to be the case for Fullscreen mode. Perhaps a 'borderless GUI' option (for the GUI window) could be of use here, however if you set the top menu-bar to always auto-hide, when you hit F12 it reliably pops GUI like this...

...that's pretty good IMHO...in fact, isn't that an awesome coincidence the window title bar overlaps the GUI itself in just the right spot...or ...did you see that coming? =) ... so that's 1 part amiberry (GUI Always on top) and 2 parts WM settings (short auto-focus, auto-hide panels) to get it like that ~ works as expected when amiberry is in Fullscreen mode. One could probably futz with WM height params wrt window title bar (there's about 5 pixels worth that could be trimmed from the bottom)..but again I'm waffling on about WM tweaks, not amiberry itself.

Ultimately, I don't see a problem here, more a case of changed behavior, as a corollary of the gfx rewrite as it were (didn't we touch upon this at some time...ie; how much was the WM's responsibility, versus how much amiberry had to do instead?)... something like that... or was this a valid case for GUI Always on top...I cannay recall =)

I'd leave alone =)

The GUI Always on top option can be used to promote the GUI (when invoked), when the WM itself doesn't know what to do when amiberry creates two 'windows' as it were, when each window is based upon a different display resolution. In turn, amiberry will display the GUI at the current display resolution setting, if GUI Always on top=True -- any WM decorations attached to the GUI remain (scaled), however this can be mostly controlled by the WM settings, to give the appearance of a fullscreen GUI.

HTH

[Retro1968]

I have now tried amiberry V.5.7.4 2024-08-07. (should i try that version?) I can live with it under RaspiOS 64 bit. Under RetroPi I still have the same problems even with the full Windows mode. F12 can still cause amiberry to crash. When the menu is there, the screen shakes. On both systems I compile with: make -j4 PLATFORM=rpi4-sdl2

[Retro1968]

Just tried it with v.6.3.4 preview 2024-08-06 on retropie and got there the same issues as with v.5.7.4 2024-08-07.

[giantclambake]

I believe you should be compiling with: make -j4 PLATFORM=rpi4-64-sdl2

[Retro1968]

I have to correct myself:

Certainly I compiled on RaspiOS 64 Bit with: make -j4 PLATFORM=rpi4-64-sdl2

Since RetroPi runs on 32-Bit Linux I compiled there with: make -j4 PLATFORM=rpi4-sdl2

;-)

[Retro1968]

This "screen shaking" (retropie) after pressing F12 for menue seems to me to be caused by the menu window and the workbench window "arguing" about which window should be displayed at the front. And that's why one window wants to come to the front and then the other. Also the options under Miscellanious: "Always on Top" an "GUI Always on Top" couldn't fix that.

@midwan i guess that you should give the menue window a higher (maybe the highest) priority to stay save always in front as long as the user press F12 to close it.

[giantclambake]

Thanks for testing ;) Considering that (more or less) we use the same hardware, and that I can't really recreate the shaking or wobbling effect, I'm going to suspect it's being caused by the retro-pie software itself, or the host OS version/libraries in use...ie; I've only tested against debian bookworm, no retro-pie. You'd have to test on that, on your system, using the retro-pie software to launch amiberry, and then compare result against just using amiberry standalone..(launched from an xterm)....

...'wobble' suggests to me the amiberry GUI changing between 720x568 <-> 800x600 constantly ... (so the 'shake' would be a measure of 80x32 pixels)...that's the only way I can visualize 'wobble'. In my stand-alone example above, it's definitely native display resolution (Xserver) being attached to the amiberry GUI (window), in conflict with the requested display resolution used for the emulation process in Fullscreen mode.

In theory, if you set your linux desktop resolution to 800x600, then launched amiberry with a config.uae file set for 800x600 Fullscreen, the Xserver shouldn't need to change display resolution, and things will work differently. (not a fix, just to test the situation ;)

[Retro1968]

I have emulated a whole range of retro systems under RetroPie. Therefore, I will not change any RetroPie system settings. I will be happy to try out what can be set there within Amiberry. However, the problem should be able to be solved if the window for the Amiberry menu is given a higher priority as i mentioned here https://github.com/BlitterStudio/amiberry/issues/1401#issuecomment-2295147440. I am pretty sure that @midwan will find a good solution. :)

[giantclambake]

@Retro1968 ~ I tortured the situation some more, and was able to coax this uncommanded behavior from amiberry, after pressing F12 ... https://www.youtube.com/watch?v=1RCr-TVpyZk ...is that anything like what you're seeing?

[Retro1968]

@Retro1968 ~ I tortured the situation some more, and was able to coax this uncommanded behavior from amiberry, after pressing F12 ... https://www.youtube.com/watch?v=1RCr-TVpyZk ...is that anything like what you're seeing?

Yes that is nealy the same that happens here. With the different that i use a 4:3 Monitor :) Such a nice video i could watch it for hours. ;)

[midwan]

@Retro1968 ~ I tortured the situation some more, and was able to coax this uncommanded behavior from amiberry, after pressing F12 ... https://www.youtube.com/watch?v=1RCr-TVpyZk ...is that anything like what you're seeing?

Thanks for the video. That seems like an interesting situation. Both windows are open, but SDL2 (under KMSDRM only) seems to be flicking from one to the other then. I think this needs some kind of special handling for KMSDRM, it might even be a bug in SDL2 (not sure). We'll see what we can do.

[giantclambake]

@Retro1968 ~ thanks for confirming, it took some time testing to be able to find what you were referring to ... the 4:3 displays are in another room connected to my A1200 and voodoo2 PC, so 5:4 had to do (but it does 50Hz modes =)

@midwan

As noted, I had to edit /boot/cmdline.txt to append video=HDMI-A-1:800x600M@60, to get the console into the same mode as the config.uae specified (Fullscreen 800x600), to be able to create the problem. I believe I had 'GUI Always on top' enabled at the time.

Doing the same test using the default EDID mode of 1280x1024@60, I had a couple..nay, few instances of both the amiberry GUI and emulator 'disappearing' after hitting F12 to return (Resume) the emulation, only showing the console and no KBD input (mouse was still there but did nothing) ~ had to ssh in to find amiberry consuming 98+% CPU, kill the process, nothing in amiberry.log. This could likely be related...ie; if it's doing this in the vid when console modes are the same, could be it's trying to do the same thing with different modes and ends up in a deadlock?

In x11 it's the same but different...as windows don't make a lot of sense on the console ;) I eventually discovered that when SDL creates a window, that also establishes a lock in Xlib, and it's this, not so much the resolution/screenmode difference, that dictates what's going on...ie; if you set desktop display to 800x600@60, it still behaves the same way.

You can work around it as per above, using 'GUI Always on top'...and you don't need change the focus settings in the WM, but hiding the panels is worthwhile. I actually believe in x11 this is working properly, it's just that in the x11 case, you must enable the 'GUI Always on top' option, for the F12 key to pop the GUI when using Fullscreen modes.

[midwan]

@giantclambake Please check with the latest preview after the commit above?

[giantclambake]

@midwan That commit fixes the issue as exampled in the video above ~ I tested with KMS at default EDID (1280x1024), and with the videomode forced to 800x600, and the F12 key action reliably pops/toggles between emulation and GUI screens. I would imagine this fixes the OP's original issue AFAICT...(caveat OS differences & retro-pie environment).

...however, in doing these tests I did stumble upon the trigger that causes both the emulator & GUI windows to 'disappear' and leave the console visible...this is really nasty BTW, because it actually kills the keyboard input to the console altogether (killing the amiberry process does not restore kbd input)...

..the trigger is the cmdline invocation... ./amiberry -f conf/de.conf -G .... if at the console I launch like that, I can hit F12 and the GUI will appear, but after changing anything and hitting F12 again to resume emulation, kbd input is lost and neither amiberry GUI or emulation is visible, and you're headed for a machine reboot to clean up.

Conversely, if you just launch ./amiberry and then load/start (or double-click) on the 'de' entry in Configurations, once the emulation has started, you can use F12 to toggle between GUI/emulation and it all works as expected. (the de.uae file is just base config + Fullscreen 800x600 options)

[midwan]

@giantclambake Was this behavior something new after the above commit, or was it there before also? I need to know where to look... :)

[midwan]

For the record, I cannot recreate the above issue, when using that syntax in general. Does it always trigger for you? Maybe more details are needed.

[Retro1968]

As the headline says... it started with v5.7.2. v5.7.1 do not have that problem.

[midwan]

@Retro1968 I was referring to the issue @giantclambake mentioned, after the commit above. The main issue you mentioned should be resolved now, but I wanted to see if the other one mentioned there is related or not. I cannot recreate it here, at least.

[giantclambake]

@midwan

Problem was there before the commit, so this is a secondary issue. I can reliably recreate the problem. See attached logfiles...

amiberry.log.gz ---> command used ./amiberry -f conf/de.conf

You can see in the log that I pressed the F12 key a total of 10 times to toggle between emulation & GUI --> works as expected, quit amiberry.

amiberry-bad.log.gz ---> command used ./amiberry -f conf/de.conf -G

You can see in the log that I pressed the F12 key once to pop the GUI --> then pressed F12 again to dismiss GUI and return to emulation. Doesn't happen, leaving me at the console from which cmd was launched (flashing cursor), no KBD input ---> ssh to machine to kill amiberry process. No input from KBD thereafter.

So it seems to be something related to the -G switch .... maybe 1d05611 ?

amiberry.log.gz amiberry-bad.log.gz

[midwan]

@giantclambake I still cannot recreate this here however, using a similar approach under KMSDRM (on RPI5 running bookworm): ./amiberry -f conf/A4000.uae -G works fine for me, no matter how many times I switch from GUI to emulation and back. So, I don't think there's a generic problem with -G, otherwise I should be able to see it here as well.

There must be some other thing that triggers this.

[giantclambake]

@midwan Thanks for checking ~ all things considered, the obvious difference would be the config.uae -- retried with a different config.uae file (AmigaTestKit), and it does indeed work correctly.

Turns out the config.uae file being used prompted the behavior -- it does not specify any bootable media, it just boots to the KS-1.3 insert disk hand (kickstart ROM init). I suspect in this emulation state, kbd & mouse aren't actually used (sans reset sequence), and things become unhinged handing these devices back to the emulation?

The fact it doesn't display this behavior and works normally without the -G switch is not making sense to me. It seems if the GUI is allowed to be started first, then start the emulation, it works as expected --- it's only when GUI is skipped and launched straight into emulation the problem happens.

I would doubt this is typical usage as such ~ user may actually stumble into it, if they load a config.uae file, but they have moved the bootable media to a different location ; in that case it would just do kickstart ROM init and the user would likely end up at this impasse..with KMS....that's about the only way a user could 'accidentally' trip this.

de.uae.gz

[midwan]

@giantclambake Thanks, I managed to recreate that now - it doesn't even need a config, it also happens under KMSDRM if you use --model A1200 -G for example.

[midwan]

@giantclambake Should be fixed now - please verify when you get a chance.

[giantclambake]

@midwan Retested all scenarios ~ seems to be fixed now... F12 working correctly with KMSDRM (irrespective of console videomode & emulator Fullscreen mode)...

...in x11 when using Fullscreen mode, the option GUI Always on top must be enabled for the F12 key to work correctly (as explained above). The Full-window mode works as before, and does not require GUI Always on top to be set for F12 to work as expected.

I'd call that completed ~ as always, thanks for the fix-ups =)

[giantclambake]

Footnote: I had tested the above using RPi4/Master, and m93p Tiny/Preview to cover off x86-64 ~ everything worked as expected on both branches/platforms.

I just retested on this setup using Nvidia drivers and G-Sync display. Same test in x11, hitting F12 does pop the GUI (GUI Always on top is enabled), however it's scaled entirely wrong, with about half the GUI hidden at the top.

If then I click just outside the GUI surface to the left or right, the GUI immediately resizes/updates and is usable as in the tests....that is saying, clicking inside the GUI area at first is ostensibly useless ; you have to click just outside it for the GUI to refresh/resize, before it becomes usable.

I'll need dig into it some, to see if it's just an NV driver thing ; I'll hoist another ticket about this if I find anything wrong that's not NV driver related ;)

[Retro1968]

@Retro1968 I was referring to the issue @giantclambake mentioned, after the commit above. The main issue you mentioned should be resolved now, but I wanted to see if the other one mentioned there is related or not. I cannot recreate it here, at least.

So the screen problem is solved. Thanks for that :)

However, I experience an amiberry crash when I leave the menu with the "Resume" button under RetroPie with amiberry v5.7.4 (2024-08-24).

[Retro1968]

Footnote: I had tested the above using RPi4/Master, and m93p Tiny/Preview to cover off x86-64 ~ everything worked as expected on both branches/platforms.

I just retested on this setup using Nvidia drivers and G-Sync display. Same test in x11, hitting F12 does pop the GUI (GUI Always on top is enabled), however it's scaled entirely wrong, with about half the GUI hidden at the top.

If then I click just outside the GUI surface to the left or right, the GUI immediately resizes/updates and is usable as in the tests....that is saying, clicking inside the GUI area at first is ostensibly useless ; you have to click just outside it for the GUI to refresh/resize, before it becomes usable.

I'll need dig into it some, to see if it's just an NV driver thing ; I'll hoist another ticket about this if I find anything wrong that's not NV driver related ;)

Good idea. Thx for testing Mate!

[giantclambake]

@midwan I found what's responsible for the errant behavior here-above wrt widescreen G-Sync monitor - Correct Aspect Ratio

If Correct Aspect Ratio is set, after hitting F12 the GUI opens scaled too big vertically ~ if I nudge mouse-pointer to top of screen, the GUI immediately resizes and is usable.

Conversely, if Correct Aspect Ratio is unset the GUI opens at the correct size, and follows the examples above.

This seems like a different issue to me, and not really related to this ticket....do you concur?

[giantclambake]

However, I experience an amiberry crash when I leave the menu with the "Resume" button under RetroPie with amiberry v5.7.4 (2024-08-24).

@Retro1968 ~ does it crash if you use the F12 key instead to resume emulation?

[Retro1968]

However, I experience an amiberry crash when I leave the menu with the "Resume" button under RetroPie with amiberry v5.7.4 (2024-08-24).

@Retro1968 ~ does it crash if you use the F12 key instead to resume emulation?

Yes, even exiting the menu with F12 causes amiberry to crash.

[giantclambake]

@Retro1968 ~ I can't recreate any crash here... is this on your 32bit or 64bit OS install? (both??)

[Retro1968]

RetroPie runs on 32-Bit Linux

[Retro1968]

Didnt checked it on RaspiOS 64 Bit.

[midwan]

The latest commits that fixed #1411 could possibly help with the crashes on RetroPie also. If the crashes were due to the old SDL2 version and KMSDRM, these latest fixes change the behavior to something similar that the older versions had (using a single window, when KMSDRM is detected), which could potentially solve this issue as well.

Either way though, RetroPie needs to upgrade from Buster sooner or later, as it's out of support. I suspect that when that happens, since a newer version of SDL2 will come with it, many such issues will resolve themselves.

After the next release comes out, I'll spend some time with the teams of RetroPie, Batocera, Knulli and MuOS, to help them bring this latest version to their distros in the best way possible.