Red Hat Bugzilla – Full Text Bug Listing
|Summary:||GDM use clone mode by default for multi-screen|
|Product:||[Fedora] Fedora||Reporter:||Pasi Karkkainen <pasik>|
|Component:||gdm||Assignee:||Ray Strode [halfline] <rstrode>|
|Status:||CLOSED NOTABUG||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||19||CC:||jglisse, jonathan, negativo17, rcollet, redhat, rstrode, uckelman, vanmeeuwen+fedora, xgl-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-05-15 10:48:48 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Pasi Karkkainen 2011-06-12 11:31:33 EDT
Description of problem: I'm reporting this against rawhide and hoping this could be solved for upcoming Fedora 16. I just tested Fedora 15 on my laptop (HP elitebook 8530p), and it seems "/proc/acpi/button/lid/LID/state" is still ignored by anaconda/Xorg in the Fedora installer.. So I have my laptop in the docking station with only external monitor in use. The laptop LID is closed so the internal LVDS panel is not in use at all. However, when I boot F15 installer live CD, the desktop/anaconda installer GUI is displayed only on the internal LVDS display under the closed LID ! The GUI should be obviously displayed on the external monitor instead, which is the only active display! "/proc/acpi/button/lid/LID/state" works OK on this laptop and shows properly if the lid is open or closed. Version-Release number of selected component (if applicable): Fedora 15. How reproducible: Always. Steps to Reproduce: 1. Attach the laptop to a docking station, have the laptop lid closed, and use (only) external (DVI) monitor. 2. Boot Fedora 15 live CD. Actual results: Livecd desktop/installer is displayed on the laptop (non-visible) internal LVDS panel under the closed LID! Expected results: desktop/installer should be displayed on the external monitor instead. (Or both the displays should be in clone mode). Additional info: This has been discussed many times here on redhat bugzilla and on various dri/drm/kms related mailinglists. The proper way to deal with this is to check the ACPI LID state from /proc and do the right thing based on it. ACPI LID state works properly on this laptop.
Comment 1 Pasi Karkkainen 2011-06-12 11:37:10 EDT
Hmm, actually I guess the
Comment 2 Pasi Karkkainen 2011-06-12 11:37:37 EDT
.. component should be xorg, so changed to that.
Comment 3 Pasi Karkkainen 2011-06-13 03:19:37 EDT
Additional info: the laptop in question has ATI Radeon graphics (RV635).
Comment 4 Pasi Karkkainen 2011-06-13 03:56:43 EDT
Erm, I meant Radeon HD3650.
Comment 5 Matěj Cepl 2011-06-17 12:25:05 EDT
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please add drm.debug=0x04 to the kernel command line, restart computer, and attach * your X server config file (/etc/X11/xorg.conf, if available), * X server log file (/var/log/Xorg.*.log) * output of the dmesg command, and * system log (/var/log/messages) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Comment 6 Pasi Karkkainen 2011-06-19 09:56:17 EDT
Created attachment 505455 [details] F15 live CD kernel dmesg with drm.debug=0x04
Comment 7 Pasi Karkkainen 2011-06-19 09:56:51 EDT
Created attachment 505456 [details] F15 live CD Xorg.0.log
Comment 8 Pasi Karkkainen 2011-06-19 09:57:17 EDT
Created attachment 505457 [details] F15 live CD /var/log/messages
Comment 9 Pasi Karkkainen 2011-06-19 10:04:07 EDT
Ok, attachments added. There's no "/etc/X11/xorg.conf" on the Fedora 15 live CD. dmesg does not have everything from the beginning of boot because drm.debug=0x04 causes so much spam that the beginning of the kernel log buffer gets overwritten or something. Additional info: "/proc/acpi/button/lid/LID/state" works OK on this laptop, it says "open" if the LID is open, or "closed" it the LID is closed. From https://bugzilla.redhat.com/show_bug.cgi?id=595644 : 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 I checked the gconf settings with gconf-editor, and there's no /apps/gnome_settings_daemon/xrandr/ on the Fedora 15 live CD .. So maybe this issue is revolved just by adding those xrandr gconf settings ?
Comment 10 Pasi Karkkainen 2011-06-19 10:06:07 EDT
NOTE: When I captured the logs the laptop lid was initially closed, but because in the end of the livecd boot process the primary desktop was displayed under the closed lid I had to actually open the laptop lid to be able to login to livecd/gnome and capture the logs.
Comment 11 Pasi Karkkainen 2011-06-19 10:39:14 EDT
Created attachment 505462 [details] F15 live CD dmesg with default boot/kernel options
Comment 12 Pasi Karkkainen 2011-06-19 11:01:14 EDT
Oh, one more thing. RHEL 6.1 Workstation seems to do the right thing on this laptop! I tried the rhel61 ws installer DVD and it doesn't try to display the desktop under the closed lid! Instead it uses only the external monitor, just like it should be doing.
Comment 13 Jérôme Glisse 2011-06-20 09:40:01 EDT
Not sure we can do anything, lid status have been so unreliable on so many laptop that we ignore what it reports.
Comment 14 Pasi Karkkainen 2011-06-20 09:44:35 EDT
Why not use clone-mode then? Instead of expanding the desktop to all displayes.. Using clone-mode would make this issue go away! (=every display shows the same image).
Comment 15 Robert Hoekstra 2011-07-03 03:45:45 EDT
The problem does not only occur on livecd boot with anaconda. I am running Fedora 15 (upgraded using preupgrade from 14 -> 15). I too am using the EliteBook 8530p. Is the issue ATI bound? Or HP bound? At startup, with only internal lid, all works as expected. Though, when docked, external DVI display attached and the lid closed, the gdm greeter shows its information on the internal display (the external display gets the extended desktop background). So I have to open the lid if I want to see the login dialogue. There are so many exclusions in many different modules (like the blacklisting for video devices on different hardware using standby and hibernate). could such a list be initiated to know whether to ignore or trust the lid status indicator? Just a thought. It appears clumsy for an OS to show the logon screen on an internal display that is actually closed, so I would guess it doesn't suffice to just say 'not sure we can do anything about it' ? If there is any information I need to provide to help any further, please let me know. Thanks.
Comment 16 Pasi Karkkainen 2011-07-04 10:39:54 EDT
Yep, improvements definitely should be done on this area. - In the installer/livecd: Use clone-mode as a default, not "extended desktop". User can manually enable "extended desktop" if he wants it. - Is ACPI lid state still broken nowadays? Was it broken because of kernel/driver bugs or due to BIOS/ACPI/firmware bugs? ACPI LID state definitely works on my laptops.
Comment 17 Jérôme Glisse 2011-07-05 10:22:05 EDT
Matthew would know a lot more on the brokeness. But the issue is with the bios (buggy bios) so nothing we can do. Some bios report lid open when it's close, and close when it's open, other report always open or always close ... AFAIK windows driver have other way to figure it out but it's very likely to be specific to each laptop model.
Comment 18 Pasi Karkkainen 2011-07-05 10:32:45 EDT
Ok. Well shouldn't we use 'clone' mode as a default then, and not 'extended', if there's nothing we can do about the lid status.. ?
Comment 19 Jérôme Glisse 2012-02-21 17:01:42 EST
Assigning to gdm as it's more a gdm issue. ie user when clone mode to be default when gdm face multi-screen
Comment 20 Remi Collet 2012-10-19 09:29:32 EDT
Same issue. gdm-3.6.1-1.fc18 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) Bios configured to use the "Dock external digital #1 display" $ cat /proc/acpi/button/lid/LID/state state: closed The gdm login screen appear on the monitor where the mouse is... Which can be the internal monitor, even if the lip is closed. Only a gdm issue. Gnome shell works as expected. Workaround : move the mouse before to the external monitor before the login screen appear...
Comment 21 Remi Collet 2013-02-27 04:33:58 EST
It seems latest f18 updates have fix this issue.
Comment 22 Simone Caronni 2013-05-28 02:51:59 EDT
Hello, I have a similar problem with Fedora 19; GDM always sets clone mode even if the xorg.conf explicitly disables that. Don't know if it's related or not with this bug. I've configured my dual monitor setup for my docket laptop with the lid closed. I've configured X to start with an extended desktop only on the external monitors. "xinit" or direct X commands work as expected, but GDM always clones the login on all monitors and the only way to fix it is to launch xrandr again. Please note that with Fedora 18 this is working as expected. NOUVEAU: Section "Device" Identifier "Videocard0" Driver "nouveau" Option "NoLogo" "true" EndSection Section "Monitor" Identifier "VGA-0" EndSection Section "Monitor" Identifier "DP-1" Option "RightOf" "VGA-0" EndSection NVIDIA: Section "Device" Identifier "Device0" Driver "nvidia" Option "NoLogo" "true" EndSection Section "Screen" Identifier "Screen0" Device "Device0" Option "nvidiaXineramaInfoOrder" "CRT-0" Option "metamodes" "CRT: nvidia-auto-select +0+0, DFP-2: nvidia-auto-select +1680+0" EndSection If I issue a "startx" from my logged in user I have the correct behaviour (extended desktop); if I run GDM I always have a cloned output. Should I file another bug? Thanks & regards, --Simone
Comment 23 Simone Caronni 2014-05-15 10:48:48 EDT
Working fine in Fedora 20.