On Friday, September 30th, 2022 at 16:44, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > On Fri, Sep 30, 2022 at 04:20:29PM +0200, Sebastian Wick wrote: > > > On Fri, Sep 30, 2022 at 9:40 AM Pekka Paalanen ppaalanen@xxxxxxxxx wrote: > > > > > On Thu, 29 Sep 2022 20:06:50 +0200 > > > Sebastian Wick sebastian.wick@xxxxxxxxxx wrote: > > > > > > > If it is supposed to be a non-linear luminance curve, which one is it? > > > > It would be much clearer if user space can control linear luminance > > > > and use whatever definition of perceived brightness it wants. The > > > > obvious downside of it is that it requires bits to encode changes that > > > > users can't perceive. What about backlights which only have a few > > > > predefined luminance levels? How would user space differentiate > > > > between the continuous and discrete backlight? What about > > > > self-emitting displays? They usually increase the dynamic range when > > > > they increase in brightness because the black level doesn't rise. They > > > > also probably employ some tonemapping to adjust for that. What about > > > > the range of the backlight? What about the absolute luminance of the > > > > backlight? I want to know about that all in user space. > > > > > > > > I understand that most of the time the kernel doesn't have answers to > > > > those questions right now but the API should account for all of that. > > > > > > Hi, > > > > > > if the API accounts for all that, and the kernel doesn't know, then how > > > can the API not lie? If the API sometimes lies, how could we ever trust > > > it at all? > > > > Make it possible for the API to say "I don't know". I'd much rather > > have an API tell me explicitly what it does and doesn't know instead > > of having to guess what data I can actually rely on. > > > > For example if the kernel knows the luminance is linear on one display > > and doesn't know anything about the other display and it exposes them > > both in the same way I can not possibly write any code which relies on > > exact control over the luminance for either display. > > > > > Personally I have the feeling that if we can even get to the level of > > > "each step in the value is a more or less perceivable change", that > > > would be good enough. Think of UI, e.g. hotkeys to change brightness. > > > You'd expect almost every press to change it a bit. > > > > The nice thing is that you can have that even if you have no further > > information about the brightness control and it might be good enough > > for some use cases but it isn't for others. > > > > > If an end user wants defined and controlled luminance, I'd suggest they > > > need to profile (physically measure) the response of the display at > > > hand. This is no different from color profiling displays, but you need > > > a measurement device that produces absolute measurements if absolute > > > control is what they want. > > > > If that's the kind of user experience you're after, good for you. I > > certainly want things to work out of the box which makes this just a > > big no-go. > > > I think if we have the information to make the default behaviour > better then we should do that. Ie. if the firmaware gives us a > table to remap the values for a more linear response we should > make use of that by default. > > We can of course provide a way for the user to plug in their own > actually measured data later. But IMO that doesn't even have to > happen in the initial implementation. Just need to avoid painting > ourselves totally in the corner in a way that would prevent later > additions like that. Yes. Please don't try to solve all of the problems at once. There have been many tries to add brightness to KMS, and having *something* would be a lot better than having nothing. If we try to have the perfect complete API from the start then we'll never get anything done.
