Bug 1779258

Summary: Virt-viewer Duplicating Display 1 On Display 2
Product: [Fedora] Fedora Reporter: RedHat-User
Component: xfce4-settingsAssignee: Kevin Fenzi <kevin>
Status: CLOSED EOL QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 31CC: berrange, bhoefer, cfergeau, fidencio, kevin, marcandre.lureau, nonamedotc, victortoso, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-24 17:26:45 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description RedHat-User 2019-12-03 15:21:35 UTC
Description of problem:

I'm running a virtual Fedora 31 desktop on a Fedora 31 QEMU/KVM virtualization server.  My virtualization server has an AMD Radeon R7 250 with both VGA and DVI output; I utilize both outputs with 2 monitors (each at 1280x1024) for a side-by-side desktop configured for 2560x1024.

I've configured my virtual desktop machine to also have 2 displays, and I use virt-viewer to view & interact with this virtual desktop machine.

Virt-viewer is duplicating guest display 1's output to guest display 2.  I've `lost` the output that should be going to guest display 2; instead display 1's output is duplicated to display 2.

I believe the relevant output from "virsh dumpxml {virt_machine}" is:

    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0' state='connected'/>
      <alias name='channel0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <channel type='unix'>
      <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-10-desktop/org.qemu.guest_agent.0'/>
      <target type='virtio' name='org.qemu.guest_agent.0' state='connected'/>
      <alias name='channel1'/>
      <address type='virtio-serial' controller='0' bus='0' port='2'/>
    </channel>

    <graphics type='spice' keymap='en-us'>
      <listen type='none'/>
      <image compression='off'/>
      <gl enable='no' rendernode='/dev/dri/by-path/pci-0000:01:00.0-render'/>
    </graphics>

    <video>
      <model type='virtio' heads='2' primary='yes'>
        <acceleration accel3d='yes'/>
      </model>
      <alias name='video0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>



Version-Release number of selected component (if applicable):

virt-viewer-8.0-3.fc31.x86_64



How Reproducible / Steps to Reproduce:

1. Create a QEMU/KVM guest machine with the Video model being "virtio".

2. Install Fedora 31 guest, selecting the "Xfce Desktop" software.
   Shutdown the virtual machine.

3. Edit the virtual machine's XML to change the Video's Heads to "2".

4. Start the virtual machine; open the viewer using this command:
     virt-viewer -fa --wait {virt_machine} 2>/dev/null &
   Note that virt-viewer's display 2 is disabled.

5. Log into the Xfce desktop.  Only after logging in can one then enable
   virt-viewer's display 2.

6. When one enables virt-viewer's display 2, it appears but display 1 goes
   dark with a "Guest disabled display." message.  Using Xfce's Display
   applet, one can re-enable it thus receiving output to both virtual
   display 1 and virtual display 2.



Actual results:

Configuring the virtual displays in a non-mirrored side-by-side does not work; the displays always look like they are mirrored despite that option not being enabled.



Expected results:

The virtual displays can be configured to appear non-mirrored, side-by-side.



Additional info:

I had this working under Fedora 29 up until near the end of Fedora 29's life.  This problem surfaced after some updates in the September, October or November 2019 time frame.  (I was never able to trace it down to a specific update.)

My virtualization server was system-upgraded from Fedora 29 to Fedora 31.  I installed a whole new Fedora 31 virtual desktop machine as a test.

At first I thought my guest's window manager (Xfce) was at fault -- that it was mirroring the displays even though that option was disabled.  But then I noticed some things that convinced me the problem is not with Xfce, but with virt-viewer, itself:

1. When Xfce is configured to put the displays side-by-side (but this
   bug makes it looks like they are mirrored) I cannot interact with
   the items displayed in guest display 2.  My mouse can only interact
   with desktop items on guest display 1.

   Conversely, if I change Xfce to truly mirror my displays, I
   can interact with desktop items with my mouse on either
   virt-viewer display.

2. When Xfce is configured to put the displays side-by-side (but this
   bug makes it looks like they are mirrored) my workspace switcher
   shows a 2560x1024 desktop.  Conversely, if I change Xfce to truly
   mirror my displays, my workspace switcher shows a 1280x1024 desktop.

Comment 1 Daniel Berrangé 2020-01-06 12:30:00 UTC
There's too many moving parts in the bug description to have confidence in where the problem might lie. To move this bug forward someone needs to try to narrow down where the problem lies. At least to start

 - Determine whether Xfce is a relevant factor by trying a guest using GNOME 3 with GNOME shell
 - Determine whether the host is a relevant factor by trying the F29 host with the same F31 Xfce guest.

Comment 2 RedHat-User 2020-01-15 17:52:04 UTC
Hmm, it appears this might be a Xfce issue.  I stood up a fresh Fedora 31 virtual machine, choosing "Fedora Workstation" as the software selection.  (That uses Gnome.)  I used "virsh edit" to change the machine's <video> section to have virtio's heads='2'.  I then started the machine and used:

  virt-viewer -fa --wait <name>

...and was able to get both virtual displays after logging in as my normal user.

I don't seem to have the authority to change this Bugzilla ticket's component.  Is that something you could do for me, Daniel?  Thanks.

Comment 3 Daniel Berrangé 2020-01-15 17:59:19 UTC
There's many  xfce components, so let me know which you think is best to move it to.

Comment 4 Bernie Hoefer 2020-01-15 19:04:45 UTC
(In reply to Daniel Berrangé from comment #3)
===
> There's many  xfce components, so let me know which you think is best to move it to.
===

Please move it to xfce4-settings, as that is the RPM that provides /usr/bin/xfce4-display-settings.  Thanks!

Comment 5 RedHat-User 2020-02-05 15:24:44 UTC
I learned something new, today, about this problem.  As shown in the description of this Bugzilla ticket, I was using the virtio video model type.  I discovered that if I switched to qxl:

    <video>
      <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='2' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>

...the problem goes away.  Please note that comment #2's "Fedora Workstation" test (which used Gnome) works under virtio.

Another observance between Gnome and Xfce is that when the virtual machines are booting up, the Gnome one `knows` it has 2 virtual displays attached to it and activates both.  On the Xfce virtual machine, I get only the 1st virtual display.  I have to login, take the virt-viewer window out of fullscreen and then manually activate the 2nd virtual display by visiting the View menu --> Displays --> checking "Display 2".  (This was always true, even before I had the problem for which I opened this ticket.)

As always, I'm open to running tests or providing logs if that will help get this problem fixed.  Thank you.

Comment 6 Ben Cotton 2020-11-03 17:06:04 UTC
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
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 '31'.

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 31 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 7 Ben Cotton 2020-11-24 17:26:45 UTC
Fedora 31 changed to end-of-life (EOL) status on 2020-11-24. Fedora 31 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.

Comment 8 RedHat-User 2020-12-05 21:26:09 UTC
I did a Fedora 31 --> 33 system-upgrade of the hypervisor and a fresh install of Fedora 33 onto the guest.  It now seems to work correctly.


$ virsh dumpxml --domain VMGUEST | grep -A6 '<video>'
    <video>
      <model type='virtio' heads='2' primary='yes'>
        <acceleration accel3d='yes'/>
      </model>
      <alias name='video0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>


So, I guess this Bugzilla ticket is OK to be closed.