Bug 1039332 - Wrong monitor port at login and resume
Summary: Wrong monitor port at login and resume
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati
Version: 20
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-12-08 10:28 UTC by energonic
Modified: 2015-06-29 13:26 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-29 13:26:18 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description energonic 2013-12-08 10:28:05 UTC
Description of problem:
Running fedora 20 (beta, kde version) on 21.5 iMac (11,2, mid 2010). Booted via grub after fedora 19 install and subsequent yum upgrade to 20. Current kernel 3.11.10.
iMac has the main screen and I have plugged an external monitor into mini display port via HDMI cable. 
The iMac initially presents the kdm login screen on the external monitor, not the internal monitor. xrandr shows internal monitor named DisplayPort-0, and external monitor named eDP, (names seem to be reversed). I have switched off DisplayPort-0 and the desktop now shows only on eDP (the internal monitor).
On subsequent boots I still get login on external monitor but this switches to internal as kde starts up.
If I sleep, and then resume, the login again appears on the external monitor.
This effectively means I must have two monitors connected in order to be able to sleep (and resume). Energy saving this is not.

This problem appears to be due to the radeon kernel driver module, since the X ati module is capable of recognizing the screen set by xrandr. I think that the radeon kernel driver is automatically using DisplayPort-0, hoping it corresponds to the internal monitor. On this system the monitor names (or connectors) seem to be reversed.

Version-Release number of selected component (if applicable): Kernel 3.11.10,
xorg-x11-drv-ati 7.2.0-3

How reproducible:Always happens as described above.

Steps to Reproduce:
1.Either login first time, or login after resume

Actual results: Login window on external monitor

Expected results:Login window on internal monitor

Additional info:This same behaviour has been seen (and reported by me) on Archlinux and Ubuntu installations on my iMac. Archlinux was installed and the kernel booted directly by EFI and by grub.

Since I am one of very few users with such a system I don't expect a fix, but would be happy to find a workround, such as a kernel boot option that sets, and remembers, the monitor to use whenever the kernel starts.

Comment 1 energonic 2013-12-08 10:31:58 UTC
Sorry for confusion: I (too) reversed the monitor names in my second paragraph.

The second para should read:

The iMac initially presents the kdm login screen on the external monitor, not the internal monitor. xrandr shows internal monitor named eDP, and external monitor named DisplayPort-0, (names seem to be reversed). I have switched off DisplayPort-0 and the desktop now shows only on eDP (the internal monitor).

Comment 2 energonic 2014-02-02 12:06:32 UTC
The component has been set from kernel to xorg-x11-drv-ati.
It is worth noting that the problem also occurs without running X.
If I stop X, and have only vts running, suspending the system (using systemd) works, but on resume (using keyboard) the only vt available is on the external monitor. The main monitor is black and inactive.
Attempting to restart X in this case fails to light either screen (but other vts are available, on the external screen only). I believe X is set (by xrandr) to run on the main screen (which I think is called eDP) but there is no vt there because the radeon kernel module has failed to recognise it on resume.

Comment 3 Josh Boyer 2014-02-03 12:48:43 UTC
DRM driver bugs are assigned to the corresponding xorg components.  The same people work on them and it helps them by not having to find the bugs in the sea of other kernel bugs.

Comment 4 Fedora End Of Life 2015-05-29 09:56:41 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora  'version'
of '20'.

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

Comment 5 Fedora End Of Life 2015-06-29 13:26:18 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 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.


Note You need to log in before you can comment on or make changes to this bug.