Messages in this thread | | | Date | Mon, 6 Mar 2006 22:47:58 +0100 | From | Pavel Machek <> | Subject | Re: RFC: Backlight Class sysfs attribute behaviour |
| |
Hi!
> > Well with power it's simple: LCD is either powered or it's not. After > > resuming the LCD should be always powered on, and the program can then > > turn it back off if it's desired. FB blanking isn't a issue with X11/ > > Qtopia, as far as I understand? And finally, the 'user' requested power > > state has to be tracked by the program that does the blanking (say an > > audio player or such). > > So the user powers down the LCD, the FB blanking then blanks and > unblanks. What should the current LCD power status be? The LCD should > still be off as far as I can see yet the LCD/backlight class doesn't do > this at present. > > I'm beginning to favour a system where backlight drivers only provide > two functions: > > int (*set_status)(struct backlight_device *, int brightness, int power, int fb_blank); > int (*get_status)(struct backlight_device *); > > set_status passes the user requested brightness and power values along > with the current fb_blanking status to the driver. The driver can then > set the hardware up as appropriate. > > get_status returns the brightness for the current configuration. > > The backlight core itself keeps track of the requested power and > brightness values rather than having every backlight driver including > the logic. This has the advantage of keeping behaviour the same and > avoiding subtle logic bugs of which there are several at the moment. > > This also means that "echo 31 > brightness; cat brightness" will always > give the expected answer of whatever brightness the user is requesting > and the actual current driver brightness choice is available through > "cat driver_brightness". > > Does this seem reasonable?
Yep. Keeping hardware drivers as simple as possible is good. Pavel -- Web maintainer for suspend.sf.net (www.sf.net/projects/suspend) wanted... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |