Window actions (like maximize) no more work in wayland for QEMU using GTK backend once the guest UI is intialized.

[Markus S]

Window actions (like maximize) no more work in wayland for QEMU using GTK backend once the guest UI is intialized.

This can be seen by running an installed or even a trial Ubuntu from an ISO like:

$ qemu-system-x86_64 \
  -boot d \
  -cdrom ubuntu-22.04.1-desktop-amd64.iso \
  -m 4096M \
  -machine type=q35,accel=kvm \
  -cpu host \
  -smp 2 \
  -device qxl-vga

The GTK UI of qemu has a feature called "fullscreen" which disables the screen decorations and sets the window to maximize. The decorations go away, but maximize doesn't work.

The following details were found so far:
- running with GDK_BACKEND=x11 works
- using sdl instead of gtk backend works
- using the old qemu of Focal, or the newest from upstream git in jammy all fails (no qemu change AFAICS)
- host UI widgets (the square at the window top) do not work either
- hotkeys (super-up) do not work either

It seems that once the guest has enabled the desktop something changes and the maximize/minimize/... actions are no more processed. Not sure were to debug next in regard to the gnome/wayland UI handling of this - any idea?

P.S. We can reproduce this in git builds of qemu, so we can debug of modify the code as needed. The code for this is mostly in [1]

[1]: https://gitlab.com/qemu-project/qemu/-/blob/master/ui/gtk.c

--- original report ---

Running QEMU version 4.2.1 on Ubuntu 20.04 via

qemu-system-x86_64 \
  -boot d \
  -cdrom ubuntu-22.04.1-desktop-amd64.iso \
  -m 4096M \
  -machine type=q35,accel=kvm \
  -cpu host \
  -smp 2 \
  -device qxl-vga

and pressing ctrl+alt+f after booting the Ubuntu 22.04 live ISO and adjusting the display resolution to match the native resolution, works as expected, i.e., the VM screen is correctly displayed in fullscreen.

However, after running the same command for QEMU version 6.2.0 on Ubuntu 22.04 and pressing ctrl+alt+f after making the resolution adjustment, yields a fullscreen view where the space occupied by the GNOME top bar (top panel with date in center) of the host is not used. The top bar itself is not visible but instead the purple background is shown where the top bar resides.

The problem also occurs when replacing '-device qxl-vga' by '-device VGA,vgamem_mb=64'. The problem however does not occur when using '-device virtio-vga'.

[Lena Voytek (lvoytek)]

Hello,

Thank you for the bug report. I attempted to reproduce the full screen issue but was unable to in Ubuntu 22.04. It's possible that the live ISO does not have all necessary drivers installed, causing this issue. Are you able to fully install 22.04 to test? Otherwise, can you share a screenshot of what this looks like?

[Markus S (qemvirt)]

The attached screenshot shows the problem when running the live ISO as described in the report.

[Markus S (qemvirt)]

The attached screenshot shows the problem after installing Ubuntu 22.04, updating and restarting the guest. I suspect that this is a problem of the host viewer rather than the guest because the issue is present in the GTK viewer (-display gtk) and not in the SDL viewer (-display sdl). Note that the host is Ubuntu 22.04 (QEMU version 6.2.0).

[Christian Ehrhardt  (paelzer)]

That is interesting, but also usually hard to debug (at least for me graphic issues always have the aura of mystery).
I was giving the same use-case a try so that we have more measurement points.
Installed the current 22.04.1 ISO in the default (minimal install, no customization) and set its resolution to the native one of my screens.

Then I booted that disk in different viewing modes to check how it behaves.

Display types:
- default: no display type specified (back in 20.04 it might have been sdl for you anyway)
- spice: -spice port=9999,disable-ticketing=on connect via spicy -h 127.0.0.1 -p 9999
- vnc: -vnc :1 connect via krdc vnc://127.0.0.1:5901
- gtk: -display gtk
- sdl: -display sdl
- virt-manager: sets up connecttions automatically, uses a spice based viewer

Driver QXL
- default - working fine
- spice - working fine
- vnc - working fine
- gtk - working fine
- sdl - working fine
- virt-manager - working fine

Well, I planned to go into other drivers, but since it works just fine with the reported driver I did stop here.
Hmm, we need to find what is different for you ... :-/

@markus - is this a one time thing for you e.g. right after the resolution change and goes away e.g. after a guest reboot or is it permanent? (to make sure we try to reproduce the same)

