Red Hat Bugzilla – Full Text Bug Listing
|Summary:||[Ironlake LVDS Vaio-Y i915] Backlight controls ineffective|
|Product:||[Fedora] Fedora||Reporter:||Michel Alexandre Salim <michel>|
|Component:||kernel||Assignee:||John Feeney <jfeeney>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||15||CC:||gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2011-11-24 08:36:36 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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 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 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.