Red Hat Bugzilla – Bug 689962
[Ironlake LVDS Vaio-Y i915] Backlight controls ineffective
Last modified: 2013-01-10 02:35:37 EST
Created attachment 486897 [details]
Description of problem:
On my Sony Vaio Y, backlight controls are not operative, draining battery life.
-- chipset: Arrandale Core i5 430UM, Ironlake integrated graphics.
(see lspci output)
-- Machine or mobo model: Sony Vaio VPC-Y2190X
-- Display connector: LVDS (see xrandr output)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Fn-F5 (reduce brightness) or Fn-F6 (increase brightness)
2. echo 1 > /sys/devices/virtual/backlight/acpi_video0/brightness
3. cat /sys/devices/virtual/backlight/acpi_video0/actual_brightness
With all three steps, the feedback indicates that brightness has indeed been changed. However, the actual brightness remains at 100% throughout.
Backlight brightness should change corresponding to the commands entered.
Also filed at bugs.freedesktop.org:
Created attachment 486898 [details]
lspci -s 00:02.0 -xxx
Created attachment 486899 [details]
Created attachment 486900 [details]
Created attachment 486901 [details]
intel register dump
Created attachment 486902 [details]
Assigning to Matthew Garrett, per #fedora-kernel discussion
Created attachment 486909 [details]
lspci -vv (as root)
note: I consistently get an error message while running this:
pcilib: sysfs_read_vpd: read failed: Connection timed out
Created attachment 486910 [details]
lspci -s 00:02.0 -xxx (as root)
Hi Matthew -- did you get a chance to look at this? Thanks.
Is this a duplicate of bug 702911 ?
Not quite; in that bug, no backlight control is presented, whereas in my case acpi_video0 is present in /sys/class/backlight but non functional.
setpci -s 00:02.0 F4.B=[two-digit-hex-value] does not work either; on using lspci to read the value back, it always returns 0.
I've tried using acpi_backlight=vendor -- in which case, sony-laptop is present instead of acpi_video0, but backlight is stuck to -1 regardless of what value I attempt to assign it (whereas with acpi_video0, it appears to take the new value, as shown in actual_brightness)
The problem is very similar to that reported on the forum for a Lenovo, so it's not a Sony-only problem.
Created attachment 509966 [details]
Decoded DSDT as dumped using acpidump and decoded using iasl
ah, I mean /sys/classes/backlight/sony -- not sony-laptop. If I boot with sony-laptop.debug=1, and attempt to adjust brightness via Fn-keys, I get the following in dmesg:
[22361.949175] sony_laptop: found handle 0x0100 (offset: 0x00)
[22361.949186] sony_laptop: handle 0x0127 not found
[22361.949193] sony_laptop: found handle 0x0100 (offset: 0x00)
[22361.956004] sony_laptop: called SN07 with 0x0200 (result: 0x0286)
[22361.956217] sony_laptop: sony_nc_notify, event: 0x11
[22362.042725] sony_laptop: found handle 0x0100 (offset: 0x00)
[22362.042730] sony_laptop: handle 0x0127 not found
[22362.042734] sony_laptop: found handle 0x0100 (offset: 0x00)
[22362.049667] sony_laptop: called SN07 with 0x0200 (result: 0x0206)
[22362.049672] sony_laptop: sony_nc_notify, event: 0x3b
but not if I manipulate the brightness via /sys/classes/backlight/sony/brightness. That interface behaves almost identicallly to /sys/classes/backlight/acpi_video0 (except that actual_brightness is stuck at -1 instead of pretending to agree with what's written to brightness), but max_brightness is 7 instead of 8.
I've tried the latest Rawhide kernel -- kernel-3.0-0.rc4.git3.1.fc16.x86_64 -- and the problem is still present.
Should we make a tracking bug for all i915 backlight problems? The bugs seem different enough that they shouldn't be merged into one, but similar enough that we might want an easy-to-collate set to bring up with the Intel driver developers.
Created attachment 512658 [details]
mjg's i915 native GPU backlight control patch from linux-next
Applying Matthew Garrett's latest iteration of the i915 native backlight patch, already in linux-next, on top of Linus' 3.0rc7 fixes the issue for me.
Is this patch slated to be pulled into 3.0rc8? Hopefully it will be backported to F15, or F15 gets a 3.0 kernel update.
(In reply to comment #14)
> Created attachment 512658 [details]
> mjg's i915 native GPU backlight control patch from linux-next
> Applying Matthew Garrett's latest iteration of the i915 native backlight patch,
> already in linux-next, on top of Linus' 3.0rc7 fixes the issue for me.
> Is this patch slated to be pulled into 3.0rc8? Hopefully it will be backported
> to F15, or F15 gets a 3.0 kernel update.
F15 is on 2.6.40 now, which is just a renamed 3.0. Your comment indicates this particular bug should be resolved. Is that the case?
Not in 2.6.40/3.0, but the patch was finally committed in time for 2.6.41/3.1. Sadly the laptop in question is now on Fedora 16, but I think we can close this bug.