[i915] dualscreen: video config is destroyed by acpid (videobtn.sh) when suspending via lid

[Andreas Schildbach]

Binary package hint: xserver-xorg-video-intel

On Karmic latest KMS (and Jaunty Non-KMS) on a Dell Latitude X1 (i915GMS), with an externally connected Dell 2405, suspending by closing the lid destroys the video configuration. Briefly before going to standby, the displays switch to mirrored mode and a low resolution. After waking up, the configuration has to be manually restored via xrandr or Display Properties or by pressing Fn-F8 (CRT/LCD) several times.

Suspending via FUSA or pm-suspend instead works as expected.

This is a regression from Intrepid and Hardy.

ANALYSIS OF THE PROBLEM:

- destroying the display config happens in the /etc/acpi/videobtn.sh script, invoked by acpid when the lid is closed

[lspci]
00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express Processor to DRAM Controller (rev 03)
     Subsystem: Dell Device 01a3
00:02.0 VGA compatible controller: Intel Corporation Mobile 915GM/GMS/910GML Express Graphics Controller (rev 03)
     Subsystem: Dell Device 01a3

[Andreas Schildbach (schildbach)]

When I try to correct the situation via display preferences, the application goes mad:

My external screen is switched off. I switch it back on, but then the internal display disappears and I cannot freely move the external display any more. When clicking on Apply, I get the "virtual resolution" dialog that was introduced with Intrepid, although my virtual resolution is already big enough.

[Andreas Schildbach (schildbach)]

I just found out that this issue has got something to do with the laptop lid: Suspending via FUSA works, but by closing the lid not.

[Andreas Schildbach (schildbach)]

Sometimes, even the internal screen does not activate after suspend/resume by lid. I managed to recover both screens by Alt-F1-ing to shell and restarting gdm. However, things are very weird afterwards. Both gnome panels sits directly on top of each other. Maximizing windows on the external screen result in ~100 pixel wide windows, although the screen has got 1920 pixels and the desktop background spreads to all of those.

[Andreas Schildbach (schildbach)]

On one test with todays upgrades, the internal display stayed deactivated rather than die external display (also in display preferences). On subsequent tests, the bug behaved as described above.

[Andreas Schildbach (schildbach)]

I just tried to suspend/resume in succession, without taking any steps to correct the problems. It seems that each resume randomly chooses one of the following results:

1) internal display at native resolution, external display shut off
2) internal display shut off, external display at native resolution
3) both displays working and using extended desktop
4) both displays mirrored, and at a resolution lower than the native resolution of both

[Andreas Schildbach (schildbach)]

reconfirmed on jaunty final

[Bryce Harrington (bryce)]

Please check to see if turning on Pipe-A forcing solves the freeze for you.

Section "Device"
      ..
      Option "ForceEnablePipeA" "true"

EndSection

[Andreas Schildbach (schildbach)]

I tried the Option, but it did not change anything.

[Andreas Schildbach (schildbach)]

Just reconfirmed on several proposed-updated packages, namely -intel driver and linux kernel .12 update.

[Andreas Schildbach (schildbach)]

Just installed the -intel 2.7.1 driver from the x-updates-ppa, and the bug is still there.

[Andreas Schildbach (schildbach)]

Some more insight: I tested several suspend methods without closing the lid (pm-suspend, power-button), and they do not show the bug. Furthermore, I tried closing the lid _after_ suspending with pm-suspend, and resume via opening the lid. This also does not show the bug.

Re-test: If I suspend by closing the lid, the bug still shows up.

Thus, I guess this bug is only about suspending, not about resuming.

Is there anyone working on this / looking into it?

[Andreas Schildbach (schildbach)]

This is getting worse:

All of the above was dualscreen with extended desktop. Now, I tested a mirrored configuration - this also shows the bug.

Then, I tried to just configure the notebook display, having the external display shut off. When I close the lid, I briefly see the external display being activated - just before the machine goes to standby and all displays are switched off. When I re-open the lid, suddenly only the external display is activated - it should not!