@markus - you said you set it to the native resolution of the screen - maybe it depends on that. I've used normal full-HD 1920x1080 what did you use?

@markus - For the sake of trying if there is a fix even thought we do not know which one. Would you be able to try the backport of qemu 7.0 from https://launchpad.net/~canonical-server/+archive/ubuntu/server-backports ?

[Markus S (qemvirt)]

Thanks for your elaborate comment and efforts, Christian. To answer your questions, the problem is permanent (not just after guest reboot), and the native resolution is 1920x1200.

Also, I would like to report some observations I made that indeed suggest that the issue is caused by my configuration. I booted the Ubuntu 20.04 and 22.04 live ISO images, installed qemu there and ran qemu with the options mentioned before with -display gtk in addition. In Ubuntu 22.04, I also installed the backport of qemu 7.0 and tried it. In all 3 cases, the problem does not appear, i.e., it is working fine.

I appreciate any hint about a which setting might cause the issue.

[Christian Ehrhardt  (paelzer)]

I tried 1920x1200 as well for the sake of trying, but that works here as well.

So it comes down to "what might be different on your original system that exposes the issue".
I was pondering about that for a few minutes, but nothing obvious comes to mind.
The next best two things to check are comparing the installed (and bad) system with the live iso environment (good) in regard to installed packages (dpkg -l) and anything that is in /etc.

And I said that graphic always is a bit of a mystery, but for a try some configurations are user dependent. You might create a second user, on first GUI-login that will initialize a new environment for gnome and all such. Is it working there, then you actually look for user (instead of system) specific config - I've seen such being an issue on old installs being upgraded by some old config value driving the code mad.

[Markus S (qemvirt)]

I would like to add some more observations. When running

qemu-system-x86_64 -display gtk,full-screen=on

or switching to fullscreen while the guest boot screen is active, the entire screen is used by qemu. Also, after moving the qemu window a bit, I realized that after pressing ctrl+alt+f, the "fullscreen" is merely covering the window itself. I did not notice this before because my side/bottom bar is hidden, i.e., the qemu window covers the entire screen except the GNOME shell top bar.

Running qemu in the guest (guest inside guest) interestingly results in the same problem.

[Markus S (qemvirt)]

Note that the bug has been reported here as well:
https://gitlab.com/qemu-project/qemu/-/issues/1423

[Christian Ehrhardt  (paelzer)]

Thanks Markus for the upstream report, I recommend retrying it with a build from upstream git for that report.
- If it works, bisect what was the fix so we can include it in ubuntu
- if it does not work, well that helps the upstream case

Furthermore after your update above I have tried various orders of resolution-set, screen-move, fullscreen actions - but never could reproduce it.
Maybe for prove and to remove any ambiguity consider taking a screen capture video to attach it here and in the upstream report?

[Markus S (qemvirt)]

Attached is a video that demonstrates the issue.

[Christian Ehrhardt  (paelzer)]

Thanks, I think my confusion is now gone.
I was lured by e.g. iso.png that you attached before that the top-bar would be at an offset or something.

Now I get what you describe, you are (correct me if I'm wrong) actually saying: "The output goes full-screen (guest screen now consumes all of the pane that the gtk app draws to) but the window does not go full-screen (the window doesn't consume all of the [host]screen, it is still at the same position it was before)."

Now that I know what to actually check for I've found that it also does in general "not behave", for example maximize does not maximize it to a screen. Nor do the hot keys for left/right half screen align it that way - it just stays "in place" as if all those would not mean anything to it.

Now that I knew that it isn't anything with the actual guest display or virtualization, but essentially just window behavior the first suspect to "behaves different in Jammy" is that the new default is wayland.

And the immediate "try this" worked like a charm.
Prepending GDK_BACKEND=x11 to the command like

$ GDK_BACKEND=x11 qemu-system-x86_64 -boot c -hda /tmp/ubuntu22.04-desktop.qcow2 -m 4096M -machine type=q35,accel=kvm -cpu host -smp 2 -device qxl-vga -display gtk

Makes it behave as expected.
Your view-fullscreen will work as you expect.
But also the minimize, maximize, left-half, right-half hotkeys work as expected for me now.

I need to try asking a few people that understand more of desktop/wayland to make suggestions how to fix this in the default mode.

[Christian Ehrhardt  (paelzer)]

Hmm, I might have been too fast.
While certainly X11/Wayland is in the game this really is only happening after the guest desktop has initialized.

