Bug 60545

Summary:	acpi_video0/brightness:0 after VT switch
Product:	Drivers	Reporter:	Daniel Martin (consume.noise)
Component:	Video(DRI - Intel)	Assignee:	intel-gfx-bugs (intel-gfx-bugs)
Status:	RESOLVED INVALID
Severity:	normal	CC:	aaron.lu, intel-gfx-bugs
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	3.10	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	dmesg of the problem (acpi_backlight unspecified) dmesg with acpi_backlight=vendor, problem doesn't happen dmesg of discovery (raise brightness before VT switch) Lenovo T400: acpidump Lenovo T400: dmidecode Lenovo T400: Xorg.log

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