I have just registered on the forum. I have little experience with Gentoo, but more or less, I think I'm getting the hang of it and my transition is not being as traumatic as I thought; even so I'm having some problems, including one that I don't know if it's the same as the one discussed in this thread but if not, it sounds very similar. So before opening a new thread I've taken the liberty of continuing this one. If you think it's not appropriate and I should open a new one, let me know and disqualify it.
In my case, Plasmashell stops working when I resume the session **with the monitor off** (I only have one monitor). If I first turn on the monitor and then flip the switch on the computer, the session resumes fine.
I've tried with a clean test user, and the same thing happens, so I'm ruling out a possible corruption of some configuration file of my regular user. I don't know if I'm right.
I'm also having some problems with SDDM that I'll check in another thread, but I don't know if they have anything to do with it because when I start the graphical session with `dbus-launch --exit-with-session startplasma-wayland` the same thing happens.
I'm in Plasma 6.2.5, KDE Frameworks 6.10.0 and Qt 6.8.1
Thank you.
P. D:
I forgot to mention that launching Plasmashell from Krunner works the first 2 or 3 times I come back from a suspended session. A while after the first restart of Plasmashell Krunner stops working to execute commands and only from a Konsole window I can execute `plasmashell` or `plasmashell &` , without ` --replace` since it doesn't work anymore either even from Konsole.
Plasma desktop crashes when monitor turned off
Message
Sorry, I forgot you were running a Pi5.
My Pi5's only have twm and dwm, they're essentially running a headless images for some docker apps. This does work and should be comprehensive enough to stop any "autoconfig", I left in the details for the second monitor because it's easier than writing it again if someone else needs them, you can ignore/delete them. The modes listed are for my monitor, the 60Hz one will probably work but you should update them (you can pull the relevant EDID data from Xorg.0.log, xrandr, or use one of the EDID readers in portage), though it may work if you remove them altogether (and references to them) but I can't test that so left them in.If you still have issues after this let me know and I'll build kde on one of them, but I'd be interested to know if the same bug appears on rasbian.
My Pi5's only have twm and dwm, they're essentially running a headless images for some docker apps. This does work and should be comprehensive enough to stop any "autoconfig", I left in the details for the second monitor because it's easier than writing it again if someone else needs them, you can ignore/delete them. The modes listed are for my monitor, the 60Hz one will probably work but you should update them (you can pull the relevant EDID data from Xorg.0.log, xrandr, or use one of the EDID readers in portage), though it may work if you remove them altogether (and references to them) but I can't test that so left them in.
Code: Select all
Section "Device"
Identifier "Card0"
Driver "fbdev"
EndSection
Section "Monitor"
Identifier "HDMI-1"
VendorName "Vendor"
ModelName "Model1"
DisplaySize 531 299
UseModes "Model1_Modes"
Option "PreferredMode" "Model1_Mode60"
Option "Primary"
EndSection
#Section "Monitor"
# Identifier "HDMI-2"
# VendorName "Vendor"
# ModelName "Model2"
# DisplaySize <monitor_width_mm> <montor_height_mm>
# UseModes "Model2_Modes"
# Option "PreferredMode" "Model2_Mode60"
# Option "RightOf" "HDMI-1" #<RightOf|LeftOf|SameAs>
#EndSection
Section "Modes"
Identifier "Model1_Modes"
ModeLine "Model1_Mode120" 297.00 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
Modeline "Model1_Mode75" 170.00 1920 1928 1960 2026 1080 1105 1113 1119 +hsync -vsync
Modeline "Model1_Mode60" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
Modeline "Model1_Mode50" 148.50 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync
EndSection
#Section "Modes"
# Identifier "Model2_Modes"
# ModeLine "Model2_Mode120" 297.00 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
# Modeline "Model2_Mode75" 170.00 1920 1928 1960 2026 1080 1105 1113 1119 +hsync -vsync
# Modeline "Model2_Mode60" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
# Modeline "Model2_Mode50" 148.50 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync
#EndSection
Section "Screen"
Identifier "ScreenL"
Device "Card0"
GPUDevice "Card0"
Monitor "HDMI-1"
SubSection "Display"
Virtual 1920 1080
Depth 24
EndSubSection
EndSection
#Section "Screen"
# Identifier "ScreenR"
# Device "Card0"
# GPUDevice "Card0"
# Monitor "HDMI-2"
# SubSection "Display"
# Virtual 1920 1080
# Depth 24
# EndSubSection
#EndSection
Section "ServerFlags"
Option "DefaultServerLayout" "SingleGPU"
Option "UseDefaultFontPath" "False"
Option "AutoAddGPU" "True"
Option "AutoBindGPU" "True"
EndSection
Section "ServerLayout"
Identifier "SingleGPU"
Screen 0 "ScreenL" 0 0
# Screen 1 "ScreenR" 1920 0
EndSection
Well, thanks for trying, but that didn't work! I had to make a couple of modifications to reflect my monitor as you suggested. I also included some lines which were in files in /etc/X11/xorg.conf.d. I also had to comment out the "fbdev" line to get it to work at all. The final file was:
With this file X works OK, but the problem is still there unchanged.
Code: Select all
Section "Device"
Identifier "Card0"
# Driver "fbdev"
EndSection
Section "Monitor"
Identifier "HDMI-1"
VendorName "Vendor"
ModelName "Model1"
DisplaySize 520 320
UseModes "Model1_Modes"
Option "PreferredMode" "1920x1200x60.0"
Option "Primary"
EndSection
#Section "Monitor"
# Identifier "HDMI-2"
# VendorName "Vendor"
# ModelName "Model2"
# DisplaySize <monitor_width_mm> <montor_height_mm>
# UseModes "Model2_Modes"
# Option "PreferredMode" "Model2_Mode60"
# Option "RightOf" "HDMI-1" #<RightOf|LeftOf|SameAs>
#EndSection
Section "Modes"
Identifier "Model1_Modes"
Modeline "1920x1200x60.0" 154.00 1920 1968 2000 2080 1200 1203 1209 1235 +hsync +vsync
ModeLine "Model1_Mode120" 297.00 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
Modeline "Model1_Mode75" 170.00 1920 1928 1960 2026 1080 1105 1113 1119 +hsync -vsync
Modeline "Model1_Mode60" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
Modeline "Model1_Mode50" 148.50 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync
EndSection
#Section "Modes"
# Identifier "Model2_Modes"
# ModeLine "Model2_Mode120" 297.00 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
# Modeline "Model2_Mode75" 170.00 1920 1928 1960 2026 1080 1105 1113 1119 +hsync -vsync
# Modeline "Model2_Mode60" 148.50 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync
# Modeline "Model2_Mode50" 148.50 1920 2448 2492 2640 1080 1084 1089 1125 +hsync +vsync
#EndSection
Section "Screen"
Identifier "ScreenL"
Device "Card0"
GPUDevice "Card0"
Monitor "HDMI-1"
SubSection "Display"
Virtual 1920 1200
Depth 24
EndSubSection
EndSection
#Section "Screen"
# Identifier "ScreenR"
# Device "Card0"
# GPUDevice "Card0"
# Monitor "HDMI-2"
# SubSection "Display"
# Virtual 1920 1080
# Depth 24
# EndSubSection
#EndSection
Section "ServerFlags"
Option "DefaultServerLayout" "SingleGPU"
Option "UseDefaultFontPath" "False"
Option "AutoAddGPU" "True"
Option "AutoBindGPU" "True"
Option "AllowIndirectGLX" "on"
Option "IndirectGLX" "on"
EndSection
Section "ServerLayout"
Identifier "SingleGPU"
Screen 0 "ScreenL" 0 0
# Screen 1 "ScreenR" 1920 0
EndSection
Section "OutputClass"
Identifier "vc4"
MatchDriver "vc4"
Driver "modesetting"
Option "PrimaryGPU" "true"
EndSectionThis is for HuskyDog's Pi5 only, whilst it may work for anyone using a modesetting driver, I have no hardware on which to test it.
For purely academic purposes only, here is a correct xorg.confThis will conflict with xorg.conf.d/99-v3d.conf, but because of the way the modesetting driver works it doesn't fix plasmashell (it does fix it if you install the ~fbdev driver and configure to use that).
So, I made a wrapper around plasmashell that watches for the error, then cycles the monitor off and on forcing plasmashell to behave:Adding the .start as login script, .stop as a logout script made it fix plasma every time I tried it. Depending on how long your monitor takes to "wake up and start communicating" you may need to increase the sleep time a little - so run it in a console and check before committing to use it as a login script.
This sort of stuff was much easier to deal with when you could just shut of the kscreen daemon!
For purely academic purposes only, here is a correct xorg.conf
Code: Select all
Section "Device"
Identifier "Card0"
Driver "modesetting"
Option "kmsdev" "/dev/dri/card1"
EndSection
Section "Monitor"
Identifier "HDMI-1"
VendorName "Vendor"
ModelName "Model1"
DisplaySize 531 299
UseModes "Model1_Modes"
Option "PreferredMode" "1920x1200x60.0"
Option "Primary"
EndSection
Section "Modes"
Identifier "Model1_Modes"
Modeline "1920x1200x60.0" 154.00 1920 1968 2000 2080 1200 1203 1209 1235 +hsync +vsync
EndSection
Section "Screen"
Identifier "Screen0"
Device "Card0"
GPUDevice "Card0"
Monitor "HDMI-1"
SubSection "Display"
Virtual 1920 1080
Depth 24
EndSubSection
EndSection
Section "ServerFlags"
Option "DefaultServerLayout" "SingleGPU"
Option "AutoAddGPU" "True"
Option "AutoBindGPU" "True"
Option "AllowIndirectGLX" "on"
Option "IndirectGLX" "on"
EndSection
Section "ServerLayout"
Identifier "SingleGPU"
Screen 0 "Screen0" 0 0
EndSectionSo, I made a wrapper around plasmashell that watches for the error, then cycles the monitor off and on forcing plasmashell to behave:
Code: Select all
#!/usr/bin/env python
from subprocess import Popen, PIPE, run
from time import sleep
global count
count=0
process=Popen(['/usr/bin/plasmashell','--replace'],stdout=PIPE,stderr=PIPE,encoding='UTF-8')
while not process.returncode:
line=process.stderr.readline().strip()
if line.find('unexisting screen available')>0:
count+=1
if count > 3:
args=(['/usr/bin/xrandr','--output','HDMI-1','--off'],['/usr/bin/xrandr','--output','HDMI-1','--auto'])
for arg in args:
run(arg)
sleep(1)
count=0Code: Select all
#!/bin/bash
ps -eo pid,cmd|grep "/home/$USER/bin/plasmafix.start$"|awk '{print $1}'|xargs kill 2>/dev/nullThis sort of stuff was much easier to deal with when you could just shut of the kscreen daemon!
Been working on this problem as well. I'm wanting to use plasma on a raspberry pi 5 where the screen will be turned on and off regularly and often. Here's what I've figured out:
The good news this exact config.txt seems to prevent the issue somewhat. It goes from happening every time the screen is turned off and on to rarely when the screen is power cycled:
The bad news:
I don't know why. It's a magic incantation as far as I can tell because I haven't been able to sus out why the crash happens so I don't know why these settings help. i know what they do, but any change and it's crashing every power cycle again.
Another thing I discovered is SSHing into the pi and running gdb --pid `pidof kwin_wayland` 2>&1 | tee kwin.gdb prevents the crash. I'm not sure where to go with that because I was hoping to use that discover what causes the crash. I briefly considered making a service to run that command on boot, but decided it'd probably be a resource drain. Plus using the debugger to fix a crash seems like a Jeff Foxworthy bit about rednecks using Linux.
The good news this exact config.txt seems to prevent the issue somewhat. It goes from happening every time the screen is turned off and on to rarely when the screen is power cycled:
Code: Select all
config_hdmi_boost=4
usb_max_current_enable=1
dtparam=i2c_arm=on
dtparam=i2s=on
dtparam=spi=on
dtparam=audio=on
arm_64bit=1
disable_overscan=1
dtoverlay=vc4-kms-v3d
dtparam=audio=on
disable_fw_kms_setup=1
#this line is probably only useful for me
kernel=kernel_2712_custom.img
I don't know why. It's a magic incantation as far as I can tell because I haven't been able to sus out why the crash happens so I don't know why these settings help. i know what they do, but any change and it's crashing every power cycle again.
Another thing I discovered is SSHing into the pi and running gdb --pid `pidof kwin_wayland` 2>&1 | tee kwin.gdb prevents the crash. I'm not sure where to go with that because I was hoping to use that discover what causes the crash. I briefly considered making a service to run that command on boot, but decided it'd probably be a resource drain. Plus using the debugger to fix a crash seems like a Jeff Foxworthy bit about rednecks using Linux.
So this is a bandaid solution I came up with. Basically in GUI context it loops plasmashell --replace so that whenever it crashes there's another to take its place. This works because plasmashell --replace is blocking so the script will patiently wait for it to end to continue the loop. It uses KDE autostart to make sure it's in the GUI context.
I fear in a mixed DE environment it might causes issues (I don't know if the autostart folder applies to Gnome or other DEs and I suspect launch plasmashell in Gnome for example would cause issues).
~/.local/bin/localcmd
~/.config/autostart/localcmd.desktop
I fear in a mixed DE environment it might causes issues (I don't know if the autostart folder applies to Gnome or other DEs and I suspect launch plasmashell in Gnome for example would cause issues).
~/.local/bin/localcmd
Code: Select all
#!/bin/bash
while :
do
plasmashell --replace
done
Code: Select all
[Desktop Entry]
Comment[en_US]=
Comment=
Exec=~/.local/bin/localcmd
GenericName[en_US]=
GenericName=
Icon=application-x-executable-script
MimeType=
Name[en_US]=localcmd
Name=localcmd
Path=
StartupNotify=true
Terminal=false
TerminalOptions=
Type=Application
X-KDE-AutostartScript=true
X-KDE-SubstituteUID=false
X-KDE-Username=