Bug 14997

Summary: Closing and re-opening the lid does not reactivate the backlight
Product: Drivers Reporter: o. meijer (meijer.o)
Component: Video(DRI - Intel)Assignee: Jesse Barnes (jbarnes)
Status: RESOLVED PATCH_ALREADY_AVAILABLE    
Severity: normal CC: 84yelo3, acpi-bugzilla, bugs, chasedouglas, fedora, jbarnes, mat, rjw, ron.duplain, tiwai, xjakub, yakui.zhao
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.32.2 Subsystem:
Regression: Yes Bisected commit-id:
Bug Depends on:    
Bug Blocks: 14230    
Attachments: logs and outputs
logs and outputs
before and after closing lid kernel 2.6.32.6
A patch to reinitialize CRTCs at lid open
Fix blank screen after lid open with i915
dmesg ouput comment 36

Description o. meijer 2010-01-06 15:38:25 UTC
Created attachment 24469 [details]
logs and outputs

Dear experts,

Closing and re-opening the lid does not reactivate the backlight

See bug 14722
The bug does not occur with kernel 2.6.31.9 KMS enabled.

hardware: laptop Compaq 6720S
lspci: 
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960
Integrated Graphics Controller (rev 0c)

00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated
Graphics Controller (rev 0c)

OS ubuntu 9.10
kernel 2.6.32.2 KMS enabled
Driver xserver-xorg-video-intel 2:2.9.0-ubuntu2
Xorg 1:7.4+3ubuntu10


Gnome-power-manager settings Suspend when closing lid works fine, on resume the
back-light is turned on

Gnome-power-manager settings Blank Screen when closing lid leaves the
back-light off after reopening the lid.

