Re: 2.6.21-rc1 dims my LCD

On Mon, 2007-02-26 at 16:24 +0100, Jiri Kosina wrote:

On Mon, 26 Feb 2007, Richard Purdie wrote:

quoted

Jiri: I've appended a patch that should already be queued, could you
test and see if it solves the problem.

Thanks. In the meantime I have gone through the code and I can confirm 
that this is the root cause of what I am observing.

Now regarding the patch - at the time when the dim happened previously, 
currently there is a observable blink (after which the brightness is 
correct). 

The reason for the behaviour is that its turning the backlight down/off
to save power as it thinks the screen is blank. The blink therefore
makes sense as far as the backlight class is concerned and its working
as intended now.

I have put some debugging printk() into fb_notifier_callback(), 
and it turns out that on FB_EVENT_CONBLANK, there are two successive calls 
to backlight_update_status(), second immediately following the first one:

Feb 26 15:11:14 thunder kernel: calling backlight_update_status() with bd->props.fb_blank == 1, bd->props.brightness == 0
Feb 26 15:11:14 thunder kernel: calling backlight_update_status() with bd->props.fb_blank == 0, bd->props.brightness == 0

Is this really a right thing to do?

This should come from two calls to fbcon_generic_blank() in
drivers/video/console/fbcon.c with a different blank parameter and is
therefore in a way outside the scope of the backlight class.

It would be interesting to know why it decides to blank then immediately
unblank the display though. I've cc'd the fbdev-devel list.

Richard



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

On Mon, 2007-02-26 at 15:43 +0000, Richard Purdie wrote:

On Mon, 2007-02-26 at 16:24 +0100, Jiri Kosina wrote:

quoted

On Mon, 26 Feb 2007, Richard Purdie wrote:

quoted

Jiri: I've appended a patch that should already be queued, could you
test and see if it solves the problem.

Thanks. In the meantime I have gone through the code and I can confirm 
that this is the root cause of what I am observing.

Now regarding the patch - at the time when the dim happened previously, 
currently there is a observable blink (after which the brightness is 
correct). 

The reason for the behaviour is that its turning the backlight down/off
to save power as it thinks the screen is blank. The blink therefore
makes sense as far as the backlight class is concerned and its working
as intended now.

quoted

I have put some debugging printk() into fb_notifier_callback(), 
and it turns out that on FB_EVENT_CONBLANK, there are two successive calls 
to backlight_update_status(), second immediately following the first one:

Feb 26 15:11:14 thunder kernel: calling backlight_update_status() with bd->props.fb_blank == 1, bd->props.brightness == 0
Feb 26 15:11:14 thunder kernel: calling backlight_update_status() with bd->props.fb_blank == 0, bd->props.brightness == 0

Is this really a right thing to do?

Well, no, the console should not blank and immediately unblank. Of
course, the console can blank after some time and can be induced to
unblank after a keyboard event, for example.

Besides the debugging printk's, can you also add something like
WARN_ON(1); so you can get a tracing too.

Tony



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV