Re: KMS backlight ABI proposition

[Jani Nikula <jani.nikula@linux.intel.com>]

On Wed, 22 Feb 2017, Hans de Goede <hdegoede@redhat.com> wrote:
> My first thought was that your proposal is reasonable, but on second
> thought I foresee trouble here with e.g. the backlight level save / restore
> code in systemd still using the sysfs interface, while the desktop
> environment has moved on to the property, I believe we really need to
> do some sort of bi-directional syncing here ...

FWIW I think systemd should have no business changing the backlight. The
save/restore should belong in the desktop environments... But I think we
could dodge this one by having the initial sysfs value synced back to
the property on initialization, but not otherwise. The systemd stuff,
IIRC, happens before/after X.

>> We can bikeshed the meaning of 0 or -1, I don't mind. The point is, we
>> need to define what the drivers should aim for, with the potentially
>> limited information they have available, to provide as smooth and
>> unified an experience as possible.
>>
>> One benefit of -1 is that we might get away with adding that as a
>> special case later on, if we define 0 properly. And if the drivers know
>> they don't support off, they could have range 0..100 instead.
>
> I really believe that we need to define the ABI as 0 meaning minimal
> brightness which keeps the screen readable (which for the epaper
> example would be no brightness, but normally would be some minimal
> level).

We can define anything, but it doesn't mean it makes sense for the
drivers or that the drivers can implement it. By your above definition,
the right thing for the driver to do in the epaper case is to switch off
the backlight at 0, because switching it off completely can save more
power than just setting duty cycle to 0. That's the whole point for
epaper. And this contradicts with what you say below about backlight
on/off being orthogonal.

> Yes we do not get this right in some cases, but let at least define
> it properly in the ABI. Add a fat disclaimer for all I care that
> in some cases the driver is unable to guarantee this, but lets
> clearly define what 0 means and then try to get as much drivers
> to adhere to that as possible.
>
> As for -1 meaning turning stuff off, I'm against that, on/off
> vs brightness setting really are 2 almost orthogonal controls,
> in many cases in hardware they are truely orthogona, with both
> an enable pin as well as a pwm input for the brightness level,
> and driving the enable low will get the pwm input to effectively
> be ignored.

I think the crux with the on/off/minimum etc. is to have an ABI that
works sensibly also for drivers/hardware that is not able to switch
backlight off, or doesn't know whether the minimum is off or not. And we
need to have recommendations for drivers on what to do in the imperfect
reality.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel