Bug 350601 - radeonhd: Laptop panel backlight control broken
Summary: radeonhd: Laptop panel backlight control broken
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-radeonhd   
(Show other bugs)
Version: 8
Hardware: All Linux
Target Milestone: ---
Assignee: Hans Ulrich Niedermann
QA Contact: Fedora Extras Quality Assurance
Whiteboard: bzcl34nup
Depends On:
TreeView+ depends on / blocked
Reported: 2007-10-24 15:35 UTC by cje
Modified: 2018-04-11 08:57 UTC (History)
6 users (show)

Fixed In Version: xorg-x11-drv-radeonhd-1.1.0-0.9.20080404git
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-09 15:52:34 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description cje 2007-10-24 15:35:10 UTC
Description of problem:
backlight controls (Fn keys, gnome panel applet, 'dim on idle') no longer work.
 they were working okay one or two kernel versions ago.

however, this first showed up when the screen was dim - and it appears that
rebooting the system restores full brightness.  and since you can only update
the kernel with a reboot ... it can't be the kernel update that caused the problem.

damn.  any ideas?

Version-Release number of selected component (if applicable):
kernel- on a Thinkpad Z61m

Comment 1 cje 2007-10-25 11:56:04 UTC
latest weirdness:

yesterday the backlight was stuck on dim.  then a reboot got it stuck on bright.
 at that point unplugging the AC worked fine (well, the display didn't go dim
but at least the laptop stayed on, running off batteries) and shutting the lid
correctly suspended to ram.

today, (after resume from suspend) the display was still stuck on bright but
unplugging the AC made the system suspend immediately despite the batteries
being fully charged.

now i've rebooted and the display is stuck on dim!  but unplugging AC doesn't
suspend the laptop anymore.

Comment 2 David Nielsen 2007-10-30 06:01:56 UTC
Can you go back and check what kernel was the last that worked,
koji.fedoraproject.org/koji should have the goods. That would aid greatly in
spotting the cause.

Comment 3 John W. Linville 2007-10-30 13:16:26 UTC
This doesn't really sound like my area of expertise.  It seems more like an 
ACPI issue (or a busted laptop).  I'm assigning this back to kernel-maint so 
it is more likely that the "right" person sees it...

Comment 4 John W. Linville 2007-10-30 13:19:09 UTC
This seems suspicious:

* Mon Oct 15 2007 Jeremy Katz <katzj@redhat.com>
- fix thinkpad key events for volume/brightness

So, my bet is that these kernels ( work:


And these ( fail:


Can you confirm?

Comment 5 cje 2007-10-30 13:25:22 UTC
okay.  many thanks for the koji tip.  i've always wondered what koji is and i've
always wondered how i can get hold of old builds.  :-D

i also realised i was running 32bit so i've just done a reinstall and i'm yum
updating now.

at the moment it's running 2.6.23-0.214.rc8.git2.fc8 and display dimming is
working.  (both 'dim when idle' and the planel applet) - i've not tried suspending.

i'll try those kernels and update here shortly.

Comment 6 cje 2007-10-30 13:40:15 UTC
hmm.  pretty certain i was running 32 bit anyway - i don't think i had a 64 bit
install image anywhere until today.  so i can only assume i wrote x86_64 in the
original description by mistake.  sorry about that.

Comment 7 cje 2007-10-30 13:57:16 UTC
news, as it happens....
running and it's still working.
saw an equally suspicious comment in the changelog for xorg-x11-drv-radeonhd
which i had been using and which has now been removed from F8:
- Trade in ThinkPad backlight key fix for non-broken mode on lid event.
hmm.  still checking...

Comment 8 cje 2007-10-30 14:00:47 UTC
and another little piece - at least up to the 'dim when idle'
and the panel applet are working perfectly (using vesa driver) but the Fn keys
for brightness do go a bit wrong:
'brightness down' sets brightness to 0
'brightness up' toggles between 1 and 2 with the on-screen display appearing to
toggle between 1 and 0.

Comment 9 David Nielsen 2007-10-30 14:11:47 UTC
Doh, sorry John, I'll be more careful when editing 2 bug reports at the same
time, you were supposed to have reassigned for a wifi problem I was helping a
user with. Now I wonder who I assigned that to.. oh brother.

Comment 10 cje 2007-10-30 15:24:49 UTC
tried a few kernels and now i'm back to 2.6.23-1-30.fc8 and it's still working
okay (apart from the Fn key weirdness) with the vesa driver so it looks like
it's either:
a) a problem with radeonhd or
b) an x86 vs x86_64 issue or
c) some other strangeness.

