Bug 11455 - [intel] laptop lid switch status not used at server startup time
[intel] laptop lid switch status not used at server startup time
Status: RESOLVED WONTFIX
Product: DRI
Classification: Unclassified
Component: DRM/Intel
unspecified
Other All
: medium enhancement
Assigned To: Jesse Barnes
http://bugs.debian.org/cgi-bin/bugrep...
:
: 17771 19991 20973 22580 22751 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-02 14:52 UTC by Brice Goglin
Modified: 2010-07-02 09:37 UTC (History)
12 users (show)

See Also:


Attachments
Xorg.0.log when lid is closed and VGA is connected (73.76 KB, text/plain)
2007-07-02 14:52 UTC, Brice Goglin
no flags Details
Xorg.0.log when lid is closed, DFP is connected, and xrandr is toyed with (260.07 KB, text/plain)
2007-08-25 10:10 UTC, Stu Black
no flags Details
laptop_boot_with_closed_panel_xrandr_verbose (4.18 KB, text/plain)
2009-02-05 22:31 UTC, MaLing
no flags Details
laptop_boot_with_closed_panel.Xorg.0.log (72.11 KB, application/octet-stream)
2009-02-05 22:32 UTC, MaLing
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Brice Goglin 2007-07-02 14:52:10 UTC
This bug has been reported recently by Guy Heatley on the Debian BTS. Basically, when booting a laptop with the panel closed and an external output plugged, both are enabled by the server, while we would expect the LVDS to be disabled (as the old i810 driver did). So there might be something broken in the way the driver obtains/uses the lid sensor value.

I will be attaching Xorg.0.log from Guy when booting with lid closed and VGA connected. I have seen the same problem with TMDS-1 instead of VGA.

However, we are not sure what should be done here:
* assuming we decide to disable LVDS in RandR-1.2 when the lid is closed, what should be done if no external monitor is plugged at all? I guess the server would not be happy with no output enabled at all?
* then if we can't disable LVDS as above, maybe we should just make LVDS off by DPMS? But I don't know whether it is possible to do that on LVDS while the external monitor stays enabled.

Anyway, it's easy to workaround this behavior with xrandr, but it would be good to do something about it anyway.

Thanks.
Comment 1 Brice Goglin 2007-07-02 14:52:51 UTC
Created attachment 10559 [details]
Xorg.0.log when lid is closed and VGA is connected
Comment 2 Stu Black 2007-08-25 10:08:58 UTC
I have also encountered this problem, and it is not something that I can get
around with xrandr.

I am using a Lenovo ThinkPad T60 with a docking station that provides it with
DVI output. Whenever i try to use a monitor (a DFP) connected through the DVI
port, I start the laptop with the monitor plugged in and turned on. The
external display is detected and used for regular console mode, but when I
start X both the laptop's built-in display and the external display are
used. (This is the case both when the laptop is open and when it is closed.)

My X desktop is cloned between both displays. The external display has a
native resolution lower than that of the laptop, so the desktop's lower
right-hand corner is cut off on the external monitor. I can turn off the LVDS
output with xrandr, but even after doing so I cannot change the output on the
external display because doing so brings the desktop resolution to one that is
lower than the resolution that the LVDS output likes to use. Here is an
example session with xrandr:

stu@rowena:~$ xrandr
Screen 0: minimum 320 x 200, current 1400 x 1050, maximum 1400 x 1400
VGA disconnected (normal left inverted right)
LVDS connected 1400x1050+0+0 (normal left inverted right) 287mm x 215mm
   1400x1050      60.0*+   50.0
   1280x1024      59.9
   1024x768       60.0
   800x600        60.3
   640x480        60.0     59.9
TMDS-1 connected 1280x1024+0+0 (normal left inverted right) 376mm x 301mm
   1280x1024      60.0*+   75.0     59.9
   1280x960       59.9
   1152x864       75.0     74.8
   1024x768       75.1     70.1     60.0
   832x624        74.6
   800x600        72.2     75.0     60.3     56.2
   640x480        75.0     72.8     66.7     60.0
   720x400        70.1
TV disconnected (normal left inverted right)
stu@rowena:~$ xrandr --output LVDS --off
              (Laptop internal display turns off)
stu@rowena:~$ xrandr --fb 1280x1024
              (Nothing happens)
stu@rowena:~$ xrandr --output LVDS --auto
              (Laptop internal display comes on)
stu@rowena:~$ xrandr --output TMDS-1 --off
              (External display turns off)
stu@rowena:~$ xrandr --output TMDS-1 --auto
              (External display comes back, clipped)
stu@rowena:~$ xrandr --fb 1280x1024
xrandr: specified screen 1280x1024 not large enough for output LVDS (1400x1050+0+0)



There are a few different configurations that I have tried to get around this
issue, but the only workaround I have found is to use a pre-2.0 driver
(currently 1.7.4). Things that I have tried include:

 - fiddling with xrandr (as described above)

 - using a blank or no xorg.conf (which autodetects things well)

 - writing explicity in xorg.conf not to use LVDS output (with things like
   Option "MonitorLayout" "DFP,none" and Option "Clone" "False")

 - telling the laptop in its BIOS to ignore the internal display when starting
   up with an external display attached

Something a bit odd that happens whenever I run xrandr with the external
display hooked up, it blanks for a few seconds, even when the LVDS output is
turned off.

I'm running xorg-server 1.3.0.0.

I will attach an Xorg.0.log in which I ran the xrandr commands above.
Comment 3 Stu Black 2007-08-25 10:10:14 UTC
Created attachment 11272 [details]
Xorg.0.log when lid is closed, DFP is connected, and xrandr is toyed with
Comment 4 Gordon Jin 2007-10-12 01:47:28 UTC
When I close lid or press lid button, the LVDS becomes darkened but not totally off.

Is this expected and we just suggest to use xrandr to disable LVDS, or shall we consider this as a bug to fix?
Comment 5 Eric Anholt 2007-10-12 12:26:01 UTC
Gordon: On lid switch, your BIOS should be turning off the panel entirely, including backlight.  The driver is not involved.  The bug I was talking about last night involved the x server getting an event on lid switch, doing dpms on, and turning the panel back on at that time just after the BIOS turned it off.

However, this bug is about initial LVDS configuration when the laptop is closed.  I'm not really sure what to do about this -- we have no way of reliably getting the information from the BIOS about the lid switch, as far as I know (jbarnes, is there opregion magic here?).  But even if we can it's nasty, because the user probably expects the panel to come on when they open the laptop again, so we have to configure the panel as enabled, but dpms it off, then hope that the BIOS would DPMS it on when lid switch happens.
Comment 6 Stu Black 2007-10-12 16:34:03 UTC
As a user, I would be pretty happy if there were just some way to force that a particular monitor (in this case, LVDS) be completely bypassed so that it isn't taken into consideration when sizing the screen.  (Forgive my ignorance if there really is some way to do that now; I have tried, as in my above post, to do just that in 2.x with no success.)  Of the 2.x drivers that I have tried (2.0.0, 2.1.0, and 2.1.1 in Gentoo Portage), all force me to start with the clipped screen on my external DFP even if I have Option "MonitorLayout" "DFP,NONE" and Option "Display" "DFP" in my video card's device section.

I am suggesting this workaround because it would at least let a user have different ServerLayouts for different monitor configurations in 2.x.  As far as I can determine, such is not currently possible.  (It is in 1.7.4.)
Comment 7 Eric Anholt 2007-10-15 11:26:04 UTC
See intel(4) and xorg.conf(5).  MonitorLayout doesn't exist.  Off the top of my head you want:

Options "Monitor-LVDS" "my lvds"

Section "Monitor"
  Identifier "my lvds"
  Option "Ignore" "TRUE"
EndSection
Comment 8 Jesse Barnes 2007-10-31 14:28:58 UTC
There may be a way of getting at the lid switch status using the IGD OpRegion extensions.  If so, we could disable the LVDS output if the lid switch indicated that the lid was closed.  Probably won't happen for the next release though.
Comment 9 ajax at nwnk dot net 2008-02-24 18:22:34 UTC
Mass reopen.  The "LATER" resolution is lame, I'm deleting it.  Consider LATER to have arrived.
Comment 10 Orion Poplawski 2008-09-29 09:06:00 UTC
*** Bug 17771 has been marked as a duplicate of this bug. ***
Comment 11 Orion Poplawski 2008-09-29 09:12:08 UTC
My current workaround.  Haven't tried the ignore suggestion yet.

Section "Device"
        Identifier  "Videocard0"
        Driver      "intel"
        Option      "Monitor-TMDS-1" "Dell"
EndSection


Section "Monitor"
        Identifier   "Dell"
        Option      "PreferredMode" "1600x1200"
EndSection
Comment 12 Orion Poplawski 2008-11-10 12:13:42 UTC
I'm also seeing many times when the external display will remain black.  It seems time and sometimes switching VTs will get it to come up.
Comment 13 Wang Zhenyu 2009-01-11 22:40:25 UTC
Please test with current git master which has added lid switch detection for LVDS based on acpi or bios info. The original bug should be fixed.
Comment 14 MaLing 2009-01-18 22:55:30 UTC
(In reply to comment #13)
> Please test with current git master which has added lid switch detection for
> LVDS based on acpi or bios info. The original bug should be fixed.

hi   Brice,

Could you try our latest version ?

Thanks
Ma Ling
Comment 15 MaLing 2009-02-02 05:32:43 UTC
ping Brice...

Thanks
Ma Ling
Comment 16 Brice Goglin 2009-02-02 06:05:23 UTC
I pingued the downstream bug reporter 2 weeks ago, no reply yet. I just pingued him again.
Comment 17 MaLing 2009-02-04 19:50:27 UTC
hi Brace,

I have tested, currently our driver may disconnect LVDS and connect external display when lid button is pressed. So I closed issue, you can reopen it if you find the issue still occurs.

Thanks
Ma Ling



Comment 18 Brice Goglin 2009-02-04 21:46:23 UTC
Could you clarify how you tested this? What does this "may" mean? Do we need to enable something in xorg.conf first?

I don't know about the original downstream bug reporter (he told me he will try soon), but on my Dell Latitude D420, Intel 2.6.1 doesn't seem to solve the original issue: if you boot with LVDS closed, LVDS is still enabled by default.

And you press the lid button after boot, LVDS seem to be DPMS-blanked only.
Comment 19 MaLing 2009-02-05 22:28:11 UTC
(In reply to comment #18)
> Could you clarify how you tested this? What does this "may" mean? Do we need to
> enable something in xorg.conf first?
don't need to enable anything to xorg.conf, "may" means I use external VGA, instead of DVI.

> I don't know about the original downstream bug reporter (he told me he will try
> soon), but on my Dell Latitude D420, Intel 2.6.1 doesn't seem to solve the
> original issue: if you boot with LVDS closed, LVDS is still enabled by default.
Yes, I tried as follows
1) laptop is on dock station connected with external VGA
2) boot laptop with closed panel, start Xorg, then run xrandr --verbose, it told me LVDS was disconnected and VGA was connected.

I will provide my xrandr --verbose and Xorg.log with Modedebug option.

Thanks
Ma Ling
Comment 20 MaLing 2009-02-05 22:31:44 UTC
Created attachment 22625 [details]
laptop_boot_with_closed_panel_xrandr_verbose
Comment 21 MaLing 2009-02-05 22:32:15 UTC
Created attachment 22626 [details]
laptop_boot_with_closed_panel.Xorg.0.log
Comment 22 Michael Fu 2009-02-08 21:44:04 UTC
(In reply to comment #18)
> 
> I don't know about the original downstream bug reporter (he told me he will try
> soon), but on my Dell Latitude D420, Intel 2.6.1 doesn't seem to solve the
> original issue: if you boot with LVDS closed, LVDS is still enabled by default.
> 
> 

