Bug 1897717 - Plasma 5.20 has Black desktop screen when using wayland in conjunction with SDDM
Summary: Plasma 5.20 has Black desktop screen when using wayland in conjunction with SDDM
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: sddm
Version: rawhide
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
Assignee: Martin Bříza
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-11-13 21:36 UTC by Gerald Cox
Modified: 2021-01-16 01:34 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-01-16 01:34:09 UTC
Type: Bug


Attachments (Terms of Use)
sddm .cache/wayland-errors (16.49 KB, text/plain)
2020-11-17 05:03 UTC, Gerald Cox
no flags Details
ksplashqml crash on black screen (11.81 KB, text/plain)
2020-11-17 19:23 UTC, Gerald Cox
no flags Details
.config/kwinrc file (1.14 KB, text/plain)
2020-11-19 17:34 UTC, Gerald Cox
no flags Details
.cache/wayland-errors (7.35 KB, text/plain)
2020-11-19 19:17 UTC, Gerald Cox
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github sddm sddm issues 1335 0 None closed Plasma 5.20 has Black desktop screen when using wayland in conjunction with SDDM 2021-01-19 07:19:52 UTC
KDE Software Compilation 404335 0 NOR REOPENED Don't rely on dbus-run-session or dbus-launch for starting plasma-wayland session 2021-01-19 07:20:33 UTC
Red Hat Bugzilla 1912046 0 unspecified CLOSED BASH_FUNC environment variables reigning havoc and it just keeps getting worse 2021-02-22 00:41:40 UTC

Internal Links: 1912046

Description Gerald Cox 2020-11-13 21:36:28 UTC
Description of problem:

Upon upgrade to Plasma 5.20 receive black screen when using wayland.  X so far appears to work fine, however has some weirdness, i.e. pinned to task manager is blank folder org.kde.discover.desktop.  What is that?

Currently using X since Wayland is now unusable.

Comment 1 MicMor 2020-11-14 08:16:09 UTC
For me, X and wayland works without problems on my optimus system (nvidia + intel)

Small bug,
- sddm that does not reappear when I log out of my session but the problem was already existing under F31, F32
- And kio-gdrive which does not work 100%. We can now create the google account but the link to gdrive in dolphin does not work.

error message: Impossible de créer le module d'entrée / sortie. klauncher a indiqué : Erreur lors du chargement de « /usr/lib64/qt5/plugins/kf5/kio/gdrive.so ».

Comment 2 Gerald Cox 2020-11-14 19:12:58 UTC
X appears to work fine.  Problem is with Wayland.  My system is AMD/Radeon, so that 
may explain why yours is working.  I did try remove the .kde directory and having the system
recreate - but that didn't help.  

I did notice a crash and tried to save it to 
my disk, but that failed.  I just created an empty file named:  
ksplashqml-20201113-115926.kcrash

Comment 3 Gerald Cox 2020-11-15 00:43:33 UTC
I am able to open a terminal window, so if somebody could give me some commands to assist in debugging, I can perform and post the output here.

Thanks.

I tried stopping and restarting plasmashell, here is the output:

$ kquitapp5 plasmashell

$ kstart5 plasmashell
Omitting both --window and --windowclass arguments is not recommended

$ Aborting shell load: The activity manager daemon (kactivitymanagerd) is not running.
If this Plasma has been installed into a custom prefix, verify that its D-Bus services dir is known to the system for the daemon to be activatable.

Comment 4 Gerald Cox 2020-11-15 21:18:15 UTC
Appears to be an issue when using SDDM in conjunction with the 5.20 update.  I'm currently using:
sddm-0.18.1-8.fc33.x86_64
sddm-themes-0.18.1-8.fc33.noarch
sddm-kcm-5.20.3-1.fc33.x86_64
sddm-breeze-5.20.3-1.fc33.noarch

When I switch my displaymanager to use GDM, Plasma Wayland no longer experiences the black screen issue.

Comment 5 Gerald Cox 2020-11-15 21:44:26 UTC
I just tried with:
sddm-kcm-5.20.3-1.fc33.x86_64
sddm-breeze-5.20.3-1.fc33.noarch
sddm-0.19.0-1.fc33.x86_64

