Bug 595644 - internal LCD under the closed lid used as primary display
Summary: internal LCD under the closed lid used as primary display
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-settings-daemon
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Bastien Nocera
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: card_965GM
Depends On: 531219
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-25 09:27 UTC by Dan Horák
Modified: 2010-12-17 15:14 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 531219
Environment:
Last Closed: 2010-11-05 16:34:43 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
/var/log/gdm/:0.log (54.36 KB, text/plain)
2010-05-25 09:30 UTC, Dan Horák
no flags Details

Description Dan Horák 2010-05-25 09:27:18 UTC
It's back ...

kernel-2.6.33.4-95.fc13.x86_64
xorg-x11-server-Xorg-1.8.0-12.fc13.x86_64
xorg-x11-drv-intel-2.11.0-4.fc13.x86_64

+++ This bug was initially created as a clone of Bug #531219 +++

Created an attachment (id=366235)
Xorg.log from GDM

Description of problem:
X starts with the internal (but the lid is closed) LCD as primary and external LCD as secondary. I need to open the lid, now see the gdm login page there and then some flickering occurs and then both displays have the same content (internal is cloned after external). No xorg.conf is used.

Version-Release number of selected component (if applicable):
xorg-x11-drv-intel-2.9.0-2.fc12.x86_64
kernel-2.6.31.5-96.fc12.x86_64

also tried
xorg-x11-drv-intel-2.9.1-1.fc12
kernel-2.6.31.5-96.fc12.x86_64

How reproducible:
always


Steps to Reproduce:
1. start the computer
  
Actual results:
gdm login screen shown on the internal LCD


Expected results:
gdm login screen shown on the external LCD


Additional info:
The machine is Lenovo T61 placed in the docking station, external LCD is connected via DVI.

--- Additional comment from dan on 2009-10-27 07:15:23 EDT ---

The system was recently upgraded to F-12 from F-10, where the displays worked as expected.

--- Additional comment from mcepl on 2009-11-05 12:19:26 EST ---

Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages (at least F12Beta, but even better if the very latest versions).

Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you.

If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.

[This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.]

--- Additional comment from dan on 2009-11-06 11:33:00 EST ---

I have fully updated my laptop today and there is no change in the described behaviour.

--- Additional comment from fedora-triage-list on 2009-11-16 09:24:31 EST ---


This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from uckelman on 2009-11-20 22:09:45 EST ---

I'm seeing precisely the same problem with F12 and a docked Thinkpad T61 with an external CRT. In F11 and before, if I booted with the laptop in the dock and the lid closed, the CRT would be made the sole display. In F12 what I'm seeing is that both the CRT and laptop panel are active, with the laptop panel as the primary display, despite that the lid is closed. Afterwards, when I try to close the lid, my laptop goes into suspend (!) which never happened before when an external monitor was connected.

Possibly related is the fact the detection of the resolution capabilities of my external monitor also broken when I upgraded from F11 to F12, which I've reported as Bug 539785.

If there's any more information I can provide, please let me know. These two problems combined are making work with my laptop rather unpleasant.

--- Additional comment from timo.sorvoja on 2010-04-09 15:27:54 EDT ---

I can confirm that this also happens with Dell Latitude D610 wih docking station.

--- Additional comment from dan on 2010-04-16 08:10:05 EDT ---

The issue was probably resolved with the update to xorg-x11-server-Xorg-1.7.6-1.fc12, because it doesn't happen with an up-to-date laptop anymore.

--- Additional comment from uckelman on 2010-04-16 08:23:17 EDT ---

I'm not seeing this problem anymore with the current xorg.

--- Additional comment from dan on 2010-04-16 08:33:52 EDT ---

Switching to xorg-x11-server and closing.

Comment 1 Dan Horák 2010-05-25 09:30:54 UTC
Created attachment 416334 [details]
/var/log/gdm/:0.log

Comment 2 Joel Uckelman 2010-05-26 20:24:00 UTC
I can confirm that I'm seeing this behavior again with my Thinkpad T61 when booting with the Fedora 13 x86_64 Live CD.

Comment 3 Nunatak 2010-07-08 18:51:15 UTC
I have the same problem. Lenovo X200 (Intel GM45 Chipset) with dockstation. Fresh install (Fedora-13-x86_64-DVD.iso) with updates


-- 

kernel-2.6.33.5-124.fc13.x86_64


xorg-x11-drv-synaptics-1.2.2-6.fc13.x86_64
xorg-x11-drv-voodoo-1.2.3-2.fc13.x86_64
xorg-x11-drv-mutouch-1.2.1-6.fc13.x86_64
xorg-x11-server-Xorg-1.8.2-1.fc13.x86_64
xorg-x11-drv-acecad-1.4.0-3.fc13.x86_64
xorg-x11-drv-hyperpen-1.3.0-4.fc13.x86_64
xorg-x11-drv-openchrome-0.2.904-2.fc13.x86_64
xorg-x11-utils-7.4-9.fc13.x86_64
xorg-x11-drv-void-1.3.0-5.fc13.x86_64
xorg-x11-drv-sis-0.10.2-2.fc13.x86_64
xorg-x11-drv-vmmouse-12.6.9-2.fc13.x86_64
xorg-x11-xauth-1.0.2-7.fc12.x86_64
xorg-x11-drv-sisusb-0.9.3-2.fc13.x86_64
xorg-x11-drv-fbdev-0.4.1-3.fc13.x86_64
xorg-x11-drv-intel-2.11.0-5.fc13.x86_64
xorg-x11-drivers-7.3-14.fc13.x86_64
xorg-x11-fonts-ISO8859-1-100dpi-7.2-9.fc12.noarch
xorg-x11-drv-cirrus-1.3.2-2.fc13.x86_64
xorg-x11-drv-nv-2.1.15-5.fc13.x86_64
xorg-x11-apps-7.4-14.fc13.x86_64
xorg-x11-drv-i128-1.3.3-2.fc13.x86_64
xorg-x11-drv-savage-2.3.1-2.fc13.x86_64
xorg-x11-drv-nouveau-0.0.16-7.20100423git13c1043.fc13.x86_64
xorg-x11-drv-evdev-2.4.0-2.fc13.x86_64
xorg-x11-drv-aiptek-1.3.0-3.fc13.x86_64
xorg-x11-drv-glint-1.2.4-2.fc13.x86_64
xorg-x11-drv-rendition-4.2.2-5.fc13.x86_64
xorg-x11-drv-i740-1.3.2-2.fc13.x86_64
xorg-x11-drv-mga-1.4.11-2.fc13.x86_64
xorg-x11-drv-apm-1.2.2-1.fc12.x86_64
xorg-x11-drv-penmount-1.4.0-6.fc13.x86_64
xorg-x11-drv-ati-6.13.0-1.fc13.x86_64
xorg-x11-drv-keyboard-1.4.0-4.fc13.x86_64
xorg-x11-xkb-utils-7.4-7.fc13.x86_64
xorg-x11-xinit-1.0.9-16.fc13.x86_64
xorg-x11-font-utils-7.2-11.fc13.x86_64
xorg-x11-drv-trident-1.3.3-2.fc13.x86_64
xorg-x11-drv-v4l-0.2.0-4.fc13.1.x86_64
xorg-x11-drv-mouse-1.5.0-4.fc13.x86_64
xorg-x11-resutils-7.1-10.fc13.x86_64
xorg-x11-drv-wacom-0.10.6-4.fc13.x86_64
xorg-x11-drv-vesa-2.3.0-1.fc13.x86_64
xorg-x11-drv-siliconmotion-1.7.3-3.20100122.fc13.x86_64
xorg-x11-drv-vmware-10.16.7-3.fc13.x86_64
xorg-x11-drv-dummy-0.3.3-2.fc13.x86_64
xorg-x11-drv-ast-0.89.9-1.fc12.x86_64
xorg-x11-server-utils-7.4-16.fc13.x86_64
xorg-x11-server-common-1.8.2-1.fc13.x86_64
xorg-x11-drv-elographics-1.2.4-1.fc13.x86_64
xorg-x11-drv-r128-6.8.1-3.fc13.x86_64
xorg-x11-drv-s3virge-1.10.4-2.fc13.x86_64
xorg-x11-drv-mach64-6.8.2-2.fc13.x86_64
xorg-x11-drv-tdfx-1.4.3-2.fc13.x86_64
xorg-x11-drv-fpit-1.3.0-10.fc13.x86_64

