Screen turns off after KDE Splash-Screen

I’ve installed Arch on my Chromebook (BUGZZY, see mrchromebox.tech) and in one afternoon I’ve got nearly everything working. Apart from one weird issue:
After logging in (SDDM) to Plasma (both Wayland and X11 tested) the Splash-screen shows up as expected, and then the screen turns black. Only the screen is not on, sound still works. After closing the lid and reopening after a few seconds, everything works fine (even the rotation).
The same issue happens when changing the resolution. I have tried:

  • Disabling hardware acceleration; that only broke SDDM.
  • Installing the necessary packages didn’t do anything
  • Setting scaling to 100% and rotation to normal – also did nothing
  • Budgie desktop – did work, but I prefer KDE Plasma ofcourse :slight_smile:
  • There is 30 GB free and .Xauthority is not there (it’s here: /run/user/1000/xauth_nVDjYY)
  • Tested with a new user: didn’t work
  • A different OS did work, but I prefer Arch
  • Confirmed all Xorg and Wayland packages (that seem slightly relevant) and Intel drivers are installed
  • And more
    But I keep having the exact same issue.
    Does anyone have an idea how to fix this issue? Could .Xauthority be the issue? When I have tried to set it to ~/.Xauthority it staid at /run/user/1000/xauth_nVDjYY…

Relevant details (neofetch --off):
OS: Arch Linux x86_64
Host: Google Bugzzy
Kernel: 6.14.7-arch2-1
Packages: 880 (pacman), 8 (flatpak)
Shell: fish 4.0.2
Resolution: 1600x2560
DE: Plasma 6.3.5 (Wayland)
WM: KWin
Theme: Breeze [GTK2/3]
Icons: breeze [GTK2/3]
Terminal: konsole
CPU: Intel Celeron N4500 (2) @ 2.800GHz
GPU: Intel JasperLake [UHD Graphics]
Memory: 2708MiB / 3763MiB

That sounds like an issue with the lid sensor to me. The first component that actually handles lid closed signals is loaded during the Plasma splash-screen, which would explain why it turns off at that moment.
It is possible that either the kernel has some bug on your hardware resulting in incorrect values, or that the firmware of your device is at fault.
Of course it could also be a bug in Plasma, but given that it is somewhat special hardware, that is probably less likely.

Yes, but then it wouldn’t also happen when changing display settings, right? And the issue only occurs in KDE Plasma…
EDIT:
The output of journalctl --user-unit=plasma-plasmashell.service --boot 0 --no-pager

ei 29 18:29:31 arch-bugzzy systemd[680]: Starting KDE Plasma Workspace...
mei 29 18:29:31 arch-bugzzy systemd[680]: Started KDE Plasma Workspace.
mei 29 18:29:32 arch-bugzzy plasmashell[923]: kf.plasma.quick: Applet preload policy set to 1
mei 29 18:29:32 arch-bugzzy plasmashell[923]: file:///usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/main.qml:178:25: QML FolderViewDropArea (parent or ancestor of QQuickLayoutAttached): Binding loop detected for property "minimumWidth":
                                              file:///usr/share/plasma/plasmoids/org.kde.desktopcontainment/contents/ui/main.qml:201:9
mei 29 18:29:32 arch-bugzzy plasmashell[923]: Toolbox not loading, toolbox package is either invalid or disabled.
mei 29 18:30:11 arch-bugzzy plasmashell[923]: file:///usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/main.qml:310:13: QML Image: Cannot open: file:///usr/share/plasma/plasmoids/org.kde.plasma.kickoff/contents/ui/start-here-kde-symbolic
mei 29 18:30:12 arch-bugzzy plasmashell[923]: org.kde.applets.brightness: D-Bus action "KeyboardBrightnessControl" is not available at service "org.kde.Solid.PowerManagement"
mei 29 18:30:13 arch-bugzzy plasmashell[923]: org.kde.applets.brightness: D-Bus action "KeyboardBrightnessControl" is not available at service "org.kde.Solid.PowerManagement"
mei 29 18:30:19 arch-bugzzy plasmashell[923]: Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
mei 29 18:30:19 arch-bugzzy plasmashell[923]: kf.kunitconversion: currency conversion table data obtained via network
mei 29 18:30:56 arch-bugzzy plasmashell[923]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/delegates/DelegatePopup.qml:147:17: QML Body: Binding loop detected for property "width"
mei 29 18:30:56 arch-bugzzy plasmashell[923]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/delegates/DelegatePopup.qml:147:17: QML Body: Binding loop detected for property "width"
mei 29 18:32:10 arch-bugzzy plasmashell[923]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/delegates/DelegatePopup.qml:147:17: QML Body: Binding loop detected for property "width"
mei 29 18:32:10 arch-bugzzy plasmashell[923]: file:///usr/share/plasma/plasmoids/org.kde.plasma.notifications/contents/ui/delegates/DelegatePopup.qml:147:17: QML Body: Binding loop detected for property "width"

Hopefully someone with a bit more knowledge about powerdevil can have a look. I think it would be really useful to know what powerdevil thinks is the state of the lid sensor, and which actions it triggers in response.

Unfortunately I do not know how to debug this, I’m usually doing work on apps and not much on Plasma itself

Well, I have been able to fix my problem because of your response! After searching the powerdevil logs, I have found this thread with the solution to downgrade ddcutil and powerdevil:

I had to downgrade both ddcutil and powerdevil to get it to work again. The last known working combination is:
ddcutil-1.4.1-1 (downgraded from ddcutil-2.0.0-1)
powerdevil-5.27.9-1 (downgraded from powerdevil-5.27.9-2)
sudo pacman -U https://archive.archlinux.org/packages/d/ddcutil/ddcutil-1.4.1-1-x86_64.pkg.tar.zst https://archive.archlinux.org/packages/p/powerdevil/powerdevil-5.27.9-1-x86_64.pkg.tar.zst
Thank you very much, jbb!

1 Like

For anyone with the same issue:
Please first try this solution before changing packages:
Adding --disable-cross-instace-locks to $HOME/.config/ddcutil/ddcutilrc fixed all my problems!

KDE Plasma 6

ddcutil commands fail after upgrade to version 2.0 and KDE Plasma 6
ddcutil 2.0 added a cross-instance locking facility. The problem addressed was random failures when multiple ddcutil or libddcutil instances clobber each other’s DDC transactions. Internally, ddcutil uses what are called display handles to represent /dev/i2c devices that have been opened at the OS level. Proper use of the API is, for each DDC transaction, to open a display, creating a display handle, perform the transaction, and then close it. This sounds expensive, but in fact the time spent opening and closing is negligible compared to the time spent performing the I2C operations of a DDC transaction.
When the cross-instance locking facility is enabled, and a display is opened creating display handle, ddcutil calls flock() on the underlying /dev/i2c device and holds the flock until the handle is closed. Unfortunately, at startup PowerDevil creates a display handle for each /dev/i2c device and never closes it. So the flock’s are never released, blocking other ddcutil instances.
Cross-instance locking can be disabled using option --disable-cross-instance-locks. This option can be specified on the ddcutil command line, or in configuration file $HOME/.config/ddcutil/ddcutilrc. The latter is the only way to control libddcutil, which is used by PowerDevil.

(see ddcutil FAQ)