KMS backlight ABI proposition

[Jani Nikula]

On Mon, 20 Feb 2017, Hans de Goede <hdegoede at redhat.com> wrote:
> On 17-02-17 13:58, Martin Peres wrote:
> So 1 and 2 are closely related the problem is that if we expose a
> fixed number of steps we need to convert in both directions, and if
> userspace tries to increment by doing read, add 1, write and we expose
> 1-100 but the hardware has only 4 levels then the read will keep
> returning the same value. Note I've fixed bugs like this already so
> this is a real problem. As already mentioned in the thread this can be
> fixed by caching the last written value on both sides and invalidating
> both caches on a new write to one side.

I don't think userspace should be doing read-modify-write like this,
*unless* the value read is guaranteed to be the same as the last value
written.

Contrast with the sysfs brightness class interface. RMW should only ever
have been done on the "brightness" attribute alone, never using read on
"actual_brightness" attribute and write on "brightness".

>> The display brightness MUST be a monotonically increasing function of
>> the brightness property.
>
> What does "monotonically increasing" actually mean ? I would prefer
> to clearly define that we are talking about perceived brightness here,
> for 2 reasons:

https://en.wikipedia.org/wiki/Monotonic_function

Increase in the property means the same or higher "perceived
brightness".

> 1) This is what the user actually wants
> 2) Some of the x86 firmware interfaces only give us perceived brightness
> and no way to get back to any other unit of measire.
>
>> Brightness property value 1 MUST mean the minimum supported visible
>> brightness.
>>
>> Brightness property value 100 MUST mean the maximum supported
>> brightness.
>>
>> Brightness property value 0 SHOULD mean backlight off or equivalent for
>> non-backlight brightness adjustment, typically completely
>> black. Brightness property value 0 MUST NOT switch the display or pipe
>> off [1].
>>
>> If the hardware is not capable of supporting zero brightness, and the
>> driver knows this, value 0 MUST be equal to value 1.
>
> Ok.
>
>> If the driver does not know whether the hardware is capable of
>> supporting zero brightness, the driver SHOULD err on the side of 0 not
>> being off rather than 1 meaning off. In this case, value 0 is likely
>> different from value 1, and the minimum brightness can only be reached
>> via property value 0 [2].
>
> I agree, but this needs rewording (I had to read it 3 times).
>
>> 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