Hi On Wed, Mar 5, 2014 at 8:31 PM, Josh Triplett <j...@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 (j...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
