Bug 38342 - [Ironlake LVDS Vaio-Y i915] Backlight controls ineffective
[Ironlake LVDS Vaio-Y i915] Backlight controls ineffective
Status: CLOSED INSUFFICIENT_DATA
Product: ACPI
Classification: Unclassified
Component: Power-Video
All Linux
: P1 normal
Assigned To: acpi_power-video
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-06-27 09:54 UTC by Michel Alexandre Salim
Modified: 2012-05-24 08:00 UTC (History)
1 user (show)

See Also:
Kernel Version: 3.0-rc4
Tree: Mainline
Regression: No


Attachments
lspci -vv (36.05 KB, text/plain)
2011-06-27 21:20 UTC, Michel Alexandre Salim
Details
Disassembled DSDT (361.17 KB, text/x-dsl)
2011-06-27 21:24 UTC, Michel Alexandre Salim
Details
dmesg changes from setting brightness (892 bytes, text/plain)
2011-06-27 21:34 UTC, Michel Alexandre Salim
Details
dmesg changes from issuing setpci command (616 bytes, text/plain)
2011-06-27 21:43 UTC, Michel Alexandre Salim
Details
mjg's i915 native GPU backlight control patch from linux-next (7.23 KB, patch)
2011-07-13 13:01 UTC, Michel Alexandre Salim
Details | Diff

Description Michel Alexandre Salim 2011-06-27 09:54:51 UTC
lspci -vv

Description of problem:
On my Sony Vaio Y, backlight controls are not operative, draining battery life.

System environment: 
-- 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)
and also:
kernel-2.6.38.8-32.fc15.x86_64
kernel-3.0-0.rc4.git3.1.fc16

libdrm-2.4.26-1.fc15.x86_64
mesa-dri-drivers-7.11-0.11.20110525.0.fc15.x86_64
xorg-x11-drv-intel-2.15.0-3.fc15.x86_64
xorg-x11-server-Xorg-1.10.2-1.fc15.x86_64

How reproducible:
Always

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]

Actual results:
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

Expected results:
Backlight brightness should change corresponding to the commands entered.

Additional info:
Also filed at bugs.freedesktop.org:
https://bugs.freedesktop.org/show_bug.cgi?id=34417

and Red Hat Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=689962
Comment 1 Michel Alexandre Salim 2011-06-27 21:20:31 UTC
Created attachment 63582 [details]
lspci -vv
Comment 2 Michel Alexandre Salim 2011-06-27 21:24:23 UTC
Created attachment 63602 [details]
Disassembled DSDT

Taken with acpidump followed by iasl, per http://www.linux.it/~malattia/wiki/index.php/Disassemble_your_DSDT
Comment 3 Michel Alexandre Salim 2011-06-27 21:34:29 UTC
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)
Comment 4 Michel Alexandre Salim 2011-06-27 21:43:22 UTC
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
00
Comment 5 Michel Alexandre Salim 2011-06-30 18:56:50 UTC
Same results with 3.0-rc5
Comment 6 Michel Alexandre Salim 2011-07-13 13:01:41 UTC
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.

Several points:
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?
Comment 7 Zhang Rui 2012-01-18 05:21:56 UTC
It's great that the kernel bugzilla is back.

Can you please verify if the problem still exists in the latest upstream
kernel?
Comment 8 Zhang Rui 2012-05-24 08:00:23 UTC
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.

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