This bug is about the kernel module i915 in text (framebuffer) mode. It's not about any X11 driver. So I hope the Component is right. I tested it with Linux 3.18.24 and 4.3. What I want to achive: I want to turn off the backlight. On some other i915 based hardware (8086:a011) this worked with "vbetool dpms on" and back on with "vbetool dpms off". With my i915/Haswell (8086:0a16) the "turn off" part works, albeit I get error messages in dmesg. But the "turn on" doesn't work: Backlight goes on, but LCD display stays black. root:/sys# dmesg -c >/dev/null root:/sys# vbetool dpms off root:/sys# dmesg -c [ 325.704229] [drm:intel_uncore_check_errors [i915]] *ERROR* Unclaimed register before interrupt [ 326.290205] [drm:intel_uncore_check_errors [i915]] *ERROR* Unclaimed register before interrupt root:/sys# vbetool dpms on root:/sys# dmesg -c [ 340.408883] [drm:intel_uncore_check_errors [i915]] *ERROR* Unclaimed register before interrupt [ 340.682288] [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* uncleared fifo underrun on pipe A [ 340.682348] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO underrun When I run "vbetool vbestate save" I also get a number of error messages, as well as with "vbetool vbestate restore". It however restores the display partially: But it's greatly enlarged, probably the upper left quarter of the former display now magnified over the whole screen. Some dmesg output related to the i915/Haswell: [ 0.221025] vgaarb: setting as boot device: PCI:0000:00:02.0 [ 0.221099] vgaarb: device added: PCI:0000:00:02.0,decodes=io+mem,owns=io+mem,locks=none [ 0.221168] vgaarb: loaded [ 0.221225] vgaarb: bridge control possible 0000:00:02.0 ... [ 2.969865] [drm] Memory usable by graphics device = 2048M [ 2.969930] [drm] Replacing VGA console driver [ 2.970595] Console: switching to colour dummy device 80x25 [ 2.976807] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 2.976814] [drm] Driver supports precise vblank timestamp query. [ 2.976895] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 3.003257] fbcon: inteldrmfb (fb0) is primary device [ 3.005096] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [ 3.005312] input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input17 [ 3.005362] [drm] Initialized i915 1.6.0 20150731 for 0000:00:02.0 on minor 0 [ 4.092573] Console: switching to colour frame buffer device 128x48 [ 4.096012] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device ... vbetool is 1.1 If there is something else beside vbetool I would use it. The files in /sys/class/backlight/intel_backlight/* seem to be no-op on my board. One thing: after running "vbotool dpms off", the file dpms in /sys/class/drm/card0-DP-2/ stays in state "On". But it's the only connected port: root@hwtester:~# grep -d skip . /sys/class/drm/*/enabled /sys/class/drm/card0-DP-1/enabled:disabled /sys/class/drm/card0-DP-2/enabled:enabled /sys/class/drm/card0-HDMI-A-1/enabled:disabled /sys/class/drm/card0-HDMI-A-2/enabled:disabled root@hwtester:~# grep -d skip . /sys/class/drm/*/dpms /sys/class/drm/card0-DP-1/dpms:Off /sys/class/drm/card0-DP-2/dpms:On /sys/class/drm/card0-HDMI-A-1/dpms:Off /sys/class/drm/card0-HDMI-A-2/dpms:Off
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.