On Mon, 3 Oct 2022 12:29:01 +0300 Ville Syrjälä <ville.syrj...@linux.intel.com> wrote:
> On Mon, Oct 03, 2022 at 11:37:50AM +0300, Pekka Paalanen wrote: > > On Fri, 30 Sep 2022 18:17:39 +0200 > > Sebastian Wick <sebastian.w...@redhat.com> wrote: > > > > > On Fri, Sep 30, 2022 at 5:27 PM Pekka Paalanen <ppaala...@gmail.com> > > > wrote: > > > > > > > > On Fri, 30 Sep 2022 17:44:17 +0300 > > > > Ville Syrjälä <ville.syrj...@linux.intel.com> 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 > > > > > > <ppaala...@gmail.com> wrote: > > > > > > > > > > > > > > On Thu, 29 Sep 2022 20:06:50 +0200 > > > > > > > Sebastian Wick <sebastian.w...@redhat.com> 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. ... > > I suppose the firmware may expose some tables that may allow mapping > > raw hardware values into something more pleasant to use. Like something > > where each step is more or less a visible change. That does not have to > > imply anything about linearity in any space, they may just be "good > > values" for e.g. keyboard-based changing of backlight levels with no > > mathematical or physical basis. > > > > Ville, what kind of tables do you know about? What do they actually > > tell? > > We just get a set of points (up to 20 originally, and I think up to > 32 in later spec revisions) that map input brightness (in %) to > output duty cycle (0-0xff in old spec, 0-0xffff in new spec). > And I *think* we're supposed to just linearly inteprolate between > the entries, though the spec doesn't really state that in super > clear terms. > > There is some mention in the spec about this being more or less > designed for Windows Vista, so a look through eg. > https://learn.microsoft.com/en-us/windows-hardware/drivers/display/supporting-brightness-controls-on-integrated-display-panels > might be a good idea here. That's a nice link. Quote: "Brightness levels are represented as single-byte values in the range from zero to 100 where zero is off and 100 is the maximum brightness that a laptop computer supports. Every laptop computer must report a maximum brightness level of 100; however, a laptop computer is not required to support a level of zero. The only requirement for values from zero to 100 is that larger values must represent higher brightness levels. The increment between levels is not required to be uniform, and a laptop computer can support any number of distinct values up to the maximum of 101 levels. You must decide how to map hardware levels to the range of brightness level values. However, a call to the display miniport driver's DxgkDdiGetPossibleBrightness function should not report more brightness level values than the hardware supports." Sounds like "good values" to me, and that each value must be distinguishable from any another (at least electrically). Thanks, pq
pgp4pfmyVC2XC.pgp
Description: OpenPGP digital signature
