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

2014-03-10 Thread Lennart Poettering
On Wed, 05.03.14 11:31, Josh Triplett (j...@joshtriplett.org) wrote:

 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?

I'd be willing to merge that on ignore put the brightness to at least
1 or 5% of the full range, for whatever is larger. i.e. MAX(1, 
max_brightness/20).

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2014-03-05 Thread Josh Triplett
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.)

- 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.


- Josh Triplett
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2014-03-05 Thread David Herrmann
Hi

On Wed, Mar 5, 2014 at 6:46 PM, 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.)

Never restoring val==0 seems fine to me.

 - 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.

We cannot do that. It requires keymap-handling (as brightness keys are
handled on the keysym, not keycode level) and this is exclusive
territory of the compositor (or other foreground session controllers).

Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2014-03-05 Thread Lennart Poettering
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).

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...

 - 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.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2014-03-05 Thread Josh Triplett
On Wed, Mar 05, 2014 at 06:59:27PM +0100, David Herrmann wrote:
 On Wed, Mar 5, 2014 at 6:46 PM, 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.)
 
 Never restoring val==0 seems fine to me.

Likewise.

  - 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.
 
 We cannot do that. It requires keymap-handling (as brightness keys are
 handled on the keysym, not keycode level) and this is exclusive
 territory of the compositor (or other foreground session controllers).

Perhaps this will get fixed when we switch from kernel VTs to a
userspace-managed console, then.

- Josh Triplett
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2014-03-05 Thread Josh Triplett
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 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


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

2014-03-05 Thread David Herrmann
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


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

2014-03-05 Thread Josh Triplett
On Wed, Mar 05, 2014 at 10:21:17PM +0100, David Herrmann wrote:
 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.

Not a bad idea, but rather than requiring the addition of an extra
option (or potentially more than one, if other parts of systemd might
want to be more conservative on recovery as well), how about having
systemd-backlight treat single as systemd.restore_state=0?

- Josh Triplett
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel