Description of problem: Hibernating the system puts the laptop panel into minimum brightness at reboot, inhibiting typing in of the LUKS passphrase. I've tried to 'systemctl disable systemd-backlight' but the file /var/lib/systemd/backlight/acpi_video0 keeps reappearing after reboot/hibernate. Version-Release number of selected component (if applicable): 208-9.fc20 How reproducible: Every time. Steps to Reproduce: 0. This is all under AC power. 1. # systemctl disable systemd-backlight 2. Delete /var/lib/systemd/backlight/acpi_video0 3. systemctl hibernate, then power back on. Actual results: Thinkpad laptop panel at dimmest level, same with plymouth LUKS UI. Expected results: Laptop panel should be at level right before hibernation, or at least a sane level that doesn't inhibit the UI. Additional info: Thinkpad X200s with Intel graphics: 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller]) Subsystem: Lenovo Device 20e4 Flags: bus master, fast devsel, latency 0, IRQ 44 Memory at f2000000 (64-bit, non-prefetchable) [size=4M] Memory at d0000000 (64-bit, prefetchable) [size=256M] I/O ports at 1800 [size=8] Expansion ROM at <unassigned> [disabled] Capabilities: <access denied> Kernel driver in use: i915 /proc/cmdline: BOOT_IMAGE=/vmlinuz-3.12.8-300.fc20.x86_64 root=/dev/mapper/vg0-root ro rd.md=0 rd.dm=0 rd.lvm.lv=vg0/swap vconsole.keymap=us rd.lvm.lv=vg0/root rd.luks.uuid=luks-d8a4c588-941a-4edf-9682-6e2670830744 vconsole.font=latarcyrheb-sun16 rhgb acpi_osi=Linux thinkpad_acpi.brightness_enable=0 quiet [thinkpad_acpi.brightness_enable needs to be disabled otherwise beightness hotkey behavior breaks]
THe kernel should probably save/restore the brightness level when going into hibernation. systemd has no business with that. Reassigning. (systemd-backlight@.service is only used to persist the setting across normal reboots. It's a static service, you can only disable it by masking it, see "systemctl mask" for more info.)
Update: The 'systemctl hibernate' command in the description was run from a gnome terminal while logged into a gnome-shell session. If I Ctrl-Alt-F2 into the console and run the same command there, the system hibernates and resumes leaving the brighness alone, as it should. gnome-shell or kernel mode/KMS problem?
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.13.4-200.fc20. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
Still here with 3.13.6-200.fc20.x86_64, but: This strongly seems like a gnome-shell problem, as it can be avoided with any one of the following "workarounds": - While viewing the desktop on the screen, start hibernate. - Immediately after the screen blanks, and while the Thinkpad's suspend LED is blinking, move the mouse. - Screen unblanks and shows the screen lock image. This seems to reset the brightness. - Hibernate completes, system powers down. - Start system: brightness now normal. workaround 2: - Switch to another VT console. - Hibernate the system. - On resume, brighness normal. So it appears to be connected to the gnome-shell's behavior when hibernating.
This may be related to Bug 1178447 in Fedora 22.
Still here under F21.
This message is a reminder that Fedora 21 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 21. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '21'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 21 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 21 changed to end-of-life (EOL) status on 2015-12-01. Fedora 21 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.