You are not logged in.
Every time the screen turns on, the actual brightness is set to maximum. The brightness "reported" by the system (gnome settings, /sys/class/backlight/intel_backlight/brightness, etc.) still shows the value it was previously set to. Changing the brightness (like pressing a brightness key) immediately restores it back to the right brightness. If that's relevant, I noticed when this happens, the value in /sys/class/backlight/intel_backlight/actual_brightness is 0 instead of being the same as the brightness file.
This happens not just on boot and waking up from sleep, but also when only the screen gets turned off due to inactivity.
Started happening in kernel 6.15 and persists in 6.16.
DE: gnome on wayland
Kernel: linux 6.16.arch2-1
Graphics: Intel Arc 140V (Lunar Lake)
Last edited by miguel375 (2025-09-02 09:22:35)
Offline
also when only the screen gets turned off due to inactivity.
Ie. dpms.
Does this also happen w/ the LTS kernel?
If yes: does it w/ gnome/X11?
Offline
also when only the screen gets turned off due to inactivity.
Ie. dpms.
Does this also happen w/ the LTS kernel?
If yes: does it w/ gnome/X11?
Just tried the LTS kernel and it doesn't happen, it works as expected.
Offline
Can you control the default backlight in the UEFI?
Does it reset to that or the maximum level regardless?
Can you run some X11 session, "xset dpms force off", wait some minutes and after waking the output post your Xorg log, https://wiki.archlinux.org/title/Xorg#General ?
(I suspect what might happen is that the output unregisters and gets re-initialized after the DPMS and the X11 log will hopefully capture that)
Otherwise and in general: are there any recordings of this incident in the system journal?
Offline
Can you control the default backlight in the UEFI?
I cannot.
Can you run some X11 session, "xset dpms force off", wait some minutes and after waking the output post your Xorg log, https://wiki.archlinux.org/title/Xorg#General ?
(I suspect what might happen is that the output unregisters and gets re-initialized after the DPMS and the X11 log will hopefully capture that)
The problem still happens in a X11 sesssion but nothing gets printed to the log at all when I tried that.
Otherwise and in general: are there any recordings of this incident in the system journal?
Nothing relevant shows up in the system journal.
Offline
The problem still happens in a X11 sesssion but nothing gets printed to the log at all when I tried that.
Can you please post the log after entering and leaving dpms? (Can be the log from your previous X11 server run, if that covers such action, so you won't have to switch your session again)
Most likely offender would be one of the patches in https://gitlab.freedesktop.org/drm/xe/k … ssues/3669 / https://patchwork.freedesktop.org/series/143909/
Can you compile a local kernel and test to revert all of those and then bisect them?
Offline
Hi, I have the exact same issue, also on a LNL laptop
> Can you run some X11 session, "xset dpms force off", wait some minutes and after waking the output post your Xorg
I tested, sadly as @miguel375 said, it does not produce any logs, but here is my Xorg logs if it can help
https://bin.deip.fr/upload/mouse-crow-cobra
Dmesg -> https://bin.deip.fr/p/bat-deer-dove
6.16.4-arch1-1 X11 no DE, wm only
Last edited by doums (2025-09-01 20:13:20)
Offline
i915.force_probe=!64a0 xe.force_probe=64a0
Does the chip normally get picked up by and work w/ i915?
And do you get the same behavior w/ i915?
Offline
yes, mostly testing the new driver by curiosity
Offline
THen it's not one of the XE patches.
What does the dmesg excerpt actually cover?
It shows your wifi, sound and nvme being initialized, typically early boot stuff (but missing any wider context) - did you actually activate the DPMS during this time?
Started happening in kernel 6.15 and persists in 6.16.
Is the LTS kernel afffected as well?
Offline
I completely forgot to update this, sorry.
Most likely offender would be one of the patches in https://gitlab.freedesktop.org/drm/xe/k … ssues/3669 / https://patchwork.freedesktop.org/series/143909/
Can you compile a local kernel and test to revert all of those and then bisect them?
I compiled the 6.16 kernel with those removed and the issue was indeed fixed. I was going to report it in the xe repo but then I confirmed the issue has already been fixed in the 6.17 mainline kernel.
Offline
Ah that's a good news then it is already fixed in mainline :popcorn:
> What does the dmesg excerpt actually cover?
sorry warn,err+ range
Note: it also happens when switching to VTty console from X and vice versa
Last edited by doums (2025-09-02 13:22:22)
Offline
Hi, just upgraded to `6.17.1` kernel, I confirm the issue is fixed now, brightness is restored as expected after reboot/sleep etc.
Offline