Hi RP, David, thanks for your continuos comments, On Fri, Dec 21, 2007 at 12:01:11AM +0000, Richard Purdie wrote: > On Thu, 2007-12-20 at 14:31 -0800, David Brownell wrote: > > The "backlight" directory is a bit misnamed, since it also holds > > the LCD_CLASS_DEVICE stuff which is just "lowlevel LCD controls". > > You'll observe the LTV driver controls power and gamma just like > > this JBT driver does... > > > > Of course there aren't yet many "lowlevel LCD controls" drivers, > > and this driver might suggest revisiting that class. There's one > > LCD controller I know of with integral PWM contrast control, which > > might help motivate relocating that class code. How about a new > > "lcm" directory? :) > > Backlights and lcd controllers mainly reside in drivers/video/backlight > although there are a number of backlight drivers spread about the tree.
well, there alsi is drivers/video/display now, which is where I have put my driver now. However, I'm not using the DISPLAY_CLASS, since it seems to deal mainly with contrast settings. > I'm not sure the LCD class would be very helpful to this driver. As you > say, this really suggests shortcomings of the LCD class but with only > one LCD driver in mainline changing that class to work better for LCDs > is possible. > > The main question is whether the functionality here is suitably generic > to turn into a class? Personally I'm not sure it is but I'm open to > opinions (and patches). I think the power states and configuration parameters of different TFT panels (in embedded devices) are fairly device-specific. Even the power states of different panels can differ a lot. So I don't know how much common abstrction is possible to implement. One thing that we still need for the Neo1973 is some kind of interaction betwee the display driver and the framebuffer driver. The issue is that if we change the framebuffer resolution from VGA to QVGA, the display driver needs to alter the timing configuration of the display ASIC. I was thinking of something abstact like a notifier_chain for resolution changes. This way the display driver (and other potential users) can get informed about resolution changes. And then, after all, we have the issue of backlight, display and framebuffer all together. If you want to blank the screen, you would want to switch off the backlight, but also put the display into a lower-power mode. Right now we're not doing any of this in the kenrel, but I believe we definitely should. Any suggestions on that? Cheers, -- - Harald Welte <[EMAIL PROTECTED]> http://openmoko.org/ ============================================================================ Software for the world's first truly open Free Software mobile phone ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ spi-devel-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/spi-devel-general
