On Thu, Feb 23, 2017 at 12:40 AM, Jani Nikula <jani.nikula@xxxxxxxxxxxxxxx> 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.
In the same message, I mentioned the idea of providing an API to
increase/decrease brightness. That might be much easier to implement
than allowing the property range change.
[1] http://marc.info/?i=87mvdei7ug.fsf@xxxxxxxxx
As a consumer of this API, I need the step size. If the max changes and we have a normalization, then the step size changes, and we run into the same exact set of problems where now "+5" means something completely different and I need to know that.
> Yes the ability to turn off the backlight is important. Some
> backlights are not stable at low levels, so they don't expose these
> low levels and effectively level 0 is not off (it is the lowest level
> which works). So I guess the question is how should that non-linearity
> be exposed versus the ability to turn it off completely.
You fail to say *why* the ability to turn off the backlight is
important. I've seen it used as a kind of "light DPMS" that can be done
using the sysfs interface, but I think that's a hack, really. Here,
whoever changes the backlight would be doing it using the DRM APIs
anyway, so it could do actual DPMS anyway. And, of course, not all
backlight hardware is able to switch off the backlight, and not all
drivers will be able to say whether 0 is off or not.
>> The backlight_current interface in the backlight devices is meant to expose
>> the currently-used backlight value, regardless of the wanted value that
>> should be used when the backlight is not off.
>>
>> My current stance on this is that this should not be needed. The userspace
>> should describe the intent of the user (wanted backlight level) and trust
>> the KMS property to turn off the backlight when entering DPMS.
>
> Are we saying that we are putting the kernel in charge of display vs
> backlight sequencing? Currently on some ARM boards with separate pwm
> backlight drivers that's not the case. Don't get me wrong, I think the
> kernel should be in charge of enforcing sequencing because otherwise
> user space can damage hardware, I'm just pointing out that right now
> it isn't the case.
Whenever the kernel is able to enforce the sequencing, it should. I
believe this is the case for most native backlight implementations. And
in these cases the backlight on/off toggling would really have to be a
substate of enabled display; can't enable backlight without display
enabled.
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
--
Jasper
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
