Bug 835158

I don't want to pre-empt the maintainer's reply, as I may be missing some information, but AIUI this isn't a gdm bug and arguably isn't a bug at all.

Essentially what's missing here is an 'apply system-wide' box in the Displays applet. That should be filed as an RFE with GNOME upstream (if it isn't filed already, which it probably is; I know the GNOME team is aware of it in a general sense).

It can't be safely assumed that any settings any user picks in the Display applet should be applied system-wide (which includes the gdm screen). They can only safely be assumed to be _that particular user's personal preferences_. This is why they're applied only to that user's desktop session, not system-wide. So that's not a bug, it's intentional.

An 'apply systemwide' button, requiring root authentication, would make sense, but the lack of it isn't really a bug, it's just a possible feature which hasn't been written yet.

You can configure display priority, layout, orientation and so on system-wide on a per-boot basis using xrandr, or more permanently in xorg.conf (or xorg.conf.d snippets). I find http://wiki.debian.org/XStrikeForce/HowToRandR12 a useful reference for the appropriate syntax.

(In reply to comment #1)
> I don't want to pre-empt the maintainer's reply, as I may be missing some
> information, but AIUI this isn't a gdm bug and arguably isn't a bug at all.
> 
> Essentially what's missing here is an 'apply system-wide' box in the
> Displays applet. That should be filed as an RFE with GNOME upstream (if it
> isn't filed already, which it probably is; I know the GNOME team is aware of
> it in a general sense).

This is not the only issue described by the bug reporter. Showing GDM on the laptop display when it is closed does not make any sense as a default behaviour.
IMHO the internal display should just be off when the notebook is closed and docked. But maybe this is not just GDM specific as I also noted that anaconda and the welcome screen start on the internal closed display when using the Live install method after booting a docket notebook with closed lid.

Till: I believe the usual explanation for that is that ACPI lid detection is considered fundamentally unreliable; it's just broken on too many systems. That's why it's not taken into account in considering displays 'active' or not.

(In reply to comment #3)
> Till: I believe the usual explanation for that is that ACPI lid detection is
> considered fundamentally unreliable; it's just broken on too many systems.
> That's why it's not taken into account in considering displays 'active' or
> not.

But it is taken into account for power management, i.e. when opening and closing the lid, the notebook suspends by default (which is also annoying when using a docking station and being forced to open the lid, because the external monitor displays nothing). Therefore for a uniform user experience it should be either considered or not.

This message is a reminder that Fedora 17 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 17. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '17'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 17's end of life.

Bug Reporter:  Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 17 is end of life. If you 
would still like  to see this bug fixed and are able to reproduce it 
against a later version  of Fedora, you are encouraged  change the 
'version' to a later Fedora version prior to Fedora 17's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Worked in F18, is broken in F19 again.

Might be releated to

https://bugzilla.redhat.com/show_bug.cgi?id=876134
https://bugzilla.gnome.org/show_bug.cgi?id=709062

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Worked in F24 andd F25 perfectly, but it´s happening in F26 alpha again.

While docked and lid closed, GDM and desktop shows up on the disabled internal display.

This is broken for me on F25 using 4.10.10, but not using 4.10.8.

I use a Thinkpad E470 with external HDMI monitor. If I start the system and close the lid (or if I reboot the system working on external display only and with lid closed), desktop appears on both displays, but GDM shows up only on the disabled internal display.

My system is Fedora 26 Alpha with Linux 4.11.0-0.rc7.git0.1.fc26.x86_64.

Same issue here, starting around kernel 4.10.10 on Fedora 25 and Lenovo T450s with docking station and an external display through DisplayPort (Dell U2915WM).

Same issue for me to since Fedora 25 moved to Kernel 4.10.*
If i disable Wayland in /etc/gdm/custom.conf it works as supposed.
Im working on an Thinkpad X230. I only have this problem when the thinkpad is docked (2*Dell UH2715) and the lid is closed.

I'm seeing this issue as well. Docked Thinkpad t460s with 2 monitors. On kernel 4.10.8, everything works as expected. However, when booting into 4.10.11, 4.10.12, or 4.10.13 I get just a blank gray screen instead of my login options.

Just another confirmation that recently (around the time of the move to the 4.10.* kernel) this issue reappeared on my Dell Latitude e5470 with 2 external monitors and the lid always kept closed. The GDM login appears on the closed laptop screen.  after logging in, I can close the lid again and everything shifts to the two correct monitors.

For me with full disk encryption it helps to open and close the lid during the disk encryption prompt.

This appears to have been fixed for me today when I pulled in kernel 4.11.4-200.fc25.x86_64.

Indeed, fixed by commit 4c5681afdf984b5eec41b280d43b9934af0f3144 for Kernel 4.11.4

Perfect.