Bug 712706

Hmm, actually I guess the

.. component should be xorg, so changed to that.

Additional info: the laptop in question has ATI Radeon graphics (RV635).

Erm, I meant Radeon HD3650.

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.

Created attachment 505455 [details]
F15 live CD kernel dmesg with drm.debug=0x04

Created attachment 505456 [details]
F15 live CD Xorg.0.log

Created attachment 505457 [details]
F15 live CD /var/log/messages

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 ?

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.

Created attachment 505462 [details]
F15 live CD dmesg with default boot/kernel options

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.

Not sure we can do anything, lid status have been so unreliable on so many laptop that we ignore what it reports.

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).

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.

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.

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.

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.. ?

Assigning to gdm as it's more a gdm issue. ie user when clone mode to be default when gdm face multi-screen

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...

It seems latest f18 updates have fix this issue.

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

Working fine in Fedora 20.