Summary: | [regression] save/restore screen backlight brightness fails after xorg update | ||
---|---|---|---|
Product: | systemd | Reporter: | Mike C <mike.cloaked> |
Component: | general | Assignee: | systemd-bugs |
Status: | RESOLVED FIXED | QA Contact: | systemd-bugs |
Severity: | normal | ||
Priority: | medium | ||
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Journal log adding drm.debug=0xe showing failed brightness restore
Journal log with drm.debug=0xe systemd.restore_state=0 |
Description
Mike C
2014-07-29 19:05:13 UTC
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.