On Mon, Aug 19, 2019 at 12:21:27PM +0200, Uwe Kleine-König wrote: > > > > In an ideal world the backlight interface would be consistent as you > > > > suggest, however there are plenty of existing devices which use the > > > > 'other' scaling (regardless of which is chosen as the 'correct' > > > > one). Userspace still has to deal with these. And changing previously > > > > 'logarithmic' drivers to linear (or viceversa) may 'break' userspace, > > > > when it keeps using its 'old' scaling, which now isn't correct anymore. > > > > > > It might be subjective, or maybe I'm just too optimistic, but I think if > > > there was no policy before about the meaning of > > > > > > echo 17 > brightness > > > > > > other than "brighter than lower values and darker than higher ones" > > > introducing (say) the scale is intended to represent a linear brightness > > > curve is ok. > > > > > > Unless userspace jumps through hoops and tries to identify the actual > > > device it is running on it is wrong on some machines anyhow and we're > > > only shifting the set of affected machines with a tighter policy (until > > > that userspace application is fixed). > > > > I believe that there are two common approaches by userspace at present: > > > > 1. Assume the scale is perceptual and we can directly map a slider > > to the backlight value. This is common simply because most ACPI > > backlights are perceptual and therefore when tested in a laptop > > it works OK. > > > > 2. Assume that is max brightness is small (e.g. ACPI) then the > > scale is perceptual and if the max brightness is large (e.g. > > a PWM) then the scale is linear and apply a correction > > function between the slider and the control. > > > > That historic baggage makes is diffcult to "just define a standardized > > scale"... especially given that if we selected a standardized scale we > > would probably want a perceptual scale with lots of steps (e.g. break > > the heuristic). > > With "perceptual" you mean that logarithmic stuff, right? Human perception is fairly complex so it depends how strict you want to get. At the end of the day what it means is you can map a slider UI component directly to the backlight range and it will feel right. Thus a userspace that maps directly to a slider *is* assuming the scale is perceptual. Logarithmic scales are often mentioned in this kind of conversation because they are hoped to be "perceptual enough". They are not strictly matched to human perception but with a sane exponent shouldn't feel as broken as a linear scale does. Finally note that for people with an audio background then logarithmic and perceptual are used interchangably (based on the assumption that decibels are a preceptual scale). > I would tend to go for linear because this is easily measureable and > also is straight forward to implement in the usual cases (attention: I > assume that "usual" means something like PWM and I don't know much about > the physics of backlights but just assume that a PWM will create a > linear mapping). Mandating a linear scale makes things difficult for ACPI systems (which are amoung the most common cases) since we would have to un-perceptualize it. Additionally it is not a particularly helpful scale to offer the userspace. All proposals I have seen in this space assume we will map linear hardware to a perceptual scale rather than trying to unmap devices that are already perceptual. Within the backlight space we are also moving (slowly) towards perceptual scales to align with this. For example pwm_bl.c will automatically generate a perceptual table unless the DT tells it not to. > > > And the big upside is that in the end (i.e. when all kernel drivers and > > > userspace applications are adapted to provide/consume the "correct" > > > curve) the result is simpler. > > > > My view is that this convergence will eventually be achieved but it will > > happen through the obsolescence of the backlight sysfs interface. The > > sysfs interface has other flaws, in particular no integration with the > > DRM connector API. > > > > Thus I would expect an alternative interface to emerge, most likely as > > part of the DRM connector API. I'd expect such a new API to a > > perceptual scale and to have a fixed max brightness with enough > > steps to support animated backlight effects (IIRC 0..100 has been > > proposed in the past) > > Then work on the new stuff instead of making the old stuff (that is > intended to die) harder to use correctly? I do not accept this this change makes it harder to use the backlight correctly. We know the current userspace heuristics are fragile and that as backlight animation becomes more popular will become unmaintainable (backlight animation encourages backlights with a perceptual scale to introduce more steps... resulting in them being mishandled by userspace). Anyhow given we know sophisticated userspaces already have two code paths controls by heuristic and that this will break then we are simply providing a clear indication that allows their maintainers a non-heuristic solution when bug reports come in. It also means that userspaces that are currently naive (e.g. assume perceptual scale) need not introduce a heuristic if they get a bug report. > > In the mean time getting the existing collection of backlight drivers > > marked up as linear/logarithmic/etc will ease the introduction of that > > API because, within the kernel, we might have gathered enough knowledge > > to have some hope of correctly mapping each backlight onto a > > standardized scale. > > It would be enough to do this in a code comment then. That would come > without the need to adapt the old userspace API. Also when the old > solution works at 95% instead of 90% before, it will resist harder to > dying. To be honest I think the traction for the sysfs interface comes from the fact that, with or without the proposed change, it is good enough for the ACPI systems that dominate the landscape. Daniel. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
