On Thu, 2007-02-22 at 14:34 -0200, Henrique de Moraes Holschuh wrote: > On Thu, 22 Feb 2007, Richard Purdie wrote: > > If you really care, add a a call to backlight_update_status() after you > > set the brightness attribute like some of the other drivers have. The > > I will. Do you ACK the patch, then?
Yes, it can have an Acked-by: Richard Purdie <[EMAIL PROTECTED]>. > > Have a look at what corgi_bl does. It can know what state it set the > > hardware too as it keeps track itself, it just can't read that state > > You are assuming nothing else is changing the hardware behind the driver's > back. Which it can't in the corgi_bl case (excluding poking things like /dev/mem). Its safe to assume it has exclusive access. > I am against such assumptions when they can be avoided, but that's a > particular PoV and not much more than that. IMHO, if you cannot query the > hardware, you shouldn't provide a way to query the current brightness that > will be right only if nobody else messed with the device. > > Maybe for corgi, that doesn't hold much strength, but for stuff tied to > ACPI, it does. And in a ThinkPad's case, where even writes to /dev/nvram > can change the brightness, well, if there weren't a way to ask the EC the > current real brightness, there is NO way I'd be implementing it based on a > memory cache. Right, I'd be against such a driver. On the embedded hardware we can safely assume there is nothing else playing with the brightness settings though and such a driver is perfectly valid. > > > Howerver, I *do* strongly wish for a way to combine various drivers into a > > > single backlight device, where radeon/intelfb takes care of some stuff, > > > ibm-acpi/asus-laptop/sony-laptop takes care of other stuff, etc. Also, a > > > standard naming for the builtin screen(s) would help, calling it "ibm", > > > "asus", "sony" is not good IMHO. > > > > I wasn't aware of this problem. If some devices need bits from both > > raedon/whatever and acpi, the current implementations are just plain > > wrong. Its not really a backlight class problem and more of an > > implementation and interaction problem between acpi and the framebuffer > > drivers. They should be presenting and registering *one* backlight class > > I.e. we should add hooks to the framebuffer drivers? It would work, that's > for sure. If the backlight controls would then power off the backlight properly that would be desirable as we've have a more standard interface. Richard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
