[systemd-devel] systemd-backlight and backlight level 0
Josh Triplett
josh at joshtriplett.org
Wed Mar 5 11:31:55 PST 2014
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 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.
- Josh Triplett
More information about the systemd-devel
mailing list