Bug 21230

Created attachment 24871 [details]
dmesg after lid close/reopen

Created attachment 24872 [details]
intel reg_dumper before lid close

Created attachment 24873 [details]
intel reg_dumper while lid is closed

Created attachment 24874 [details]
intel reg_dumper after lid is re-opened

Created attachment 24875 [details]
xorg log

Hardware:
  http://www.smolts.org/client/show/pub_8723ef2a-0781-4aa9-a49c-f20b18645cfc

Package versions:
  xorg-x11-drv-intel-2.6.99.902-3.fc11.i586
  kernel-2.6.29.1-70.fc11.i586
  hwdata-0.225-1.fc11.noarch
  xorg-x11-server-Xorg-1.6.1-1.fc11.i586
  kernel-firmware-2.6.29.1-70.fc11.noarch.rpm

Config:
  No Xorg.conf (all auto-detected)
  Kernel: 
    CONFIG_DRM_I915=m 
    CONFIG_DRM_I915_KMS=y

Can you see if your platform is generating LID open/close events?  There's a an
intel_lid tool in src/reg_dumper you can use to see whether the status is
correct, but we'll also want to see if there's an ACPI event generated.  Looks
like your machine is disabling the display at lid time, and messing with the
mode:

-(II):             DSPBCNTR: 0xd9000000 (enabled, pipe B)
+(II):             DSPBCNTR: 0x59000000 (disabled, pipe B)

so we'll need to reset the mode at lid open, but we need a way of detecting it
first.

