On Tue, 2008-01-08 at 14:49 -0200, Henrique de Moraes Holschuh wrote: > On Tue, 08 Jan 2008, Richard Purdie wrote: > > On Tue, 2008-01-08 at 15:54 +0000, Matthew Garrett wrote: > > > On Tue, Jan 08, 2008 at 03:45:02PM +0000, Richard Purdie wrote: > > > > > > > I did't get enough context above but I went through the archives and it > > > > seems this is about linearising backlight values. > > > > > > Indeed. The ACPI spec provides a range of 0-100, without specifying what > > > this actually means (it gives brightness and power consumption as two > > > different examples). Implementations are only required to support a > > > subset of these, with the others being ignored. The current hook into > > > the backlight class exports this range but provides no means for an > > > application to determine which values are valid - I'd prefer to just > > > flatten the range to remove the holes. Given the lack of standardisation > > > in the real meaning of the values, I don't think exporting the 0-100 > > > range buys us anything. > > > > I agree with that. 0-100 actually breaks a useful and valid way the > > class gets used in the "brightness + 1" case... > > So be it, then. But my request that we get a way to add the information we > are losing to the backlight class still stands. The thing is does this 0-100 value have a use to userspace? Its extremely device specific and can't be exported from the class in a generic way suggesting it should really be something exported by the driver itself. You still have to ask whether userspace actually needs this value though? Kernel debugging is the one use I can see. For that you'd probably be better off with a pr_debug() though. There are hundreds of other 'useful' numbers the kernel has but doesn't export. Cheers, Richard - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
