Created attachment 987685 [details] X log file written out by anaconda-22.17-1.fc22 Description of problem: For the current development tree, only a white screen appears on the external monitor attached to the docking station of a (docked) Lenovo ThinkPad T400 after booting up even when the lid is closed. After opening the lid it turns out that the installer screen is actually shown on the internal display which should have been disabled altogether. Version-Release number of selected component (if applicable): anaconda-22.17-1.fc22 How reproducible: Always. Steps to Reproduce: 1. Boot from netinst boot image. Actual results: After displaying the first stages of the boot procedure on the external monitor, only a white screen is shown after the system has launched the graphical installer. Expected results: The installer screen should appear on the external monitor attached to the docking station and not on the internal display when the lid is closed. Additional info: This used to work for Fedora 21.
This bug appears to have been reported against 'rawhide' during the Fedora 22 development cycle. Changing version to '22'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora22
Issue still present for anaconda-22.20.4-1.fc22.
As opposed to the netinst installer, the X session starts up correctly on the external monitor when booting into a live session. Therefore, it is probably an anaconda issue rather than an X issue.
Created attachment 1002885 [details] X log file written out by X server 1.17.1 of the Fedora 22 Beta TC2 live system
Issue still present for anaconda-22.20.11-1.fc22 and the Fedora 22 TC1 netinst boot image.
Issue still present for anaconda-22.20.12-1.fc22 and the Fedora 22 TC4 netinst boot image. The internal display is switched off but the installer nevertheless sets up a dual monitor configuration mapping the installer screen to the internal display. It is possible to move the mouse pointer from the (invisible) internal display to the attached external display which merely shows a white background. After opening the lid, the backlight is turned on, and the install can proceeed a expected using the internal display.
When the (invisible) mouse pointer is moved immediately from the area off-screen (internal display) to the external display as soon as the grey background appears, then the installer window is correctly opened on the external display. Otherwise it will appear on the internal display.
This issue also affects the Fedora 22 RC3 netinst image featuring anaconda-22.20.12-1.fc22 and (can/will) not be addressed once Fedora 22 has been released. It should therefore be investigated as soon as possible.
(In reply to Joachim Frieben from comment #3) > As opposed to the netinst installer, the X session starts up correctly on > the external monitor when booting into a live session. Therefore, it is > probably an anaconda issue rather than an X issue. Reassigning to the window manager used in netinst, then.
Bug also affects the branched tree of Fedora 23 including packages anaconda-23.19.1-1.fc23 and metacity-3.12.0-3.fc23.
Issue still around for Fedora 23 RC3 including anaconda-23.19.10-1.fc23 and metacity-3.12.0-3.fc23.
Issue still around for the Fedora development tree including anaconda-24.9-1.fc24 and metacity-3.12.0-3.fc23.
Similarly, the current Fedora 23 Mate spin erroneously enables the internal display of a Lenovo ThinkPad T400 notebook even when the system is docked as reported in bug 1298700. The window manager marco v1.2.1 is a derivative of metacity.
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Issue (still) applies to both of Fedora development 24 and 25 (rawhide) including packages: - anaconda-24.13.5-1.fc24 - anaconda-25.15-1.fc25 Let me recall that the main screen of the installer should definitely not be assigned to the internal display of a notebook when the lid is closed and an external monitor is attached.
Issue still present for the current Fedora development 25 (rawhide) tree including anaconda-25.19-1.fc25 and metacity-3.12.0-4.fc24.
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle. Changing version to '25'.
Proposed as a Blocker and Freeze Exception for 25-final by Fedora user frieben using the blocker tracking app because: The default setup of my system is a Lenovo ThinkPad T400 used as a desktop PC replacement which is permanently attached to an ensemble of of mini-dock, external monitor, keyboard, and mouse. "Installation interfaces When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces." The inclusion of an outdated metacity package was reported in bug 1376984: "[metacity] new upstream release 3.20.3 available." Booting the system in basic graphics mode fails, too, because of bug 1358306: "[systemd] Lenovo ThinkPad T400 suspends upon boot in basic graphics mode when docked and lid closed."
725219 (which has been open more or less since Noah started on the ark) is also relevant here, I guess.
Discussed during the 2016-10-17 blocker review meeting: [1] The decision to classify this bug as a "RejectedBlocker" was made as this has been an issue with Fedora for several years and has not blocked in the past. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2016-10-17/f25-blocker-review.2016-10-17-16.02.txt
Discussed during the 2016-10-24 blocker review meeting: [1] The decision to delay the classification of this as a freeze exception was made as we would like to know the ramifications of the fix before accepting it. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2016-10-24/f25-blocker-review.2016-10-24-16.01.txt
Discussed during the 2016-10-31 blocker review meeting: [1] The decision to drop this bug as a blocker/freeze exception was made as this bug has been around for a long time and as such, we are not willing to grant it a blocker/freeze exception status until a fix is available for test. If a fix is released, please re-propose this bug and it will be considered for reclassification. [1] https://meetbot.fedoraproject.org/fedora-blocker-review/2016-10-31/f25-blocker-review.2016-10-31-16.01.txt
Proposed as a Blocker for 26-alpha by Fedora user frieben using the blocker tracking app because: The default setup of my system is a Lenovo ThinkPad T400 used as a desktop PC replacement which is permanently attached to an ensemble of of mini-dock, external monitor, keyboard, and mouse. "Installation interfaces When using a dedicated installer image, the installer must be able to complete an installation using the text, graphical and VNC installation interfaces." The inclusion of an outdated metacity package was reported in bug 1376984: "[metacity] new upstream release 3.20.3 available." Booting the system in basic graphics mode fails, too, because of bug 1358306: "[systemd] Lenovo ThinkPad T400 suspends upon boot in basic graphics mode when docked and lid closed."
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I was just given metacity, and have rebased it to 3.25.1 in rawhide, and there are packages in my copr (yselkowitz/gnome-flashback) for 3.20 (F24), 3.22 (F25), and 3.24 (F26). If this is still an issue for F26 final, then we'll need to discuss the viability of rebasing to 3.24 this late in the cycle.
(In reply to Yaakov Selkowitz from comment #25) I had proposed this bug as a blocker earlier in the Fedora 26 development cycle as you can see above. Since this issue and others like the one reported in bug 725219 affect the anaconda installer, any external packages or later updates are strictly useless. Updates for Fedora 24 and 25 are less relevant because there will not be any new netinst install media anyway.
(In reply to Joachim Frieben from comment #26) > Since this issue and others like the one reported in bug 725219 affect the > anaconda installer, any external packages or later updates are strictly > useless. Understood; the questions are 1) will 3.24.1 fix this, and 2) is it too late to consider such a rebase even if it does. I can prepare an update for F26 -- and leave it in testing until we either agree that it should be stable, or until F26 GA -- if that will help you test.
(In reply to Yaakov Selkowitz from comment #27) The problem is that metacity is used by anaconda as window manager during a network install session. In order to test the effect of a recent metacity, a new netinst image based upon metacity 3.24.1 is needed. I do remember that older versions of the Fedora Mate spin which do use metacity did have the problem outlined above whereas recent versions were not affected anymore. Unfortunately, bug 1430259 may interfere with this bug unless the running kernel is 4.11.4 or later.
(In reply to Joachim Frieben from comment #28) > (In reply to Yaakov Selkowitz from comment #27) > The problem is that metacity is used by anaconda as window manager during a > network install session. In order to test the effect of a recent metacity, a > new netinst image based upon metacity 3.24.1 is needed. Update for F26: https://bodhi.fedoraproject.org/updates/FEDORA-2017-468c0a45bf
The graphical installer boots up successfully on the (docked) Lenovo ThinkPad T400 using the Fedora-Workstation-netinst-x86_64-Rawhide-20170613.n.0 media which does include metacity 3.25.1. Unfortunately, the very issue of this bug 1188774 persists. I am therefore sceptical that updating metacity on Fedora 25 and Fedora 26, respectively, will help. However, it likely will not hurt either.
Thanks for testing. Once Fedora is installed, does the desktop behave properly with that setup (external monitor with lid closed)? Would you be able to test gnome-flashback (which uses metacity) from my yselkowitz/gnome-flashback copr in that setup?
(In reply to Yaakov Selkowitz from comment #31) I am currently running Fedora 26 on said system. After installing package gnome-flashback, the additional GDM option "Classic GNOME" results in a classic GNOME desktop. Display properties show that the internal display is effectively disabled (lid closed and -not- switched off by the user) leading to a working single-screen setup. Unfortunately, current rawhide is possibly still affected by bug 1430259 (wrong handling of closed lid) which has been fixed in the stable 4.11.x series valid for Fedora 25 and Fedora 26. Note that the issue described in this bug 1188774 was present well before the wrong handling of a closed lid reported in bug 1430259 was introduced.
(In reply to Yaakov Selkowitz from comment #31) There is another caveat: when choosing the classic GNOME session, then there is no process "metacity" but instead one called "gnome-shell". Please verify that this behaviour is intended, thanks.
GNOME Classic has nothing to do with Flashback. When you install a new desktop session, the already running gdm doesn't pick it up automatically. The easiest thing to do is reboot, and then you will see a "GNOME Flashback (Metacity)" option.
(In reply to Yaakov Selkowitz from comment #34) The "GNOME Flashback (Metacity)" option leads to a working single-screen setup. The output of 'xrandr -q' reads: Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192 DVI-0 connected primary 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 301mm 1280x1024 60.02*+ 75.02 1024x768 75.03 60.00 800x600 75.00 60.32 640x480 75.00 59.94 720x400 70.08 LVDS connected (normal left inverted right x axis y axis) 1440x900 60.00 + 50.00 1280x854 59.95 1280x800 59.96 1280x720 59.97 1152x768 59.95 1024x768 59.95 800x600 59.96 848x480 59.94 720x480 59.94 640x480 59.94 VGA-0 disconnected (normal left inverted right x axis y axis). Alternatively, I have launched a simple X session which I found more representative of the netinst case. With a file .xinitrc : "metacity & exec twm", running command 'startx' leads to a working double-screen setup but xterm is actually launched correctly on the external display and visible right from the start. The output of 'xrandr -q' now reads Screen 0: minimum 320 x 200, current 2720 x 1024, maximum 8192 x 8192 DVI-0 connected primary 1280x1024+0+0 (normal left inverted right x axis y axis) 376mm x 301mm 1280x1024 60.02*+ 75.02 1024x768 75.03 60.00 800x600 75.00 60.32 640x480 75.00 59.94 720x400 70.08 LVDS connected 1440x900+1280+0 (normal left inverted right x axis y axis) 303mm x 190mm 1440x900 60.00*+ 50.00 1280x854 59.95 1280x800 59.96 1280x720 59.97 1152x768 59.95 1024x768 59.95 800x600 59.96 848x480 59.94 720x480 59.94 640x480 59.94 VGA-0 disconnected (normal left inverted right x axis y axis).
Ultimately, metacity is just a window manager. It knows only what it is told by the X server, which gets its information from its drivers and the kernel. So it seems unlikely that metacity is really the cause of use (or lack thereof) of the external monitor.
(In reply to Yaakov Selkowitz from comment #36) Please note that this report was initially posted for component anaconda, which then changed twice: first to component xorg-x11-server, then, as per comment 9, to component metacity and initiated by D. Shea. I recall that even when anaconda was directed to the internal display despite a closed lid, the live session which ran in a GNOME on Xorg session, too, was not affected by this issue.
(In reply to Yaakov Selkowitz from comment #36) Please note that starting metacity either with gnome-flashback or with 'startx' using file .xinitrc from comment 35 results in -different- screen setups, namely a single-screen setup in the former case and a dual-screen setup in the latter. This seems to refute your argument that the screen configuration is carried out by kernel and drivers alone.
That would be coming from the gnome-flashback component itself managing the display configuration based on such information, like gnome-shell does.
Created attachment 1332851 [details] X log file written out by anaconda-27.20.1-6.fc27 Installer screen is still mapped to the internal display for anaconda-27.20.1-6.fc27.
Created attachment 1332852 [details] X log file written out by X server 1.19.3 of the Fedora 27 Beta live system
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 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.