Bug reported by Chip Salzenberg on the Debian BTS a couple days ago, applies to 1.1.0 and current git. My Thinkpad has a blue Fn button; when this is depressed, the Home and End keys are supposed to control backlight brightness. When the radeonhd driver is active, these buttons have no effect. However, the BIOS does seem to know they're being pushed, because after switching to a text console, and pressing those keys once, the cumulative effect of the previous presses is also seen. Subsequently switching back to the radeonhd vt leaves the brightness at the new (modified) level. So essentially I have to switch to tty1 to change the backlight brightness. Config and log available at the URL above.
Known issue - see Known Bugs & Limitations on the wiki page.
Mass reopen. The "LATER" resolution is lame, I'm deleting it. Consider LATER to have arrived.
Hello, same issue with some HP Notebooks here. For example with the HP Compaq 6715s. Would be nice if it could be fixed fast, because without this feature my battery life time isn't very long :(
I have the same problem and switching over to a tty lets me change the brightness.
Created attachment 15710 [details] [review] Implements RANDR backlight property
Hi, I have the same problem on a HP Compaq 8510p, so I implemented RANDR backlight support and now am able to change and query the backlight with xbacklight. The patch I attached is against the current git and tested on M76.
patch works on M54 (Thinkpad T60) I didn't know i could adjust my brightness THAT fine-grained
Tried above patch, it builds and installed ok: ... (II) RADEONHD: version 1.1.0, built from git branch master, commit db2c3948 + changes ... (II) RADEONHD(0): RandR 1.2 enabled, ignore the following RandR disabled message. (II) RADEONHD(0): LVDSBacklight: PWRSEQ BLON State: on (II) RADEONHD(0): LVDSBacklight: BLON: off BLON_OVRD: disabled BLON_POL: non-invert (II) RADEONHD(0): LVDSBacklight: BL_MOD: disable BL_MOD_LEVEL: 255 BL_MOD_RES: 0 But, I still can't change backlight with sysctl dev.acpi_ibm.0.lcd_brightness and also can't change display brightness with xrandr: It shows: xrandr --verbose Screen 0: minimum 320 x 200, current 1400 x 1050, maximum 2720 x 1050 PANEL connected 1400x1050+0+0 (0x46) normal (normal) 305mm x 228mm Identifier: 0x43 Timestamp: 1300801 Subpixel: unknown Clones: VGA_1 DVI-D_1 CRTC: 0 CRTCs: 0 1 RANDR_OUTPUT_NUMBER: 2 (0x00000002) BACKLIGHT: 255 (0x000000ff) range: (0,255) ... I can change backlight with: xrandr --output PANEL --set BACKLIGHT 90 xrandr --verbose | fgrep BACK BACKLIGHT: 90 (0x0000005a) range: (0,255) But, actual brightness is not changed. I have T60 also.
Created attachment 15726 [details] [review] Implements RANDR backlight property The sysctl thing won't work with this patch, only the xrandr/xbacklight method is implemented yet. (hopefully) the backlight setting is fixed (BL_MOD is force enabled now)
The first patch did not work on my Z61m (X1400/M54), the second one works fine. However, it would be nicer, when the buttons would work (they do update /sys/class/backlight/acpi_video0/actual_brightness but don't really change it [this works in xf86-video-ati and on the VT])
The buttons require bang the hardware directly via vga io space which the radeonhd driver disables at the moment. You'd need to either enable the vga io or if you can get events for the acpi buttons, bind them to xbacklight. Also, I think the backlight can be controlled via an atom method as well, which may be preferable as not all vendors control the backlight the same way. This could be used with the bios scratch registers to keep the backlight in sync between the driver and the bios. See atombios.h.
Uhm, the nice thing on ThinkPads (at least pre T/R61) is, that these buttons work in firmware, so you usually do not need anything in userspace for them, but radeonhd seems to block something there...
(In reply to comment #12) > Uhm, the nice thing on ThinkPads (at least pre T/R61) is, that these buttons > work in firmware, so you usually do not need anything in userspace for them, > but radeonhd seems to block something there... > See comment 11
Yes, that patch works. Thank you. Still there is two minor issues: 1. It takes significant time to change back-light brightness even with /usr/X11R6/bin/xbacklight -inc 10 -steps 1 -time 0 When I've bound this on native Fn->Home (increase brightness) I should wait wafter click before next click. 2. It is hard to combine system increase brightness event (under devd on FreeBSD) with X-related xbacklight utility (need to guess current use, xauthority from scripts running under root without X context)
(In reply to comment #14) > Yes, that patch works. Thank you. Happy to hear that, you are welcome! > > Still there is two minor issues: > > 1. It takes significant time to change back-light brightness even with > /usr/X11R6/bin/xbacklight -inc 10 -steps 1 -time 0 > When I've bound this on native Fn->Home (increase brightness) > I should wait wafter click before next click. > Hmm, I think the driver has nothing to do with it... the brightness change isn't immediate here either, I guess it's something BIOS related... > 2. It is hard to combine system increase brightness event (under devd on > FreeBSD) > with X-related xbacklight utility (need to guess current use, xauthority > from scripts running under root without X context) > I know... the patch is just another workaround
> Hmm, I think the driver has nothing to do with it... the brightness change > isn't immediate here either, I guess it's something BIOS related... Hmm ... In other cases (via sysctl or in Windows) it does backlight change without delay.
The proposed patch was added and modified slightly to fit in the context of a output callback. We check if this back light control was enabled at startup, if it wasn't, no back light control is offered. Like Alex said this will have to be handled thru AtomBIOS, something that I still need to pull from another branch. To handle the hot keys there need to be some hooks into ACPI added either to the server or to a client which then does these property settings. This seems to be preferrable over two things trying to control the same hardware. This is beyond the scope of RadeonHD, though.
Commit ID of the Krisztian's patch: b7a2fa2550e41ff0c59d517d5cbc3042a5fa83ff. Krisztian, thanks for your great work!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.