Re: Backlight support

Re: Backlight support

[Richard Purdie]

John Lenz:
> Perhaps the patch being referred to is the "Backlight and LCD module
> patches" that Andrew Zabolotny and I proposed on lkml?

I think the above patch was nearly there. The issues seemed to be with the
method of associating framebuffer devices with their backlights. I've come
up with a solution to that problem (see below) so that code can be removed
from that patch and that should make it acceptable for mainstream kernel
inclusion.

Russ Dill:
> The driver/bus/device model driver? Probably just no one there with
> the time to spend on it. It be a real help, and would be a good use of
> sysfs (for changing contrast, getting info, etc).

I'm keen to get this sorted out and I agree its an ideal use of sysfs. I'm
still getting up to speed on sysfs though...

Steven Scholz:
> Where can I find the most recent version of your patch?

I've had a discussion with Andrew. I think he's going to find the latest
version of the and post it for inclusion without the problematic parts...
Andrew?

> Excuse me ignorance, but what is "frontlight"?

I think a frontlight shines onto the display and reflects off a reflector at
the back of the LCD. A backlight lights it from the rear. As far as the
sysfs representations go, they'll be essentially identical. You can read a
frontlit display without the light in strong light. The backlit display
always needs the backlight.

My solution for associating backlight drivers with framebuffer drivers is
for the backlight driver to call fb_register_client() and register for fb
events. You can then intercept blanking requests (FB_EVENT_BLANK) which get
passed with an fb_info struct and the new blanking setting. It's entirely up
to the backlight driver how it tells which displays it should be blanking.
For something like my PDA, there is only one framebuffer/LCD to blank but in
other cases you would analyse fb_info. (FB_EVENT_BLANK is destined for
2.6.11)

I propose this discussion should move to linux-fbdev-devel and hopefully
Andrew will provide a sysfs representation we can discuss (maybe with some
comments from lkml).

I have one implementation question though - should backlight drivers be in
the arch folder (arch/arm/mach-pxa in my case) or should
drivers/video/backlights be created? They're all likely to be using
fb_register_client() so maybe the latter would be preferred?

Richard



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Backlight support

[Nicolas Pitre]

On Tue, 30 Nov 2004, Richard Purdie wrote:

> I have one implementation question though - should backlight drivers be in
> the arch folder (arch/arm/mach-pxa in my case) or should
> drivers/video/backlights be created? They're all likely to be using
> fb_register_client() so maybe the latter would be preferred?

Try to keep pieces of code sorted on their function first. It is harder 
for a subsystem maintainer to go all over the tree looking for all files 
that a particular change to the subsystem might affect than it is for an 
architecture maintainer to look after files affecting a specific 
architecture.


Nicolas

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:       http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

Re: Backlight support

[Russ Dill]

> I'm keen to get this sorted out and I agree its an ideal use of sysfs. I'm
> still getting up to speed on sysfs though...
>

The sysfs interface should probably tell you about the backlight too,
like, does it need to be on, or is ambient light enough. Possibly
recommended power modes, standardized power modes, or recommendations
based on ambient light.

-------------------------------------------------------------------
Subscription options: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:       http://www.arm.linux.org.uk/armlinux/mlfaq.php
Etiquette: http://www.arm.linux.org.uk/armlinux/mletiquette.php

Re: Re: Backlight support

[Andrew Zabolotny]

On Tue, 30 Nov 2004 16:28:26 -0000
"Richard Purdie" <rpurdie@rpsys.net> wrote:

> I think the above patch was nearly there. The issues seemed to be with
> the method of associating framebuffer devices with their backlights.
> I've come up with a solution to that problem (see below) so that code
> can be removed from that patch and that should make it acceptable for
> mainstream kernel inclusion.
I confirm that the solution you proposed is quite suitable for the job.
I've already modified the lcd/backlight subsystem, and I have a few
comments;

a) First of all, the implementation of your idea looks quite well
(it's simpler and cleaner than the old method), although initially I
didn't like it (mea culpa). I have removed a lot of now unneeded code
from b/l support, and also it removes a lot of lcd/backlight
maintainance code from the framebuffer drivers(pxafb, sa11xxfb,
mq11xxfb). Last but not least, it removed the class_find_device()
function that was the sticking point in the discussion with gkh.

b) No modification is needed to the existing lcd/backlight drivers
(there are about ten of them in hh.org cvs). I've added just one more
function pointer in the lcd_properties and backlight_properties to a
function that gets a fb_info and examinates if it is the
framebuffer to which the lcd/backlight is attached to. If the function
is NULL, the framebuffer is considered to match (since in PDAs there's
only one framebuffer, this perfectly fits already existing drivers).

c) There's a problem though; if someone will REALLY want to inspect
the fb_info, it would be very helpful to be able to deduce somehow the
'struct device' associated with the framebuffer, since the fb_info
itself doesn't contain anything more useful than the current resolution
and pixel format. Knowing the device (and its position on the parent
bus) the backlight/lcd driver will know exactly what to look at. I've
seen some semi-commented code in 2.6.10 which tells me there are plans
to integrate the fb_info into the sysfs (and, therefore, to add a
class_device somewhere in the fb_info); this will allow also the b/l
drivers to find the associated framebuffer device. Am I correct in my
assumptions?

As soon as handhelds.org will be up, I'll be able to test the code and,
once it'll work, I'll send a patch to linux-fbdev-devel@.

-- 
Greetings,
   Andrew


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Re: Backlight support

[Antonino A. Daplas]

On Thursday 02 December 2004 06:34, Andrew Zabolotny wrote:
> On Tue, 30 Nov 2004 16:28:26 -0000
>
> "Richard Purdie" <rpurdie@rpsys.net> wrote:
> > I think the above patch was nearly there. The issues seemed to be with
> > the method of associating framebuffer devices with their backlights.
> > I've come up with a solution to that problem (see below) so that code
> > can be removed from that patch and that should make it acceptable for
> > mainstream kernel inclusion.
>
> I confirm that the solution you proposed is quite suitable for the job.
> I've already modified the lcd/backlight subsystem, and I have a few
> comments;
>
> a) First of all, the implementation of your idea looks quite well
> (it's simpler and cleaner than the old method), although initially I
> didn't like it (mea culpa). I have removed a lot of now unneeded code
> from b/l support, and also it removes a lot of lcd/backlight
> maintainance code from the framebuffer drivers(pxafb, sa11xxfb,
> mq11xxfb). Last but not least, it removed the class_find_device()
> function that was the sticking point in the discussion with gkh.
>
> b) No modification is needed to the existing lcd/backlight drivers
> (there are about ten of them in hh.org cvs). I've added just one more
> function pointer in the lcd_properties and backlight_properties to a
> function that gets a fb_info and examinates if it is the
> framebuffer to which the lcd/backlight is attached to. If the function
> is NULL, the framebuffer is considered to match (since in PDAs there's
> only one framebuffer, this perfectly fits already existing drivers).
>
> c) There's a problem though; if someone will REALLY want to inspect
> the fb_info, it would be very helpful to be able to deduce somehow the
> 'struct device' associated with the framebuffer, since the fb_info

We already have a struct device field in fb_info. It was initially requested
for swsusp2, but I find that it has other uses as well (in userland).

Tony




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/