Comment 4 Bob Kennedy 2010-08-18 09:57:13 UTC
Same behaviour on a Dell E6500 with docking station. Laptop display used as primary display when docked. I upgraded from FC11 to FC13. In FC11 it worked fine. After the update (performed update while docked) an empty desktop was shown on the external display. I then discovered that the lcd display was on. No solution found yet.

Comment 5 Timo Sorvoja 2010-08-18 17:26:44 UTC
Same behaviour found with Dell Latitude D610 with docking station. Same symptoms as in comment 4.

Comment 6 Bob Kennedy 2010-08-20 13:43:27 UTC
Extra info:
on startup the lcd of the laptop is switched off, external monitor connected to docking station is on and shows startup screen. When login is shown, internal display switches on. I can login. Menu bar etc is then only shown on internal display. External display shows an empty desktop (extension of internal display to right, I think). 

A workaround to use the external monitor:
Open the laptop lid, both internal and external display show same desktop in 1024 x 768. With the screen config tool, select the external display, correct the resolution, switch of the internal display. No ideal, but at least  can use my external monitor / keyboard.

(Dell E6500 with docking station and Dell external Lcd connected with DVI)

Comment 7 Bob Kennedy 2010-08-21 21:06:34 UTC
Extra info:
After configuration as described in comment 6, the laptop display is switched on with proper resolution when used undocked, the external display is used with proper resolution when using docked and laptop display is automatically switched off.
When docked, I saw that both displays were switched on during login, afterwards the laptop display switched off again.

Comment 8 Pasi Karkkainen 2010-09-04 10:12:04 UTC
Any news about this? I'm seeing the same problem on my HP EliteBook 8530p (Radeon 3650HD).

Details: I have the laptop in the docking station, laptop lid closed, and only external DVI monitor in use. BIOS and grub show up on the external monitor OK, I choose the Fedora 13 kernel and it boots up using the external DVI monitor. 

Then gdm starts, and I get the login prompt on the external DVI monitor. All fine so far. After logging in the internal laptop lvds display gets turned on, and the gnome desktop stuff shows ONLY on the laptop internal lvds, but because I have the lid closed I don't see it.. external monitor only has the background image, nothing more.

What's the component misbehaving here? gdm? Xserver? some session-manager?

Comment 9 Bob Miller 2010-09-05 14:02:03 UTC
Dell Latitude D630 running FC13

Plug my computer into a docking station, or attach an external monitor to the rear port.  

Start FC13.

When the log-on screen appears, the external monitor display is being positioned to the right of the LCD. I can tell this by dragging my mouse pointer across the screen left to right. The log-on widget is not visible on the external monitor. The LCD is active, even with the lid closed and plugged into a docking station. 

Log-in. With the external monitor attached I can see the log-in widget on the laptop screen. When attached to a docking station, I just type the password blind.

KDE starts. The external monitor is still positioned to the right of the LCD display, which can be verified by running xrandr or just dragging the mouse.

Use the Fn-F8 button to turn-off the LCD display and use only the external monitor.


Note that:
In FC11, the LCD display was not active when the laptop was docked.
In FC12, the LCD display WAS active when docked; but at least the displays (LCD and external) were on top of each other so the log-in widget was visible.

The only bright stop is that in FC13 the Fn-F8 combo now works.

Comment 10 aNDy 2010-09-09 09:55:10 UTC
Similar problem with minor variants and additional info:

HP nc8430 notebook in docking station, external hp1940 monitor 
ATI Radeon Mobility x1600 card
fedora's radeon driver

- gdm greeter appears on the wrong display, but if I click  on the background and press enter then the greeter is moved to external monitor and I can log in. The resolution is still wrong and the additional options as desktop manager selection (KDE/Gnome), keyboard, etc. are off-screen.

