Kernel Bug Tracker – Bug 38342
[Ironlake LVDS Vaio-Y i915] Backlight controls ineffective
Last modified: 2012-05-24 08:00:28 UTC
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):
upstream kernel 3.0 rc4 (using the same config as Fedora's 3.0-0.rc4.git3.1)
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
4. setpci -s 00:02.0 F4.B=[two-digit-hex-value]
With the first three steps, the feedback indicates that brightness has indeed been changed. However, the actual brightness remains at 100% throughout.
With setpci, lspci-ing the register always reads 00
Backlight brightness should change corresponding to the commands entered.
Also filed at bugs.freedesktop.org:
and Red Hat Bugzilla:
Created attachment 63582 [details]
Created attachment 63602 [details]
Taken with acpidump followed by iasl, per http://www.linux.it/~malattia/wiki/index.php/Disassemble_your_DSDT
Created attachment 63622 [details]
dmesg changes from setting brightness
(brightness set by echo-ing to /sys/class/backlight/acpi_video0/brightness -- kernel booted with options i915.lvds_use_ssc=0 drm.debug=0x06)
Created attachment 63632 [details]
dmesg changes from issuing setpci command
[root@sojourner sony]# setpci -s 00:02.0 f4.b=ff
[root@sojourner sony]# setpci -s 00:02.0 f4.b
Same results with 3.0-rc5
Created attachment 65412 [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.
1) it'd be nice if the acpi_video0 interface is not made available since it does not work - is there a way to blacklist my particular hardware?
2) is there a kernel switch for selecting the graphics device's backlight control, similar to how now the user can select between video.ko and the vendor-supplied driver?
It's great that the kernel bugzilla is back.
Can you please verify if the problem still exists in the latest upstream
bug closed as there is no response from the bug reporter.
please feel free to reopen it if the problem still exists in the latest upstream kernel.