Second display framebuffer created when using virtio-ramfb-gl

[alicela1n]

I've encountered this issue when using Fedora with KDE Plasma, however it might affect other distros as well. A second display framebuffer is created and shares the same VM window, which is very annoying to disable because it causes the mouse movement to be off. I should also mention I'm using X11.

Configuration

• UTM Version: 3.2.4
• macOS Version: 12.6
• Mac Chip (Intel, M1, ...): M1

debug log and config plist.zip

[alicela1n]

PS: For anyone looking for a work around, you can disable that second display, but it's annoying and difficult to do because the mouse movement is off, however once you've got it disabled then the mouse movement will be fixed.

[tpasternak]

Same issue on Fedora GNOME

[romi2002]

Same issue here, on Fedora GNOME and UTM 4.1.0.

[AwlsomeAlex]

Ditto. Fedora 37 with UTM 4.1.0 and 4.1.1.

[gasinvein]

It seems like the second output is the kernel's simple framebuffer, which was enabled in Fedora 36. As a workaround, you can disable it by adding initcall_blacklist=sysfb_init to the kernel boot arguments (press e while in GRUB boot menu, and type in the argument at the end of the line starting with linux, then press Ctrl+x).

[AwlsomeAlex]

This fixes it for me, however Anaconda seems to crash now.

[gasinvein]

Anaconda seems to crash now

Yeah, I didn't find a way around it other than switching the gpu device to virtio-ramfb before installing Fedora and then switching it back to virtio-ramfb-gl, or running liveinst from serial console and installing in text mode.

[osy]

Have you all tried the latest beta? Crashes due to graphics rendering should be fixed.

[gasinvein]

Have you all tried the latest beta? Crashes due to graphics rendering should be fixed.

Anaconda still crashes with UTM 4.1.3. On a side note, it seems like UTM now defaults to virtio-gpu-gl-pci GPU, which renders unusably slow. Changing it to virtio-ramfb-gl manually gets us back we were.

[osy]

“ renders unusably slow” explain?

[gasinvein]

“ renders unusably slow” explain?

The display draws the image line-by-line, something like a really slow CRT. Even GRUB menu is like this actually, only GRUB menu is like this; graphical session renders normally, same as with virtio-ramfb-gl. The initcall_blacklist=sysfb_init boot arg isn't needed with virtio-gpu-gl-pci, but Anaconda still crashes.

[osy]

That’s always been an issue with UEFI firmware’s virtiogpu drivers. I’ll try to fix it one day but it shouldn’t affect anything else

Anaconda still crashes

Do you mean crashes UTM or crashes in the guest? If it’s the guest try running it with QEMU. If it’s an issue with QEMU, file an issue with them. Otherwise open a new issue here.

[gasinvein]

That’s always been an issue with UEFI firmware’s virtiogpu drivers.

Just curious, why doesn't it happen with virtio-ramfb-gl device?

Anaconda still crashes

Do you mean crashes UTM or crashes in the guest?

Crashes in the guest. And indeed it looks like an unrelated problem.

[osy]

Just curious, why doesn't it happen with virtio-ramfb-gl device?

EFI uses the ramfb device instead of the virtiogpu device when both are provided.

[osy]

So I don’t have grub set to show up every boot so the slow console buffer isn’t an issue for me. If people really feel that strongly about it, I can investigate the issue in the EFI driver code…

[AwlsomeAlex]

I find it becomes more of an issue if you're using Retina mode and it has to draw the entire GRUB menu. If this GPU driver is the new default, it should probably be documented in "Known Issues", as the workaround isn't apparent.

For the original issue, I'll have to check Fedora Rawhide to see if its fixed.

[tpasternak]

For me it seems to be fixed as of 4.2.4

[gasinvein]

I can confirm it seems to work properly on 4.2.4. Tested with Fedora 38, GNOME Wayland session, booted with initcall_blacklist=sysfb_init; used glmark2 and glmark2-wayland programs. Oddly enough and contrary to the known issues list, it seems to work fine with the Metal ANGLE backend as well.

Update: sorry, was replying to the wrong thread; actually it's #4983 that seems to be fixed. This issue, i.e. the stray framebuffer, seems to be still there as of 4.2.4.