Summary: | fbcon doesn't restore backlight (if X turns it off before VT switching for example) | ||||||
---|---|---|---|---|---|---|---|
Product: | DRI | Reporter: | Daniel Martin <consume.noise> | ||||
Component: | DRM/Intel | Assignee: | Antti Koskipaa <antti.koskipaa> | ||||
Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> | ||||
Severity: | normal | ||||||
Priority: | low | ||||||
Version: | unspecified | ||||||
Hardware: | x86-64 (AMD64) | ||||||
OS: | Linux (All) | ||||||
Whiteboard: | |||||||
i915 platform: | i915 features: | ||||||
Attachments: |
|
Description
Daniel Martin
2013-07-18 08:16:48 UTC
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.