[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070226160354.GC2909@khazad-dum.debian.net>
Date: Mon, 26 Feb 2007 13:03:54 -0300
From: Henrique de Moraes Holschuh <hmh@....eng.br>
To: Jiri Kosina <jikos@...os.cz>
Cc: Richard Purdie <rpurdie@...ys.net>, linux-kernel@...r.kernel.org
Subject: Re: 2.6.21-rc1 dims my LCD
On Mon, 26 Feb 2007, Jiri Kosina wrote:
> Now regarding the patch - at the time when the dim happened previously,
> currently there is a observable blink (after which the brightness is
> correct). 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
This should cause *no* blink. It is setting brightness to zero anyway, which
is all ibm-acpi cares about (without a patch I will be sending in soon).
And ibm-acpi doesn't issue hardware calls that would not change the
brightness value.
If a brightness value query is causing blinks on your thinkpad, something is
very weird.
Maybe something else is also getting these events and processing them?
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists