First, I thought this was a kernel bug: Bug 60545 - acpi_video0/brightness:0 after VT switch https://bugzilla.kernel.org/show_bug.cgi?id=60545 "I'm having an X server configured to use the external monitor only (LVDS off). If I switch from that X server to a console (or to another X server which uses the LVDS), then the brightness of the LVDS stays at very low level (text is unreadable)." Now, I've figured out that xf86-video-intel is causing this behaviour. (The affected code in uxa seems to be equal, but I've tested sna only.) Commenting out the call to sna_output_dpms_backlight() when dpms==DPMSModeOff in sna_output_dpms() fixed it. What happens when disabling the LVDS output - the dpms state changes: - sna_output_dpms(..., dpms=DPMSModeOff) o sna_output_dpms_backlight(..., mode=DPMSModeOff) * sna_output_backlight_set(..., 0) -> writes 0 to $backlight_iface/brightness o drmModeConnectorSetProperty(..., dpms=DPMSModeOff) ... from libdrm into the kernel ... * intel_crtc_dpms() -> disable encoder driving the LVDS connector So, from what I think sna_output_backlight_set(..., 0) is not necessary as this lowers the brightness, when the output gets turned off anyways. Maybe calling sna_output_backlight_set() in the case of dpms!=DPMSModeOff is not necessary too. I've tested the patched version (just commenting out the dpms==DPMSModeOff case in sna_output_dpms()) without the acpi_backlight kernel parameter (acpi_video) and with acpi_backlight=vendor (thinkpad_screen). Both worked. But, I'm not sure about the implications on other backlight interfaces, maybe it's necessary for others or for older kernels. That's why I haven't made it a patch yet.
The backlight is independent of the pipe, so both need to be turned off. Due to hilarities with supporting all kernels and the kernel not always being in control of the backlight, we need to turn off the backlight manually. The question you should be asking is: why are we turning things off for a VT switch?
(In reply to comment #1) > The backlight is independent of the pipe, so both need to be turned off. Due > to hilarities with supporting all kernels and the kernel not always being in > control of the backlight, we need to turn off the backlight manually. I thought that it's not that easy. > The question you should be asking is: why are we turning things off for a VT > switch? It already happens when doing a `xrandr --output LVDS1 --off`. The VT switch itself just unveils that it has been lowered, there're no more brightness adjustments when switching.
In which case, this is just a feature request for fbcon to remember its backlight settings as part of its mode. Doing a restore from within X on VT switch, doesn't cover us for when X dies unexpectedly.
If I follow the code correctly, drm_fb_helper_restore_fbdev_mode should restore the backlight (through the crtc enable in the mode set). Maybe I'm missing something. And maybe I don't understand the problem... Daniel Martin, is this still an issue for you with the latest kernels? Please provide a dmesg from early boot to the issue, with drm.debug=0xe module parameter so we can see what's really going on with the backlight.
Created attachment 91033 [details] dmesg-3.13.0-rc1 (drm.debug=0xe) Yes, the problem still exists (3.13.0-rc1). This log has been produced on a Lenovo ThinkPad T430. Comments on the logs/my actions (waited a few secs between all steps for readability): (brightness of LVDS at min after booting) 43.810098 Press the key to raise the brightness. 73.718055 Start X. 103.429718 Connect the external monitor. 138.938385 `xrandr --output LVDS1 --off --output VGA1 --preferred` 164.327787 Switch VT to console. (brightness of LVDS at min) 191.973135 Raise the brightness to max by pressing the key a few times. 213.612743 Switch VT to X. 232.882267 Switch VT to console. (brightness of LVDS at min) 251.699579 Raise the brightness to max by pressing the key a few times.
commit fc64ba821749ed0a0197a69d9bae81957aceb55f Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sat Jun 7 23:27:49 2014 +0100 sna: Restore backlight when switching to VT fbcon doesn't adjust the backlight when it takes over. Therefore if X performs a VT switch whilst its outputs are off, fbcon wakes up with no backlight and users are unhappy. Make the assumption that whoever takes over the VT will set the outputs as it desires, and that the failsafe value is to then turn the backlight to full. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67025 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
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.