I am using KMS with a Intel 915GM card (on a Thinkpad X41 Tablet). Closing and reopening the lid blanks the display permanently until a reboot. Same for docking/undocking. This happens even before X starts. This is not related to suspend/hibernate etc. The problem occurs only with modeset enabled. I can still fly blind (or log in over the network); and vbetool dpms does manage to turn the backlight on or off, but the display remains black. I posted a video of the bug at: http://www.youtube.com/watch?v=-q1N4iosOCI
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
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.