Summary: | intel_backlight doesn't work with i915 Haswell | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Holger Schurig <holgerschurig> | ||||||||||
Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||
Status: | CLOSED INVALID | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||||||||
Severity: | normal | ||||||||||||
Priority: | medium | CC: | intel-gfx-bugs | ||||||||||
Version: | unspecified | ||||||||||||
Hardware: | x86 (IA32) | ||||||||||||
OS: | Linux (All) | ||||||||||||
Whiteboard: | |||||||||||||
i915 platform: | HSW | i915 features: | display/backlight | ||||||||||
Attachments: |
|
Description
Holger Schurig
2015-11-09 07:51:11 UTC
The first instinct is RESOLVED WONTFIX, and even more so after having a glance at vbetool source. vbetools can't work with i915 (by design since it uses root access to the Video Bios which means writing to hardware registers owned by i915 and so causing choas). But the bug here is that the intel_backlight doesn't work, and so presumably this is a machine that must be quirked to provide acpi_backlight instead. Holger, please add drm.debug=14 module parameter, and attach dmesg from boot to trying to write values to /sys/class/backlight/intel_backlight/brightness. Created attachment 119503 [details]
dmesg 1.txt
Created attachment 119504 [details]
dmesg 2.txt
Created attachment 119505 [details]
dmesg 3.txt
@Jani, I attached 3 files which I made this way: root:~# history 1 dmesg -c >1.txt 2 vbetool dpms off 3 dmesg -c >2.txt 4 vbetool dpms on 5 dmesg -c >3.txt The funny thing: this time it worked. I did neither get the funny "Unclaimed register before interrupt" error message ... (but I get other ERRORs!). But more important: after "vbetool dpms on", why text screen was back there. @Chris: if vbetool would't generally not work with i915, when why did it work with the i915 with PCI id 8086:a011, or why did it work when the drm debug output changed the timing :-) BTW, my kernel doesn't have CONFIG_X86_LEGACY_VM86 set, so I'm unsure if/how it can access the video BIOS. But this is just a guess, I've not really looked into this. A rebooted and retried (still with debugging), and this time my text didn't come back. So out of 4 tries, twice I got the text back, twice not. I never got the text back without drm.debug=14 I increase my kernel's log buffer and try to get a full dmesg log when text doesn't came back and will attach that as 4.txt. Created attachment 119506 [details]
dmesg 4.txt (full dmesg when text mode didn't come back)
(In reply to Holger Schurig from comment #7) > @Chris: if vbetool would't generally not work with i915, when why did it > work with the i915 with PCI id 8086:a011, or why did it work when the drm > debug output changed the timing :-) BTW, my kernel doesn't have > CONFIG_X86_LEGACY_VM86 set, so I'm unsure if/how it can access the video > BIOS. But this is just a guess, I've not really looked into this. Pure circumstance. vbetool accesses hardware registers and disregards that those registers are under the control of an actual hardware driver, just as we will disregard bug reports where vbetool has been used. Holger, I wanted the dmesg about you trying to change backlight brightness through sysfs, *not* vbetool. Jani, there is no dmesg output. I actually have two different systems with 8086:0a16 devices, one is running an i5-4300U and an Advantech BIOS, the other is running some slower CPU (forgot which one) on has a congatec BIOS (derived from AMI BIOS, I think). Both have the same issue with vbetool, it's just the 8086:a011 (also i915) that worked (and various device with even other graphics card). I'm writing this because both Haswell devices export different backlight directories in /sys. This is the congatec BIOS one: root@hwtester:/sys/class/backlight/acpi_video0# grep -d skip . * actual_brightness:0 bl_power:0 brightness:0 max_brightness:100 type:firmware When (still with drm.debug=14) I "echo 0 >bl_power" or when I run "echo 0 >brightness" ... * nothing visible changes on the display and * nothing new will be emitted to dmesg Aaaaaaand this is i915 with the Advantech BIOS: root@hwtester:/sys/class/backlight/intel_backlight# grep -d skip . * actual_brightness:937 bl_power:1 brightness:937 max_brightness:937 type:raw First, it exports a different backlight interfaces. But (still with drm.debug=14) I can "echo 0 >bl_power" and won't see anything at all in dmesg. But when I run "echo 1 >bl_power", I see this: [ 82.253378] [drm:intel_backlight_device_update_status] updating intel_backlight, brightness=937/937 [ 82.253381] [drm:intel_panel_actually_set_backlight] set backlight PWM = 937 [ 82.253388] [drm:intel_edp_backlight_power] panel power control backlight disable Only after this will "echo 0 >bl_power" emit this: [ 157.801385] [drm:intel_backlight_device_update_status] updating intel_backlight, brightness=937/937 [ 157.801388] [drm:intel_panel_actually_set_backlight] set backlight PWM = 937 [ 157.801395] [drm:intel_edp_backlight_power] panel power control backlight enable That is, the first "echo 0" was silent, the 2nd not. And visible is nothing, if I enable or disable anything. I also think that the dmesg output doesn't reflect the intent (despite from not working). I emits "disable" when I send a 1 (enable) and vica verca. Funny fact: the opaque OS called "Windows 10" can turn the backlight on and off on both i915 devices. This bug just got so confusing and misleading so fast that I will close this one right now, and kindly ask you to file new, clear bug reports with *one* issue and *one* platform per bug that you have. There are too many things conflated here now. Don't report bugs about vbetool or its use. The bug report was (or at least I thought it was) originally about Haswell, but all the attached dmesgs are captured on a Valleyview. That particular Valleyview has a VBT (video bios table) that says the machine does *not* have backlight at all. Indeed we don't detect eDP or LVDS on it, so it's natural that there's no backlight. (Maybe that is a bug in your perspective as well, but it has to be a separate one.) Comment #12 also brings up a Pineview. We don't really know or care about the congatec vs. advantech BIOS versions; please refer to the hardware platforms. In comment #3 I asked you to write to the "brightness" attribute to check whether intel_backlight works. Not acpi_backlight nor bl_power. I didn't ask you to try bl_power on purpose because it's confusing. 0 means on, and 4 means off. So let's start afresh. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.