Zhenyu's patch isn't pushed to 2.6.1 branch but in master. Ma Ling should have told you this...
Comment 23 Michael Fu 2009-02-12 15:16:29 UTC
*** Bug 19991 has been marked as a duplicate of this bug. ***
Comment 24 Gordon Jin 2009-03-31 23:52:48 UTC
*** Bug 20973 has been marked as a duplicate of this bug. ***
Comment 25 Gordon Jin 2009-03-31 23:57:05 UTC
reopening, since zhenyu's patch mentioned in comment#13 has been disabled for now:

New commits:
commit 4f046af760b92c07f59664359453933fb5358e3d
Author: Zhenyu Wang <zhenyu.z.wang@intel.com>
Date:   Tue Mar 31 13:49:44 2009 +0800

    Disable LVDS detect methods
    
    Both methods ACPI lid and SWF bit have issues in LVDS detect from
    wider testing. Fallback to origin code.
Comment 26 Michael Fu 2009-07-14 15:53:50 UTC
*** Bug 22751 has been marked as a duplicate of this bug. ***
Comment 27 Jesse Barnes 2009-07-27 18:57:03 UTC
My recent patchset adds this, but it needs quirks for platforms that have broken LID devices.
Comment 28 Martin Pitt 2009-07-29 06:11:21 UTC
I confirm that this is still an issue with Linux 2.6.31rc4 (KMS), and -intel 2.8.0, at least on my Dell Latitude D430 (GM945). I reported bug 22580 with detailled logs a while ago, and was now pointed to this master bug. I'll mark 22580 as a dupe. Thanks!
Comment 29 Martin Pitt 2009-07-29 06:11:40 UTC
*** Bug 22580 has been marked as a duplicate of this bug. ***
Comment 30 Martin Pitt 2009-07-30 00:30:40 UTC
Just in case it's helpful, this is how the lid could/should be handled under Linux at least:

 * State changes are propagated as input events. I. e. the /dev/input/eventX which belongs to the lid switch will emit a EV_SW/SW_LID event.

   But I guess you by and large just need to know the current status at startup, so you don't need to pay attention to lid events.

 * Current state can be retrieved with an ioctl on the input file (see
/usr/include/linux/input.h), something like:

        #include <linux/input.h>

        int f;
        long bitmask;
        int is_closed;

        /* open device file */
        f = open (device_file, O_RDONLY | O_NONBLOCK);
        /* do error handling here if f < 0 */

        if (ioctl (f, EVIOCGSW(sizeof (bitmask)), bitmask) < 0)
             /* error handling */

        is_closed = bitmask & (1 << SW_LID) > 0;

This is the approach which is also taken by hal and devicekit, and have been working for ages. I don't think it makes much sense to try and replicate the kernel detection in the X.org driver?
Comment 31 Wang Zhenyu 2009-07-30 01:42:13 UTC
The problem of this bug is that detecting lid status is hard and depends on manufacture's behavior. We have tried to use

- ACPI lid object, which is supposed to be the most generic interface for this, but we've seen failed laptops, which usually require to fix DSDT, or completely "un-fixable" (e.g lid status will only be correct after one lid switch action.)
- Vbios flag for lid status, which also showed failure pattern on some laptops.

So the problem is not in what kind of interface for X driver, but retrieving trusted lid status is hard. Now we just check ACPI lib object's existence but ignore its lid state, which actually helps on some eeetop like device, but not
for your requirement.
Comment 32 Martin Pitt 2009-07-30 02:52:22 UTC
BTW, in my duplicate bug 22580 I suspected something like this, if lid switch detection turns out to be too unreliable:

  "If that's too complicated, then maybe it could default to only using the
external, or only using the device with the largest resolution available, and
switch off the others? If you need them, you can still configure them with
xrandr, but IMHO the current default isn't very good."

