Dear Kernel Developers,
Since the most recent successful for me kernel 2.6.19-rc6-mm1, I've
tried few times to build more recent snapshots and now finally
2.6.20-mm2. In all those cases I have a sad outcome -- kernel boots but
at some point during boot (few moments after Penguin icon in the top left
corner appears), light turns off... I still can see something, especially
if I light a strong flashlight at a sharp angle.
I've enabled back-light support and lcd support for those unsuccessful
kernels (with all backlight support features disabled kernel boots
ok and backlight shines as bright as always)
All my changes of values for files under
/sys/class/backlight/radeonbl0
had no impact on the screen. Also I had no files under /sys/class/lcd.
Running
radeontool light off
caused complete turning off of LCD - I could not see
anything anymore.
sony's spictl -b had no effect as well.
Config can be found at
http://www.onerussian.com/Linux/bugs/nobacklight.1/config-2.6.20-mm2
lshw
http://www.onerussian.com/Linux/bugs/nobacklight.1/lshw
other details are available from
http://www.onerussian.com/Linux/bugs/nobacklight.1/
Could you please advise?
--
Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW: http://www.linkedin.com/in/yarik
On Sun, 18 Feb 2007 23:46:16 -0500 Yaroslav Halchenko <[email protected]> wrote:
> Dear Kernel Developers,
>
> Since the most recent successful for me kernel 2.6.19-rc6-mm1, I've
> tried few times to build more recent snapshots and now finally
> 2.6.20-mm2. In all those cases I have a sad outcome -- kernel boots but
> at some point during boot (few moments after Penguin icon in the top left
> corner appears), light turns off... I still can see something, especially
> if I light a strong flashlight at a sharp angle.
>
> I've enabled back-light support and lcd support for those unsuccessful
> kernels (with all backlight support features disabled kernel boots
> ok and backlight shines as bright as always)
>
> All my changes of values for files under
> /sys/class/backlight/radeonbl0
> had no impact on the screen. Also I had no files under /sys/class/lcd.
>
> Running
> radeontool light off
> caused complete turning off of LCD - I could not see
> anything anymore.
>
> sony's spictl -b had no effect as well.
>
> Config can be found at
> http://www.onerussian.com/Linux/bugs/nobacklight.1/config-2.6.20-mm2
> lshw
> http://www.onerussian.com/Linux/bugs/nobacklight.1/lshw
> other details are available from
> http://www.onerussian.com/Linux/bugs/nobacklight.1/
>
> Could you please advise?
(cc's added)
Is 2.6.20 broken? I assume the latest 2.6.20-gitN snapshot are failing..
On Mon, 2007-02-19 at 00:04 -0800, Andrew Morton wrote:
> On Sun, 18 Feb 2007 23:46:16 -0500 Yaroslav Halchenko <[email protected]> wrote:
> > Since the most recent successful for me kernel 2.6.19-rc6-mm1, I've
> > tried few times to build more recent snapshots and now finally
> > 2.6.20-mm2. In all those cases I have a sad outcome -- kernel boots but
> > at some point during boot (few moments after Penguin icon in the top left
> > corner appears), light turns off... I still can see something, especially
> > if I light a strong flashlight at a sharp angle.
> >
> > I've enabled back-light support and lcd support for those unsuccessful
> > kernels (with all backlight support features disabled kernel boots
> > ok and backlight shines as bright as always)
> >
> > All my changes of values for files under
> > /sys/class/backlight/radeonbl0
> > had no impact on the screen. Also I had no files under /sys/class/lcd.
> >
> > Running
> > radeontool light off
> > caused complete turning off of LCD - I could not see
> > anything anymore.
> >
> > sony's spictl -b had no effect as well.
> >
> > Config can be found at
> > http://www.onerussian.com/Linux/bugs/nobacklight.1/config-2.6.20-mm2
> > lshw
> > http://www.onerussian.com/Linux/bugs/nobacklight.1/lshw
> > other details are available from
> > http://www.onerussian.com/Linux/bugs/nobacklight.1/
> >
> > Could you please advise?
>
> (cc's added)
>
> Is 2.6.20 broken? I assume the latest 2.6.20-gitN snapshot are failing..
It would be extremely useful to know which kernel versions you tested
and which ones failed. There are a number of backlight changes which are
just in 2.6.20-mm1 and -mm2 which it would be useful to rule out or
identify as the cause.
Also, do you normally see files under /sys/class/lcd?
Regards,
Richard
I am sorry on the delay
> > On Sun, 18 Feb 2007 23:46:16 -0500 Yaroslav Halchenko <[email protected]> wrote:
> > > Since the most recent successful for me kernel 2.6.19-rc6-mm1, I've
> > > tried few times to build more recent snapshots and now finally
> > > 2.6.20-mm2. In all those cases I have a sad outcome -- kernel boots but
> > > >...<
> > Is 2.6.20 broken? I assume the latest 2.6.20-gitN snapshot are failing..
-mm's have been failing since some time after .19-rc6-mm1. I believe
I've tried 2.6.19-mm? with the same luck
> It would be extremely useful to know which kernel versions you tested
> and which ones failed. There are a number of backlight changes which are
> just in 2.6.20-mm1 and -mm2 which it would be useful to rule out or
> identify as the cause.
I didn't mention 2.6.20-mm1 and got to see -mm2 so it is the one which
Iv'e tried, but, once again, I experienced the same issue with 19-mm?
kernels.
I built 2.6.20-mm2 without backlight support
$> grep BACKLIGH /boot/config-2.6.20-mm2
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
# CONFIG_FB_BACKLIGHT is not set
# CONFIG_FB_RIVA_BACKLIGHT is not set
# CONFIG_FB_RADEON_BACKLIGHT is not set
that "eliminated" the problem. Also I can see the screen with pure
2.6.20 with backlight support (whatever it does since after
loading lcd, backlight modules, my /sys/class/{lcd,backlight} are empty):
*$> grep BACKLIGH /boot/config-2.6.20
# CONFIG_FB_BACKLIGHT is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=m
CONFIG_BACKLIGHT_DEVICE=y
> Also, do you normally see files under /sys/class/lcd?
nope... after I load lcd module, no files under :-/ regardless either it
is mm or not. But there are files under /sys/class/backlight/ for mm2
compiled with backlight support (whenever the screen is dark as per my
original email)
--
.-.
=------------------------------ /v\ ----------------------------=
Keep in touch // \\ (yoh@|http://www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User ^^-^^ [175555]
Richard Purdie <[email protected]> writes:
> On Mon, 2007-02-19 at 00:04 -0800, Andrew Morton wrote:
>> On Sun, 18 Feb 2007 23:46:16 -0500 Yaroslav Halchenko <[email protected]> wrote:
>> > Since the most recent successful for me kernel 2.6.19-rc6-mm1, I've
>> > tried few times to build more recent snapshots and now finally
>> > 2.6.20-mm2. In all those cases I have a sad outcome -- kernel boots but
>> > at some point during boot (few moments after Penguin icon in the top left
>> > corner appears), light turns off... I still can see something, especially
>> > if I light a strong flashlight at a sharp angle.
>> >
>> > I've enabled back-light support and lcd support for those unsuccessful
>> > kernels (with all backlight support features disabled kernel boots
>> > ok and backlight shines as bright as always)
>>
>> Is 2.6.20 broken? I assume the latest 2.6.20-gitN snapshot are failing..
>
> It would be extremely useful to know which kernel versions you tested
> and which ones failed. There are a number of backlight changes which are
> just in 2.6.20-mm1 and -mm2 which it would be useful to rule out or
> identify as the cause.
i have exactly the same problem with 2.6.21-rc1 on a thinkpad t40
with an ati radeon card. the machine boots up but the backlight never
comes on. 2.6.20 worked okay.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
On Wed, 2007-02-21 at 14:18 -0800, Alex Romosan wrote:
> Richard Purdie <[email protected]> writes:
> i have exactly the same problem with 2.6.21-rc1 on a thinkpad t40
> with an ati radeon card. the machine boots up but the backlight never
> comes on. 2.6.20 worked okay.
Can you have a look at the differences between the defconfigs for 2.6.20
and 2.6.21-rc1?
If the backlight changes are at fault, I'm guessing James' Kconfig
changes to the video Kconfig would be the culprit since
FB_RADEON_BACKLIGHT only used to be selectable if PMAC_BACKLIGHT was
enabled. On a thinkpad, the backlight is probably under ACPI control.
If FB_RADEON_BACKLIGHT wasn't set for 2.6.20, can you try 2.6.21-rc1
with that option disabled?
An ls /sys/class/backlight under 2.6.20 will tell us which driver it was
using...
Thanks,
Richard
On Wed, 21 Feb 2007, Richard Purdie wrote:
> enabled. On a thinkpad, the backlight is probably under ACPI control.
BIOS+ACPI, actually. Without ACPI video loaded, the firmware does
everything correctly. With ACPI video, the firmware does it, then its
changes are clobbered over by ACPI video's.
If ibm-acpi is loaded, a backlight device "ibm" is added. ibm-acpi's ibm
backlight device can change the display brightness. It is *not* capable of
turning the backlight on or off, AFAIK.
BTW, some ThinkPads don't have a Radeon, but rather an Intel GM/GMX device.
--
"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
Richard Purdie <[email protected]> writes:
> If FB_RADEON_BACKLIGHT wasn't set for 2.6.20, can you try 2.6.21-rc1
> with that option disabled?
i don't have my laptop with me but i am pretty sure
FB_RADEON_BACKLIGHT wasn't set for 2.6.20 (i think it showed up as a
new option when i did make oldconfig). i'll post the difference when i
get home tonight and also try disabling it.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
On Wed, 2007-02-21 at 21:17 -0200, Henrique de Moraes Holschuh wrote:
> On Wed, 21 Feb 2007, Richard Purdie wrote:
> > enabled. On a thinkpad, the backlight is probably under ACPI control.
>
> BIOS+ACPI, actually. Without ACPI video loaded, the firmware does
> everything correctly. With ACPI video, the firmware does it, then its
> changes are clobbered over by ACPI video's.
>
> If ibm-acpi is loaded, a backlight device "ibm" is added. ibm-acpi's ibm
> backlight device can change the display brightness. It is *not* capable of
> turning the backlight on or off, AFAIK.
>
> BTW, some ThinkPads don't have a Radeon, but rather an Intel GM/GMX device.
I have a thinkpad with Intel GM graphics ;-). I need it to work so I try
not to experiment too much on it. I've just tried the ibm-acpi driver
and it doesn't work well :-(.
So far I've noticed:
* 'cat brightness' != 'cat actual_brightness' upon bootup (doesn't have
to be true if there is hardware brightness limiting or level changing in
action but that wouldn't be the case here and this could be fixed
easily).
* 'echo 0 > brightness' lowered the intensity but by a level or two, not
set it to level 0. A couple of more attempts and it did jump from 7 -> 1
and so on, it seems erratic.
actual_brightness always seems to be correct, as does brightness so it
looks like its not updating the hardware correctly.
Regards,
Richard
On Wed, 2007-02-21 at 00:56 -0500, Yaroslav Halchenko wrote:
> I didn't mention 2.6.20-mm1 and got to see -mm2 so it is the one which
> Iv'e tried, but, once again, I experienced the same issue with 19-mm?
> kernels.
>
> I built 2.6.20-mm2 without backlight support
> $> grep BACKLIGH /boot/config-2.6.20-mm2
> # CONFIG_BACKLIGHT_LCD_SUPPORT is not set
> # CONFIG_FB_BACKLIGHT is not set
> # CONFIG_FB_RIVA_BACKLIGHT is not set
> # CONFIG_FB_RADEON_BACKLIGHT is not set
>
> that "eliminated" the problem. Also I can see the screen with pure
> 2.6.20 with backlight support (whatever it does since after
> loading lcd, backlight modules, my /sys/class/{lcd,backlight} are empty):
>
> *$> grep BACKLIGH /boot/config-2.6.20
> # CONFIG_FB_BACKLIGHT is not set
> CONFIG_BACKLIGHT_LCD_SUPPORT=y
> CONFIG_BACKLIGHT_CLASS_DEVICE=m
> CONFIG_BACKLIGHT_DEVICE=y
>
>
> > Also, do you normally see files under /sys/class/lcd?
> nope... after I load lcd module, no files under :-/ regardless either it
> is mm or not. But there are files under /sys/class/backlight/ for mm2
> compiled with backlight support (whenever the screen is dark as per my
> original email)
There should be no files appearing under /sys/class/lcd, so thats all
normal. There is another report with similar symptoms which also sounds
like enabling the following options are at fault:
# CONFIG_FB_RIVA_BACKLIGHT is not set
# CONFIG_FB_RADEON_BACKLIGHT is not set
I suspect these options only work on certain hardware and aren't
generic. James, any idea what hardware these do/don't work with?
Worst case, we set them to depend on PMAC_BACKLIGHT again I guess...
Richard
On Thu, 22 Feb 2007, Richard Purdie wrote:
> I have a thinkpad with Intel GM graphics ;-). I need it to work so I try
> not to experiment too much on it. I've just tried the ibm-acpi driver
> and it doesn't work well :-(.
2.6.21-rc, or 2.6.20? If it is in 2.6.21, could you give me a report of how
it fares on 2.6.20?
> * 'cat brightness' != 'cat actual_brightness' upon bootup (doesn't have
Hmm, I see this in 2.6.20 too. And brightness is the one that is buggy. I
will look into it.
> * 'echo 0 > brightness' lowered the intensity but by a level or two, not
> set it to level 0. A couple of more attempts and it did jump from 7 -> 1
> and so on, it seems erratic.
I know it used to work fine before 2.6.20. Let me check... works fine on a
T43, 2.6.20 (Radeon X300). I need more data to fix it :-)
> actual_brightness always seems to be correct, as does brightness so it
> looks like its not updating the hardware correctly.
Well, if you have the ACPI video module loaded, unload it. Does it work
now?
--
"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
> On Wed, 2007-02-21 at 00:56 -0500, Yaroslav Halchenko wrote:
> > I didn't mention 2.6.20-mm1 and got to see -mm2 so it is the one which
> > Iv'e tried, but, once again, I experienced the same issue with 19-mm?
> > kernels.
> >
> > I built 2.6.20-mm2 without backlight support
> > $> grep BACKLIGH /boot/config-2.6.20-mm2
> > # CONFIG_BACKLIGHT_LCD_SUPPORT is not set
> > # CONFIG_FB_BACKLIGHT is not set
> > # CONFIG_FB_RIVA_BACKLIGHT is not set
> > # CONFIG_FB_RADEON_BACKLIGHT is not set
> >
> > that "eliminated" the problem. Also I can see the screen with pure
> > 2.6.20 with backlight support (whatever it does since after
> > loading lcd, backlight modules, my /sys/class/{lcd,backlight} are empty):
> >
> > *$> grep BACKLIGH /boot/config-2.6.20
> > # CONFIG_FB_BACKLIGHT is not set
> > CONFIG_BACKLIGHT_LCD_SUPPORT=y
> > CONFIG_BACKLIGHT_CLASS_DEVICE=m
> > CONFIG_BACKLIGHT_DEVICE=y
> >
> >
> > > Also, do you normally see files under /sys/class/lcd?
> > nope... after I load lcd module, no files under :-/ regardless either it
> > is mm or not. But there are files under /sys/class/backlight/ for mm2
> > compiled with backlight support (whenever the screen is dark as per my
> > original email)
>
> There should be no files appearing under /sys/class/lcd, so thats all
> normal. There is another report with similar symptoms which also sounds
> like enabling the following options are at fault:
Correct. LCD class was never used by anyone.
> # CONFIG_FB_RIVA_BACKLIGHT is not set
> # CONFIG_FB_RADEON_BACKLIGHT is not set
>
> I suspect these options only work on certain hardware and aren't
> generic. James, any idea what hardware these do/don't work with?
>
> Worst case, we set them to depend on PMAC_BACKLIGHT again I guess...
Ug. Previously it did the selecting for you. If you selected
backlight support the fbdev backlight would just come to life. This caused
problems for the case of having ACPI backlight and a fbdev driver with
backlight support. Two drivers controling the same hardware is not the
greatest idea. I made it so that people explictly had to pick the backlight
with a fbdev device. The other reason for this change was not every
one is using a LCD display. I have a system at home that uses a CRT.
Plus their is the case of "standard" PC graphics cards being used
in embedded devices. In this case even tho the graphics card has backlight
support the external lcd/backlight is routed through gpio independent of
the embedded graphics card. In such case we don't want to enable the
backlight for the graphics card but enable it.
In a nut shell the solution is select the backlight support for your
fbdev driver if you need it.
On Wed, 21 Feb 2007, Henrique de Moraes Holschuh wrote:
> > * 'cat brightness' != 'cat actual_brightness' upon bootup (doesn't have
>
> Hmm, I see this in 2.6.20 too. And brightness is the one that is buggy. I
> will look into it.
Now, that was trivial to fix, and I will reply with a patch (which will have
Cc's trimmed to just the MLs and Richard).
But really, should not the backlight *class* be doing the initial update of
the brightness? Looks like something that every device would need to do if
the class doesn't do it, and unlike the "power it off on unregister" thing,
I can't think of a reason not to do it for every backlight class device.
Please ACK the ibm-acpi patch in my next message if you'd like me to submit
it to Len Brown for merging into 2.6.21, or NACK it if you'd rather do it in
the backlight class core.
--
"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
On Wed, 2007-02-21 at 22:51 -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 22 Feb 2007, Richard Purdie wrote:
> > I have a thinkpad with Intel GM graphics ;-). I need it to work so I try
> > not to experiment too much on it. I've just tried the ibm-acpi driver
> > and it doesn't work well :-(.
>
> 2.6.21-rc, or 2.6.20?
2.6.21-rc1
> If it is in 2.6.21, could you give me a report of how
> it fares on 2.6.20?
Maybe next week. I'm away over the weekend and I need it working now ;-).
> > * 'echo 0 > brightness' lowered the intensity but by a level or two, not
> > set it to level 0. A couple of more attempts and it did jump from 7 -> 1
> > and so on, it seems erratic.
>
> I know it used to work fine before 2.6.20. Let me check... works fine on a
> T43, 2.6.20 (Radeon X300). I need more data to fix it :-)
The following sequence is reproducible:
echo 7 > brightness (repeat until actual_brightness reads 7)
echo 0 > brightness (brightness reads 0, actual_brightness reads 4)
echo 0 > brightness (brightness reads 0, actual_brightness reads 0)
I suspect this is interference from software on the machine as it does
show an onscreen display when I change the values in sysfs and the
values on the OSD don't match what's really going on. The
actual_brightness does match the screen.
I guess this just means we need to get userspace to agree on one method
of access for this kind of thing. It makes me wondering where the
hardware brightness keys fit into things though...
> > actual_brightness always seems to be correct, as does brightness so it
> > looks like its not updating the hardware correctly.
>
> Well, if you have the ACPI video module loaded, unload it. Does it work
> now?
No change if unloaded.
Cheers,
Richard
> I built 2.6.20-mm2 without backlight support
> $> grep BACKLIGH /boot/config-2.6.20-mm2
> # CONFIG_BACKLIGHT_LCD_SUPPORT is not set
> # CONFIG_FB_BACKLIGHT is not set
> # CONFIG_FB_RIVA_BACKLIGHT is not set
> # CONFIG_FB_RADEON_BACKLIGHT is not set
>
> that "eliminated" the problem. Also I can see the screen with pure
> 2.6.20 with backlight support (whatever it does since after
> loading lcd, backlight modules, my /sys/class/{lcd,backlight} are empty):
>
> *$> grep BACKLIGH /boot/config-2.6.20
> # CONFIG_FB_BACKLIGHT is not set
> CONFIG_BACKLIGHT_LCD_SUPPORT=y
> CONFIG_BACKLIGHT_CLASS_DEVICE=m
> CONFIG_BACKLIGHT_DEVICE=y
You need to explictly enable the backlight for your fbdev driver. It
doesn't do the selecting magically for you.
Jus do a make "favorite"config and go to the fbdev menu and select the
backlight option for your fbdev driver.
> Richard Purdie <[email protected]> writes:
>
> > If FB_RADEON_BACKLIGHT wasn't set for 2.6.20, can you try 2.6.21-rc1
> > with that option disabled?
>
> i don't have my laptop with me but i am pretty sure
> FB_RADEON_BACKLIGHT wasn't set for 2.6.20 (i think it showed up as a
> new option when i did make oldconfig). i'll post the difference when i
> get home tonight and also try disabling it.
Correct. You need to enable the backlight for the radeon card.
The brightness class core does not update the initial status of
the device's brightness at register time. Do it by ourselves
before we register the class device.
Signed-off-by: Henrique de Moraes Holschuh <[email protected]>
Cc: Richard Purdie <[email protected]>
---
NOTE: This patch needs an ACK from Richard Purdie before it can be merged,
as he might want to change the backlight class code instead.
drivers/acpi/ibm_acpi.c | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c
index 2429e11..6875421 100644
--- a/drivers/acpi/ibm_acpi.c
+++ b/drivers/acpi/ibm_acpi.c
@@ -1713,6 +1713,13 @@ static struct backlight_properties ibm_backlight_data = {
static int brightness_init(void)
{
+ int b;
+
+ b = brightness_get(NULL);
+ if (b < 0)
+ return b;
+ ibm_backlight_data.brightness = b;
+
ibm_backlight_device = backlight_device_register("ibm", NULL, NULL,
&ibm_backlight_data);
if (IS_ERR(ibm_backlight_device)) {
--
1.4.4.4
--
"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
On Thu, Feb 22, 2007 at 01:11:18AM +0000, James Simmons wrote:
> > *$> grep BACKLIGH /boot/config-2.6.20
> > # CONFIG_FB_BACKLIGHT is not set
> > CONFIG_BACKLIGHT_LCD_SUPPORT=y
> > CONFIG_BACKLIGHT_CLASS_DEVICE=m
> > CONFIG_BACKLIGHT_DEVICE=y
>
> You need to explictly enable the backlight for your fbdev driver. It
> doesn't do the selecting magically for you.
> Jus do a make "favorite"config and go to the fbdev menu and select the
> backlight option for your fbdev driver.
I would think that we'd always want to enable the backlight.
How are people supposed to Just Know that the kernel defaults to a black
LCD?
Joel
--
Life's Little Instruction Book #407
"Every once in a while, take the scenic route."
Joel Becker
Principal Software Developer
Oracle
E-mail: [email protected]
Phone: (650) 506-8127
On Thu, 22 Feb 2007, Richard Purdie wrote:
> The following sequence is reproducible:
>
> echo 7 > brightness (repeat until actual_brightness reads 7)
> echo 0 > brightness (brightness reads 0, actual_brightness reads 4)
> echo 0 > brightness (brightness reads 0, actual_brightness reads 0)
As I said, it works fine on 2.6.20 on the hardware I have. I will see if I
can test on 2.6.21, but it is something non-trivial for me to do right now.
> I suspect this is interference from software on the machine as it does
> show an onscreen display when I change the values in sysfs and the
Yes, I am using something like that here too, and it doesn't break anything.
> values on the OSD don't match what's really going on. The
> actual_brightness does match the screen.
So something is screwing with what gets written to the EC, and it does it
AFTER ibm-acpi started processing the brightness change request.
actual_brightness asks the *EC* what the current brightness value is, so it
will never be wrong on a new-enough ThinkPad.
> I guess this just means we need to get userspace to agree on one method
> of access for this kind of thing. It makes me wondering where the
> hardware brightness keys fit into things though...
For ThinkPads:
The Golden Rule: never talk to the EC or write to firmware-command-space in
the CMOS NVRAM in userspace. If you do, bad things could happen and it is
your fault.
Here's how brightness control works in ThinkPads:
0. Brightness and backlight on/off state are decoupled. Turning the
backlight on or off is done through DPMS or something else video-card
specific. Newer models shut the backlight off by EC firmware (or maybe even
on hardware) when the lid is closed, too.
1. The thinkpad does everything brightness-related in firmware (EC+BIOS).
If you keep your hands off, it works correctly on every O.S.
2. The brightness up key exports hotkey events (all models) and a brightness
up ACPI event (*60 and newer thinkpads, with 2.x BIOS). It is a bad idea to
use those events to change the backlight brightness, because the firmware
will be doing just that too.
3. It doesn't export anything for brightness down. You find it happened
snooping the CMOS nvram.
4. Ibm-acpi doesn't care about the ACPI events much, it just asks the EC
what the brightness level is when it needs to do something, then it issues
both CMOS commands and EC writes to make damn sure the level is changed.
The CMOS commands are step-style, so to go from 4 to 7, you issue 3x
brightness up.
> > Well, if you have the ACPI video module loaded, unload it. Does it work
> > now?
>
> No change if unloaded.
I am out of ideas. But blacklist that module on your ThinkPad, it just gets
in the way, even if you are not using ibm-acpi.
--
"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
Richard Purdie writes:
> Can you have a look at the differences between the defconfigs for
> 2.6.20 and 2.6.21-rc1?
this is probably the relevant part:
--- config-2.6.20 2007-02-04 12:09:28.000000000 -0800
+++ config-2.6.21-rc1 2007-02-21 08:37:53.000000000 -0800
@@ -1270,16 +1302,25 @@
#
# Graphics support
#
-CONFIG_FIRMWARE_EDID=y
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_LCD_CLASS_DEVICE=y
+# CONFIG_BACKLIGHT_PROGEAR is not set
CONFIG_FB=y
+CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DDC=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
+# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
-# CONFIG_FB_BACKLIGHT is not set
+CONFIG_FB_BACKLIGHT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y
+
+#
+# Frambuffer hardware drivers
+#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
@@ -1297,9 +1338,11 @@
# CONFIG_FB_MATROX is not set
CONFIG_FB_RADEON=y
CONFIG_FB_RADEON_I2C=y
+CONFIG_FB_RADEON_BACKLIGHT=y
# CONFIG_FB_RADEON_DEBUG is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
+# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
@@ -1333,11 +1376,6 @@
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
-CONFIG_BACKLIGHT_LCD_SUPPORT=y
-CONFIG_BACKLIGHT_CLASS_DEVICE=y
-CONFIG_BACKLIGHT_DEVICE=y
-CONFIG_LCD_CLASS_DEVICE=m
-CONFIG_LCD_DEVICE=y
#
# Sound
> If the backlight changes are at fault, I'm guessing James' Kconfig
> changes to the video Kconfig would be the culprit since
> FB_RADEON_BACKLIGHT only used to be selectable if PMAC_BACKLIGHT was
> enabled. On a thinkpad, the backlight is probably under ACPI
> control.
there was no FB_RADEON_BACKLIGHT in 2.6.20 and CONFIG_FB_BACKLIGHT
wasn't set.
> If FB_RADEON_BACKLIGHT wasn't set for 2.6.20, can you try 2.6.21-rc1
> with that option disabled?
i'll try recompiling without this option and let you know what happened.
> An ls /sys/class/backlight under 2.6.20 will tell us which driver it
> was using...
ls /sys/class/backlight/
0 ./ 0 ../ 0 ibm/
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
Richard Purdie <[email protected]> writes:
> If FB_RADEON_BACKLIGHT wasn't set for 2.6.20, can you try 2.6.21-rc1
> with that option disabled?
i've disabled FB_RADEON_BACKLIGHT (FB_BACKLIGHT also got deselected)
and i managed to boot into 2.6.21-rc1 and have a working backlight.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
On Thu, 2007-02-22 at 01:07 +0000, James Simmons wrote:
> > # CONFIG_FB_RIVA_BACKLIGHT is not set
> > # CONFIG_FB_RADEON_BACKLIGHT is not set
> >
> > I suspect these options only work on certain hardware and aren't
> > generic. James, any idea what hardware these do/don't work with?
> >
> > Worst case, we set them to depend on PMAC_BACKLIGHT again I guess...
>
> Ug. Previously it did the selecting for you. If you selected
> backlight support the fbdev backlight would just come to life. This caused
> problems for the case of having ACPI backlight and a fbdev driver with
> backlight support. Two drivers controling the same hardware is not the
> greatest idea. I made it so that people explictly had to pick the backlight
> with a fbdev device. The other reason for this change was not every
> one is using a LCD display. I have a system at home that uses a CRT.
> Plus their is the case of "standard" PC graphics cards being used
> in embedded devices. In this case even tho the graphics card has backlight
> support the external lcd/backlight is routed through gpio independent of
> the embedded graphics card. In such case we don't want to enable the
> backlight for the graphics card but enable it.
> In a nut shell the solution is select the backlight support for your
> fbdev driver if you need it.
This is ugly for distribution maintainers as pick the wrong Kconfig
options and your device breaks. You need a different build depending on
the hardware you have.
I understand some people need to be able to turn these things on but it
sounds like the majority of users don't need it and it will break things
for them. The config option sounds tempting to them though...
In case anyone else is wondering, the commit in question is
http://git.o-hand.com/?p=linux-rpurdie-backlight;a=commitdiff;h=e0e34ef7f02915cfe50e501e9f32c24217177a96
and previously, all the appropriate entries had "depends PMAC_BACKLIGHT"
I think the way forward is going to be to have the backlights disabled
by default at runtime and require enabling through a framebuffer module
parameter. The should be enabled by default in the PMAC_BACKLIGHT case.
Anyone needing it can then pass the appropriate parameter. Does that
sound like the best solution?
Cheers,
Richard
On Thu, 2007-02-22 at 01:13 +0000, James Simmons wrote:
> > Richard Purdie <[email protected]> writes:
> >
> > > If FB_RADEON_BACKLIGHT wasn't set for 2.6.20, can you try 2.6.21-rc1
> > > with that option disabled?
> >
> > i don't have my laptop with me but i am pretty sure
> > FB_RADEON_BACKLIGHT wasn't set for 2.6.20 (i think it showed up as a
> > new option when i did make oldconfig). i'll post the difference when i
> > get home tonight and also try disabling it.
>
> Correct. You need to enable the backlight for the radeon card.
The problem is when that is set, the device doesn't work as they need
the ibm ACPI driver, not the raedon one.
Richard
On Wed, 2007-02-21 at 23:10 -0200, Henrique de Moraes Holschuh wrote:
> On Wed, 21 Feb 2007, Henrique de Moraes Holschuh wrote:
> > > * 'cat brightness' != 'cat actual_brightness' upon bootup (doesn't have
> >
> > Hmm, I see this in 2.6.20 too. And brightness is the one that is buggy. I
> > will look into it.
>
> Now, that was trivial to fix, and I will reply with a patch (which will have
> Cc's trimmed to just the MLs and Richard).
>
> But really, should not the backlight *class* be doing the initial update of
> the brightness? Looks like something that every device would need to do if
> the class doesn't do it, and unlike the "power it off on unregister" thing,
> I can't think of a reason not to do it for every backlight class device.
>
> Please ACK the ibm-acpi patch in my next message if you'd like me to submit
> it to Len Brown for merging into 2.6.21, or NACK it if you'd rather do it in
> the backlight class core.
We can't change the backlight class code since some hardware can't read
from the device, only write to it. Initialisation in that case is a bit
different.
Richard
On Wed, 2007-02-21 at 23:16 -0200, Henrique de Moraes Holschuh wrote:
> NOTE: This patch needs an ACK from Richard Purdie before it can be merged,
> as he might want to change the backlight class code instead.
As mentioned elsewhere, we can't do this in the class itself.
> --- a/drivers/acpi/ibm_acpi.c
> +++ b/drivers/acpi/ibm_acpi.c
> @@ -1713,6 +1713,13 @@ static struct backlight_properties ibm_backlight_data = {
>
> static int brightness_init(void)
> {
> + int b;
> +
> + b = brightness_get(NULL);
> + if (b < 0)
> + return b;
> + ibm_backlight_data.brightness = b;
> +
> ibm_backlight_device = backlight_device_register("ibm", NULL, NULL,
> &ibm_backlight_data);
This isn't against 2.6.21-rc1 which changed the backlight class a bit.
Basically, you need to set the brightness variable after
backlight_device_register(). It should be simple enough to do and fix
the problem the same way though.
Richard
On Thu, 22 Feb 2007, Richard Purdie wrote:
> On Thu, 2007-02-22 at 01:13 +0000, James Simmons wrote:
> > > Richard Purdie <[email protected]> writes:
> > >
> > > > If FB_RADEON_BACKLIGHT wasn't set for 2.6.20, can you try 2.6.21-rc1
> > > > with that option disabled?
> > >
> > > i don't have my laptop with me but i am pretty sure
> > > FB_RADEON_BACKLIGHT wasn't set for 2.6.20 (i think it showed up as a
> > > new option when i did make oldconfig). i'll post the difference when i
> > > get home tonight and also try disabling it.
> >
> > Correct. You need to enable the backlight for the radeon card.
>
> The problem is when that is set, the device doesn't work as they need
> the ibm ACPI driver, not the raedon one.
They need the ibm-acpi one for brightness, and the radeon one for on/off. I
want a way to join that all together in a single place, if at all possible.
--
"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
The brightness class core does not update the initial status of the
device's brightness at register time. Do it by ourselves.
Signed-off-by: Henrique de Moraes Holschuh <[email protected]>
Cc: Richard Purdie <[email protected]>
---
Waiting ACK from Richard Purdie, applies on top of 2.6.21-rc1. Also fixes a
whitespace problem.
drivers/acpi/ibm_acpi.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c
index 4cc534e..c59ebff 100644
--- a/drivers/acpi/ibm_acpi.c
+++ b/drivers/acpi/ibm_acpi.c
@@ -1711,6 +1711,12 @@ static struct backlight_ops ibm_backlight_data = {
static int brightness_init(void)
{
+ int b;
+
+ b = brightness_get(NULL);
+ if (b < 0)
+ return b;
+
ibm_backlight_device = backlight_device_register("ibm", NULL, NULL,
&ibm_backlight_data);
if (IS_ERR(ibm_backlight_device)) {
@@ -1718,7 +1724,8 @@ static int brightness_init(void)
return PTR_ERR(ibm_backlight_device);
}
- ibm_backlight_device->props.max_brightness = 7;
+ ibm_backlight_device->props.max_brightness = 7;
+ ibm_backlight_device->props.brightness = b;
return 0;
}
--
1.4.4.4
--
"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
On Thu, 22 Feb 2007, Richard Purdie wrote:
> > it to Len Brown for merging into 2.6.21, or NACK it if you'd rather do it in
> > the backlight class core.
>
> We can't change the backlight class code since some hardware can't read
> from the device, only write to it. Initialisation in that case is a bit
> different.
Initializing stuff after registering is also racy as the device is not
locked but we are going to clobber data in its properties struct. I don't
particularly care about that race, but...
Anyway, you have the 2.6.21-rc patch now, to ACK or NACK. I still think the
class should be handling this. If a device is write-only, it should have no
_get ops handler, which means that the class can easily differentiate the
two cases and do the right thing for both. There's less code duplication
that way.
Howerver, I *do* strongly wish for a way to combine various drivers into a
single backlight device, where radeon/intelfb takes care of some stuff,
ibm-acpi/asus-laptop/sony-laptop takes care of other stuff, etc. Also, a
standard naming for the builtin screen(s) would help, calling it "ibm",
"asus", "sony" is not good IMHO.
--
"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
> > Ug. Previously it did the selecting for you. If you selected
> > backlight support the fbdev backlight would just come to life. This caused
> > problems for the case of having ACPI backlight and a fbdev driver with
> > backlight support. Two drivers controling the same hardware is not the
> > greatest idea. I made it so that people explictly had to pick the backlight
> > with a fbdev device. The other reason for this change was not every
> > one is using a LCD display. I have a system at home that uses a CRT.
> > Plus their is the case of "standard" PC graphics cards being used
> > in embedded devices. In this case even tho the graphics card has backlight
> > support the external lcd/backlight is routed through gpio independent of
> > the embedded graphics card. In such case we don't want to enable the
> > backlight for the graphics card but enable it.
> > In a nut shell the solution is select the backlight support for your
> > fbdev driver if you need it.
>
> This is ugly for distribution maintainers as pick the wrong Kconfig
> options and your device breaks. You need a different build depending on
> the hardware you have.
Distros would have to enable "standard" backlights to maximize their
target machines. In other words they will aim for backlights from the ACPI layer
for x86_64/ia32 machine and pmac_backlights for select ppc machines.
Specially since most default kernels on distros use only vgacon for intel
type machines.
> I understand some people need to be able to turn these things on but it
> sounds like the majority of users don't need it and it will break things
> for them. The config option sounds tempting to them though...
>
> In case anyone else is wondering, the commit in question is
> http://git.o-hand.com/?p=linux-rpurdie-backlight;a=commitdiff;h=e0e34ef7f02915cfe50e501e9f32c24217177a96
> and previously, all the appropriate entries had "depends PMAC_BACKLIGHT"
>
> I think the way forward is going to be to have the backlights disabled
> by default at runtime and require enabling through a framebuffer module
> parameter. The should be enabled by default in the PMAC_BACKLIGHT case.
> Anyone needing it can then pass the appropriate parameter. Does that
> sound like the best solution?
That is the correct solution. Basically people that select PMAC_BACKLIGHT
expect there driver to automatically to work. Basically they want
PMAC_BACKLIGHT to work as a generic selectfor there card. I will work up a
patch.
On Thu, 2007-02-22 at 12:56 -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 22 Feb 2007, Richard Purdie wrote:
> > > it to Len Brown for merging into 2.6.21, or NACK it if you'd rather do it in
> > > the backlight class core.
> >
> > We can't change the backlight class code since some hardware can't read
> > from the device, only write to it. Initialisation in that case is a bit
> > different.
>
> Initializing stuff after registering is also racy as the device is not
> locked but we are going to clobber data in its properties struct. I don't
> particularly care about that race, but...
If you really care, add a a call to backlight_update_status() after you
set the brightness attribute like some of the other drivers have. The
only data you're changing are single numbers and as long as
update_status is called afterwards, a consistent state is pushed to the
hardware so there is no race problem.
> Anyway, you have the 2.6.21-rc patch now, to ACK or NACK. I still think the
> class should be handling this. If a device is write-only, it should have no
> _get ops handler, which means that the class can easily differentiate the
> two cases and do the right thing for both. There's less code duplication
> that way.
Have a look at what corgi_bl does. It can know what state it set the
hardware too as it keeps track itself, it just can't read that state
from the hardware. Note how there is extra code in it to handle a power
limit on the backlight under certain conditions and how this is fed back
through the class through the get_brightness method.
Adding one line of code (admittedly slight more due to error handling),
is hardly that much code duplication.
> Howerver, I *do* strongly wish for a way to combine various drivers into a
> single backlight device, where radeon/intelfb takes care of some stuff,
> ibm-acpi/asus-laptop/sony-laptop takes care of other stuff, etc. Also, a
> standard naming for the builtin screen(s) would help, calling it "ibm",
> "asus", "sony" is not good IMHO.
I wasn't aware of this problem. If some devices need bits from both
raedon/whatever and acpi, the current implementations are just plain
wrong. Its not really a backlight class problem and more of an
implementation and interaction problem between acpi and the framebuffer
drivers. They should be presenting and registering *one* backlight class
device, not two. Without knowing more about the circumstances and
how/when to combine which drivers its hard for me to help further...
Richard
> On Thu, Feb 22, 2007 at 01:11:18AM +0000, James Simmons wrote:
> > > *$> grep BACKLIGH /boot/config-2.6.20
> > > # CONFIG_FB_BACKLIGHT is not set
> > > CONFIG_BACKLIGHT_LCD_SUPPORT=y
> > > CONFIG_BACKLIGHT_CLASS_DEVICE=m
> > > CONFIG_BACKLIGHT_DEVICE=y
> >
> > You need to explictly enable the backlight for your fbdev driver. It
> > doesn't do the selecting magically for you.
> > Jus do a make "favorite"config and go to the fbdev menu and select the
> > backlight option for your fbdev driver.
>
> I would think that we'd always want to enable the backlight.
> How are people supposed to Just Know that the kernel defaults to a black
> LCD?
I just tested various confirations of backlight support. Backlight is
ALWAYS selected by default when you select a particular fbdev driver that
has backlight support. You just have the option to turn it off if you
want. These problems are showing up because of stale .config files.
> > Howerver, I *do* strongly wish for a way to combine various drivers into a
> > single backlight device, where radeon/intelfb takes care of some stuff,
> > ibm-acpi/asus-laptop/sony-laptop takes care of other stuff, etc. Also, a
> > standard naming for the builtin screen(s) would help, calling it "ibm",
> > "asus", "sony" is not good IMHO.
>
> I wasn't aware of this problem. If some devices need bits from both
> raedon/whatever and acpi, the current implementations are just plain
> wrong. Its not really a backlight class problem and more of an
> implementation and interaction problem between acpi and the framebuffer
> drivers. They should be presenting and registering *one* backlight class
> device, not two. Without knowing more about the circumstances and
> how/when to combine which drivers its hard for me to help further...
This is always been a problem. For the fbdev layer you can run vesafb with
a specific fbdev driver and they both access the same hardware. There is
no really way around this. The user has to be smart enough to not enable
bothe drivers.
On Thu, 22 Feb 2007, Richard Purdie wrote:
> If you really care, add a a call to backlight_update_status() after you
> set the brightness attribute like some of the other drivers have. The
I will. Do you ACK the patch, then?
> Have a look at what corgi_bl does. It can know what state it set the
> hardware too as it keeps track itself, it just can't read that state
You are assuming nothing else is changing the hardware behind the driver's
back. I am against such assumptions when they can be avoided, but that's a
particular PoV and not much more than that. IMHO, if you cannot query the
hardware, you shouldn't provide a way to query the current brightness that
will be right only if nobody else messed with the device.
Maybe for corgi, that doesn't hold much strength, but for stuff tied to
ACPI, it does. And in a ThinkPad's case, where even writes to /dev/nvram
can change the brightness, well, if there weren't a way to ask the EC the
current real brightness, there is NO way I'd be implementing it based on a
memory cache.
> from the hardware. Note how there is extra code in it to handle a power
> limit on the backlight under certain conditions and how this is fed back
> through the class through the get_brightness method.
I will read the corgi driver code, it looks interesting.
> Adding one line of code (admittedly slight more due to error handling),
> is hardly that much code duplication.
No, it really isn't much trouble. Which is why I wrote a patch right away.
> > Howerver, I *do* strongly wish for a way to combine various drivers into a
> > single backlight device, where radeon/intelfb takes care of some stuff,
> > ibm-acpi/asus-laptop/sony-laptop takes care of other stuff, etc. Also, a
> > standard naming for the builtin screen(s) would help, calling it "ibm",
> > "asus", "sony" is not good IMHO.
>
> I wasn't aware of this problem. If some devices need bits from both
> raedon/whatever and acpi, the current implementations are just plain
> wrong. Its not really a backlight class problem and more of an
> implementation and interaction problem between acpi and the framebuffer
> drivers. They should be presenting and registering *one* backlight class
I.e. we should add hooks to the framebuffer drivers? It would work, that's
for sure.
--
"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
On Thu, 2007-02-22 at 14:34 -0200, Henrique de Moraes Holschuh wrote:
> On Thu, 22 Feb 2007, Richard Purdie wrote:
> > If you really care, add a a call to backlight_update_status() after you
> > set the brightness attribute like some of the other drivers have. The
>
> I will. Do you ACK the patch, then?
Yes, it can have an Acked-by: Richard Purdie <[email protected]>.
> > Have a look at what corgi_bl does. It can know what state it set the
> > hardware too as it keeps track itself, it just can't read that state
>
> You are assuming nothing else is changing the hardware behind the driver's
> back.
Which it can't in the corgi_bl case (excluding poking things
like /dev/mem). Its safe to assume it has exclusive access.
> I am against such assumptions when they can be avoided, but that's a
> particular PoV and not much more than that. IMHO, if you cannot query the
> hardware, you shouldn't provide a way to query the current brightness that
> will be right only if nobody else messed with the device.
>
> Maybe for corgi, that doesn't hold much strength, but for stuff tied to
> ACPI, it does. And in a ThinkPad's case, where even writes to /dev/nvram
> can change the brightness, well, if there weren't a way to ask the EC the
> current real brightness, there is NO way I'd be implementing it based on a
> memory cache.
Right, I'd be against such a driver. On the embedded hardware we can
safely assume there is nothing else playing with the brightness settings
though and such a driver is perfectly valid.
> > > Howerver, I *do* strongly wish for a way to combine various drivers into a
> > > single backlight device, where radeon/intelfb takes care of some stuff,
> > > ibm-acpi/asus-laptop/sony-laptop takes care of other stuff, etc. Also, a
> > > standard naming for the builtin screen(s) would help, calling it "ibm",
> > > "asus", "sony" is not good IMHO.
> >
> > I wasn't aware of this problem. If some devices need bits from both
> > raedon/whatever and acpi, the current implementations are just plain
> > wrong. Its not really a backlight class problem and more of an
> > implementation and interaction problem between acpi and the framebuffer
> > drivers. They should be presenting and registering *one* backlight class
>
> I.e. we should add hooks to the framebuffer drivers? It would work, that's
> for sure.
If the backlight controls would then power off the backlight properly
that would be desirable as we've have a more standard interface.
Richard
From: James Simmons <[email protected]>
Date: Thu, 22 Feb 2007 15:55:24 +0000 (GMT)
> I just tested various confirations of backlight support. Backlight is
> ALWAYS selected by default when you select a particular fbdev driver that
> has backlight support. You just have the option to turn it off if you
> want. These problems are showing up because of stale .config files.
BTW, enabling the backlight option broke things for me with
Radeon on sparc64 too, FWIW.
And when the option was presented to me for the first time,
the default was yes, so that's what I gave it.
This is what a lot of users would see.
Here's the final version. I will request a pull from Len Brown to get it
into acpi-test, from where it will eventually reach mainline at Len's
discretion.
--
"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
From: Henrique de Moraes Holschuh <[email protected]>
ACPI: ibm-acpi: fix initial status of backlight device
The brightness class core does not update the initial status of the
device's brightness at register time. Do it by ourselves.
Signed-off-by: Henrique de Moraes Holschuh <[email protected]>
Acked-by: Richard Purdie <[email protected]>
---
drivers/acpi/ibm_acpi.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c
index 4cc534e..7c1b418 100644
--- a/drivers/acpi/ibm_acpi.c
+++ b/drivers/acpi/ibm_acpi.c
@@ -1711,6 +1711,12 @@ static struct backlight_ops ibm_backlight_data = {
static int brightness_init(void)
{
+ int b;
+
+ b = brightness_get(NULL);
+ if (b < 0)
+ return b;
+
ibm_backlight_device = backlight_device_register("ibm", NULL, NULL,
&ibm_backlight_data);
if (IS_ERR(ibm_backlight_device)) {
@@ -1718,7 +1724,9 @@ static int brightness_init(void)
return PTR_ERR(ibm_backlight_device);
}
- ibm_backlight_device->props.max_brightness = 7;
+ ibm_backlight_device->props.max_brightness = 7;
+ ibm_backlight_device->props.brightness = b;
+ backlight_update_status(ibm_backlight_device);
return 0;
}
--
1.4.4.4
So the problem is not the configuration but that for some reason the
backlight state is set to off by default.
On Thu, 22 Feb 2007, David Miller wrote:
> From: James Simmons <[email protected]>
> Date: Thu, 22 Feb 2007 15:55:24 +0000 (GMT)
>
> > I just tested various confirations of backlight support. Backlight is
> > ALWAYS selected by default when you select a particular fbdev driver that
> > has backlight support. You just have the option to turn it off if you
> > want. These problems are showing up because of stale .config files.
>
> BTW, enabling the backlight option broke things for me with
> Radeon on sparc64 too, FWIW.
>
> And when the option was presented to me for the first time,
> the default was yes, so that's what I gave it.
>
> This is what a lot of users would see.
>