Bug 1030812 - Screen configuration broken after switching from X to tty and back with multiple displays
Screen configuration broken after switching from X to tty and back with multi...
Status: CLOSED DUPLICATE of bug 1101269
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kernel (Show other bugs)
7.0
Unspecified Linux
unspecified Severity low
: rc
: ---
Assigned To: Rob Clark
Red Hat Kernel QE team
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-15 03:38 EST by Milan Barta
Modified: 2015-10-27 20:19 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-12-11 15:06:41 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Screenshot of screen configuration after switching back to X (514.73 KB, image/png)
2013-11-15 03:38 EST, Milan Barta
no flags Details

  None (edit)
Description Milan Barta 2013-11-15 03:38:05 EST
Created attachment 824355 [details]
Screenshot of screen configuration after switching back to X

Description of problem:
After switching to text console from X and back with multiple displays on, the screen configuration breaks. Display number two shows cloned display number one plus display number two next to it (see the attached screenshot).

Version-Release number of selected component (if applicable):
Host, Client, Guest: RHEL7
spice-server-0.12.4-3.el7.x86_64
spice-gtk3-0.20-6.el7.x86_64
qemu-kvm-1.5.3-19.el7.x86_64
virt-viewer-0.5.7-2.el7.x86_64
spice-vdagent-0.14.0-5.el7.x86_64
xorg-x11-drv-qxl-0.1.1-5.el7.x86_64

How reproducible:
100 % times

Steps to Reproduce:
1. run VM with two displays using remote-viewer
2. switch to tty (using the menu -> send key -> ctrl+alt+f2)
3. switch back to X (using the menu -> send key -> ctrl+alt+f1)

Actual results:
Screen configuration is corrupted. Second display shows cloned display one attached to display two.

Expected results:
Each display is showed in its own window.

Additional info:
Comment 2 Søren Sandmann Pedersen 2014-01-20 16:50:16 EST
Can you provide the specific qemu-kvm command line that you used?
Comment 3 Milan Barta 2014-01-23 07:45:50 EST
Yes, I'm running the VM using virt-manager. 
The command line used:

/usr/libexec/qemu-kvm -name rhel7beta -S -machine pc-i440fx-rhel7.0.0,accel=kvm,usb=off -m 2048 -realtime mlock=off -smp 2,sockets=2,cores=1,threads=1 -uuid 4ebd40ec-1e77-49a2-bd89-d65523848043 -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/rhel7beta.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-shutdown -boot strict=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/var/lib/libvirt/images/rhel7beta.img,if=none,id=drive-virtio-disk0,format=raw,cache=none -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=23,id=hostnet0,vhost=on,vhostfd=24 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:02:19:1c,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing,seamless-migration=on -vga qxl -global qxl-vga.ram_size=67108864 -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
Comment 4 Jonathon Jongsma 2014-01-23 10:40:46 EST
Can you reproduce with virt-viewer 0.5.7-3? It's possible that this is related to bug 1022769...
Comment 5 Milan Barta 2014-01-24 05:00:02 EST
Yes I can. I've tested this with virt-viewer-0.5.7-4.el7.x86_64 and the bug is still there.
Comment 6 Søren Sandmann Pedersen 2014-03-11 04:16:49 EDT
It *appears* this bug is connected with the following code in spice-gtk3:

    if (c->surface_id != 0) {
        g_warning("FIXME: only support monitor config with primary surface 0, "
                  "but given config surface %d", c->surface_id);
        goto whole;
    }

If I comment it out I can't reproduce this bug any more.

Marc-Andre, Christophe -- any ideas?
Comment 7 Marc-Andre Lureau 2014-03-11 07:49:05 EDT
(In reply to Søren Sandmann Pedersen from comment #6)
> It *appears* this bug is connected with the following code in spice-gtk3:
> 
>     if (c->surface_id != 0) {
>         g_warning("FIXME: only support monitor config with primary surface
> 0, "
>                   "but given config surface %d", c->surface_id);
>         goto whole;
>     }
> 
> If I comment it out I can't reproduce this bug any more.
> 

When we get a monitor config with a surface != 0, we don't have any support for that. There is no code to handle such case, and in general I expect this to be a bit tricky to get right (changing surface etc). 

I suppose this is still using the xf86-qxl driver, right? (not the drm) Any idea why we have monitor config with surface_id != 0?
Comment 8 Søren Sandmann Pedersen 2014-03-11 12:13:07 EDT
This is using kernel mode setting, if that's what you mean.
Comment 9 Marc-Andre Lureau 2014-03-11 12:25:51 EDT
(In reply to Søren Sandmann Pedersen from comment #8)
> This is using kernel mode setting, if that's what you mean.

shouldn't this bug be moved to kernel then?

That doesn't answer my question: why we have monitor config with surface_id != 0? Afaik, we shouldn't reach this, but perhaps drm/kms driver is doing something new?
Comment 10 Søren Sandmann Pedersen 2014-03-11 16:15:00 EDT
I thought that the multi-monitor work added the ability to set any surface as scan-out.

Cc'ing Dave and Alon.
Comment 13 Fabiano Fidêncio 2014-08-26 21:02:50 EDT
This problem is in drm/kms driver, as noted by Marc-André. The fix is already pushed upstream (52571ad5f4c57067ac593a6bdb1f7a35ed032d27) and has to be backported to rhel-7.1.

Shall I just move this bug to kernel?
Comment 14 Rob Clark 2014-08-27 10:02:01 EDT
fyi, this landed upstream in 3.15-rc3, and is part of the rhel71 drm backport
Comment 15 Rob Clark 2014-12-11 15:06:41 EST

*** This bug has been marked as a duplicate of bug 1101269 ***

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