Same issue, black screen.

Comment 6 Neal Gompa 2020-11-17 02:57:06 UTC
Gerald, can you upload the ~/.cache/wayland-errors log file? It may help with further troubleshooting.

Comment 7 Gerald Cox 2020-11-17 05:03:00 UTC
Created attachment 1730006 [details]
sddm .cache/wayland-errors

Hope this helps.  If you need me to provide any additional information, LMK.  Thanks!

Comment 8 Aleix Pol 2020-11-17 13:23:57 UTC
These look like they could be related to the problem:
error: : cannot open
error: : cannot open
error: : cannot open

Increasing debug could help figure out this issue, something like this in profile.d would help:
QT_MESSAGE_PATTERN=%{if-category} %{category}:%{endif} %{if-debug}%{function}%{endif}%{if-warning}%{backtrace depth=3}%{endif}%{if-critical}%{backtrace depth=3}%{endif}%{if-fatal}%{backtrace depth=3}%{endif} %{message}

Comment 9 Aleix Pol 2020-11-17 13:40:23 UTC
That's coming from telegram desktop, so it's not it.

Does alt+f2 or alt+space bring krunner?

Can you check in coredumpctl if there's something crashing?

Comment 10 Gerald Cox 2020-11-17 19:23:10 UTC
Created attachment 1730274 [details]
ksplashqml crash on black screen

Comment 11 Gerald Cox 2020-11-17 19:25:15 UTC
Just tried with the 5.20.3-2 updates.  Same issue.
Was able to capture kspashqml crash which I've attached.
Cannot open krunner for some reason, but am able to 
open ksonsole and also ssh into the server.

Comment 12 Adrien Faveraux 2020-11-17 23:26:23 UTC
Can you test remove QML cache dir ? : 

rm -fr /var/lib/sddm/.cache/sddm-greeter/qmlcache

Or Remove other cache in /var/lib/sddm/.cache/ ?

