only Xorg available when running under qemu-kvm

[bsherman]

Describe the bug

I noticed that when I run a silverblue 39 image in qemu-kvm (on my ublue 39 host) I lose ability to run Wayland after rebasing to bluefin.

What did you expect to happen?

I expected to use Wayland.

Output of rpm-ostree status

State: idle
AutomaticUpdates: stage; rpm-ostreed-automatic.timer: no runs since boot
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bluefin:39 (index: 0)
                   Digest: sha256:12237f09943c091bb5a4965e7284aad9f8ae1f016e95254483c7ab545d0f227c
                  Version: 39.20240129.0 (2024-01-29T23:17:22Z)
                   Commit: 6fe8df244314c307e9859b7e9bc36b7a03d23deba555eb4630f8360b6105b5f1
                StateRoot: fedora

ostree-unverified-registry:ghcr.io/bsherman/silverblue-custom:pr-6-39 (index: 1)
                   Digest: sha256:89ee4bf7d22f77bf22e4a0f89b57aea72e7b2bf30dc7d6ceaa7a37953c221fc7
                  Version: 39.20240131.0 (2024-02-01T07:49:45Z)
                   Commit: a05c4b73bfd5f6d08dad86f15ca41d4b15812a27f9685ad19c6f3b77efb942f1
                   Staged: no
                StateRoot: fedora

Extra information or context

No response

[bsherman]

I'm happy to dig into this further, but not time right now. If someone else sees the solution, by all means please jump in here. :-)

[m2Giles]

Inside of /usr/lib/udev/rules.d/61-gdm.rules

There appears to be checks for virtual GPU. It will write variables to /run/udev/gdm-machine-has-virtual-gpu. Unless nomodeset is still set from kernel cmdline, it should good. If there are multiple virtual gpus it disables wayland.

[bsherman]

I'm afk now, but is this file in Silverblue upstream or in Bluefin?

My report is that the same VM uses Wayland with upstream, but stops using Wayland after rebase to Bluefin

[m2Giles]

We should be getting this file from upstream. While we make changes for gnome-vrr, I don't believe this affects this file.

[m2Giles]

Playing with F40 iso's with qemu.

By default something in /usr/lib/udev/rules.d/61-gdm.rules is triggering the no-wayland support. Per the arch wiki, you can override this file with a symlink to /dev/null. Qemu is now working with wayland for gdm which then enables wayland sessions for login.

Aurora out of the box supports wayland.

[m2Giles]

Found the issue:

On lines 82 to 87 of /usr/lib/udev/rules.d/61-gdm.rules there is a check to disable wayland for the following situation:
If you have both a virtual gpu and a hardware gpu then wayland is disabled.

We obviously have a virtual gpu. But where does the hardware gpu come from? Well, displaylink apparently creates 4 additional /dev/dri/cards. The check for a hardware gpu is if there is an additional card that is not associated with the cirrus, virtio, qxl, or vga virtual hardware devices. So displaylink triggers that we have a physical gpu and the udev rule then disables wayland.

I'll see if disabling displaylink service fixes this. Otherwise, we can comment out a single line in /usr/lib/udev/rules.d/61-gdm.rules. And looks like disabling the service isn't good enough.

[bsherman]

Well, displaylink apparently creates 4 additional /dev/dri/cards.

That is pretty wild!

I wonder if, other than disabling a service, there is a way to stop displaylink from loading. Shouldn't the driver only load if required?

[bsherman]

@m2Giles filed this for more info negativo17/displaylink#2

as we see the problem is here: negativo17/displaylink@1feee61

[scaronni]

Interesting take, I can revert that commit, no problem, but I did not find the automatic startings/stopping based on USB IDs very reliable, EVDI takes some time to settle up and with dynamic loading we had a few end users connecting and disconnecting stuff before the display had time to initialize.

What is the use case for running Displaylink inside a VM though?

[scaronni]

New packages with the change reverted will be live in a few minutes.

[m2Giles]

What is the use case for running Displaylink inside a VM though?

We install displaylink by default on all of our images. When it was first added to the image it was still in the hot plug mode where evdi didn't load until the plug in event.

We didn't put it together on why on VMs it was failing until the GitHub issue.

Also, this is something we'll likely bring up to gdm since the udev rules seem extremely out of place now.

[scaronni]

Also, this is something we'll likely bring up to gdm since the udev rules seem extremely out of place now.

@m2Giles did you get in touch with the GDM folks?

[m2Giles]

I have not.