[systemd-devel] systemd-backlight and backlight level 0

[David Herrmann]

Hi

On Wed, Mar 5, 2014 at 8:31 PM, Josh Triplett <josh at joshtriplett.org> wrote:
> On Wed, Mar 05, 2014 at 07:10:51PM +0100, Lennart Poettering wrote:
>> On Wed, 05.03.14 09:46, Josh Triplett (josh at joshtriplett.org) wrote:
>> > systemd-backlight saves backlight levels on shutdown, and restores them
>> > on startup.  However, on some systems, backlight level 0 actually turns
>> > the backlight *off*; this can potentially make the system unusable.
>> > Complicating matters, on most systems, nothing pays attention to the
>> > brightness adjustment keys in text mode.
>> >
>> > I'd suggest one or both of the following two changes, to avoid a painful
>> > failure mode:
>> >
>> > - systemd-backlight should avoid saving/restoring a backlight level of
>> >   0, and have a minimum backlight level.  (Possibly overridable via
>> >   configuration, for people who *really* want to restore backlight level
>> >   0.)
>>
>> To deal with situations like this there's systemd.restore_state=0 on the
>> kernel cmdline, see kernel-command-line(7).
>
> Yeah, I've seen that one; however, having to reboot the system and
> change the kernel command line to unbreak it seems less ideal than
> having the system avoid broken states to begin with.

I'd expect this to be set on the "recovery boot" option. At I know
some distros always provide two boot entries and to me this seems like
the right place to set it.

>> I could be convinced to fix brightness level 0 to 1 when restoring. But
>> then again, I fear the next people will come then and say "1 is only
>> marginally better than 0, i want the minimum to be 16!"... Or even
>> others saying "Dude, I only got 3 brightness levels, and you took one
>> away from me...". So I am not enthusiastic about the idea...
>
> Given the choice between maximum flexibility and never making the system
> unusable, I'll take the latter.  Not that hard to make it configurable,
> if that proves necessary.
>
> On restore, I'd suggest reading max_brightness, and if the stored value
> falls under a threshold of ceil(max_brightness/SOME_DIVISOR), restore it
> to that value instead.  (Ideally there should be some way to ask the
> driver "what level of brightness will produce a non-zero value in
> actual_brightness", but no such mechanism seems to exist.)
>
> Does that sound reasonable?
>
>> > - Something ought to listen to the brightness keys (and perhaps other
>> >   hotkeys) in pure text mode.  systemd seems like a good place for such
>> >   a something to live.
>>
>> That's definitely a job for the DE I am sure, so that can it do an OSD
>> and all the other stuff. We do power button handling in logind only
>> because what it does is relatively important and really close to the
>> system lifecycle... But brightness keys (or volume keys..) are not close
>> at all. I am really sure that that's for the DEs to handle, not us.
>
> DEs don't handle the text consoles.  However, it does sound like this
> will have to wait for kmscon or equivalent.

Yepp.

Thanks
David