Bug 2016788 - sddm-0.19.0-17.fc35 didn't allow logging in to the Plasma on Wayland desktop session
Summary: sddm-0.19.0-17.fc35 didn't allow logging in to the Plasma on Wayland desktop ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: sddm
Version: 35
Hardware: Unspecified
OS: Unspecified
urgent
high
Target Milestone: ---
Assignee: Martin Bříza
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-10-23 20:46 UTC by Matt Fagnani
Modified: 2021-10-28 18:28 UTC (History)
9 users (show)

Fixed In Version: sddm-0.19.0-18.fc35
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-10-28 18:28:04 UTC
Type: Bug


Attachments (Terms of Use)
Hide wayland sessions if /dev/dri isn't found. (5.78 KB, application/mbox)
2021-10-25 20:08 UTC, Jeremy Linton
no flags Details

Description Matt Fagnani 2021-10-23 20:46:14 UTC
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.

Comment 1 Jeremy Linton 2021-10-23 21:57:40 UTC
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?

Comment 2 Jeremy Linton 2021-10-23 21:58:22 UTC
The update changed /usr/lib/udev/rules.d/61-sddm-plasmawayland.rules too, so also look for a /dev/dri/card* device.

Comment 3 Matt Fagnani 2021-10-23 22:37:41 UTC
(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

Comment 4 Gerald Cox 2021-10-24 06:07:33 UTC
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.

Comment 5 Jeremy Linton 2021-10-24 16:47:23 UTC
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.

Comment 6 Adam Williamson 2021-10-24 23:33:18 UTC
I think I probably prefer the inversion option, though only if we're very sure it covers all cases in which Wayland works.

Comment 7 Jeremy Linton 2021-10-25 16:33:05 UTC
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).

Comment 8 Adam Williamson 2021-10-25 16:58:24 UTC
How about NVIDIA/AMD proprietary drivers? Do they work with Wayland, and if so do they use dev/dri?

Comment 9 Jeremy Linton 2021-10-25 20:08:26 UTC
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.

Comment 10 Adam Williamson 2021-10-25 20:11:35 UTC
thanks jeremy! I'll try it out here a bit.

Comment 11 Adam Williamson 2021-10-25 22:12:42 UTC
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!

Comment 12 Fedora Update System 2021-10-26 01:15:30 UTC
FEDORA-2021-631306a178 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-631306a178

Comment 13 Fedora Update System 2021-10-26 01:15:36 UTC
FEDORA-2021-631306a178 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-631306a178

Comment 14 Jeremy Linton 2021-10-26 02:50:35 UTC
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.

Comment 15 Adam Williamson 2021-10-26 06:04:24 UTC
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!

Comment 16 Fedora Update System 2021-10-26 15:41:41 UTC
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.

Comment 17 Adam Williamson 2021-10-26 19:30:02 UTC
Matt, do you have a minute to check the newer sddm works OK for you? Thanks!

Comment 18 Matt Fagnani 2021-10-26 19:58:49 UTC
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.

Comment 19 Fedora Update System 2021-10-28 18:28:04 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.