E.g. a plain `qemu-system-x86_64 -display gtk` behaves always well and responds.
Only after the guest desktop is fully initialized it does no more go full/half/minimized.

I've used
- qemu 7.0 (from the backport PPA that I referred before) -> same issue.

Next I tried unmodified git based builds of most recent qemu (since you reported it there) v7.2.0 -> same problem

[Christian Ehrhardt  (paelzer)]

I've also built qemu 4.2 (which worked for you before) from git and ran it in jammy.
It also shows the same bad behavior.

So the issue wasn't introduced in qemu, but in the change to wayland or any other component around it.

[Markus S (qemvirt)]

Thank you very much Christian for the confirmation (upstream as well) and your further analysis of the issue. Your comment #12 (qemu-system-x86_64 -display gtk) is also reflected in my observation in comment #7.

I also appreciate your GDK_BACKEND=x11 ... workaround.

[Christian Ehrhardt  (paelzer)]

Sorry - so far there was no great suggestion how to continue from the Desktop people that I asked directly.
Let us hope that adding the Wayland task will make one look a bit deeper in a bit.

[Markus S (qemvirt)]

Christian, there seems to be one issue with your otherwise fine GDK_BACKEND=x11 ... workaround from comment #11. Trying to switch windows in the guest using Alt+Tab does not work regardless of being in fullscreen or not. Enabling input grab (Ctrl+Alt+G) makes the mouse cursor disappear in the guest.

Can you confirm this issue?

[Christian Ehrhardt  (paelzer)]

@Markus
Hi,
on one hand on today's retry I've found it to go fullscreen correctly (even without GTK_BACKEND=x11 set). The top bar moves up to the correct place. I wondered and looked more at is, so I found that "fullscreen" works more reliable if the guest resolution isn't matching the real screen resolution. Due to scaling it doesn't look as nice, but I've found same-resolution going fullscreen more likely to expose issues. When it is on the same resolution I still can sometimes see it dropping decorations but stay "in-place". It almost seems that it is confused by thinking "huh I'm already at the target size with my panel" and then does not to the scaling/maximization.

Seeing that I'm curious how this behaves on a single screen, have you ever had the chance to try this on a single screen computer?

Also have you seen that it works better when not using the native resolution of the display?

[Christian Ehrhardt  (paelzer)]

But now to what you actually asked about:
Using Grab-Input via CTRL+ALT+G worked just fine. I can use alt-tab to switch windows (without screen grab it would switch host windows as expected). The mouse pointer stays working and visible. I found that CTRL+ALT+G no more works for me while in fullscreen, so CTRL+ALT+G -> CTRL+ALT+F works while the other order does not.

Switching to GTK_BACKEND=x11 to check if I see the mouse pointer missing again.
As before - with this the min/max works better (even with the resolution matching the real screen). And yes, in this mode going into screen grab mode via CTRL+ALT+G makes the mouse invisible for me as well.

Which is again a question to the desktop experts as this behavior AFAICS also came with the new Desktop architecture and is present throughout qemu versions.

[Christian Ehrhardt  (paelzer)]

Speaking of Desktop ...

@Daniel
I see you retriaged this for the Desktop team and removed the wayland bug task. Instead I see you added some tags. Is that (only tags) correct or should there have been another package added as bug task instead?
Maybe it was lost in between all the comments (I have even re-summarized in the description hoping to avoid that), but this affects all qemu builds from foal to jammy and newer - the difference maker to cause problem is the change in the desktop/UI environment - hence I reached out to Desktop help by assigning it to wayland which was where I assumed one would need to have a look.

[Daniel van Vugt (vanvugt)]

The 'wayland' package is just a protocol library that nobody should be logging bugs against usually. Window actions are owned by the app or the toolkit so if anything you might need a 'gtk+3.0' task.

[Markus S (qemvirt)]

@Christian, thanks for exercising this issue a bit more and confirming that the mouse becomes invisible when pressing Ctrl+Alt+G in the GTK_BACKEND=x11 setting. Can you also confirm that trying to switch windows via Alt+Tab does not work when GTK_BACKEND=x11 is active?

Also, in fact I tried this on a computer with a single screen attached.

My current understanding is that this issue is not fully resolved because with GTK_BACKEND=x11 input grabbing does not work correctly and without this setting fullscreen does not work reliably if host and guest resolution are equal.

From my personal perspective, it would be fine if it works in either of the two settings, i.e., GTK_BACKEND=x11 enabled or not. I appreciate your efforts regarding this hard to debug issue.