Tracking ticket for QEMU display device issues

[ccapitalK]

We seem to be having a lot of back and forth when it comes to deciding which display backend to use in which situation (and whether or not it is fine to enable OpenGL support). It appears that a lot of these commits end up fixing qemu on someones local machine only to break it elsewhere, so I'm going to try to summarize all of the edge cases we have encountered so that we can hopefully create a stable run script.

Edit: I just realized that there is extensive discussion about this topic in the discord, I'll try to summarize that information here too.

[ccapitalK]

Current WIP notes:

For Mac OSX:

• This is the simplest case, we always want to use cocoa here. We can simply check if the cocoa backend is available, which is true if and only if we are on OSX. I don't believe GL acceleration is supported here.

For QEMU inside Windows WSL1:
TODO Figure this out

For QEMU inside Windows WSL2:
TODO Figure this out

For Native Windows QEMU:
TODO Figure this out

For Linux:

• GTK with openGL support doesn't work, but SDL with openGL support does. Using OpenGL usually results in a smoother experience
• SDL backend has bug (in QEMU) where if the window is resized before serenity initializes, the window doesn't end up showing the whole display when after Serenity sets the resolution (until we resize the window manually).
• OpenGL support is only supported if virgl is setup, we should be ensuring that libvirglrenderer.so exists on the host system.

[tomuta]

The only thing I can add is that stock Ubuntu 21.04 QEMU does not support the SDL backend at all (at least for me).

[gunnarbeutner]

WSL1: We don't support this at all.
WSL2: We should reconsider native QEMU when WSLg and nested KVM are more common. AFAIU this currently requires an insider build which most people don't have.

Native Windows QEMU:

• GTK: Weird interaction between HiDPI displays and display scaling (QEMU/WSL: Boot slows to a crawl when WHPX acceleration is enabled #7657).
• SDL,gl=off - works just fine (for me anyway)
• SDL,gl=on - doesn't work, the pre-built QEMU binaries don't support this.

[gunnarbeutner]

Linux:

• SDL captures the mouse/keyboard more consistently than GTK. With GTK I was not able to use Alt-Tab, Super, etc.

[ccapitalK]

WSL1: We don't support this at all.

IIRC someone in the discord mentioned that they got it working in wsl1, but couldn't get it working any other way, so It might be worthwhile supporting it. Edit: Nevermind, I must have been remembering it wrong.

[ADKaster]

As far as I know the reason we "disregard" WSL1 is because it's either extremely difficult or unsupported at the OS level to generate ext2 images on it.

Like Gunnar mentioned, the GTK display on Windows Qemu has that postage stamp or freeze problem on large displays.

GTK also has less than optional mouse capture behavior. You have to repeatedly Ctrl+Shift+G to uncapture, re-align the mouse, then click back into the window directly where the mouse cursor is. SDL doesn't have that issue, it just snaps the mouse to the right location right away.

Unrelated to displays, there's still that virtio issue where windows qemu gets very upset and refuses to keep booting. Though to be honest, I haven't tried using that with the SDL backend, maybe it will have different results.

[X-yl]

Worth noting that when we have multiple screens we want to prefer SDL.

Linux: qemu-vdagent doesn't work with SDL on the latest master. Does work with GTK, don't know about other backends.