After update to xorg server 1.16 in arch linux on Thinkpad S540 the brightness that was previously being set normally on boot and shutdown is now extremely dim. The screen remains dim to the KDM login greeter but is restored to sensible levels by KDE once logged in. On shutdown after leaving KDE the screen is again very dim and nearly unreadable. Brightness values when logged in to KDE are: $ ls -1 /sys/class/backlight/intel_backlight/*brightness | xargs -I % sh -c "echo % ; cat %" /sys/class/backlight/intel_backlight/actual_brightness 937 /sys/class/backlight/intel_backlight/brightness 937 /sys/class/backlight/intel_backlight/max_brightness 937 $ ls -1 /sys/class/backlight/acpi_video0/*brightness | xargs -I % sh -c "echo % ; cat %" /sys/class/backlight/acpi_video0/actual_brightness 100 /sys/class/backlight/acpi_video0/brightness 100 /sys/class/backlight/acpi_video0/max_brightness 100 However the journal log shows the likely problem: Jul 29 17:56:28 lenovo1 systemd[1]: Created slice system-systemd\x2dbacklight.slice. Jul 29 17:56:28 lenovo1 systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:acpi_video0... Jul 29 17:56:28 lenovo1 kernel: thinkpad_acpi: ThinkPad ACPI Extras v0.25 Jul 29 17:56:28 lenovo1 kernel: thinkpad_acpi: http://ibm-acpi.sf.net/ Jul 29 17:56:28 lenovo1 kernel: thinkpad_acpi: ThinkPad BIOS GPET58WW (1.58 ), EC unknown Jul 29 17:56:28 lenovo1 kernel: thinkpad_acpi: Lenovo ThinkPad S5-S540, model 20B3CTO1WW Jul 29 17:56:28 lenovo1 systemd[1]: Starting Load/Save Screen Backlight Brightness of backlight:intel_backlight... Jul 29 17:56:28 lenovo1 kernel: snd_hda_intel 0000:00:1b.0: irq 61 for MSI/MSI-X Jul 29 17:56:28 lenovo1 kernel: tpm_tis 00:0b: 1.2 TPM (device-id 0x0, rev-id 78) Jul 29 17:56:28 lenovo1 kernel: ACPI Error: [\_SB_.PCI0.GFX0.DD02._BCL] Namespace lookup failure, AE_NOT_FOUND (20 Jul 29 17:56:28 lenovo1 kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.RP05.PEGP.DD02._BCL] (Node f Jul 29 17:56:28 lenovo1 kernel: thinkpad_acpi: detected a 8-level brightness capable ThinkPad Jul 29 17:56:28 lenovo1 kernel: thinkpad_acpi: This ThinkPad has standard ACPI backlight brightness control, suppo Jul 29 17:56:28 lenovo1 kernel: thinkpad_acpi: Disabling thinkpad-acpi brightness events by default... Jul 29 17:56:28 lenovo1 systemd-backlight[200]: Saved brightness 11 too low; increasing to 46. Jul 29 17:56:28 lenovo1 kernel: snd_hda_intel 0000:00:03.0: irq 62 for MSI/MSI-X Jul 29 17:56:28 lenovo1 kernel: ACPI Exception: AE_BAD_PARAMETER, Returned by Handler for [EmbeddedControl] (20140 Jul 29 17:56:28 lenovo1 kernel: ACPI Error: Method parse/execution failed [\_TZ_.TZ01._TMP] (Node ffff880226839cd0 Jul 29 17:56:28 lenovo1 kernel: ACPI Exception: AE_BAD_PARAMETER, Returned by Handler for [EmbeddedControl] (20140 Jul 29 17:56:28 lenovo1 kernel: ACPI Error: Method parse/execution failed [\_TZ_.TZ01._TMP] (Node ffff880226839cd0 Jul 29 17:56:28 lenovo1 systemd[1]: Started Load/Save Screen Backlight Brightness of backlight:acpi_video0. Jul 29 17:56:28 lenovo1 systemd[1]: Started Load/Save Screen Backlight Brightness of backlight:intel_backlight.
The current kernel and version of xorg server are: $ uname -r 3.15.7-1-ARCH $ pacman -Q xorg-server xorg-server 1.16.0-5 When booting if systemd.restore_state=0 is added to the kernel line then the brightness is correct through the rest of the boot but then goes dim again when shutting down.
Created attachment 103651 [details] Journal log adding drm.debug=0xe showing failed brightness restore Boot log from journalctl showing brightness problem
Created attachment 103652 [details] Journal log with drm.debug=0xe systemd.restore_state=0 Journal log file showing correct brightness setting when systemd-restore_state=0
Is there a way to reset the saved value that systemd uses so that the kernel boot line workaround is not required?
It looks like systemd is not storing the brightness values correctly so maybe xf86-video-intel is involved as well as systemd? Anyway I checked the values that systemd stored and they look as follows: # cat /var/lib/systemd/backlight/pci-0000\:00\:02.0\:backlight\:acpi_video0 100 # cat /var/lib/systemd/backlight/pci-0000\:00\:02.0\:backlight\:intel_backlight 11 So the value in intel_backlight is certainly incorrect - the above values were checked after KDE resets the brightness correctly. So the numbers in the /sys/ area are set right but on shutdown it seems that the saved values by systemd are wrong: # ls -1 /sys/class/backlight/*/*brightness | xargs -I % sh -c "echo % ; cat %" /sys/class/backlight/acpi_video0/actual_brightness 100 /sys/class/backlight/acpi_video0/brightness 100 /sys/class/backlight/acpi_video0/max_brightness 100 /sys/class/backlight/intel_backlight/actual_brightness 937 /sys/class/backlight/intel_backlight/brightness 937 /sys/class/backlight/intel_backlight/max_brightness 937 These values are not getting saved by systemd but the intel value is somehow becoming 11 instead of 937
I have some progress now. It was suggested to try a patch to xf86-video-intel at http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=5935c93ce77a5da09aab9b45b1a5710d681c171e. I rebuilt xf86-video-intel with this patch and rebooted and the symptoms persisted. Later this evening a new set of updates was available that included kdelibs. So after doing the pacman update that included upgraded kdelibs (4.13.3-1 -> 4.13.3-2), and then shutting down completely, and then booting from cold seems to have resolved the issue! I checked the stored value which is at /var/lib/systemd/backlight/pci-0000\:00\:02.0\:backlight\:intel_backlight and it gives 937 which is correct! I tested further by reverting the xf86-video-intel package to that in the [core] repo, and the problem with brightness returned. Re-installing the amended package containing the patch http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=5935c93ce77a5da09aab9b45b1a5710d681c171e fixes the issue again. So indeed the patch does fix the problem. Whether additionally I needed to fully shutdown and boot from cold only, or whether the additional update to kdelibs was crucial I don't know but with both the version 4.13.3-2 of kdelibs as well as the patched xf86-video-intel this is resolved for me now. Therefore I will close this bug.
I spoke too soon - although the problem seemed to be resolved it isn't and booting the machine again shows the same issue. So the patch applied to the package xf86-video-intel has not fixed this bug. I have added more information to the arch report at https://bugs.archlinux.org/task/41390 and reopening this bug.
This issue is resolved for me with an update to kernel 3.16 so I presume this was a kernel bug that has been fixed with one of the patches that went into the 3.16 kernel.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.