What is happening here?

[Andreas Schildbach (schildbach)]

This is also happening on Karmic dist-upgraded today.

[Bryce Harrington (bryce)]

Hi Andreas,

Going forward, we will be switching on KMS by default for -intel, probably within the week. Can you re-confirm that the bug is not an issue with KMS enabled? If that is the case, I think we should just consider that the "fix", since we do not have plans to support !KMS on -intel.

If you disagree with this approach, you would be welcome to forward the bug upstream to freedesktop.org for further investigation. I think they plan to continue supporting !KMS for a while at least.

[Andreas Schildbach (schildbach)]

Hi Bryce,

I cannot re-test this atm due to bug 389643, but the last time I tested KMS was ok. I would agree this is a fix for Karmic. However, how do you propose to fix this bug in Jaunty, as KMS is not available there?

[Andreas Schildbach (schildbach)]

Hi Bryce, I retested KMS fixes the problem.

[Bryce Harrington (bryce)]

We're shipping KMS on by default now, so guess we can consider this one solved. :-)

[Andreas Schildbach (schildbach)]

I am very sorry to say that this bug has recently cropped up with Karmic and KMS as well. If I suspend with lid, after resume resolutions are totally wrong and sometimes the displays are garbled. If I use suspend from the shutdown menu, all goes well.

I suspect this is the same bug, because it's strongly dependant on using the lid.

[Bryce Harrington (bryce)]

Hi Andreas,

Sorry to hear that. Okay, please attach a fresh Xorg.0.log and xrandr output. We can use those to forward the bug upstream, and also compare with your previous ones to see if there are any differences with this problem.

[Andreas Schildbach (schildbach)]

I believe that the process of 'destroying' the xrandr configuration is happening actually before suspend. When I close the lid, I see the screens switch resolutions to 800x600 just before they fade out and the system starts to sleep.

[Andreas Schildbach (schildbach)]

At least for karmic, I think I've found a candidate: When I kill acpid before lid close, everything works as expected. It looks acpid is destroying the display configuration on lid close event.

[Andreas Schildbach (schildbach)]

More debugging on karmic:

/etc/acpi/events/asus-wireless

is the event that is responsible. I looked into

/etc/acpi/asus-wireless.sh

and found that somewhere in toggleAllWirelessStates() the video configuration is destroyed. This method is imported from /usr/share/acpi-support/state-funcs

Thus, I am assigning this bug to acpi-support.

[Steve Langasek (vorlon)]

> I looked into

> /etc/acpi/asus-wireless.sh

> and found that somewhere in toggleAllWirelessStates() the video configuration is destroyed.

How? This function only touches network devices.

Please show the output of ls -lAR /sys/class/net on your system. Please also test re-enabling acpid and editing /usr/share/acpi-support/state-funcs to add a 'return' at the top of the toggleAllWirelessStates function, to confirm whether your problem persists under those circumstances.

[Andreas Schildbach (schildbach)]

I am puzzled by this as well.

In the case of having just the "asus-wireless" event in /etc/acpi/events, the return statement at the top of toggleAllWirelessStates() indeed decides about the appearance of the bug.

$ ls -lAR /sys/class/net
/sys/class/net:
total 0
lrwxrwxrwx 1 root root 0 2009-07-21 21:00 eth0 -> ../../devices/pci0000:00/0000:00:1c.0/0000:01:00.0/net/eth0
lrwxrwxrwx 1 root root 0 2009-07-21 21:01 eth1 -> ../../devices/pci0000:00/0000:00:1e.0/0000:02:03.0/net/eth1
lrwxrwxrwx 1 root root 0 2009-07-21 21:00 lo -> ../../devices/virtual/net/lo
lrwxrwxrwx 1 root root 0 2009-07-21 21:01 pan0 -> ../../devices/virtual/net/pan0

[Andreas Schildbach (schildbach)]

