Bug 689962 - [Ironlake LVDS Vaio-Y i915] Backlight controls ineffective
[Ironlake LVDS Vaio-Y i915] Backlight controls ineffective
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
15
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: John Feeney
Fedora Extras Quality Assurance
http://www.smolts.org/client/show/pub...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-03-22 17:18 EDT by Michel Alexandre Salim
Modified: 2013-01-10 02:35 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-11-24 08:36:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
lspci -vv (14.74 KB, text/plain)
2011-03-22 17:18 EDT, Michel Alexandre Salim
no flags Details
lspci -s 00:02.0 -xxx (317 bytes, text/plain)
2011-03-22 17:23 EDT, Michel Alexandre Salim
no flags Details
sysfs hierarchy (1.12 KB, text/plain)
2011-03-22 17:26 EDT, Michel Alexandre Salim
no flags Details
ACPI dump (214.04 KB, text/plain)
2011-03-22 17:30 EDT, Michel Alexandre Salim
no flags Details
intel register dump (8.78 KB, text/plain)
2011-03-22 17:32 EDT, Michel Alexandre Salim
no flags Details
dmesg (123.42 KB, text/plain)
2011-03-22 17:33 EDT, Michel Alexandre Salim
no flags Details
lspci -vv (as root) (36.03 KB, text/plain)
2011-03-22 17:49 EDT, Michel Alexandre Salim
no flags Details
lspci -s 00:02.0 -xxx (as root) (941 bytes, text/plain)
2011-03-22 17:50 EDT, Michel Alexandre Salim
no flags Details
Decoded DSDT as dumped using acpidump and decoded using iasl (361.17 KB, text/x-dsl)
2011-06-26 10:53 EDT, Michel Alexandre Salim
no flags Details
mjg's i915 native GPU backlight control patch from linux-next (7.23 KB, patch)
2011-07-13 08:58 EDT, Michel Alexandre Salim
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 38342 None None None Never
FreeDesktop.org 34417 None None None Never

  None (edit)
Description Michel Alexandre Salim 2011-03-22 17:18:37 EDT
Created attachment 486897 [details]
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):
kernel-2.6.38-1.fc15.x86_64
libdrm-2.4.24-1.fc15.x86_64
mesa-dri-drivers-7.10-0.29.fc15.x86_64
xorg-x11-drv-intel-2.14.0-3.fc15.x86_64
xorg-x11-server-Xorg-1.10.0-3.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
  
Actual results:
With all three steps, the feedback indicates that brightness has indeed been changed. However, the actual brightness remains at 100% throughout.

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
Comment 1 Michel Alexandre Salim 2011-03-22 17:23:47 EDT
Created attachment 486898 [details]
lspci -s 00:02.0 -xxx
Comment 2 Michel Alexandre Salim 2011-03-22 17:26:10 EDT
Created attachment 486899 [details]
sysfs hierarchy
Comment 3 Michel Alexandre Salim 2011-03-22 17:30:45 EDT
Created attachment 486900 [details]
ACPI dump
Comment 4 Michel Alexandre Salim 2011-03-22 17:32:29 EDT
Created attachment 486901 [details]
intel register dump
Comment 5 Michel Alexandre Salim 2011-03-22 17:33:18 EDT
Created attachment 486902 [details]
dmesg
Comment 6 Michel Alexandre Salim 2011-03-22 17:33:44 EDT
Assigning to Matthew Garrett, per #fedora-kernel discussion
Comment 7 Michel Alexandre Salim 2011-03-22 17:49:25 EDT
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
Comment 8 Michel Alexandre Salim 2011-03-22 17:50:22 EDT
Created attachment 486910 [details]
lspci -s 00:02.0 -xxx (as root)
Comment 9 Michel Alexandre Salim 2011-04-06 08:22:28 EDT
Hi Matthew -- did you get a chance to look at this? Thanks.
Comment 10 Chuck Ebbert 2011-06-25 01:46:18 EDT
Is this a duplicate of bug 702911 ?
Comment 11 Michel Alexandre Salim 2011-06-26 10:50:06 EDT
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.

http://forums.fedoraforum.org/showthread.php?t=258868
Comment 12 Michel Alexandre Salim 2011-06-26 10:53:11 EDT
Created attachment 509966 [details]
Decoded DSDT as dumped using acpidump and decoded using iasl
Comment 13 Michel Alexandre Salim 2011-06-26 10:59:07 EDT
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
[22361.983875] [drm:intel_crtc_cursor_set], 
[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.
Comment 14 Michel Alexandre Salim 2011-07-13 08:58:01 EDT
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.
Comment 15 Josh Boyer 2011-09-27 15:02:42 EDT
(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?
Comment 16 Michel Alexandre Salim 2011-11-24 08:36:36 EST
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.

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