Key-combination <control Alt F2> followed by <control Alt F7> turns the
backlight on again. (with an error-message of OSD “Could not switch the monitor
configuration Could not set the configuration for CRCT 58”


--- Comment #6 from ykzhao <yakui.zhao@intel.com>  2010-01-02 13:56:43 ---
Hi, Meijer
    It seems that you have a different bug. (bug 14722) Will you please open a new

    1. Xorg.0.log
    2. the output of dmesg after adding the boot option of "drm.debug=0x06".
The output of dmesg after close and reopen the LID
    3. acpidump (The pmtools-2007116 dump tool can be found in
http://www.lesswatts.org/projects/acpi/utilities.php)

It will be great if you can boot the system with "nomodeset" and do the
following test.
    a. kill the process using the /proc/acpi/event( use the command of "lsof
/proc/acpi/event" to get the process ID)
    b. cat /proc/acpi/event >lid_result
    c. close and reopen the LID several times
    d. press "ctrl + c" and attach the output of lid_result.
Note by c.:
The backlight turns off and on again whether the lid is closed or not.

Please see attachment for 1-3 and a-d

I used the kernel source from kernel.org and compiled it myself. Please let me know if I made a mistake or if you need additional information or logs.

I am not an Linux expert but know how to work with it.

Kind regards,

Otto Meijer
Comment 1 o. meijer 2010-01-06 15:58:02 UTC
Created attachment 24470 [details]
logs and outputs

I forgot adding dmesg after closing en reopening the lid
Comment 2 o. meijer 2010-01-25 20:21:21 UTC
Created attachment 24710 [details]
before and after closing lid kernel 2.6.32.6

The "bug"is not fixed with kernel 2.6.32.6. I am prepared to supply further information or do more testing

Best regards,

Otto Meijer
Comment 3 Thorsten Leemhuis 2010-01-30 08:09:15 UTC
I afaics have exactly the same problem on Fedora 12 with Kenrel >= 2.6.32; filed a Fedora bug yesterday https://bugzilla.redhat.com/show_bug.cgi?id=560121

As mentioned there: The acpi subsystem according to the content of the file
/proc/acpi/button/lid/LID/state seems to properly detect when the lid was
opened, so I tend to think it's something in the KMS code for intel.
Comment 4 Thorsten Leemhuis 2010-01-31 10:35:20 UTC
Tried Fedora rawhide kernel-2.6.33-0.25.rc6.git0.fc13.x86_64 (based on 2.6.33-rc6) and it shows the same error
Comment 5 Rafael J. Wysocki 2010-01-31 12:20:14 UTC
Notify-Also : Thorsten Leemhuis <fedora@leemhuis.info>
Comment 6 o. meijer 2010-02-03 20:19:06 UTC
I tested kernel 2.6.33-rc6 and 2.6.32.7. The issue has not been resolved. I am always prepared to test or to supply further information

Best regard,

Otto Meijer
Comment 7 Jesse Barnes 2010-02-05 18:56:36 UTC
Can one of you bisect this bug?  I assume it's related to KMS lid handling, but we haven't changed the actual backlight handling for awhile iirc, so this is still strange.
Comment 8 Milos Jakubicek 2010-02-11 21:05:46 UTC
Same (worse: have to restart X after opening the lid) problem with Intel 4500 (details in the Fedora bug).
Comment 9 Matthias Hopf 2010-02-12 10:04:38 UTC
Milos, your bug very much sounds like a completely different issue.


Jesse, I'm able to reproduce here (and 2.6.31.12 does not exhibit the problem), thus I'm able to bisect.

I think I have a good clue about the culprit already - 2.6.32ff apparently switch off the output completely (xrandr tells LVDS1 disconnected) in order to save power (switching off the crtc). It *is* reestablished upon lid open, though.

With 2.6.31.12 LVDS1 stays connected and up and running (while the panel definitely goes off). Switching VTs is enough to get the screen back, so apparently something is missing in the lid event routine. xrandr output doesn't change before and after the VT switch.


Of course this could also be an xorg driver bug that is only triggered by this change of behavior...
Comment 10 Matthias Hopf 2010-02-12 11:07:15 UTC
It looks like this is closely correlated to bug 14484. The workaround in comment #41 there fixes this issue. The CRTC stays enabled, the lid event still works in Gnome, so from a user's pov no negative side effects (apart from slightly higher power consumption).

I don't think this requires further bisecting.
Comment 11 Matthias Hopf 2010-02-12 11:30:30 UTC
It seems this is highly correlated with RandR as well. Talking about unpatched drm right now.


Szenario: the screen locker kicks in upon lid close.
After lid close + open the screen stays black. Switching VTs brings the screen up again. After lid close + open (with*out* logging back in) the screen still comes up again.

However, if I scan the RandR state remotely  (xrandr -q), it shows that LVDS1 is disconnected when closing the lid, and reconnected when opening - and the screen stays black again.


So in short - as long as RandR does not trigger any status updates, the screen stays up. HTH
Comment 12 Takashi Iwai 2010-02-12 15:12:00 UTC
I took a bit more at this problem, too, for the same machine Matthias is checking (945GM).  The problem looks like that the encoder->crtc is cleared at lid close, but it's never recovered properly.

Namely, drm_crtc_helper_set_config() is called by intel's set_config, and this calls drm_helper_disable_unused_functions() that prunes off crtcs used for LVDs.  Then, at lid open, drm_helper_resume_force_mode() is called, but this resumes the CRTCs that are already enabled, thus it doesn't help for resuming LVDS.

The ad-hoc patch below fixes this issue.  I'm not 100% sure whether this is really correct.  Hopefully this will help for a better fix.
Comment 13 Takashi Iwai 2010-02-12 15:13:30 UTC
Created attachment 25007 [details]
A patch to reinitialize CRTCs at lid open
Comment 14 Jesse Barnes 2010-02-12 17:57:23 UTC
Right, that makes sense, thanks Takashi.  What *should* happen is that at close time, we just send an event to userspace which may choose to reconfigure your outputs.

But if your ACPI lid status is wrong (i.e. acpi_lid_open returns true when your lid is closed) then we'd reset the mode at close time as well, turning off LVDS.  Then at open time we'd reset and keep the lost the LVDS output, but again userspace could choose to reconfigure (but if your LID is lying it'll see "disconnected").

Assuming that's what's going on here, in the intel_lid_notify() function we need to add the DMI check:

diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds
index 75a9772..d03f6d4 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -708,7 +712,7 @@ static int intel_lid_notify(struct notifier_block *nb, unsig
         */
        if (connector)
                connector->status = connector->funcs->detect(connector);
-       if (!acpi_lid_open()) {
+       if (dmi_check_system(bad_lid_status) || !acpi_lid_open()) {
                dev_priv->modeset_on_lid = 1;
                return NOTIFY_OK;
        }

then make sure these machines are added to the DMI list.
Comment 15 Takashi Iwai 2010-02-12 19:10:11 UTC
Well, I'm afraid this doesn't help.  IIRC, acpi_lid_open() returned the correct value when notifier is called for both close and open in my tests.  (I can't say this 100% since I can't test it now at home, though....)

To be noted, the blank screen problem appears only with X.  On framebuffer, it works after lid open.  So, as Matthias mentioned in comment 11, the invocation of randr triggers something wrong in the i915 driver.

My understanding is that X reacts something after the lid is closed.  Then, this calls drm_crtc_helper_set_config().  This eventually removes the disconnected LVDS CRTC via drm_helper_disable_unused_functions().
When the lid is opened, the driver tries to resume, but CRTC was already disabled and deassociated from encoders.  Thus the modeset isn't resumed.
drm_crtc_helper_set_config() is recalled by X as lid user event after it, but this also doesn't resume because crtc isn't associated with encoders.
Comment 16 Jesse Barnes 2010-02-12 19:15:33 UTC
But on lid open, if X or the kernel re-probes it should see LVDS active and assign something to it, right?  If the server is generating randr events when it gets the hotplug event, why isn't it picking this up?
Comment 17 Takashi Iwai 2010-02-12 19:42:37 UTC
The problem is that the driver skips the crtc reconfiguration by some reason at randr events on lid open...

Well, I think I was confused in the comment above between drm_crtc_helper_set_config() and drm_helper_probe_single_connector_modes() (Sorry, I'm writing this based on my memory of hours ago ;)
*_set_config() wasn't called in the lid-open path...  Does it sound more reasonable?

Hopefully someone can give another kernel log with drm.debug=4 or 6.
Comment 18 Jesse Barnes 2010-02-12 21:18:11 UTC
If set_config wasn't called at lid open time, then yes, the display might not be restored.  But it also shouldn't have been called at lid close time in any case, so it shouldn't have been shut off and removed from the config, except by X upon receiving the lid event...

So I'm still confused about what's going on here.  It's acting like X received an event then processed it when LVDS was marked as "disconnected", and even a lid open didn't fix that.
Comment 19 Thorsten Leemhuis 2010-02-13 11:04:58 UTC
(In reply to comment #15 from Takashi)
> To be noted, the blank screen problem appears only with X.  On framebuffer,
> it
> works after lid open.
Same here. *But* the backlight isn't disabled on framebuffer at all afaics when the lid is closed :-/ When opening the lid the screen goes dark for half a second or so and then is back properly.

(In reply to comment #18 from Jesse)
> So I'm still confused about what's going on here. 
Can I provide anything to help finding the root cause without a whole bisection, as doing one afaics would take quite a while...
Comment 20 Takashi Iwai 2010-02-13 19:32:25 UTC
(In reply to comment #19)
> (In reply to comment #15 from Takashi)
> > To be noted, the blank screen problem appears only with X.  On framebuffer,
> it
> > works after lid open.
> Same here. *But* the backlight isn't disabled on framebuffer at all afaics
> when
> the lid is closed :-/ When opening the lid the screen goes dark for half a
> second or so and then is back properly.

Hm, I didn't check it properly.  Will check on Monday.

> (In reply to comment #18 from Jesse)
> > So I'm still confused about what's going on here. 
> Can I provide anything to help finding the root cause without a whole
> bisection, as doing one afaics would take quite a while...

Could you set debug=6 option for drm module and take the kernel logs at lid close and open before that?

Of course, you can try some patches floating around here (e.g. the one in comment 13 or in comment 14).  If the comment 13 works, it's the identical problem.  So far, it's not 100% clear whether we all see the same problem.
Comment 21 Thorsten Leemhuis 2010-02-13 20:07:40 UTC
(In reply to comment #20)
> Could you set debug=6 option for drm module and take the kernel logs at lid
> close and open before that?

Sure: http://www.leemhuis.info/files/misc/part.gz (¹)

The logs starts at second 90; I think I closed the lid two or three seconds later; then I waited round about five seconds and opened it again; waited another five seconds and switched to a text console; waited another five seconds and switched back to X, unlocked the screensaver and captured the log.

(¹) Full dmesg in case it matters:
http://www.leemhuis.info/files/misc/full.gz
Comment 22 Thorsten Leemhuis 2010-02-13 21:44:04 UTC
(In reply to comment #20)
>
> Of course, you can try some patches floating around here (e.g. the one in
> comment 13 or in comment 14).  If the comment 13 works, it's the identical
> problem. 

Patch from comment 13 works fine for me; will try the other one tomrrow
Comment 23 Takashi Iwai 2010-02-15 16:57:38 UTC
OK, some information updates, finally :)

- acpi_lid_open() returns the correct value in the notifier and other places.  So, the quirk isn't the solution.

- Upon lid close, drm_helper_disable_unused_functions() gets called from intel_release_load_detect_pipe() from intel_tv_detect().  This is triggered by drm_mode_getconnector() ioctl.

- drm_helper_disable_unused_functions() purges the stale connections.  This includes the disconnected LVDS.

- Upon lid open, drm_helper_resume_force_mode() activates only the enabled CRTCs.  Since the CRTC connection of LVDS is cleared in the previous action, this configuration is skipped.

- While the mode of TVs can be set via intel_tv_detect(), intel_lvds_detect() doesn't do such a thing.

- This problem doesn't appear on IronLake machines because they have no analog TV lines, thus CRTCs of LVDS aren't deactivated.
Comment 24 Jesse Barnes 2010-02-16 23:01:20 UTC
Ugg, so imo X is really to blame here.  It's doing the right thing at close time when it receives a hotplug event (detecting available outputs) but at open time it's not bothering to restore the LVDS config.

This is actually why we don't do any reconfiguration in the kernel at event time and why the console works fine; trying to do anything other than just blindly restore the last config at open time is just guesswork.  If X is going to listen for events it also needs to handle them correctly.

That said, doing load detect shouldn't affect the configuration, so we may have to remove the drm_helper_disable_unused_functions() from our load detect code, or use your patch from comment #13 to pick up changes correctly.
Comment 25 Jesse Barnes 2010-02-16 23:22:22 UTC
Looking at the code, it seems the drm_helper_disable_unused_functions call shouldn't be necessary in the load detect release function; if you remove it do things work correctly?
Comment 26 Takashi Iwai 2010-02-17 09:19:21 UTC
Yeah, X could be more proactive.  OTOH, it's also fragile that just detecting (not setting) the outputs causes the problem.

I'll try to remove the drm_helper_disable_unused_functions() with a machine in my office later.  FWIW, I tried to adjust xorg.conf (yes we still use it ;) to disable the "TV" monitor section.  Then the problem disappeared.  So I guess it will work.  Let's see...
Comment 27 Takashi Iwai 2010-02-17 09:59:45 UTC
Removing drm_helper_disable_unused_functions() in intel_display.c fixes the problem on a machine here.  The display appears at lid open.

I see, however, a popup from gnome display applet or setting-daemon saying
   Could not switch the monitor configuration
   could not set the configuration for CRTC 58

I guess this isn't directly related with the blank screen issue.  It's likely the hotplug detection error of analog lines I didn't notice because of blank screen...
Comment 28 Takashi Iwai 2010-02-17 15:15:40 UTC
The CRTC error is found on other machines with IronLake, so this should be irrelevant.  This is perhaps because of the reconnection at lid open, though.

To be sure, I attach the patch I tested below.  It'd be nice if someone can confirm this really fixes the problem.
Comment 29 Takashi Iwai 2010-02-17 15:16:44 UTC
Created attachment 25092 [details]
Fix blank screen after lid open with i915
Comment 30 Thorsten Leemhuis 2010-02-17 16:44:28 UTC
(In reply to comment #28)
> To be sure, I attach the patch I tested below.  It'd be nice if someone can
> confirm this really fixes the problem.

Patch fixes the problem for me on my Dell Latitude D630 with GM965
Comment 31 Rafael J. Wysocki 2010-02-17 19:44:45 UTC
Handled-By : Takashi Iwai <tiwai@suse.de>
Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=25092
Comment 32 o. meijer 2010-02-17 21:49:06 UTC
I tested the patch. on closing the lid, the back-light turns off and directly on again  (with lid closed).

On opening the lid, the back-light turns off and directly on again

< Could not switch the monitor
configuration Could not set the configuration for CRCT 58 >  error-message of OSD still pops up (twice). 

I patched and compiled kernel 2.6.32.8. Hopefully this can be resolved as well

Kind regards,

Otto Meijer
Comment 33 Thorsten Leemhuis 2010-02-17 22:02:34 UTC
(In reply to comment #32)
> I tested the patch. on closing the lid, the back-light turns off and directly
> on again  (with lid closed).
>
> On opening the lid, the back-light turns off and directly on again

Just as additional data-point: that definitely doesn't happen here when closing the lid while in X with a fedora kernel based on 2.6.33-rc8 that has the patch from comment 28; but it's like described when closing the lid on a plain text console when KMS is active
Comment 34 Takashi Iwai 2010-02-17 22:06:00 UTC
(In reply to comment #32)
> I tested the patch. on closing the lid, the back-light turns off and directly
> on again  (with lid closed).
> 
> On opening the lid, the back-light turns off and directly on again

This can be rather due to the unstable acpi-lid state query.  Try to add debug prints to show acpi_lid_open() values in intel_lvds_detect() and intel_lid_notify() in drivers/gpu/drm/i915/intel_lvds.c.

If acpi_lid_open() isn't reliable, better to put your device to bad_lid_status[] in intel_lvds.c.
Comment 35 Takashi Iwai 2010-02-17 22:10:32 UTC
(In reply to comment #33)
> (In reply to comment #32)
> > I tested the patch. on closing the lid, the back-light turns off and
> directly
> > on again  (with lid closed).
> >
> > On opening the lid, the back-light turns off and directly on again
> 
> Just as additional data-point: that definitely doesn't happen here when
> closing
> the lid while in X with a fedora kernel based on 2.6.33-rc8 that has the
> patch
> from comment 28; but it's like described when closing the lid on a plain text
> console when KMS is active

On HP machines here, this didn't happen with linux console, AFAIK.

Do you see any action from extern when you close the lid when you log with drm.debug=6 (or even 7) option?
Comment 36 o. meijer 2010-02-18 21:58:27 UTC
Created attachment 25108 [details]
dmesg ouput comment 36
Comment 37 o. meijer 2010-02-18 22:01:38 UTC
dmesg ouput comment 36 = closing and reopening lid with boot option drm.debug=0x07
Comment 38 o. meijer 2010-02-18 22:11:35 UTC
with this grub option < video=LVDS-1:e > the lid works fine. I do not even know what the option does

Kernel: 2.6.32-8

Kind regards,

Otto
Comment 39 Jesse Barnes 2010-02-18 22:56:38 UTC
Ok just sent the patch upstream; should land in stable and hopefully 2.6.33.
Comment 40 Jesse Barnes 2010-02-18 23:15:55 UTC
*** Bug 14766 has been marked as a duplicate of this bug. ***
Comment 41 Nicolo' Chieffo 2010-02-19 18:31:10 UTC
Hello, I tested a ubuntu kernel (2.6.32-13-generic) with this [1] patch applied.
I have to say that it fixed the problem, but it introduces an issue with gnome-settings-daemon:
a notification (sent by gnome-settings-daemon, because if I kill the process there's no such), that says: "Could not switch the monitor configuration / could not set the configuration for CRTC 64".

Do you think it's gnome-settings-daemon fault?
If I boot with "nomodeset" it does not emit any notifications.

[1]: http://bugzilla.kernel.org/attachment.cgi?id=25092
Comment 42 Takashi Iwai 2010-02-20 10:08:28 UTC
As mentioned in comment 27 and 28, this isn't directly related with the blank screen problem, but partly yes, it's due to the recent change of intel KMS.

My understanding is that the CRTC detection isn't stable enough for some devices, and this gives the error at lid open since now the lid-open issues the reconnection.
Comment 43 Nicolo' Chieffo 2010-02-20 10:44:43 UTC
So, you are saying that the problem is not gnome-settings-daemon.
Just for curiosity, do you experience also the other issues reported in this gnome-settings-daemon bug [1], after you open the lid?
Thanks

[1] https://bugzilla.gnome.org/show_bug.cgi?id=610482
Comment 44 Takashi Iwai 2010-02-21 16:20:19 UTC
This is no "bug" of g-s-d.  g-s-d reports that the detection failed, and it's true.  Thus it's the designed behavior.

It's a different question whether g-s-d should retry to be more robust in such a case, or whether we should improve the connection detection in KMS side, though.