Bug 1108019

Summary:	systemd should save + restore raw backlight interface(s) when there are no firmware interfaces
Product:	[Fedora] Fedora	Reporter:	Hans de Goede <hdegoede>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	johannbg, lnykryn, msekleta, s, systemd-maint, vpavlin, zbyszek
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-07-20 00:00:50 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Hans de Goede 2014-06-11 10:13:29 UTC

Hi,

Judging from the discussion in bug 1090860, it seems that systemd-backlight only saves backlight settings for backlight interfaces with the "firmware" type.

Normally this is the right thing to do since firmware interfaces should be preferred when available. However sometimes there only is a raw interface, and in this case it should be used rather then not saving and restoring backlight settings at all.

Note that only a raw interface becoming available is becoming more and more common as many designed for windows 8 laptops have a broken acpi-video implementation. The kernel currently has a video.use_native_backlight boolean kernel cmdline option which will disable the acpi_video backlight interface when the BIOS is "windows 8  ready". Currently there is an ever growing list of DMI based quirks enabling this options for many many new laptop models, so the plan for 3.16 is to flip this option to on by default.

Regards,

Hans

Comment 1 Lennart Poettering 2014-06-17 00:47:24 UTC

Hmm? current upstream versions of systemd actually save/erstore backlight for all backlight devices, regardless how it is accessed.

Comment 2 Zbigniew Jędrzejewski-Szmek 2014-06-17 03:07:22 UTC

The OP mentions systemd-208. I'll release an update for F20 with commit
http://cgit.freedesktop.org/systemd/systemd/commit/?id=0f4ba83.

Comment 3 Fedora Update System 2014-06-19 13:19:38 UTC

systemd-208-18.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/systemd-208-18.fc20

Comment 4 Fedora Update System 2014-06-19 22:56:23 UTC

Package systemd-208-18.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-208-18.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-7512/systemd-208-18.fc20
then log in and leave karma (feedback).

Comment 5 Fedora Update System 2014-06-22 23:55:45 UTC

Package systemd-208-19.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-208-19.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-7512/systemd-208-19.fc20
then log in and leave karma (feedback).