I have an issue with the screen brightness on Ubuntu 26.04 - currently using kernel 7.0.0-22.
Every time I power on my laptop, the brightness is set to 100%. I manually reduce it to 50% and everything works normally during the session. However, after a reboot or a complete shutdown, the brightness is again restored to 100% instead of keeping the previous value.
I have already tried several alternative solutions but none of them fixed the problem. On my previous installation of Ubuntu 22.04.5 the brightness was restored correctly after every reboot, so this issue only appeared after upgrading to Ubuntu 26.04.
Could this be a regression in the current kernel eg. 7+ or Ubuntu 26.04? Is it something that might be fixed in Ubuntu 26.04.1, or could it be a compatibility issue with my laptop?
This isn’t a kernel regression, it just looks like one because of the timing. I’ve hit this exact issue before and it’s almost always the same cause: two backlight interfaces sitting under /sys/class/backlight/, and whatever saves/restores brightness on shutdown writes to the wrong one.
Check first:
ls /sys/class/backlight/
If you see both intel_backlight and acpi_video0, that’s it. systemd-backlight generates a save/restore unit for each interface it finds, but on a lot of Intel laptops only one of them actually reflects real hardware state. The other one sits at (or gets written as) max, and on boot systemd restores from whichever one it saved last, which can be the wrong one. You can confirm by checking /var/lib/systemd/backlight/ for the saved value files, or running:
systemctl status "systemd-backlight@backlight:*"
The fix that’s worked reliably for me across several Ubuntu releases is forcing the kernel to use native backlight control instead of splitting it between ACPI and native. Edit /etc/default/grub, add acpi_backlight=native to GRUB_CMDLINE_LINUX_DEFAULT, then:
sudo update-grub
and reboot. If it’s still not right, mask the unit for the wrong interface (confirm which one first, don’t just copy this):
zram/zstd has nothing to do with this, backlight restore happens well before that’s even relevant, so you can rule it out.
22.04.5 was fine and 26.04 isn’t:
it’s not that restore logic broke, it’s that the kernel now exposes a second backlight node for your Satellite L50 that didn’t show up before, which is a known category of issue on Toshiba/Intel hardware depending on how i915 and the ACPI video driver negotiate control. Try the grub parameter first, it fixes the large majority of cases like this.
It’s all but certain to be a driver issue. I don’t know the solution, but when I had a similar problem before it was fixed, I had to add acpi_backlight=native to the GRUB boot.
On 24.04 and prior, this was easy, but with 26.04 I don’t know how to do this because the whole mechanism has changed. I only know how to make the change permanent, but you don’t want to do this in case it breaks your system.
This is how you make a permanent change — don’t do this in case it breaks your system. Only do this if it proves to fix the problem.
sudo snap set system system.kernel.dangerous-cmdline-append=“acpi_backlight=native”
I’ve tried to find out how to make a temporary change in 26.04, but haven’t succeeded, sorry. At least you know the command that might work. I’m hoping that someone else will chip in here with how to make a temporary change.
I don’t think that works on a standard (TPM/FDE) installation, because it requires the model assertion to be “dangerous” as well. At least I seemed unable to make it work.
How did you check? I’m still very unsure about this whole process. Here is what I tried:
Before the change:
$ cat /proc/cmdline
snapd_recovery_mode=run console=ttyS0,115200n8 console=tty1 panic=-1 quiet splash snapd.xkb="gb,pc105,,"
$ sudo snap get system system.kernel.dangerous-cmdline-append
error: snap "core" has no "system" configuration option
$ sudo snap set system system.kernel.dangerous-cmdline-append="acpi_backlight=native"
After the change:
$ cat /proc/cmdline
snapd_recovery_mode=run console=ttyS0,115200n8 console=tty1 panic=-1 quiet splash snapd.xkb="gb,pc105,,"
$ sudo snap get system system.kernel.dangerous-cmdline-append
acpi_backlight=native
You’ll notice that /proc/cmdline has no change. Thus, I don’t know how to check that the new boot option was in fact applied.
Well, I guess that proves Peters point then (I wasn’t actually aware we could have grade: signed on non Core installs (the existence of deb packages on the system kind of makes that technically pointless (it is usually used to confirm a fully locked down system))
I had the understanding that the TPM-backed FDE installation of 26.04 did in fact use Ubuntu Core at its base. I don’t recall where I read that, sorry.
It does indeed, but the model assertion tells snapd that the system is immutable and locked when it is signed which is indeed not the case when you have half of the system managed via debian packages that can change everything (though that is just the German in me nitpicking about the buerocracy being off, I doubt it has any actual impact)
(If it would be actually Ubuntu Core it would also use the core26 snap as rootfs though, it only uses gadget and kernel from Core (i.e the necessary bits for TPM/FDE) in this setup)
If it worked correctly on Ubuntu 22.04.5 with the same laptop, this does suggest a regression rather than a hardware issue. I’d try booting an older kernel from GRUB to see if the behavior changes, and check journalctl/dmesg for any backlight-related errors. It may also be worth reporting it as a bug if others on 26.04 are seeing the same issue, as it could be fixed in a future kernel or the 26.04.1 release.
Not necessarily, because there were some major backlight handling changes in kernel version 6.1, and the GA kernel of 22.04 is 5.15.
BTW, how has this not raised any red flags?
There is no direct upgrade path to 26.04 from 22.04, but if @devilboy somehow managed to do that anyway, that’d be my best guess for the actual cause of the issue at hand.
I did not have the exact same issue, but at some point my laptop brightness restored to way too low a level. The actual reason was that, in the meantime, thinkpad_acpi had yielded its handling of brightness control to to the ACPI video driver:
Jun 21 23:34:26 Roadrunner kernel: thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, supported by the ACPI video driver
Jun 21 23:34:26 Roadrunner kernel: thinkpad_acpi: Disabling thinkpad-acpi brightness events by default...
...
Jun 21 23:34:26 Roadrunner kernel: thinkpad_acpi: Standard ACPI backlight interface available, not loading native one
And the brightness scale had changed from 8 bits (0..255) to (something close to) 16 bits (0..64764) but restore logic seemed to pick up the value from the old scale and passed it on unchanged to the new driver. I don’t remember all the details, but there was something wrong with the state not being written correctly, or not at all, on shutdown.
That episode somewhat matches @marcelstevano’s description of the save/restore problem. If OP has managed to upgrade directly from 22.04 to 26.04, which, ill-advised and discouraged though it may be, should be technically possible — it’s just APT doing APT things, after all —, then some migration logic might not have run.
That’s why I assumed that the model assertion didn’t fit; the change simply was not applied.
But I also think we shouldn’t assume TPM/FDE here, because there is no known upgrade path; must be a clean install from scratch.
I’m really excited that I’ve finally joined the Ubuntu family permanently.
I also want to correct something I wrote earlier. I didn’t upgrade directly from Ubuntu 22.04.5 to Ubuntu 26.04, as that’s not possible. I was using Ubuntu 22.04.5, but I wanted to try Ubuntu 26.04 - and yes, I fell in love with it, even though I only have 6.69 GB of available RAM.
I’ll go through each of your suggestions one by one and see if any of them solve the issue. Personally, I think it might be a bug, although I’m not an expert and I hope it gets fixed in Ubuntu 26.04.1.
I had already tried the GRUB parameters before, and none of them worked, but I’ll go through all the advice you’ve shared here and come back with an update.
Thank you all so much. You’ve made me feel very, very welcome!
Did you upgrade from 22.04 to 24.04 to 26.04, or did you create a clean install?
If it was a clean install, did you choose full-disk encryption with TPM-backed encryption? If you don’t know or don’t remember, post the results of this command:
It’s likely to be a specific type of bug known as a “regression”, as mentioned earlier. It would be worth reporting, but let’s first answer the previous questions.