(In reply to comment #7)
> Can you see if your platform is generating LID open/close events?  There's a an
> intel_lid tool in src/reg_dumper you can use to see whether the status is
> correct, but we'll also want to see if there's an ACPI event generated.  Looks
> like your machine is disabling the display at lid time, and messing with the
> mode:
> 
> -(II):             DSPBCNTR: 0xd9000000 (enabled, pipe B)
> +(II):             DSPBCNTR: 0x59000000 (disabled, pipe B)
> 
> so we'll need to reset the mode at lid open, but we need a way of detecting it
> first.
> 

I ran the intel_lid tool (while logged in over the network) and closed and
opened the lid twice. As expected the screen blanked out after the
first close-open cycle. The output is below.

[saikat@seshat reg_dumper]$ sudo ./intel_lid
----------------------------- SG: LID was open ----------------------------
Intel LVDS Lid status:
       SWF14(0xc0000000) : open
       ACPI Lid state : open
Intel LVDS Lid status:
       SWF14(0xc0000000) : open
       ACPI Lid state : open
Intel LVDS Lid status:
       SWF14(0xc0000000) : open
       ACPI Lid state : open
Intel LVDS Lid status:
       SWF14(0xc0000000) : open
       ACPI Lid state : open
Intel LVDS Lid status:
       SWF14(0xc0000000) : open
       ACPI Lid state : open
Intel LVDS Lid status:
       SWF14(0xc0000000) : open
       ACPI Lid state : open
----------------------------- SG: LID was closed ----------------------------
Intel LVDS Lid status:
       SWF14(0xc0000000) : open
       ACPI Lid state : close
Intel LVDS Lid status:
       SWF14(0xc0000000) : open
       ACPI Lid state : close
Intel LVDS Lid status:
       SWF14(0xc0000000) : open
       ACPI Lid state : close
----------------------------- SG: LID was opened ----------------------------
Intel LVDS Lid status:
       SWF14(0xc0000000) : open
       ACPI Lid state : open
Intel LVDS Lid status:
       SWF14(0xc0000000) : open
       ACPI Lid state : open
Intel LVDS Lid status:
       SWF14(0xc0000000) : open
       ACPI Lid state : open
Intel LVDS Lid status:
       SWF14(0xc0000000) : open
       ACPI Lid state : open
Intel LVDS Lid status:
       SWF14(0xc0000000) : open
       ACPI Lid state : open
Intel LVDS Lid status:
       SWF14(0xc0000000) : open
       ACPI Lid state : open
----------------------------- SG: LID was closed ----------------------------
Intel LVDS Lid status:
       SWF14(0xc0000000) : open
       ACPI Lid state : close
Intel LVDS Lid status:
       SWF14(0xc0000000) : open
       ACPI Lid state : close
----------------------------- SG: LID was opened ----------------------------
Intel LVDS Lid status:
       SWF14(0xc0000000) : open
       ACPI Lid state : open
Intel LVDS Lid status:
       SWF14(0xc0000000) : open
       ACPI Lid state : open
Intel LVDS Lid status:
       SWF14(0xc0000000) : open
       ACPI Lid state : open
^C

This issue is still present with:
 xorg-x11-drv-intel-2.7.0-1.fc11.i586
 kernel-2.6.29.1-102.fc11.i586

My laptop is completely unusable as a laptop with this bug. I'd be happy to test out a kernel or xorg patch to get this resolved quickly. 

Ok let me see what I can come up with... if there's not a way to disable your machine from poking at display registers at lid event time (sometimes the _DOS setting or another ACPI setting will affect this) we'll have to catch an event in the kernel driver and reset the mode.

Created attachment 25426 [details] [review]
add lid event handler

Can you confirm that you get debug output about your lid with this patch applied?  Assuming you do I can add some infrastructure for handling disable/enable of your display at lid time.

(In reply to comment #11)
> Can you confirm that you get debug output about your lid with this patch
> applied?  Assuming you do I can add some infrastructure for handling
> disable/enable of your display at lid time.

Yes, I am getting the debug out. Although, each action generates two lines. See below:

-------- Closing lid ...
May  5 03:31:29 seshat kernel: [drm:lid_event] *ERROR* received lid close event
May  5 03:31:29 seshat kernel: [drm:lid_event] *ERROR* received lid open event

-------- Opening lid ...
May  5 03:31:33 seshat kernel: [drm:lid_event] *ERROR* received lid open event
May  5 03:31:33 seshat kernel: [drm:lid_event] *ERROR* received lid open event

-------- Closing lid ...
May  5 03:31:38 seshat kernel: [drm:lid_event] *ERROR* received lid close event
May  5 03:31:38 seshat kernel: [drm:lid_event] *ERROR* received lid open event

-------- Opening lid ...
May  5 03:31:42 seshat kernel: [drm:lid_event] *ERROR* received lid open event
May  5 03:31:42 seshat kernel: [drm:lid_event] *ERROR* received lid open event

Ok that matches what I'm seeing (I was hoping it was just a problem on my platform).  Maybe I'm processing the input events wrong...

Anyway looks like we're a lot closer to being able to handle these.  Updated patch will follow soon.

Things are getting better (on my x61).  Now after closing/opening the lid
*twice* the screen will come back.  The first time it's blank.

  2.6.30-rc5-00096-ga4d7749
  xorg-x11-drv-intel-2.7.0-4.fc11.x86_64

I get one of the these messages every lid close/open cycle.

  ...
  [drm] LVDS-8: set mode  1a
  [drm] LVDS-8: set mode  1b
  [drm] LVDS-8: set mode  1c
  [drm] LVDS-8: set mode  1d

Of course I can't seen the first one until I perform the cycle again.  At least
I don't have to reboot now!

FWIW, I also get these on startup.  I'm not sure if they are related.

  [drm:i915_gem_object_bind_to_gtt] *ERROR* GTT full, but LRU list empty
  [drm:i915_gem_object_pin] *ERROR* Failure to bind: -12
  [drm:i915_gem_evict_something] *ERROR* inactive empty 1 request empty 1 flushing empty 1

For the record, I can reproduce the behavior described in comment #12. My system's a 915GM in a ThinkPad T43.

xorg-x11-drv-intel-2.7.0-5.fc11.i586
kernel-PAE-2.6.29.3-141.fc11.i686 (compiled with the patch from comment #11)

See also the downstream Fedora bug:
https://bugzilla.redhat.com/show_bug.cgi?id=489907

It's currently being considered as a blocker for F11 release (due in ~2 weeks) because there's a lot of Fedora devs with intel-based ThinkPads. What are the chances of this having a fix in the next 7 days or so?

Created attachment 25832 [details] [review]
add lid detection

This one is slightly better:
  - sends DRM hotplug events on lid open/close
  - uses lid switch for LVDS connector detection

I'm somewhat reluctant to add automatic mode setting to the lid handler though, since after the hotplug event userspace may reconfigure the outputs, so we might end up restoring the wrong configuration.  However in the kms console case we might want to do something, if only to get the display back...

(In reply to comment #16)
> This one is slightly better:
>   - sends DRM hotplug events on lid open/close
>   - uses lid switch for LVDS connector detection

I am getting the hotplug events; no duplicates. Log output below.

----------------- Closing lid -------------
/root/testplug: drm
declare -x ACTION="change"
declare -x DEVPATH="/devices/pci0000:00/0000:00:02.0/drm/card0"
declare -x HOME="/"
declare -x HOTPLUG="1"
declare -x MAJOR="226"
declare -x MINOR="0"
declare -x OLDPWD
declare -x PATH="/sbin:/bin:/usr/sbin:/usr/bin"
declare -x PWD="/"
declare -x SEQNUM="1241"
declare -x SHLVL="1"
declare -x SUBSYSTEM="drm"

----------------- Opening lid -------------
/root/testplug: drm
declare -x ACTION="change"
declare -x DEVPATH="/devices/pci0000:00/0000:00:02.0/drm/card0"
declare -x HOME="/"
declare -x HOTPLUG="1"
declare -x MAJOR="226"
declare -x MINOR="0"
declare -x OLDPWD
declare -x PATH="/sbin:/bin:/usr/sbin:/usr/bin"
declare -x PWD="/"
declare -x SEQNUM="1242"
declare -x SHLVL="1"
declare -x SUBSYSTEM="drm"

----------------- Closing lid -------------
/root/testplug: drm
declare -x ACTION="change"
declare -x DEVPATH="/devices/pci0000:00/0000:00:02.0/drm/card0"
declare -x HOME="/"
declare -x HOTPLUG="1"
declare -x MAJOR="226"
declare -x MINOR="0"
declare -x OLDPWD
declare -x PATH="/sbin:/bin:/usr/sbin:/usr/bin"
declare -x PWD="/"
declare -x SEQNUM="1243"
declare -x SHLVL="1"
declare -x SUBSYSTEM="drm"

----------------- Opening lid -------------
/root/testplug: drm
declare -x ACTION="change"
declare -x DEVPATH="/devices/pci0000:00/0000:00:02.0/drm/card0"
declare -x HOME="/"
declare -x HOTPLUG="1"
declare -x MAJOR="226"
declare -x MINOR="0"
declare -x OLDPWD
declare -x PATH="/sbin:/bin:/usr/sbin:/usr/bin"
declare -x PWD="/"
declare -x SEQNUM="1244"
declare -x SHLVL="1"
declare -x SUBSYSTEM="drm"

Will, have you tested this patch?  I think ajax might be working on the X side of KMS hotplug events; if he's got that working this patch may be sufficient.

(In reply to comment #18)
> Will, have you tested this patch?  I think ajax might be working on the X side
> of KMS hotplug events; if he's got that working this patch may be sufficient.


The LVDS turns off even without X. e.g. during plymouth, or in init level 3. Turning the LVDS back on in X may be an interim solution, but not sufficient imo.

Yeah I'm just worried about clobbering a config by blindly re-enabling plane B or something.  It would be really easy to freeze the machine at lid open if we just did something simple; thus my desire to push it off to userspace, which will be responding to these events and making changes.

But in the plain console mode, yeah we need a solution here for sure...

(In reply to comment #18)
> Will, have you tested this patch?  I think ajax might be working on the X side
> of KMS hotplug events; if he's got that working this patch may be sufficient.

kylem did a scratch build of the Fedora kernel with that patch merged. (It had to be modified a bit since the trees have diverged a little.) 
Build: http://koji.fedoraproject.org/koji/taskinfo?taskID=1356787
Patch: http://shortfin.cabal.ca/~kyle/drm-intel-fix-lid_close.patch

No change at all on my laptop. I checked /proc/kallsyms to make sure the new 'acpi_lid_close' symbol was present, just to be double-sure that the patch was actually applied.

Hi, Saikat
    Will you please attach the output of acpidump?
    Thanks.

Will you please do the following test with KMS enabled?
   a. kill the process using the /proc/acpi/event (use the command of "lsof /proc/acpi/event" to get the process id)
   b. close/reopen the lid and see whether the issue still exists?
   Thanks.

Created attachment 26581 [details]
acpidump output

> with KMS enabled?
>  a. kill the process using the /proc/acpi/event
>  b. close/reopen the lid and see whether the issue still exists?

Yes, the issue still exists without any acpi listeners.

acpidump is attached.

Currently installed:
 xorg-x11-drv-intel-2.7.0-7.fc11.i586
 kernel-2.6.30-0.97.rc8.fc12.i586

Still exists with xorg-x11-drv-intel-2.8.0-0.1.fc12.i586

A workaround that previously used to work (xrandr --output LVDS1 --off; xrandr --output LVDS1 --auto) stopped working with 2.8.0 with error "xrandr: Configure crtc 1 invalid time" 

Can someone look into this? If you need any additional info, I am happy to provide it. It is perfectly reproducible by many people who are eager to have this resolved. This is an embarrassing regression.

Yeah, I'm still looking at this one... forward porting my patch now.

Created attachment 27484 [details] [review]
add lid detection & mode reset

How about this patch?  It resets the mode at open time before we send the event.  That should be safe, since userland is free to change the mode once it receives the event; in the meantime we'll have the last config.

Your patch worked for me on 2.6.31-rc3.  I can now open and close my lid with abandon!

BTW, you forgot to include your new acpi.h header in your patch.

Great, thanks for testing, I'll fix the acpi header issue and see if the patch can get included in the next kernel.

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

Jesse, how's the patch going?

Patch is done and posted to intel-gfx, just needs to be integrated into 2.6.32.

Jesse, is the patch in drm-intel-next?

Not yet.  Will ping Eric again.

Fix is upstream now:

commit c1c7af60892070e4b82ad63bbfb95ae745056de0
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Thu Sep 10 15:28:03 2009 -0700

    drm/i915: force mode set at lid open time