Testing drm-hyperv driver in Fedora

_README.md

Fedora 35

Both the issues mentioned below are solved! My PR to switch to hyperv_drm was accepted, and the kernel fix needed to boot the liveCD are in.

You can boot this as a generation 2 (UEFI) VM with secure boot enabled, using the Microsoft UEFI Certificate Authority setting. Resolution switching works in GNOME under Wayland, even when booted from the live media.

Fedora 34

This is a brief experiment I did to compare these two setups in a Hyper-V VM running Fedora 34

• DRM-hyperv kernel driver from Linux-next (sort of an in-progress 5.14), using Wayland compositor in Gnome 40
• hyperv_fb kernel driver in Linux 5.12.9, using X11 in Gnome 40

Subjectively, the DRM-hyperv + Wayland setup felt a lot smoother and more responsive. glxgears performance was similar in terms of total FPS rendered, but it looks smoother with the new framebuffer driver.

The steps to install the kernel were pretty typical, but covered here: https://docs.fedoraproject.org/en-US/quick-docs/kernel/build-custom-kernel/

Fedora rawhide (35)

Fedora rawhide currently has kernel 5.14-rc1 running. There are still a few issues that need to be worked out.

Need updated kernel settings

CONFIG_DRM_HYPERV is not set, so the new graphics driver is not available. It does at least boot in BIOS / generation 1 VMs.

I opened a pull request https://src.fedoraproject.org/rpms/kernel/pull-request/49#commit_list https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1273

UEFI live ISO boot fails

The current nightly Workstation-live-iso isn't booting in UEFI, there is some issue finding the root FS. Surprisingly the ISO is ejected from the virtual SCSI DVD after this failure happens. Adding rdshell to the grub command line shows some more details but I would need to dig a bit deeper to get more logs.

Need to read https://docs.fedoraproject.org/en-US/quick-docs/debug-dracut-problems/ and file a bug

Filed https://bugzilla.redhat.com/show_bug.cgi?id=1984688

Fedora 34 works fine. /proc/cmdline is BOOT_IMAGE=/images/pxeboot/vmlinuz root=live:CDLABEL=Fedora-WS-Live-34-1-2 rd.live.image (maybe with rd.shell rd.debug log_buf_len=1M but not default)

It seems like /dev/sr0 is processed twice by udev, and the second one is setting a different link to the device that's based on the SCSI ID instead of media's labels. When that happens, it ejects /dev/sr0 which of course is bad for a LiveCD

@virgiliofornazin yeah you're right about Ubuntu 22.04.

I just installed it, ran an apt upgrade and now I'm using kernel 5.15.0-58-generic. I had to set the resolution with Set-VMVideo -HorizontalResolution:1920 -VerticalResolution:1080 -ResolutionType single from the host, and that worked but I can't change the resolution from inside the VM. dmesg does show that it loaded hyperv_fb instead of hyperv_drm.

Both CONFIG_DRM_HYPERV and CONFIG_FB_HYPERV are set to m. I guess the DRM one is not taking precedence for some reason.

Hello @PatrickLang and greetings from Germany.

I just worked on getting Debian 12 (bookworm) in Hyper-V (Win11) to run in 3840x2160 resolution.

I used
Set-VMVideo -VMName "TheNameOfTheVM" -HorizontalResolution 3840 -VerticalResolution 2160 -ResolutionType Single
on the VM (switched off, PowerShell in Administrator-Mode).

In the Grub-File:
I changed
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=hyperv_fb:3840x2160"
to
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash video=Virtual-1:3840x2160"

---

hyperv_fb replaced with Virtual-1

After that, I was able to change the resolution inside the KDE-Desktop.

I don't know if the DRM is used or not.

Maybe that helps with resizing?

Tschüß :)