Hi, I just got a new laptop with OLED screen and have installed Arch KDE on top of it. The bizarre thing is that the OLED screen will not respond to any keybind once its brightness has gone to 0%, I understand that OLED dimming in Linux is relatively new and was only officially supported by 5.12, but does anyone have any clue to fix it?

A more relevant question to KDE, as a workaround, is there any ways I could prevent screen dimming under the energy saving tab to go below 5% brightness? I would still like to have the functionality of screen dimming.

Any help or support is much appreciated. Thank you!

Hi!

What laptop model do you use? Graphics card? Backlight? What kde packages did you install? Did you set up acpid or similar? Does setting the brightness with `brightnessctl` work as expected (small tool with the same package name)?

koffeinfriedhof wrote:Hi!

What laptop model do you use? Graphics card? Backlight? What kde packages did you install? Did you set up acpid or similar? Does setting the brightness with `brightnessctl` work as expected (small tool with the same package name)?

Hi, thank you for the reply,

Here's the model information about my laptop, it's a asus zenbook UX3402, with igpu for rendering, I've only installed the minimal package in arch (plasma-meta). I didn't set up acpid. And yes, brightness control works just fine with brightnessctl, I could echo in values out of 512 into /sys/class/backlight/intel_backlight/brightness and it would work. Just that I couldn't turn it back up from 0%. I've never used acpid before but from the looks of it I could create an event that triggers according to different preconditions, do you think I should do that to override the default brightness control keybinds for KDE? Thank you so much for your inspiration.

Code: Select all

dmidecode:
        System Information
        Manufacturer: ASUSTeK COMPUTER INC.
        Product Name: Zenbook UX3402ZA_Q409ZA
        Version: 1.0
        Serial Number: N3N0LP029682129
        UUID: 9f6e58c8-8e40-8444-bb29-44b782bf0228
        Wake-up Type: Power Switch
        SKU Number: 
        Family: Zenbook

Code: Select all

 lshw -class display:
  *-display                 
       description: VGA compatible controller
       product: Alder Lake-P Integrated Graphics Controller
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       version: 0c
       width: 64 bits
       clock: 33MHz
       capabilities: vga_controller bus_master cap_list rom
       configuration: driver=i915 latency=0
       resources: iomemory:600-5ff iomemory:400-3ff irq:181 memory:603e000000-603effffff memory:4000000000-400fffffff ioport:3000(size=64) memory:c0000-dffff memory:4010000000-4016ffffff memory:4020000000-40ffffffff

Code: Select all

 inxi:
CPU: 12-core (4-mt/8-st) 12th Gen Intel Core i5-1240P (-MST AMCP-)
speed/min/max: 569/400/4400:3300 MHz Kernel: 5.18.12-arch1-1 x86_64
Up: 18m Mem: 3869.7/7573.5 MiB (51.1%) Storage: 1.86 TiB (1.2% used)
Procs: 325 Shell: Bash inxi: 3.3.19

I cannot tell you if you should change key bindings as on my laptop brightness changes via "invisible" keybinds and the surface gets its updates due to watching the hardware file changes.

So if I understand you correctly you can set a 0 value with brightnessctl but cannot go back to a higher setting once set? Is there some information in the logfiles (`journalctl -b -p err`[i] or [i]warning) if you use a command line like

Code: Select all

brightnessctl set 0; sleep 2; brightnessctl set 20%

Yes, that is correct, it actually took me a while to narrow down the problem to the display. As by default KDE would go to screen saving mode in idle and I was just scratching my head as to why the laptop would be stuck in a black screen despite no coredumpctl or dmesg error messages.

I have tried out the commands you mentioned, and yeah, once the display turned to 0, it wouldn't turn by up the brightness set afterward. There's no error logs and when I resume from the sleep, the screen was set to that brightness, just that it didn't turn up from 0.

So I think I should mention this, the only way I can turn the screen back up without reboot is to close the lid (so it goes to sleep), and wake up from sleep. What difference does it during the resume process that is different than simply turning up the brightness from zero?

