I was able to reproduce the following report on the laptops: - Lenovo T400, - Lenovo T500 and - Lenovo X230. The problem: 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). When the issue happens, it's possible to raise the brightness by: - pressing the brightness keys or - writing a value > 0 into /sys/class/backlight/acpi_video0/brightness. It doesn't happen if I pass "acpi_backlight=vendor" to the kernel. A dmesg log for this case will be attached too. The following attachments are dmesg logs that have been made with the kernel parameters: - drm.debug=0x2 (DRM_UT_DRIVER), - acpi.debug_layer=0x10000000 (ACPI_VIDEO_COMPONENT) and - acpi.debug_level=0x20000004 (ACPI_LV_VERBOSE_INFO | ACPI_LV_INFO). Additionally they include the output of my script to monitor the /sys/class/brightness/*/* states, this output can found by searching for "XXX", and a few comments I've made to document dmesg log lines occuring due to user interaction, my comments can be found by searching for "YYY". (Basically, those pimped dmesg log have been created by: - capturing the output of my script into a file, - attach the dmesg output to that file, - sort that file `sort -k2 -bn $file` and - add my comments.) So the following attachments (dmesg logs) are: 1. for the case this report is about, 2. with acpi_backlight=vendor, where this bug doesn't happen, and 3. for documenting another discovery I've made: o If I setup the X server as described (external only, LVDS off), o press the keys to raise the brightness (I can't see any changes as the LVDS is and stays off) and o switch to the console, then the brightness is at a normal level.
Created attachment 106860 [details] dmesg of the problem (acpi_backlight unspecified)
Created attachment 106861 [details] dmesg with acpi_backlight=vendor, problem doesn't happen
Created attachment 106862 [details] dmesg of discovery (raise brightness before VT switch)
Please attach the output of acpidump and dmidecode, and /var/log/Xorg.0.log. Does this problem occur if you add video.use_bios_initial_backlight=0 option to the kernel command line? Thanks.
Created attachment 106876 [details] Lenovo T400: acpidump
Created attachment 106877 [details] Lenovo T400: dmidecode Created with dmidecode version 2.12.
Created attachment 106878 [details] Lenovo T400: Xorg.log
(In reply to Aaron Lu from comment #4) > Please attach the output of acpidump and dmidecode, and /var/log/Xorg.0.log. Done, though the Xorg.log doesn't give any usefull hints. Do you want the undecoded DMI data from dmidecode too? > Does this problem occur if you add video.use_bios_initial_backlight=0 option > to the kernel command line? Thanks. That option doesn't change the situation. (And the initial brightness was okay before.)
My guess on the issue is that video(?) doesn't track the state of the LVDS correctly. Within the first attachment "dmesg of the problem": - LVDS is active at max brightness [ 65.984072] [drm:intel_panel_actually_set_backlight], set backlight PWM = 2408475 - LVDS turns off [ 66.872419] [drm:intel_panel_actually_set_backlight], set backlight PWM = 0 - I switch to the console, LVDS turns on with the lowest available brightness: [ 87.630062] [drm:intel_panel_actually_set_backlight], set backlight PWM = 18890 PWM values for the brightness states (out of the dmesg): 0 (off), 18890, 56670, 94450, 132230, 179455, 226680, 273905, 330575, 396690, 462805, 538365, 613925, 793380, 1086175, 1596205, 2408475 So, the problem seems to be, when switching to the console the LVDS state "off" gets interpreted as "lowest brightness".
Hmm...sounds related to intel drm driver, I'll re-assign there and see if they know what happened.
xf86-video-intel is causing this behaviour: turning off LVDS leads to acpi_video0/brightness:0 on another console https://bugs.freedesktop.org/show_bug.cgi?id=67025