Brightness control doesn't work right on Ubuntu Mate 22.04.1

Hello, I'm running Ubuntu Mate 22.04.1 LTS on my Lenovo Thinkpad x280 and I'm having issues with brightness control. If I use FN keys to set brightness, once rebooted the brightness is reset to what is in Power Management Preferences.
If I use xrandr or /sys/class/backlight/intel_backlight/brightness still the same, the brightness is reset to whatever is set in Power Management Preferences.

Basically, it doesn't matter what I do, the brightness settings are reset to whatever is set in Power Management Preferences -> Set display brightness to

I did changes to grub and whatever else, nothing changes. Please note that this wasn't happening on openSUSE with Xfce.

Any ideas?

I think it is operating normally.
Open the Power Management Preference screen.
On my UM22.04.1 Dell when I use fn keys to change screen brightness the slider (Set display brightness to:) in the PMP screen changes to current brightness level, thus when rebooting it would use that setting.
I might be missing something on my end though.


1 Like

Yes, you are missing something. If I use the FN keys to set the brightness, it should stay like that after reboot, but it will always default to the Power Management settings. This would not happen on Xfce (openSUSE). I actually have the same issue even with the keyboard backlight, it was always on, no matter what until I found a 'workaround' online. Like I said before, the settings from FN or whatever should match everywhere else and should be saved once you reboot, should default to something else.

I do that and I get this.
fn key 65 reboot, check PM 65
fn key 100 reboot, check PM 100
fn key 5 reboot, check PM 5
Works here gif shows PM as using fn key

Have you submitted a bug for this? If not, please do. Bug Reporting and Triage | Ubuntu MATE

Until this is fixed in Ubuntu MATE, as a work around, you could create a script that sets the brightness at the desired level, then run that script at boot time using Startup Applications.

1 Like

I haven't reported a bug as I'm not sure or wasn't sure if its a bug or not.

I acknowledge this behaviour on some hardware but not on others.

I'll leave some specs of two of my laptops ( inxi -SMz ) in the hope that it can help a bit to find a solution.

On my home/dev laptop it works like @mendy describes (which is the correct way):

  Kernel: 5.15.0-47-generic x86_64 bits: 64 Console: pty pts/0
    Distro: Ubuntu 22.04.1 LTS (Jammy Jellyfish) Desktop: mate 1.26.0
  Type: Laptop System: LENOVO product: 4180AJ3 v: ThinkPad T420
  Mobo: LENOVO model: 4180AJ3
    UEFI-[Legacy]: LENOVO v: 83ET71WW (1.41 ) date: 07/23/2012

On my work/travel laptop it works like @robertalks describes

  Kernel: 5.15.0-46-generic x86_64 bits: 64 Console: tty 0 
  Distro: Ubuntu 20.04.5 LTS (Focal Fossa) Desktop: mate 1.24.0
  Type: Laptop System: Acer product: Swift SF114-34 v: V1.07 
  Mobo: JSL model: Labatt_JL v: V1.07
   UEFI: Insyde v: 1.07   date: 03/21/2021 

It might be a kernelbug, although I rate the chance low because:

  1. the kernel versions are almost identical.
  2. Robert uses a thinkpad with, I persume, the same kernel and desktop as my thinkpad.

So it might be a non-conform (BIOS/UEFI) ACPI implementation by the OEM (which is pretty common)

I'm not sure if this is really a kernel bug as one of the apps can control properly the blacklight, but not others, maybe the method is the issue, but not sure at all.

Post your specs by issuing

inxi -SMz

and compare it to my Thinkpad specs.
If kernel version, distro version and desktop version are the same as my Thinkpad, you can bet your bottom that the problem is in the UEFI/Motherboard-firmware (or whatever the BIOS is called these days).

robert@pandora:~$ inxi -SMz
  Kernel: 5.15.0-47-generic x86_64 bits: 64 Console: pty pts/0
    Distro: Ubuntu 22.04.1 LTS (Jammy Jellyfish)
  Type: Laptop System: LENOVO product: 20KES2WD08 v: ThinkPad X280 serial: <superuser required>
  Mobo: LENOVO model: 20KES2WD08 v: SDK0J40697 WIN serial: <superuser required> UEFI: LENOVO
    v: N20ET60W (1.45 ) date: 11/12/2021

Yep, we run both exactly the same software setup.

That means that the behavioural difference it is highly likely due to a different ACPI implementation in UEFI/firmware which is motherboard bound. Nothing we can do about that.

Is it possible that the issue is related to the fact that secure boot is disabled?

no, i don't think so. I also have my secureboot disabled.

can you do inxi -G ?

robert@pandora:~/git$ DISPLAY=:0 inxi -G
  Device-1: Intel HD Graphics 620 driver: i915 v: kernel
  Device-2: Chicony Integrated Camera (1280x720@30) type: USB
    driver: uvcvideo
  Display: server: X.Org v: driver: X: loaded: intel gpu: i915
    resolution: 1920x1080~60Hz
  OpenGL: renderer: Mesa Intel HD Graphics 620 (KBL GT2) v: 4.6 Mesa 22.0.5

Good. We even run the same video driver ( i915 ).
The only thing left to do is follow the advice of @goinglinux and report this as a bug.

The kernelteam can't fix the BIOS for you but they can (and did so numerous times) patch the umpteenth ACPI workaround in the kernel.

You might have a very small chance to fix it yourself by doing a BIOS update but I wonder if it's worth the hassle and the risk.

On my work laptop (the Acer) i have the same behaviour. I never thought about it actually.
Maybe because I couldn't care less. I'm used to it and it has some pro's actually.

If you feel like experimenting a bit,
there are several thinkpad tools:

apt search thinkpad

and several backlight tools

apt search backlight

If you have the GUI-packet manager "synaptic" installed, it makes it a bit easier to browse around in the repository, like , it gives you the packetnames and descriptions in one go.

Also visit this link for more detailed info about ACPI and backlight, including workarounds for backlight issues:

1 Like

might have fixed it with a bios update, i need to check a bit more, but maybe :slight_smile:

Alright, seems BIOS update as fixed this issue, thanks for all the help!