On Thu, Feb 23, 2017 at 12:40 AM, Jani Nikula wrote: > On Wed, 22 Feb 2017, Stéphane Marchesin > wrote: > > On Fri, Feb 17, 2017 at 4:58 AM, Martin Peres > > 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@intel.com > 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