Hi, On Fri, Jun 28, 2019 at 09:34:52AM +0100, Daniel Thompson wrote: > On Wed, Jun 26, 2019 at 04:56:11PM +0200, Pavel Machek wrote: > > Hi! > > > > > Export the type of the brightness curve via the new sysfs attribute > > > 'scale'. The value of the attribute may be a simple string like > > > 'linear' or 'non-linear', or a composite string similar to > > > 'compatible' strings of the device tree. A composite string consists > > > of different elements separated by commas, starting with the > > > most-detailed description and ending with the least-detailed one. An > > > example for a composite string is "cie-1931,perceptual,non-linear" > > > This brightness curve was generated with the CIE 1931 algorithm, it > > > is perceptually linear, but not actually linear in terms of the > > > emitted light. If userspace doesn't know about 'cie-1931' or > > > 'perceptual' it should at least be able to interpret the 'non-linear' > > > part. > > > > I'm not sure the comma-separated thing is a good idea. If it is, it should > > go to the Documentation, not to changelog. > > So I viewed the comma-separated thing as allow us to describe facts about > the scale used. > > In particular I suspect that some controllers will be non-linear *and* > non-perceptual and that some userspaces, particularly those that animate > backlight changes, may care enough about the difference to ask us to add > another fact to the set that describes that scale. > > Having said that I do share your concern that the comma-separated list > is overengineered and that all userspaces will end up implementing > something like: > > if (strstr("non-linear", scale) { > mode = PERCEPTUAL; > } else if (strstr("unknown", scale) { > mode = use_existing_hueristic(); > } else { > mode = LINEAR; > }
I agree that this is not unlikely ... So let's just make it 'linear', 'non-linear' and 'unknown'? > > > +What: /sys/class/backlight/<backlight>/scale > > > +Date: June 2019 > > > +KernelVersion: 5.4 > > > +Contact: Daniel Thompson <daniel.thomp...@linaro.org> > > > +Description: > > > + Description of the scale of the brightness curve. The > > > + description consists of one or more elements separated by > > > + commas, from the most detailed to the least detailed > > > + description. > > > + > > > + Possible values are: > > > + > > > + unknown > > > + The scale of the brightness curve is unknown. > > > + > > > + linear > > > + The brightness changes linearly in terms of the emitted > > > + light, changes are perceived as non-linear by the human eye. > > > + > > > + non-linear > > > + The brightness changes non-linearly in terms of the emitted > > > + light, changes might be perceived as linear by the human eye. > > > > non-linear is not too useful as described. > > Agree. > > The idea is that allows a userspace with simple backlight needs to > simple map the brightness property directly to a slider using the > approach above without worrying about perceptual or (possible future) > logarithmic scales. Such an approach won't be perfect but it > probably won't feel horrible for the user either. > > Arguably the descriptions should move away from the raw factual > approach and describe what advise the kernel of offering the > userspace. ok, I'll change it in the next revision > > > + perceptual,non-linear > > > + The brightness changes non-linearly in terms of the emitted > > > + light, changes should be perceived as linear by the human eye. > > > + > > > + cie-1931,perceptual,non-linear > > > + The brightness curve was calculated with the CIE 1931 > > > + algorithm. Brightness changes non-linearly in terms of the > > > + emitted light, changes should be perceived as linear by the > > > + human eye. > > > > Is it useful to know difference between perceptual, and cie-1931? > > Depends how assertive the userspaces are! > > If they follow the "fix kernel bugs in the kernel" mantra rather than > implement workarounds and heuristics then I suspect it would not be used > much. > > > > Would it be useful to export absolute values in some well-known units? > > > > If I'm in dark room, I may want 100mW/m^2 of backlight... And it would > > be nice if I could set same backlight intensity on all my devices > > easily. > > I'm a little sceptical that we could calibrate an absolute scale on > enough devices for such a property to be useful. I think it would be > "unknown" on almost every system. I share your scepticism and would expect most devices to remain "unknown"