- KDE starts in the wrong (primary display's) resolution. I have to manually set it with xrandr.

- If I use the standard vesa driver these problems don't occur.

- I upgraded for Fedora 11, where everything worked fine.

Comment 11 Pasi Karkkainen 2010-09-19 11:23:49 UTC
Is it X server that is broken here? Or is it GDM? Or something else? 

Someone familiar with this stuff please give some hints so we can try to figure this out..

Comment 12 Pasi Karkkainen 2010-09-19 12:32:26 UTC
I did some debugging and figured out something.. I added these commands to rc.local so that they get executed before GDM starts up:

cat /proc/acpi/button/lid/LID/state
cat /sys/class/drm/card0/card0-LVDS-1/status
cat /sys/class/drm/card0/card0-LVDS-1/enabled

And the result was:

lid/state: closed
lvds1/status: connected
lvds1/enabled: enabled

So things are wrong already before GDM starts.. Is it plymouth enabling the internal lvds even when the lid is closed, or is the driver always enabling the lvds even when the lid is closed?

Comment 13 Dan Horák 2010-09-19 12:43:15 UTC
(In reply to comment #11)
> Is it X server that is broken here? Or is it GDM? Or something else? 
> 
> Someone familiar with this stuff please give some hints so we can try to figure
> this out..

I think it's the xserver what makes the problem, see my comment 7 in the original bug #531219, but it's true that I looked primarily what changed in the xorg-* packages and not at e.g. gdm.

Comment 14 Pasi Karkkainen 2010-09-19 14:21:55 UTC
(In reply to comment #13)
> 
> I think it's the xserver what makes the problem, see my comment 7 in the
> original bug #531219, but it's true that I looked primarily what changed in the
> xorg-* packages and not at e.g. gdm.

I'm not sure..

I just verified and there's no X or GDM running when the LVDS is listed as enabled.. during rc.local execution, that is.

So I guess it leaves.. plymouth or the driver itself?

Comment 15 Pasi Karkkainen 2010-09-19 15:00:19 UTC
So I did more investigations.. I'm currently using 2.6.34.6-47.fc13.x86_64 kernel.

I hacked the initrd scripts to display debugging information from /proc right after drm modules are loaded, and *before* plymouth is started.

The results:

acpi lid/state: closed
lvds-1/status: connected
lvds-1/enabled: enabled

So it seems the drm/kms *driver* enables the internal LVDS even when the lid is closed!

Comment 16 Pasi Karkkainen 2010-09-19 17:03:15 UTC
And I forgot to mention I have ATI radeon 3650hd in my laptop.

Comment 17 Pasi Karkkainen 2010-10-03 13:38:12 UTC
I was discussing this with Alex Deucher (radeon/drm driver developer) and he confirmed this is expected behaviour, the internal LVDS is always reported as 'connected' so it's also always enabled.

It's up to the userspace to check the ACPI lid status and disable/enable outputs based on that.

So this is a 'feature' in the driver, and the proper decisions should be made by userspace components.. plymouth/gdm/Xorg/gnome-power-manager or something..

Comment 18 Orion Poplawski 2010-10-04 15:58:00 UTC
This really needs to not just be a Gnome thing, but distro wide.

Comment 19 Bastien Nocera 2010-11-05 16:34:43 UTC
Filed upstream: https://bugzilla.gnome.org/show_bug.cgi?id=634097

For F14 (with gnome-settings-daemon 2.32.0-2), you can:
Set /apps/gnome_settings_daemon/xrandr/use_xorg_monitor_settings to FALSE
Set /apps/gnome_settings_daemon/xrandr/turn_on_external_monitors_at_startup to TRUE
Set /apps/gnome_settings_daemon/xrandr/turn_on_laptop_monitor_at_startup to FALSE

Which would turn off the internal screen, and turn on the external screen, if there's more than one monitor available.

Comment 20 Pasi Karkkainen 2010-11-06 12:48:13 UTC
Ok, thanks!

Comment 21 Dan Horák 2010-12-17 12:04:07 UTC
Does the setting from comment #19 affect also where the initial gdm dialog is displayed?

Comment 22 Bastien Nocera 2010-12-17 14:16:14 UTC
(In reply to comment #21)
> Does the setting from comment #19 affect also where the initial gdm dialog is
> displayed?

If you set it as the default for the whole system, yes (right-click, "set as default").

Comment 23 Dan Horák 2010-12-17 15:14:38 UTC
It really works, thanks!


Note You need to log in before you can comment on or make changes to this bug.