Durian_Pie wrote:What difference does it during the resume process that is different than simply turning up the brightness from zero?

On sleep, hibernate, hybrid, etc. some kernel modules are unloaded and reloaded on wakeup. So your graphics adapter/screen gets a kind of "reset".

Can you try the kernel option (bootoption) acpi_backlight=native and see if it changes anything? And I'd set up acpid first and apply intels microcode stuff.

I have this exact issue (zenbook 14 OLED with intel 12th gen). Same model laptop, I believe. I'm in KUBUNTU 22.04.

Everything works great except for the issue stated. It seems that "turning off" the screen (going to 0 brightness, or shutting it off/"blanking" after no activity) causes the hardware to stop responding? There are no error messages that I can find. Under the energy saving settings, there is an option to "dim screen" (after X minutes) and to "Screen Energy Saving" (switch off after X minutes). With only "dim" it actually incrementally dims the screen once every 30 seconds or so, until it turns off entirely (is this intentional? It may be an interaction with xscreensaver which has a "fade to black when blanking?)). This is unrecoverable without closing the lid. The "switch off" does what it says and makes it unrecoverable without closing the lid in one jump (if I turn off the dimming). Under windows 11 which comes with the laptop, it can blank and will turn on correctly by touching keyboard or mouse.

As he noted, the computer is still running -- just the screen is off. I can run commands and change the brightness (in the OS) -- but the actual brightness on the screen does not change at all (it stays turned off). Once I close/open the lid -- the brightness goes up to some high value at the welcome (unlock) screen, and after I unlock it it stays at that high brightness value. Once I manpulate the brightness again though (via keys or brightnessctl etc.), it jumps back down to whatever level I had set it at (while the screen was off). The values are reflected correctly in /sys/class/backlight/intel_backlight/actual_brightness etc.

This suggest to me it is some hardware specific thing, rather than KDE, but I am open to ideas. Does KDE do something with brightness on the login splash screen?

I want to note also that there is quite a large battery drain while the lid is closed -- roughly 5% per hour -- which seems really high to me especially for such a new laptop. journalctl and dmesg have messages suggesting that the computer did indeed suspend, but I suspect that power mode for some things are not being toggled correctly. I checked it, and indeed you need to set the mem_sleep_default=deep kernel option...otherwise it uses light sleep (s2).

Did you try the kernel command line parameter?

Kubuntu, as all stable distributions, is too old to support newest hardware. Try setting up an arch linux, suse tumbleweed another rolling release distro or a custom kernel based on the latest upstream branch with all proprietary firmware available for your devices (also called firmware blobs).

If the problem occurs with the latest kernel too, submit a well formed bug report with technical informations and outputs to get help from kernel devs.

koffeinfriedhof wrote:Did you try the kernel command line parameter?

Kubuntu, as all stable distributions, is too old to support newest hardware. Try setting up an arch linux, suse tumbleweed another rolling release distro or a custom kernel based on the latest upstream branch with all proprietary firmware available for your devices (also called firmware blobs).

If the problem occurs with the latest kernel too, submit a well formed bug report with technical informations and outputs to get help from kernel devs.

Hey, thanks!
Yes, I tried the backlight parameter (=native) if that is what you are asking. No change. Seemed to work exactly the same.

Of course I understand it won't support newest hardware -- I suppose these OLED displays are quite new in that regard and so I am not super surprised. Actually, everything works fine except for this one weird issue...so as my linux-on-laptops experiences over the last 20 years go, it is a big success, haha.

I feel this is really not a problem for the KDE forums (although OP put it here) -- I suspect that it is a firmware issue, as you say. But, I appreciate the help!

The OLED screens aren't that new, but hardware implementations getting worse. For nearly every piece of new hardware there has to be a workaround found, acpi is often implemented without knowledge, etc. The sell-and-forget nowadays doesn't make it better. But this was customers choice, so we are the ones to blame.
Neverthless, you must use the firmware blobs on newer hardware and keep it updated. I do not exactly know Ubuntus policy with fwupd-stuff, but I imagine it is as old as the rest. So manually lookup uefi-updates, intel and amd microcode and whatever your system needs. Perhaps there is a PPA for it already.

There are other options in the acpi_backlight-section to test: https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt. But the first thing is to use an actual kernel build.

Hi, Im having the same issue.

Dell XPS 15 Oled.

The below command works to set the display off and on:
xrandr --output eDP-1 --brightness 0; sleep 1; xrandr --output eDP-1 --brightness 1

Worse yet if you dont disable screen off after 10 min you need to restart THANKS (this sucks)

This means that is not impossible.

Please fix this

Work around:

Set custom shortcut, with the actions below + to inc - to dec:
bash <PATH-TO-SCRIPT> +
bash <PATH-TO-SCRIPT> -


``` Script

# !/bin/bash

currentBrightness=$(expr `xrandr --verbose | grep -m 1 -i brightness | cut -f2 -d ' '`)

case $1 in
+)
# If increasing brightness dont allow above 100% (causes screen to become washed out)
if [ `printf '%s' $currentBrightness` != "1.0" ]
then
xrandr --output eDP-1 --brightness $(awk '{print $1+$2}' <<< "$currentBrightness 0.10")
fi
;;
-)
# If you dont have this the brightness would go back to 100% if you are already at 0%
if [ `printf '%s' $currentBrightness` != "0.0" ]
then
xrandr --output eDP-1 --brightness $(awk '{print $1-$2}' <<< "$currentBrightness 0.10")
fi
;;
esac

```

I think this does not solve the original problem of a bad firmware. So what does your script-workaround solve? Missing keybindings? Could be easier done with "brightnessctl" instead of X.

Running Kubutnu 22.04

brightnessctl isnt installed.

The workaround is to prevent you from not being able to use your machine without restarting if brightness was set to zero using default brightness controls.

The other issue is the script messes with night colors so you have to toggle it if you change the brightness with night mode one (its workable)

I agree 100% would like a proper fix

Seeing the exact same issue on a new Lenovo ThinkPad Yoga X1 Gen 7 (OLED at 3840x2400; software version details below this post).

Observations:

• Screen brightness controls in KDE work normally as long as brightness stays above 0
• Bug triggered when manually changing screen brightness to 0, and when KDE automatically does this after some inactivity
• Screen brightness control button cannot re-enable display
• Interesting: executing

  Code: Select all

   xrandr --output eDP-1 --brightness 1

  through a custom script that is activated with a global shortcut also cannot re-enable display
• Closing the lid (sleep) and opening it again works (brings back the display).

In contrast, if I set display brightness to 0 using xrandr as shown above:

• KDE brightness keys still do not work (fail to increase brightness above 0)
• My custom shortcut works (re-enables the display)

Therefore, curiously, there is a difference between "KDE disables screen" and "xrandr disables screen", and xrandr can recover from the latter only. It would be interesting to find a workaround to recover from the KDE blackscreen using the command line (then one could have sth. like "Meta+Monitor Brightness Up" as a rescue key combination).

Btw, since it was mentioned above, it is possible to control the KDE redshift from the command line (though only slowly, with fade in and fade out):

Code: Select all

qdbus org.kde.kglobalaccel /component/kwin org.kde.kglobalaccel.Component.invokeShortcut "Toggle Night Color"

Not sure if calling this twice (probably with a sleep in between) would be useful in the script shown earlier in this thread, but it might be useful in some workarounds.

Anyway, a proper fix is urgently needed here. This is fundamental functionality and OLED hardware is getting rather common.

Here are my specs:
- Distribution: KDE neon 5.26
- KDE Plasma v 5.26.3
- KDE Frameworks v 5.100.0
- Kernel 5.15.0-53-generic
- X11