"Current default": Right now, X.org picks 1024x768 on both of my screens (1280x800 internal LVDS, 1280x1024 on external DVI), thus 1024x768 does not fit on either. This introduces a lot of mode switches and looks pretty bad. An earlier version just kept whatever the kernel KMS detected and configured (which was the right thing IMHO).

However, as I said the Linux world and gnome-power-manager etc. have used the kernel's lid state ioctl() for years, so if that's broken in some cases, it should be fixed/worked around once in the kernel, instead of having X.org etc. implement all the ACPI/BIOS poking again.

Thanks!
Comment 33 ykzhao 2009-10-18 17:42:32 UTC
hi, Martin
    Will you please try the latest upstream kernel and see whether the issue still exists when the system is booted with KMS enabled?
   Thanks.
Comment 34 Martin Pitt 2009-10-20 07:13:39 UTC
I tested 2.6.32rc5, and this seems to by and large fix this now. In 2.6.31.3 I get

[    2.783416] [drm] TMDS-14: set mode 1280x1024 27
[    3.049739] [drm] LVDS-8: set mode 1280x800 28
[   39.475814] [drm] TMDS-14: set mode 1024x768 2a
[   39.972702] [drm] LVDS-8: set mode 1024x768 2b
[   72.064059] [drm] TMDS-14: set mode 1280x1024 27
[   72.556030] [drm] LVDS-8: set mode 1280x800 28

and thus X.org says

(II) intel(0): Output LVDS1 connected
(II) intel(0): Output DVI1 connected
(II) intel(0): Output TV1 disconnected
(II) intel(0): Output LVDS1 using initial mode 1024x768
(II) intel(0): Output DVI1 using initial mode 1024x768

while in 2.6.32rc5 I get

[    2.733633] [drm] TMDS-14: set mode 1280x1024 34

and X.org says

(II) intel(0): Output VGA1 disconnected
(II) intel(0): Output LVDS1 disconnected
(II) intel(0): Output DVI1 connected
(II) intel(0): Output TV1 disconnected
(II) intel(0): Using exact sizes for initial modes
(II) intel(0): Output DVI1 using initial mode 1280x1024

So when booting with lid closed, the internal LVDS stays off all the time, and DVI starts up with correct 1280x1024.

The drawback is that it's now impossible to reactivate the LVDS when opening the lid, so it requires a reboot when undocking. But this didn't really work in 2.6.31 either, so it's not a regression.

Thanks! 
Comment 35 Jesse Barnes 2009-10-21 05:42:53 UTC
When you re-open the lid, you should be able to xrandr the display back on.  If you have recent enough X server bits and the GNOME display manager running, it should even come back on automatically (depending on how you had it configured).
Comment 36 Martin Pitt 2009-10-21 08:31:40 UTC
> When you re-open the lid, you should be able to xrandr the display back on

I actually tried, but when I open the lid the DVI turns all black (I still see the mouse cursor, though), and the LVDS doesn't turn on. I don't seem to be able to recover from that with VT switching, lid closing, etc. But I still run X server 1.6.4, so perhaps that's fixed in a newer version.

Anyway, as I said that's much less of a hassle, and no regression, and not related to this bug report either. I'll test it with a newer X server at some point, and report a new bug if it still is an issue.

Thanks for resolving this one!
Comment 37 Keith Packard 2009-10-26 11:50:46 UTC
sounds like this is resolved as well as we can manage?
Comment 38 Gordon Jin 2010-06-01 19:08:51 UTC
This issue still exists in recent kernel. Reopening.
Comment 39 Orion Poplawski 2010-07-02 09:31:45 UTC
Seen with:

2.6.33.5-124.fc13.x86_64
01:00.0 VGA compatible controller: ATI Technologies Inc M56GL [Mobility FireGL V5250]

In this case the login screen is displayed on the closed LVDS display making things difficult.
Comment 40 Jesse Barnes 2010-07-02 09:37:53 UTC
Orion, you have an ATI issue, this one is for an Intel bug.

We've decided not to use lid status because we don't have a reliable way of getting it across all platforms.  So marking this one as WONTFIX.