Drats! After literally hundreds of consistent test results, suddenly the results turn by 180 degrees and seem to prove the opposite. Please disregard my findings about /etc/acpi/asus-wireless.sh and toggleAllWirelessStates()

Still, I can say that when I shutdown acpid, the bug does not happen. How can I debug this?

[Steve Langasek (vorlon)]

Please restart acpid and post the output of acpi_listen across a lid close; this will let us isolate which acpi-support script is to blame.

[Andreas Schildbach (schildbach)]

$ acpi_listen
video VID 00000080 00000000
button/lid LID 00000080 00000001
ac_adapter AC 00000080 00000001
button/lid LID 00000080 00000002
battery BAT0 00000081 00000000
^C

(it's exactly the same on karmic and jaunty)

[Andreas Schildbach (schildbach)]

With

$ sudo /etc/acpi/videobtn.sh

I can reproduce the symptom without actually using the lid.

[Andreas Schildbach (schildbach)]

Ok, it looks like if I close the lid, Ubuntu behaves as if the Fn-F8 (CRT/LCD) button is being pressed: It goes from internal only to external only, from external only to extended desktop, from extended desktop to clone, and from clone to internal only back again.

However, this behaviour is not appropriate for closing the lid.

Side note: I can recover from the situation not only from reconfiguring my display setup but also by pressing Fn-F8 several times.

[Steve Langasek (vorlon)]

So, this acpi event is the one at issue:

  video VID 00000080 00000000

This matches the pattern in /etc/acpi/events/videobtn. That pattern is correct; and the action specified for it is also correct, and the behavior you're describing appears to also be the correct behavior when a video mode switch request is received.

So I don't think this is a bug in any of the userspace packages involved in processing this event. Instead, I would argue it's a bug in the vendor ACPI implementation, which should not generate this event.

I'm reassigning this bug to the Linux kernel package; the kernel team may wish to consider filtering out the event at the kernel level to compensate for the strange behavior of the ACPI implementation.

[Leann Ogasawara (leannogasawara)]

Please run the following command which will automatically gather and attach general kernel debug info:

apport-collect -p linux 352708

[Andreas Schildbach (schildbach)]

Architecture: i386
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: aschildbach 2730 F.... pulseaudio
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
 Card hw:0 'ICH6'/'Intel ICH6 with STAC9752,53 at irq 16'
   Mixer name : 'SigmaTel STAC9752,53'
   Components : 'AC97a:83847652'
   Controls : 33
   Simple ctrls : 22
DistroRelease: Ubuntu 9.10
HibernationDevice: RESUME=UUID=500a11a1-86bd-4609-96ca-78797dfb772b
MachineType: Dell Inc. Latitude X1
Package: linux (not installed)
ProcCmdLine: root=UUID=b17e1aff-9f02-4fbd-81e5-9b1e6899baad ro quiet splash
ProcEnviron:
 SHELL=/bin/bash
 LANG=C
ProcVersionSignature: Ubuntu 2.6.31-5.24-generic
RelatedPackageVersions:
 linux-backports-modules-2.6.31-5-generic N/A
 linux-firmware 1.15
RfKill:
 0: hci0: Bluetooth
  Soft blocked: no
  Hard blocked: no
Uname: Linux 2.6.31-5-generic i686
UserGroups: adm admin cdrom dialout lpadmin plugdev sambashare
WpaSupplicantLog:

dmi.bios.date: 04/05/2005
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A02
dmi.board.name: 0G6951
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA02:bd04/05/2005:svnDellInc.:pnLatitudeX1:pvr:rvnDellInc.:rn0G6951:rvr:cvnDellInc.:ct8:cvr:
dmi.product.name: Latitude X1
dmi.sys.vendor: Dell Inc.

[Jeremy Foshee (jeremyfoshee)]

This bug report was marked as Triaged a while ago but has not had any updated comments for quite some time. Please let us know if this issue remains in the current Ubuntu release, http://www.ubuntu.com/getubuntu/download . If the issue remains, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Joseph Salisbury (jsalisbury)]

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.