Description of problem: I ran sudo dnf offline-upgrade download with updates-testing enabled then sudo dnf offline-upgrade reboot in a Fedora 35 KDE Plasma spin installation with the GNOME desktop group installed. The update included sddm-0.19.0-17.fc35 and had the following warning Oct 23 16:18:48 dnf[1830]: Running scriptlet: sddm-0.19.0-17.fc35.x86_64 Oct 23 16:18:48 dnf[1830]: Upgrading : sddm-0.19.0-17.fc35.x86_64 Oct 23 16:18:48 dnf[1830]: warning: /etc/sddm.conf created as /etc/sddm.conf.rpmnew Oct 23 16:18:48 dnf[1830]: Running scriptlet: sddm-0.19.0-17.fc35.x86_64 On the next boot the Desktop Session: option showed GNOME Classic instead of Plasma (Wayland) which I had been using. Plasma (Wayland) and GNOME on Wayland weren't in the list of desktop sessions anymore. sddm-0.19.0-17.fc35 didn't allow logging in to the Plasma on Wayland desktop session as a result. Version-Release number of selected component (if applicable): sddm-0.19.0-17.fc35.x86_64 How reproducible: 2/2 boots Steps to Reproduce: 1. Boot a Fedora 35 KDE Plasma spin installation 2. sudo dnf offline-upgrade download with updates-testing enabled 3. sudo dnf offline-upgrade reboot 4. select Desktop session: option in sddm on the next boot Actual results: sddm-0.19.0-17.fc35 didn't allow logging in to the Plasma on Wayland desktop session Expected results: sddm-0.19.0-17.fc35 allowed logging in to the Plasma on Wayland desktop session Additional info: I downgraded to sddm-0.19.0-16 and rebooted. Plasma (Wayland) and GNOME on Wayland were in the desktop sessions list again.
Check for a /etc/sddm/hide-wayland-sessions file. Its likely it's not been removed because the udev rule which was really racy before is now leaving that in place because its not detecting a DRM device. What is the graphics card?
The update changed /usr/lib/udev/rules.d/61-sddm-plasmawayland.rules too, so also look for a /dev/dri/card* device.
(In reply to Jeremy Linton from comment #1) > Check for a /etc/sddm/hide-wayland-sessions file. > > Its likely it's not been removed because the udev rule which was really racy > before is now leaving that in place because its not detecting a DRM device. > > What is the graphics card? /etc/sddm/hide-wayland-sessions doesn't exist with sddm-0.19.0-16.fc35 installed. /etc/sddm/hide-wayland-sessions is an empty file with sddm-0.19.0-17.fc35 installed. ls -l /etc/sddm/hide-wayland-sessions -rw-r--r--. 1 root root 0 Oct 23 18:28 /etc/sddm/hide-wayland-sessions The GPU is an integrated AMD Radeon R5 which uses the amdgpu kernel driver and radeonsi mesa driver. /dev/dri/card0 is there and looks the same with sddm-0.19.0-16 and sddm-0.19.0-17.fc35 installed. ls -l /dev/dri/card* crw-rw----+ 1 root video 226, 0 Oct 23 18:28 /dev/dri/card0
Upgraded to F35 just now and no Plasma Wayland session, only X11 available. Downgrade of sddm 0.19.0-15 resolved issue. Also, GDM worked fine, i.e. Plasma wayland was available there. Graphics card: GPU: AMD ATI Radeon HD 7850 / R7 265 / R9 270 1024SP This needs to get fixed BEFORE F35 goes live.
Ok, I can reproduce this, but the fix is probably to invert the hide_wayland_seessions flag since it is apparent one cannot depend on the udev rule ordering. That was the risk of doing it this way. So what I think needs to happen is that wayland is explicitly enabled on wayland/drm capable machines since is a small subset of the possible, rather than continuing to attempt to disable it for the much larger diversity of machines that happen to work with X but don't have DRM drivers. That way the udev rule would look like: ACTION=="add", SUBSYSTEM=="drm", KERNEL=="card[0-9]", RUN+="/usr/bin/touch /etc/sddm/enable-wayland-sessions" and invert the logic in the sddm-0.19.0-allow-hiding-wayland-sessions.patch Or we can try to come up with another way to create the hide-wayland-session file that assure its created before the DRM driver activates.
I think I probably prefer the inversion option, though only if we're very sure it covers all cases in which Wayland works.
I've sorta given up on getting udev to mark the files, I've simply tweaked the hide-wayland-sessions patch so that it checks for /dev/dri rather than the udev created/hidden file. So the one question is: Are there wayland capable devices that aren't using the kernel DRM, dev/dri infrastructure? My understanding is that this is where the problem lies (and simpledrm will fix).
How about NVIDIA/AMD proprietary drivers? Do they work with Wayland, and if so do they use dev/dri?
Created attachment 1836998 [details] Hide wayland sessions if /dev/dri isn't found. This patch just updates sddm-greeter to use /dev/dri as the key for whether wayland sessions will be hidden. I've tested this on an amdgpu machine, nouveau/aarch64, rpi4, etc. (couple debug builds, one for f34) https://koji.fedoraproject.org/koji/taskinfo?taskID=77813010 (and one for rawhide/f35) https://koji.fedoraproject.org/koji/taskinfo?taskID=77813038 I have an x86 laptop with a hybrid nvidia proprietary driver+intel I will be testing it on shortly, but would be helpful if a couple other people look at it in parallel at this point.
thanks jeremy! I'll try it out here a bit.
Tested on my bare metal test box and also in a VM with 'vga' graphics (this is a config that both reproduces the 'nomodeset' bug and works if the Wayland sessions are suppressed) and it behaves correctly each time; boot with nomodeset gives only the X session, boot normally gives a choice (it defaults to X11 when you booted nomodeset on the last boot, but we know about that). Jeremy, could you do an official build so we can spin an RC with it included? We won't push it stable until we're sure it's good, but we need an update in updates-testing to do a compose with. Thanks!
FEDORA-2021-631306a178 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-631306a178
Ok, the answer is that there is a nvidia_drm module which is part of the proprietary nvidia driver package I have installed. That is recognized as a DRM driver by this patch, and the wayland sessions are visible. That said, the hybrid graphics machine (lenovo P1) I have has always been "difficult" and remains that way. It seems that plasma/wayland sorta works on it with the proprietary drivers. I say sorta because the HDMI port on that machine can only be driven when the nvidia is active, and nouveau doesn't like driving 4k monitors on it, and the nvidia driver can't seem to do DPMI/etc correctly. Basically its a pain. So, I think these sddm changes are functional in that environment as well as the previous ones I listed, whether the wayland sessions actually work... well that's a different problem. PS, I don't think I have permission to push to the sddm repo/create official builds in it.
Yeah, I realized that after I asked, so I just did it :) I merged your patch from above, I'm assuming that's the same thing as went in the scratch builds. Thanks!
FEDORA-2021-631306a178 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-631306a178` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-631306a178 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Matt, do you have a minute to check the newer sddm works OK for you? Thanks!
sddm-0.19.0-18.fc35 showed Plasma (Wayland) and GNOME on Wayland normally in its Desktop sessions list. I've logged into Plasma on Wayland as usual with it. Thanks. Since the latest patch removes the lines with /etc/sddm/hide-wayland-sessions from 61-sddm-plasmawayland.rules https://src.fedoraproject.org/rpms/sddm/c/52dc921f03abf4524bb2ca249ef28cf78b8c0e4a?branch=f35 Zbigniew's problem at https://bugzilla.redhat.com/show_bug.cgi?id=1966653 might also be fixed by it.
FEDORA-2021-631306a178 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.