Hi,
I build a new computer and have two screen tied to it.
One of them is disabled in EndeavourOS since I don’t use it except for gaming.
However when I boot, the system don’t care and send signal during POST to both screen till the login screen.
After entered my password, the screen stay black and the system freeze. I can’t access my desktop or running terminal. The only possibility is hard reboot.
After many troubleshooting, I really have the feeling the issue is on KDE side.
How can I solve this please?
Hardware & software infos:
- Screen 1: Samsung G9 Neo 57" - 120Hz - 7680*2560 - DP 2.1
- Screen 2: Philips Evnia 34" - 175 Hz - 3440*1440 - DP 1.4
- GPU: AMD 7900 XTX
- Kernel v6.9.6
- KDE Plasma v6.1.0
1 Like
A. it is very easy to check if it is a KDE issue - from the login manage choose different desktop environment: try to install the GNOME desktop to check for another Wayland implementation or XFCE for an X11 implementation. If either work, then the problem is in Plasma and not in - say - the drivers or hardware.
B. When the “system freeze” - can you access a virtual text terminal using CTRLALTF3 (or F4 or other F keys)?
1 Like
When the screen stays black after starting a Plasma session (i.e. after entering username/password) then there’s a chance that one of the Plasma components is crashing. Usually Plasma will stay on the black screen for a few minutes, then give up on that particular component and load anyway without its functionality. If it’s the plasmashell process itself, that’s not going to happen.
What you might want to do is to check your recent system logs e.g. with journalctl -S today, and cross-check with the most recent crashes from coredumpctl --reverse. You’ll need to log into a terminal session for that, e.g. switch to virtual terminal #4 with Ctrl+Alt+F4 and enter username/password there.
Hard to tell what could be going wrong without looking at logs first.
2 Likes
First of all, I found a workaround and I can now boot with my two screens connected.
The Samsung G9 Neo is supporting DisplayPort 2.1 and my GPU too. I tried to change the compatibility to version 1.4 in the OSD of the screen and now it’s working! So at least I can stop playing with cables everyday.
For A. I will test as soon as possible, probably tomorrow.
B. I can’t access anything including the F keys unfortunately.
This time I waited long enough (12minutes) to see if the pc will finally start, no dice.
I checked the logs as you requested and find this, if I understood correctly sddm doesn’t succeed to launch Plasma? Keep in mind that I’m not a Linux power user so I will probably say something irrelevant.
jui 02 19:42:29 user sddm[924]: Auth: sddm-helper exited with 2
jui 02 19:42:29 user sddm[924]: Socket server stopping…
jui 02 19:42:29 user sddm[924]: Socket server stopped.
jui 02 19:42:29 user sddm[924]: Display server stopping…
jui 02 19:42:29 user systemd-logind[685]: Session 2 logged out. Waiting for processes to exit.
jui 02 19:42:34 user sddm[924]: Display server stopped.
jui 02 19:42:34 user sddm[924]: Running display stop script QList(“/usr/share/sddm/scripts/Xstop”)
jui 02 19:42:34 user sddm[924]: Removing display SDDM::Display(0x5df4ec41aef0) …
jui 02 19:42:34 user sddm[924]: Adding new display…
jui 02 19:42:34 user sddm[924]: Loaded empty theme configuration
jui 02 19:42:34 user sddm[924]: Xauthority path: “/run/sddm/xauth_ZXyJYS”
jui 02 19:42:34 user sddm[924]: Using VT 1
jui 02 19:42:34 user sddm[924]: Display server starting…
jui 02 19:42:34 user sddm[924]: Writing cookie to “/run/sddm/xauth_ZXyJYS”
jui 02 19:42:34 user sddm[924]: Running: /usr/bin/X -nolisten tcp -background none -seat seat0 vt1 -auth /run/sddm/xauth_ZXyJYS -noreset -displayfd 18
How can I share you the full logs please?
PS: Check my previous answer, if it could help to know the bug doesn’t appear if the screen is running DisplayPort 1.4 version
Here is the coredump log:
TIME PID UID GID SIG COREFILE EXE SIZE
Tue 2024-07-02 19:40:27 CEST 529 0 0 SIGSEGV inaccessible /usr/bin/ddcutil -
Mon 2024-07-01 20:25:01 CEST 11186 1000 1000 SIGSEGV present /usr/bin/plasmashell 99.6M
Mon 2024-07-01 20:08:00 CEST 1316 1000 1000 SIGSEGV present /usr/bin/plasmashell 108.5M
Mon 2024-07-01 19:23:02 CEST 1322 1000 1000 SIGSEGV present /usr/bin/plasmashell 102.6M
Mon 2024-07-01 19:20:38 CEST 1289 1000 1000 SIGSEGV present /usr/bin/plasmashell 103.6M
Mon 2024-07-01 19:20:37 CEST 3246 1000 1000 SIGSEGV present /usr/bin/systemsettings 13.9M
Mon 2024-07-01 08:30:42 CEST 539 0 0 SIGSEGV inaccessible /usr/bin/ddcutil -
Mon 2024-07-01 08:18:45 CEST 545 0 0 SIGSEGV inaccessible /usr/bin/ddcutil -
Sun 2024-06-30 21:23:38 CEST 1328 1000 1000 SIGSEGV present /usr/bin/plasmashell 101.7M
Sun 2024-06-30 20:54:12 CEST 518 0 0 SIGSEGV inaccessible /usr/bin/ddcutil -
Sun 2024-06-30 20:50:55 CEST 1337 1000 1000 SIGSEGV present /usr/bin/plasmashell 154.6M
Sun 2024-06-30 20:50:53 CEST 3908 1000 1000 SIGSEGV present /usr/bin/systemsettings 11.7M
Sun 2024-06-30 17:48:23 CEST 1342 1000 1000 SIGSEGV present /usr/bin/plasmashell 58.4M
Sun 2024-06-30 17:01:28 CEST 5232 1000 1000 SIGSEGV present /usr/bin/pipewire 566.3K
Sun 2024-06-30 16:36:48 CEST 1320 1000 1000 SIGSEGV present /usr/bin/plasmashell 134.9M
Sun 2024-06-30 15:21:45 CEST 1313 1000 1000 SIGSEGV present /usr/bin/plasmashell 101.9M
Sat 2024-06-29 11:06:54 CEST 1316 1000 1000 SIGSEGV present /usr/bin/plasmashell 101.8M
AFAIK for a USB-C to DP 2.1 you need a specific active cable for that.
Is that because of the laptop limited keyboard? Usually there’s an Fn that lets you recover the F key functionality.
I think you suppose i’m using a laptop but that is not true.
I’m on a computer with a classical DP to DP cable, not an adaptator. It’s the one from Samsung.
For the keyboard it’s also a regular keyboard, nothing prevent me to use the super keys. It just doesn’t work while the bug happen.
English isn’t my native language, sorry if something wasn’t crystal clear
Apologies, I was confusing your post with another discussion I was on.
If you can’t use your F keys while the issue is happening, then it sounds like an issue I have with KWin Wayland where it sometimes eats the CPU and prevents any input from being handled. When this happens to me, I can still SSH into the box, using an app on my phone. Can you check if you have a similar behavior?