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.
Created attachment 10559 [details] Xorg.0.log when lid is closed and VGA is connected
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.
Created attachment 11272 [details] Xorg.0.log when lid is closed, DFP is connected, and xrandr is toyed with
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?
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.
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.)
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
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.
Mass reopen. The "LATER" resolution is lame, I'm deleting it. Consider LATER to have arrived.
*** Bug 17771 has been marked as a duplicate of this bug. ***
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
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.
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.
(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
ping Brice... Thanks Ma Ling
I pingued the downstream bug reporter 2 weeks ago, no reply yet. I just pingued him again.
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
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.
(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
Created attachment 22625 [details] laptop_boot_with_closed_panel_xrandr_verbose
Created attachment 22626 [details] laptop_boot_with_closed_panel.Xorg.0.log
(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...
*** Bug 19991 has been marked as a duplicate of this bug. ***
*** Bug 20973 has been marked as a duplicate of this bug. ***
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.
*** Bug 22751 has been marked as a duplicate of this bug. ***
My recent patchset adds this, but it needs quirks for platforms that have broken LID devices.
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!
*** Bug 22580 has been marked as a duplicate of this bug. ***
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?
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.
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!
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.
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!
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).
> 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!
sounds like this is resolved as well as we can manage?
This issue still exists in recent kernel. Reopening.
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.
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.
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.