RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1263815 - Test case failure: Multihead - Large Desktop on ATI Pitcairn PRO [Radeon HD 7850] [1002:6819]
Summary: Test case failure: Multihead - Large Desktop on ATI Pitcairn PRO [Radeon HD 7...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: xorg-x11-drv-ati
Version: 7.5
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Lyude
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-16 19:06 UTC by Vasiliy Sharapov
Modified: 2017-09-26 12:36 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-09-26 12:36:02 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Xorg log of problem (117.37 KB, text/plain)
2015-09-16 19:06 UTC, Vasiliy Sharapov 		no flags Details
View All

Description Vasiliy Sharapov 2015-09-16 19:06:27 UTC 
Created attachment 1074176 [details]
Xorg log of problem

Filed from caserun (https://tcms.engineering.redhat.com/run/260129/#caserun_10820258)

Version-Release number of selected component (if applicable):
RHEL-7.2-20150820.0
xorg-x11-server-Xorg-1.17.2-7.el7.x86_64
xorg-x11-drv-ati-7.5.0-3.el7.x86_64
kernel-3.10.0-306.0.1.el7.x86_64
linux-firmware-20150727-41.git75cc3ef.el7.noarch
mesa-dri-drivers-10.6.0-1.20150616.el7.x86_64

Steps to Reproduce: 
 1. obtain a card that is capable to connect 4 screens and 4 monitors
 2. plug everything together and start GNOME


 1. go into Control Center -> Display
 2. Create 4x1 setup with all displays set to the same resolution
 3. Create 2x2 setup
 4. Create 1x4 setup with all displays set to different resolution



Actual results: 
If monitors are hotplugged up to 4 (DP must be present on boot due to another bug[1]) then 2/4 monitors work and the other two are registered by xrandr and mode is set, but monitor gets no signal and goes to sleep.
If all four are plugged on boot, then 0/4 monitors work - they all get registered by xrandr and modes set, but no signal goes to the monitors and they all go to sleep.

Expected results:
you should be able to move cursor from one screen to another flawlessly in all
setups.

In different resolution setup there should be borders where you cannot pass to
another screen accordingly


Additional info:
Xorg log attached is from latter scenario (all 4 screens plugged at boot time)
Comment 3 Lyude 2016-06-14 17:19:00 UTC 
What kind of monitor configuration was this tested with? There was a bug previously in xf86-video-ati where if we failed to do a modeset due to hardware limitations we'd drop all of the displays that had been working previously, which sounds like what you might be seeing here
Comment 4 Vasiliy Sharapov 2017-09-26 12:36:02 UTC 
4 output is flawless on:
RHEL-7.4-20170711.0
xorg-x11-server-Xorg-1.19.3-11.el7.x86_64
xorg-x11-drv-ati-7.7.1-3.20160928git3fc839ff.el7.x86_64
kernel-3.10.0-693.el7.x86_64
linux-firmware-20170606-56.gitc990aae.el7.noarch
mesa-dri-drivers-17.0.1-6.20170307.el7.x86_64
libdrm-2.4.74-1.el7.x86_64
Note You need to log in before you can comment on or make changes to this bug.