i'm betting on a.  i'm doing a full yum update (so it'll be a while) and if it's
still working i'll try each of the two versions of radeonhd that are in koji.

Comment 11 cje 2007-10-30 16:47:55 UTC
updated kernel to and it's still fine.
(tried xorg-x11-drv-ati - X doesn't start)
tried xorg-x11-drv-avivo - 1680x1050 recognised (which is one reason i was using
radeonhd in the first place) and brightness still working.
tried radeonhd 0.0.1 and it's still fine.
tried radeonhd 0.0.2 and it's broken.
reassigning to radeonhd.

Comment 12 cje 2007-10-30 16:49:31 UTC
oh, and the move from kernel- to fixed the Fn key
brokenness too :-D

Comment 13 Matěj Cepl 2007-10-31 09:09:31 UTC
Reporter, this is your hubmle desktop bugmaster, could you please explain what
is the current state of the problem and why do you think it should be X driver

Comment 14 cje 2007-10-31 13:47:54 UTC
dear humble desktop bugmaster,
is that an automatic message?  the current status and reasons for it being an X
driver issue are in comment #11

to repeat:
using xorg-x11-drv-radeonhd-0.0.1-0.6.20071015git.fc8 the backlight controls
work fine.
using xorg-x11-drv-radeonhd-0.0.2-0.7.20071017git.fc8 the backlight controls do
not work.

Comment 15 Hans Ulrich Niedermann 2007-11-21 14:40:16 UTC
In the beginning, xorg-x11-drv-radeonhd had the VGA BIOS mapped, so the BIOS
could run its usual handlers. However, that caused problems in some ways, so it
was deactivated. Since then, when running with radeonhd, the brightness keys do
not work.

The workaround is to switch to a VGA text console, adapt the brightness there,
and switch back to the X11 console.

Both the bug and the workaround are listed under KNOWN BUGS in the radeonhd(4)
man page.

Comment 16 Hans Ulrich Niedermann 2007-11-21 15:26:52 UTC
BTW, I am running a ThinkPad T60 here, and suspend/resume works fine (using
"/usr/sbin/pm-suspend --quirk-s3-bios --quirk-s3-mode").

For now, trading in the brightness setting workaround for working suspend/resume
is worthwile, I guess.

Upstream is aware of the issue.

Comment 17 Bug Zapper 2008-04-04 14:15:57 UTC
Based on the date this bug was created, it appears to have been reported
during the development of Fedora 8. In order to refocus our efforts as
a project we are changing the version of this bug to '8'.

If this bug still exists in rawhide, please change the version back to
(If you're unable to change the bug's version, add a comment to the bug
and someone will change it for you.)

Thanks for your help and we apologize for the interruption.

The process we're following is outlined here:

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

Comment 18 Hans Ulrich Niedermann 2008-04-08 16:06:53 UTC
I am running rawhide with xorg-x11-drv-radeonhd-1.1.0-0.7.20080404git.fc9.i686
now, and I can change my panel backlight brightness with the brightness keys.

However, I'll have to investigate first whether there is some Gnome brightness
applet magic happening here or whether the driver has been changed.

Comment 19 Hans Ulrich Niedermann 2008-04-09 15:52:34 UTC
Should be fixed in xorg-x11-drv-radeonhd-1.1.0-0.9.20080404git in rawhide and
F-8 (in updates-testing soon, updates a little later).

Comment 20 Fedora Update System 2008-04-09 16:03:10 UTC
xorg-x11-drv-radeonhd-1.1.0-0.9.20080404git.fc8 has been submitted as an update for Fedora 8

Note You need to log in before you can comment on or make changes to this bug.