KMS backlight ABI proposition

[Hans de Goede]

Hi,

On 23-02-17 09:40, Jani Nikula wrote:
> On Wed, 22 Feb 2017, Stéphane Marchesin <stephane.marchesin at gmail.com> wrote:
>> On Fri, Feb 17, 2017 at 4:58 AM, Martin Peres
>> <martin.peres at linux.intel.com> wrote:
>>> If the KMS property exposes a fixed number of steps (say 100), it becomes
>>> easy for the userspace to express the wanted brightness. However, on drivers
>>> exposing less than these 100 steps, we cannot guarantee that any change in
>>> the value will produce any change. If there is only one possible value (on
>>> or off), the user may be trying the change the brightness, a GUI would show
>>> what is the expected backlight state, but no change in the luminance would
>>> be seen, which is pretty bad.
>>
>> Yes, I don't think we want to normalize anything here. It would
>> essentially be hiding functionality from user space, which then can't
>> expose it in the user interface. As you say, if the backlight slider
>> moves, but the backlight level didn't change, that's weird. On the
>> other hand if user space knows the number of levels it can give you a
>> consistent slider, and normalizing in user space is not that hard
>> (that's how things currently work after all, so people should be used
>> to it).
>
> I listed some of the benefits of normalizing (or re-ranging) in
> [1]. Conversely, I haven't seen good answers on how to gracefully handle
> the brightness range changing on the fly. That is what not normalizing
> would mean. I don't think the current property implementation even
> allows changing the range. And then there'd have to be a way to tell the
> userspace that the range has changed.

Ok, so after reading [1], I understand why you want to allow the maximum
to be changed, but that only is an issue if anyone actually has the
drm-node open and has read the max value (I add the and has read the
max value here to not get in the way of boot splashscreens).

Since udev will be changing the binding between backlight interface
and drm connector, we can simply just return -EBUSY if the drm-node
is open and then we can actually save change the max level.

With that done the remaining argument seems to be what about backlight
interfaces which expose more levels then say 100. I agree that it is
probably a good idea to downscale their range to 100, but I'm not
a fan of upscaling older ACPI interfaces which have as little as 8
steps to a 100, that just means userspace will try to make a change
which may very well result in no change at all.

Regards,

Hans

[1] http://marc.info/?i=87mvdei7ug.fsf@intel.com