Created attachment 24470 [details]
logs and outputs

I forgot adding dmesg after closing en reopening the lid

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

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.

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

Notify-Also : Thorsten Leemhuis <fedora@leemhuis.info>

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

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.

Same (worse: have to restart X after opening the lid) problem with Intel 4500 (details in the Fedora bug).

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...

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.

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

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.

Created attachment 25007 [details]
A patch to reinitialize CRTCs at lid open

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.

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.

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?

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.

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.

(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...

(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.

(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

(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

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.

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.

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?

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...

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...

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.

Created attachment 25092 [details]
Fix blank screen after lid open with i915

(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

Handled-By : Takashi Iwai <tiwai@suse.de>
Handled-By : Jesse Barnes <jbarnes@virtuousgeek.org>
Patch : http://bugzilla.kernel.org/attachment.cgi?id=25092

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

(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

(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.

(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?

Created attachment 25108 [details]
dmesg ouput comment 36

dmesg ouput comment 36 = closing and reopening lid with boot option drm.debug=0x07

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

Ok just sent the patch upstream; should land in stable and hopefully 2.6.33.

*** Bug 14766 has been marked as a duplicate of this bug. ***

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

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.

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

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.