Created attachment 165041 [details] dmesg (including a suspend-resume cycle) Up to at least kernel 3.17.8, backlight was working fine on my ASUS X200M. It doesn't work on 3.18.3 (both on Fedora 21). More precisely, the screen remains blank until I suspend the machine; on resume everything is fine. I've tried passing acpi_backlight=vendor to boot options without luck.
Created attachment 165051 [details] lspci -vnn
Created attachment 165061 [details] Additional debugging information (ACPI...)
Additional info comes from following the instructions at https://wiki.ubuntu.com/Kernel/Debugging/Backlight I hope it's useful.
Bump!
Moving to Intel graphics. Might actually belong in ACPI. Also marked as a regression as it worked in 3.17.8
Please provide similar dmesg with drm.debug=14 module parameter set. Also, separate from the above, please try video.use_native_backlight=0 module parameter.
Created attachment 166471 [details] dmesg with drm.debug=14 Here's the result. video.use_native_backlight=0 has no effect.
What's the output of this when you first boot, and the screen is presumably black: cat /sys/class/backlight/intel_backlight/{brightness,actual_brightness,bl_power} I understand you may have to ssh into the machine or script this at late boot.
I get: 4062 4062 0 This is the same as when the backlight is on (after suspend). Situation is the same on 3.18.5.
What if you try echoing values to the brightness attribute when the screen is black. echo 0 > /sys/class/backlight/intel_backlight/brightness echo 4062 > /sys/class/backlight/intel_backlight/brightness
No luck. When running the script after suspend/resume, I can see the screen turn blank then back to normal. But on fresh boot, it has no effect. (I've put these commands in /etc/rc.d/rc.local, BTW.)
(In reply to Jani Nikula from comment #10) > What if you try echoing values to the brightness attribute when the screen > is black. > > echo 0 > /sys/class/backlight/intel_backlight/brightness > echo 4062 > /sys/class/backlight/intel_backlight/brightness Hmm, what if you try echoing values here *after* the suspend resume cycle, do these adjust the backlight?
Could also try this patch series: http://patchwork.freedesktop.org/patch/43342 http://patchwork.freedesktop.org/patch/43343 http://patchwork.freedesktop.org/patch/43344 http://patchwork.freedesktop.org/patch/43345 http://patchwork.freedesktop.org/patch/43346
(In reply to Jani Nikula from comment #12) > (In reply to Jani Nikula from comment #10) > > What if you try echoing values to the brightness attribute when the screen > > is black. > > > > echo 0 > /sys/class/backlight/intel_backlight/brightness > > echo 4062 > /sys/class/backlight/intel_backlight/brightness > > Hmm, what if you try echoing values here *after* the suspend resume cycle, > do these adjust the backlight? Yes, it works fine. Sorry, I won't have the time to compile a custom kernel to test the patches. Are they available in a RPM somewhere by chance?
If you don't have time to help, I'm afraid this may not be the right support channel for you.
Well, this comes accross as a bit rude. I've already carried out several tests to try identifying the problem. And I've never asked for "support", I only try to help fixing the kernel. Back to the debugging: is there any chance the bug may be fixed in 4.0 development versions? I can test them easily using Fedora rawhide RPMs. If not, I'll see whether I can find the time at some point.
Apologies; my point is that I've also spent time on trying to resolve the bug, and usually it eventually comes down to trying patches that may fix the bug. I don't think the patches will make it to v4.0.
Long time no updates, closing. If the problem persists with latest kernels, please file a bug at the freedesktop.org bugzilla [1], referencing this bug. Thank you. [1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel