From: Andrew Morton <akpm@linux-foundation.org> Date: 2007-02-19 08:04:44
On Sun, 18 Feb 2007 23:46:16 -0500 Yaroslav Halchenko [off-list ref] 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..
-------------------------------------------------------------------------
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
From: Richard Purdie <hidden> Date: 2007-02-19 09:20:20
On Mon, 2007-02-19 at 00:04 -0800, Andrew Morton wrote:
On Sun, 18 Feb 2007 23:46:16 -0500 Yaroslav Halchenko [off-list ref] wrote:
quoted
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
-------------------------------------------------------------------------
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 Sun, 18 Feb 2007 23:46:16 -0500 Yaroslav Halchenko [off-list ref] wrote:
quoted
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
quoted
...<
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@|www.)onerussian.com
Yaroslav Halchenko /( )\ ICQ#: 60653192
Linux User ^^-^^ [175555]
From: Richard Purdie <hidden> Date: 2007-02-22 00:35:00
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
quoted
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
-------------------------------------------------------------------------
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
From: James Simmons <hidden> Date: 2007-02-22 01:07:49
On Wed, 2007-02-21 at 00:56 -0500, Yaroslav Halchenko wrote:
quoted
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
quoted
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.
-------------------------------------------------------------------------
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
From: James Simmons <hidden> Date: 2007-02-22 01:11:28
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.
From: Joel Becker <hidden> Date: 2007-02-22 02:10:44
On Thu, Feb 22, 2007 at 01:11:18AM +0000, James Simmons wrote:
quoted
*$> 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: joel.becker@oracle.com
Phone: (650) 506-8127
From: Richard Purdie <hidden> Date: 2007-02-22 09:46:35
On Thu, 2007-02-22 at 01:07 +0000, James Simmons wrote:
quoted
# 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
-------------------------------------------------------------------------
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
From: James Simmons <hidden> Date: 2007-02-22 15:18:35
quoted
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.
From: James Simmons <hidden> Date: 2007-02-22 15:55:44
On Thu, Feb 22, 2007 at 01:11:18AM +0000, James Simmons wrote:
quoted
quoted
*$> 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.
-------------------------------------------------------------------------
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
From: David Miller <davem@davemloft.net> Date: 2007-02-22 17:28:14
From: James Simmons <redacted>
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.
-------------------------------------------------------------------------
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
From: James Simmons <hidden> Date: 2007-02-28 16:56:51
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 <redacted>
Date: Thu, 22 Feb 2007 15:55:24 +0000 (GMT)
quoted
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.
From: Richard Purdie <hidden> Date: 2007-03-01 10:59:05
On Wed, 2007-02-28 at 16:55 +0000, James Simmons wrote:
So the problem is not the configuration but that for some reason the
backlight state is set to off by default.
Maybe, maybe not. I'm not sure there's been enough information to
conclude that.
At the moment, I'd like a patch which makes backlight usage configurable
at runtime though a module parameter and defaults to off in all cases
except the powermac one. I'd like to get something into the tree,
preferably before the next -rc, since at the moment things are breaking
for people. If you haven't time, say so and I'll have a look and see if
I can work one out.
Cheers,
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
From: James Simmons <hidden> Date: 2007-03-01 21:08:58
Could you. Right now I'm busy with the DRM/fbdev device management.
On Thu, 1 Mar 2007, Richard Purdie wrote:
On Wed, 2007-02-28 at 16:55 +0000, James Simmons wrote:
quoted
So the problem is not the configuration but that for some reason the
backlight state is set to off by default.
Maybe, maybe not. I'm not sure there's been enough information to
conclude that.
At the moment, I'd like a patch which makes backlight usage configurable
at runtime though a module parameter and defaults to off in all cases
except the powermac one. I'd like to get something into the tree,
preferably before the next -rc, since at the moment things are breaking
for people. If you haven't time, say so and I'll have a look and see if
I can work one out.
Cheers,
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