Hi,
On 23-02-17 09:40, Jani Nikula wrote:
On Wed, 22 Feb 2017, Stéphane Marchesin <stephane.marchesin@xxxxxxxxx> wrote:
On Fri, Feb 17, 2017 at 4:58 AM, Martin Peres
<martin.peres@xxxxxxxxxxxxxxx> 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@xxxxxxxxx
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
