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
ls we do have one more level of abstraction. For e-paper-able
> displays we could simply have a full range of brightness values, with
> 0 meaning e-paper mode and panel off meaning, well, panel off.
>
> Alternatively, e-paper mode could be the same as backlight off, since
> obviously there is no backlight anymore, in which case there wouldn't be
> a need to differentiate the special case for 0.
The main goal was to allow for cases where you can't switch off the
backlight, or you don't know whether the lowest value is pitch black. As
I wrote in [1], we can change the meaning of 0, but we need to take into
account it really might mean "off" for some, and "minimum visible" for
others.
The old sysfs ABI handled this by deferring it all to drivers, and we
know the result... this really is an unholy mess.
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
s).
>
>> If the brightness gets changed outside of the property interface,
>> reading the property value MAY be out of sync with the actual brightness
>> [3].
>
> This is for when the panel is off ? Otherwise it seems like a bad idea
> to me.
It means we don't want to go dig through the sysfs class interface to
figure out what was written there, and do lossy conversions back to the
property (if there's scaling involved).
BR,
Jani.
--
Jani Nikula, Intel Open Source Technology Center
nytime soon, but the ABI and contract for the connector property will
be, "if you touch the sysfs while using the connector property, you
might get unexpected results reading back the property".
There *are* going to be subtle bugs with the simultaneous operation, and
I know I don't wa