Bug 689962

Summary: [Ironlake LVDS Vaio-Y i915] Backlight controls ineffective
Product: [Fedora] Fedora Reporter: Michel Alexandre Salim <michel>
Component: kernelAssignee: John Feeney <jfeeney>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 15CC: gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
URL: http://www.smolts.org/client/show/pub_c56830aa-111c-4398-9cad-96c821d2ad84
Whiteboard:
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:
Cloudforms Team: ---
Attachments:
Description Flags
lspci -vv
none
lspci -s 00:02.0 -xxx
none
sysfs hierarchy
none
ACPI dump
none
intel register dump
none
dmesg
none
lspci -vv (as root)
none
lspci -s 00:02.0 -xxx (as root)
none
Decoded DSDT as dumped using acpidump and decoded using iasl
none
mjg's i915 native GPU backlight control patch from linux-next none

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.