Bug 595644
Summary: | internal LCD under the closed lid used as primary display | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Dan Horák <dan> | ||||
Component: | gnome-settings-daemon | Assignee: | Bastien Nocera <bnocera> | ||||
Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 13 | CC: | ajax, bnocera, bobkennedy, iarnell, nunatak.dj, olaf.greis, orion, pasik, philosophy, robert.b.miller, rstrode, stanec, timo.sorvoja, uckelman, xgl-maint | ||||
Target Milestone: | --- | Keywords: | Triaged | ||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | card_965GM | ||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | 531219 | Environment: | |||||
Last Closed: | 2010-11-05 16:34:43 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | 531219 | ||||||
Bug Blocks: | |||||||
Attachments: |
|
Description
Dan Horák
2010-05-25 09:27:18 UTC
Created attachment 416334 [details]
/var/log/gdm/:0.log
I can confirm that I'm seeing this behavior again with my Thinkpad T61 when booting with the Fedora 13 x86_64 Live CD. 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 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. Same behaviour found with Dell Latitude D610 with docking station. Same symptoms as in comment 4. 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) 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. 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? 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. 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. 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 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? (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. (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? 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! And I forgot to mention I have ATI radeon 3650hd in my laptop. 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.. This really needs to not just be a Gnome thing, but distro wide. 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. Ok, thanks! Does the setting from comment #19 affect also where the initial gdm dialog is displayed? (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"). It really works, thanks! |