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

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.

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.

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.

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.

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

reconfirmed on jaunty final

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

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

EndSection

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

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

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

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?

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?

This is also happening on Karmic dist-upgraded today.

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.

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?

Hi Bryce, I retested KMS fixes the problem.

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

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.

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.

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.

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.

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.

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

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

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?

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.

$ 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)

With

$ sudo /etc/acpi/videobtn.sh

I can reproduce the symptom without actually using the lid.

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.

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.

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

apport-collect -p linux 352708

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.

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

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.