http://bugzilla.suse.com/show_bug.cgi?id=1170619 http://bugzilla.suse.com/show_bug.cgi?id=1170619#c3 Daniel Molkentin <daniel.molkentin@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fbui@suse.com Flags| |needinfo?(denis.kondratenko | |@suse.com) --- Comment #3 from Daniel Molkentin <daniel.molkentin@suse.com> --- So I build a package based on the current Update repo with the patch included. I modified it, so it would build (include file missing). Also, the cherry-pick took care of some file renamings. https://build.opensuse.org/package/view_file/home:dmolkentin:branches:SUSE:S... I installed the resulting package, but the result is still the same. running sway from tty by calling "sway" gives the same error. This is the error from the journal log again: Jun 09 13:28:49 workhorse.suse.de /usr/lib/gdm/gdm-wayland-session[4559]: 2020-06-09 13:28:49 - [backend/session/direct-ipc.c:35] Do not have CAP_SYS_ADMIN; cannot become DRM master Jun 09 13:28:49 workhorse.suse.de /usr/lib/gdm/gdm-wayland-session[4559]: 2020-06-09 13:28:49 - [backend/session/session.c:96] Failed to load session backend Jun 09 13:28:49 workhorse.suse.de /usr/lib/gdm/gdm-wayland-session[4559]: 2020-06-09 13:28:49 - [backend/backend.c:286] Failed to start a DRM session Jun 09 13:28:49 workhorse.suse.de /usr/lib/gdm/gdm-wayland-session[4559]: 2020-06-09 13:28:49 - [sway/server.c:47] Unable to create backend My user has: $ id uid=1000(dmolkentin) gid=100(users) groups=100(users),452(libvirt),484(video) So, in theory it should be able to access the DRM devices: $ ls /dev/dri -l total 0 drwxr-xr-x 2 root root 120 Jun 9 13:27 by-path crw-rw----+ 1 root video 226, 0 Jun 9 13:27 card0 crw-rw----+ 1 root video 226, 1 Jun 9 13:27 card1 crw-rw----+ 1 root video 226, 128 Jun 9 13:27 renderD128 crw-rw----+ 1 root video 226, 129 Jun 9 13:27 renderD129 That said, I am am currently runngin what was advertised as the GNOME wayland session (not the fallback), but regardless: $ loginctl show-session 6 -p Type Type=x11 (Didn't know there was a silent fallback). Anything more I can trace the behavior? Franck: Is is possible that the patch runs dry because of something else? It seems to be right systemd (buildlog confirms that the patch gets applied): $ rpm -q --changelog systemd|head -n3 * Mon Jun 08 2020 daniel.molkentin@suse.com - Test fix for bsc#1170619 adds 0001-logind-check-PolicyKit-before-allowing-VT-switch.patch -- You are receiving this mail because: You are on the CC list for the bug.