Bug 60545 - acpi_video0/brightness:0 after VT switch
Summary: acpi_video0/brightness:0 after VT switch
Status: RESOLVED INVALID
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: intel-gfx-bugs@lists.freedesktop.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-10 10:24 UTC by Daniel Martin
Modified: 2013-07-18 08:18 UTC (History)
2 users (show)

See Also:
Kernel Version: 3.10
Subsystem:
Regression: No
Bisected commit-id:


Attachments
dmesg of the problem (acpi_backlight unspecified) (94.81 KB, text/x-log)
2013-07-10 10:25 UTC, Daniel Martin
Details
dmesg with acpi_backlight=vendor, problem doesn't happen (78.80 KB, text/x-log)
2013-07-10 10:26 UTC, Daniel Martin
Details
dmesg of discovery (raise brightness before VT switch) (77.88 KB, text/x-log)
2013-07-10 10:28 UTC, Daniel Martin
Details
Lenovo T400: acpidump (335.92 KB, application/octet-stream)
2013-07-12 08:14 UTC, Daniel Martin
Details
Lenovo T400: dmidecode (16.54 KB, text/x-log)
2013-07-12 08:16 UTC, Daniel Martin
Details
Lenovo T400: Xorg.log (28.28 KB, text/x-log)
2013-07-12 08:16 UTC, Daniel Martin
Details

Description Daniel Martin 2013-07-10 10:24:43 UTC
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.
Comment 1 Daniel Martin 2013-07-10 10:25:39 UTC
Created attachment 106860 [details]
dmesg of the problem (acpi_backlight unspecified)
Comment 2 Daniel Martin 2013-07-10 10:26:57 UTC
Created attachment 106861 [details]
dmesg with acpi_backlight=vendor, problem doesn't happen
Comment 3 Daniel Martin 2013-07-10 10:28:02 UTC
Created attachment 106862 [details]
dmesg of discovery (raise brightness before VT switch)
Comment 4 Aaron Lu 2013-07-12 06:42:30 UTC
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.
Comment 5 Daniel Martin 2013-07-12 08:14:44 UTC
Created attachment 106876 [details]
Lenovo T400: acpidump
Comment 6 Daniel Martin 2013-07-12 08:16:04 UTC
Created attachment 106877 [details]
Lenovo T400: dmidecode

Created with dmidecode version 2.12.
Comment 7 Daniel Martin 2013-07-12 08:16:35 UTC
Created attachment 106878 [details]
Lenovo T400: Xorg.log
Comment 8 Daniel Martin 2013-07-12 08:38:44 UTC
(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.)
Comment 9 Daniel Martin 2013-07-12 08:49:56 UTC
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".
Comment 10 Aaron Lu 2013-07-12 08:55:00 UTC
Hmm...sounds related to intel drm driver, I'll re-assign there and see if they know what happened.
Comment 11 Daniel Martin 2013-07-18 08:18:33 UTC
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

Note You need to log in before you can comment on or make changes to this bug.