Comment 13 Gerald Cox 2020-11-18 17:47:32 UTC
(In reply to Adrien Faveraux from comment #12)
> Can you test remove QML cache dir ? : 
> 
> rm -fr /var/lib/sddm/.cache/sddm-greeter/qmlcache
> 
> Or Remove other cache in /var/lib/sddm/.cache/ ?

I tried both, first removing just qmlcache and then the entire .cache directory.

No noticeable effect.  Same black screen.

Comment 14 Rex Dieter 2020-11-19 15:58:58 UTC
Please post contents of ~/.config/kwinrc too.  

maybe even try removing that file to see if that helps any.  One other user reported that helped them.

Also, anything in ~/.cache/wayland-errors file ?

Comment 15 Gerald Cox 2020-11-19 17:34:22 UTC
Created attachment 1730992 [details]
.config/kwinrc file

Comment 16 Gerald Cox 2020-11-19 17:34:59 UTC
(In reply to Rex Dieter from comment #14)
> Please post contents of ~/.config/kwinrc too.  
> 
> maybe even try removing that file to see if that helps any.  One other user
> reported that helped them.
> 
> Also, anything in ~/.cache/wayland-errors file ?

Removing kwinrc had no effect.  Same black screen.

Comment 17 Rex Dieter 2020-11-19 18:24:35 UTC
And wayland-errors?

Comment 18 Gerald Cox 2020-11-19 19:01:19 UTC
(In reply to Rex Dieter from comment #17)
> And wayland-errors?

That was posted on November 17th.

Comment 19 Gerald Cox 2020-11-19 19:08:50 UTC
(In reply to Gerald Cox from comment #18)
> (In reply to Rex Dieter from comment #17)
> > And wayland-errors?
> 
> That was posted on November 17th.

Sorry you're wanting it from a different location. They shouldn't be using the same name - it's confusing.

Comment 20 Gerald Cox 2020-11-19 19:17:28 UTC
Created attachment 1731033 [details]
.cache/wayland-errors

Comment 21 Gerald Cox 2020-12-13 04:54:55 UTC
A user responding to the ticket on SDDM found a workaround.

I've tried it and it circumvents the issue.  The question is why
would this be needed apparently only when using Radeon, SDDM and Wayland?

>>>>>>>>

Well, based on this, I just tried editing /usr/share/wayland-sessions/plasmawayland.desktop, replacing the Exec= line with:
Exec=/usr/bin/dbus-run-session /usr/bin/startplasma-wayland
and not touching anything else. (Then I had to sudo service sddm restart, but simply rebooting would have been also fine most likely...)

Now I can log in to Plasma (wayland) just fine from SDDM as well.

The original line was:
Exec=/usr/libexec/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland

That plasma-dbus-run-session-id-needed script contains this:

#!/usr/bin/sh
# Usage: plasma-dbus-run-session-if-needed PROGRAM [ARGUMENTS]
# If the session bus is not available it is spawned and wrapper round our program
# Otherwise we spawn our program directly
drs=
if [ -z "${DBUS_SESSION_BUS_ADDRESS}" ]
then
    drs=dbus-run-session
fi
exec ${drs} "$@"

Perhaps something in this little wrapper goes wrong? Like it detects that dbus-run-session prefix is not needed, even if it is? I haven't tested it any further TBH...

<<<<<<<<

Comment 22 Gerald Cox 2020-12-13 23:24:33 UTC
This is the KDE bug that created the whack-a-mole situation:  https://bugs.kde.org/show_bug.cgi?id=404335

Comment 23 Rex Dieter 2020-12-14 23:37:37 UTC
Guessing this is about dbus-broker, though I'm having trouble finding where that was made the default.  I *thought* it was f33, but can't find that documented anywhere offhand.

The helper script references dbus-run-session (the old one), not dbus-broker-launch, though I believe dbus-broker launches on demand (but don't quote me on that).

Comment 24 Gerald Cox 2020-12-15 00:17:37 UTC
(In reply to Rex Dieter from comment #23)
> Guessing this is about dbus-broker, though I'm having trouble finding where
> that was made the default.  I *thought* it was f33, but can't find that
> documented anywhere offhand.
> 
> The helper script references dbus-run-session (the old one), not
> dbus-broker-launch, though I believe dbus-broker launches on demand (but
> don't quote me on that).

Yup, they talk about that in the kde bug referenced above.  There are also links back 
to a still opened (for over 2 years) issue on the github site for dbus-broker.  
As for dbus-broker, looks like in landed in F30:  https://bugzilla.redhat.com/show_bug.cgi?id=1557954

Comment 25 Gerald Cox 2021-01-04 00:04:24 UTC
Dependent on:  https://bugzilla.redhat.com/show_bug.cgi?id=1912046

Comment 26 Gerald Cox 2021-01-04 20:44:45 UTC
This problem (at least for me) is being caused because I have the package environment-modules
installed.  What is curious is why more people aren't experiencing it.  

Apparently, environment-modules is a fairly pervasive requirement.  Are most people that are using
KDE Wayland not using SDDM?  If you are using KDE Wayland and SDDM, from the investigation so far
you should be able to reproduce the issue quite easily.

dnf repoquery --whatrequires environment-modules --recursive --installed
cheese-2:3.38.0-2.fc33.x86_64
coin-or-Cbc-0:2.10.5-4.fc33.x86_64
coin-or-Cgl-0:0.60.3-2.fc33.x86_64
coin-or-Clp-0:1.17.6-2.fc33.x86_64
digikam-0:7.1.0-1.fc33.x86_64
digikam-doc-0:7.1.0-1.fc33.noarch
digikam-libs-0:7.1.0-1.fc33.x86_64
elisa-player-0:20.08.3-1.fc33.x86_64
farstream02-0:0.2.9-3.fc33.x86_64
farstream02-devel-0:0.2.9-3.fc33.x86_64
gmic-0:2.9.4-1.fc33.x86_64
gmic-gimp-0:2.9.4-1.fc33.x86_64
gnome-initial-setup-0:3.38.2-1.fc33.x86_64
gnome-tour-0:3.38.0-2.fc33.x86_64
gstreamer1-plugins-bad-1:1.18.1-2.fc33.x86_64
initial-setup-gui-0:0.3.83-1.fc33.x86_64
kde-connect-0:20.08.1-1.fc33.x86_64
kde-connect-libs-0:20.08.1-1.fc33.x86_64
kde-connect-nautilus-0:20.08.1-1.fc33.x86_64
kde-print-manager-0:20.08.1-1.fc33.x86_64
kde-print-manager-libs-0:20.08.1-1.fc33.x86_64
kdeconnectd-0:20.08.1-1.fc33.x86_64
kid3-0:3.8.4-1.fc33.x86_64
kid3-common-0:3.8.4-1.fc33.x86_64
kwin-0:5.20.4-2.fc33.x86_64
mkvtoolnix-gui-0:51.0.0-1.fc33.x86_64
mp-0:3.1.0-31.20200303git7fd4828.fc33.x86_64
opencv-0:4.3.0-9.fc33.x86_64
opencv-contrib-0:4.3.0-9.fc33.x86_64
opencv-core-0:4.3.0-9.fc33.x86_64
opencv-devel-0:4.3.0-9.fc33.x86_64
picard-0:2.5.5-1.fc33.x86_64
plasma-applet-redshift-control-0:1.0.18-9.fc33.noarch
plasma-applet-translator-0:0.7-1.fc33.noarch
plasma-desktop-0:5.20.4-2.fc33.x86_64
plasma-integration-0:5.20.4-1.fc33.x86_64
plasma-lookandfeel-fedora-0:5.20.4-1.fc33.noarch
plasma-workspace-0:5.20.4-1.fc33.x86_64
plasma-workspace-wayland-0:5.20.4-1.fc33.x86_64
plasma-workspace-xorg-0:5.20.4-1.fc33.x86_64
python3-qt5-0:5.15.0-4.fc33.x86_64
python3-qt5-webkit-0:5.15.0-4.fc33.x86_64
qmmp-0:1.4.3-1.fc33.x86_64
qmmp-devel-0:1.4.3-1.fc33.x86_64
qmmp-plugin-pack-0:1.4.0-1.fc33.x86_64
qmmp-plugin-pack-freeworld-0:1.4.0-1.fc33.x86_64
qmmp-plugins-freeworld-0:1.4.3-1.fc33.x86_64
qt5-qtmultimedia-0:5.15.2-2.fc33.x86_64
qt5-qtmultimedia-devel-0:5.15.2-2.fc33.x86_64
scl-utils-1:2.0.2-16.fc33.x86_64
sddm-breeze-0:5.20.4-1.fc33.noarch
stellarium-0:0.20.4-1.fc33.x86_64
telepathy-farstream-0:0.6.1-18.fc33.x86_64
telepathy-farstream-devel-0:0.6.1-18.fc33.x86_64
telepathy-qt5-devel-0:0.9.8-7.fc33.x86_64
telepathy-qt5-farstream-0:0.9.8-7.fc33.x86_64
vokoscreenNG-0:3.0.7-1.fc33.x86_64

Comment 27 Göran Uddeborg 2021-01-04 21:56:56 UTC
That list intrigued me, since I have many of those packages installed, so I investigated why I could remove environment-modules without any problems.

If I understand this correctly, the critical "provides" is "environment(modules)", which is also provided by Lmod. (The other component mentioned in bug 1912046.) Lmod is installed on my system, and apparently doesn't cause any issues when starting a session. But if I try to remove it, DNF wants to remove a long list of packages from my system too.

If your system is like mine, you could swap Lmod for environment-modules, avoid the black desktop, and only loose scl-utils from the list in comment 26.

Comment 28 Gerald Cox 2021-01-04 22:58:35 UTC
(In reply to Göran Uddeborg from comment #27)
> That list intrigued me, since I have many of those packages installed, so I
> investigated why I could remove environment-modules without any problems.
> 
> If I understand this correctly, the critical "provides" is
> "environment(modules)", which is also provided by Lmod. (The other component
> mentioned in bug 1912046.) Lmod is installed on my system, and apparently
> doesn't cause any issues when starting a session. But if I try to remove it,
> DNF wants to remove a long list of packages from my system too.
> 
> If your system is like mine, you could swap Lmod for environment-modules,
> avoid the black desktop, and only loose scl-utils from the list in comment
> 26.

Thank you!  You are absolutely correct.  That works-around the black-screen issue!

However, we're back to whack-a-mole, because Lmod and it's BASH_FUNC has been implicated
in:  https://bugzilla.redhat.com/show_bug.cgi?id=1754395

Unfortunately, the fundamental root cause issue of https://bugzilla.redhat.com/show_bug.cgi?id=1912046
still exists.

Comment 29 Rex Dieter 2021-01-05 04:20:40 UTC
Probably similar cause as bug #1754395 then, I'll followup here too what I found there which may be relavent.


So, I've been barking up the wrong tree... with plasma-5.20 upstream decided to write their own environment sync code and not use dbus-update-activation-environment anymore.  Some relevant upstream commits:

"[startkde] Replace calling dbus-update-activation-environment with native code "
https://invent.kde.org/plasma/plasma-workspace/-/commit/1e444c864fc175b3826c88a51a5e2c9f95e497c3

"Syncronise environment to user systemd session"
https://invent.kde.org/plasma/plasma-workspace/-/commit/77f418500e56e3227828d26619aeba462a5c8227

There was a bit of validation done in a relatively recent commit, but that probably needs more work then:
https://invent.kde.org/plasma/plasma-workspace/-/commit/875bcf1918381873f11eaa286ee3e8780c069676

Comment 30 Rex Dieter 2021-01-05 04:44:49 UTC
Interestingly, I tried more to debug/reproduce today (bug #1754395 in particular), and can't seem to possibly since installing systemd-246.7-2.fc33,
https://bodhi.fedoraproject.org/updates/FEDORA-2020-3616681a70

Comment 31 Gerald Cox 2021-01-05 06:20:43 UTC
(In reply to Rex Dieter from comment #30)
> Interestingly, I tried more to debug/reproduce today (bug #1754395 in
> particular), and can't seem to possibly since installing
> systemd-246.7-2.fc33,
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-3616681a70

If you're talking about https://github.com/systemd/systemd/pull/17188
my understanding was that patch was reverted.

Lmod only defines:

BASH_FUNC_ml%%=() {  eval $($LMOD_DIR/ml_cmd "$@")
}
BASH_FUNC_module%%=() {  eval $($LMOD_CMD bash "$@") && eval $(${LMOD_SETTARG_CMD:-:} -s sh)
}

My understanding was that there was a guard put into place, but the thought now
is that it wasn't robust as it needed to be.  That's why I created 
rhbz#1912046 so this issue could be looked at holistically rather than 
playing whack-a-mole.

Try installing: environment-modules-4.5.3-1.fc33
then boot into plasma-wayland using sddm.

Comment 32 Rex Dieter 2021-01-14 23:02:00 UTC
worth testing this
https://bodhi.fedoraproject.org/updates/FEDORA-2021-ea19dabe82

includes an upstream fix for environment import, which fixes related bug #1754395 at least, may help here too.

Comment 33 Gerald Cox 2021-01-15 17:49:06 UTC
(In reply to Rex Dieter from comment #32)
> worth testing this
> https://bodhi.fedoraproject.org/updates/FEDORA-2021-ea19dabe82
> 
> includes an upstream fix for environment import, which fixes related bug
> #1754395 at least, may help here too.

Thanks Rex, this I believe was the patch that David was referring to in SDDM #1335.
Appreciate you getting it applied quickly!  It circumvents the current issue!

I'll comment more in #1912046.

Comment 34 Fedora Update System 2021-01-15 18:13:32 UTC
FEDORA-2021-ea19dabe82 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-ea19dabe82

Comment 35 Fedora Update System 2021-01-16 01:34:09 UTC
FEDORA-2021-ea19dabe82 has been pushed to the Fedora 33 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.