Created attachment 527394 [details]
Xorg.0.log from the client system
Description of problem:
I'm using following display layout on my T400 (see gpu at additional info):
Laptop is connected trough DVI to external display which is on the left side. The laptop screen was disabled trough gnome-display properties. So the only active display is the external one.
If you'll open spice-client in fullscreen mode (only in fullscreen) then the client screen/canvas contains static image which is not being changed/refreshed until it's switched back to window mode.
I've tested this on friends laptop with nvidia which had same spice-client version and the problem did not happen while it's reproducible 100% on my intel.
I've used same display layouts on both displays (but display resolutions were bit different).
The guest seems to receive input events normally (which is proven by switching from fullscreen to window mode, as e.g. start menu appears ...) but the screen is not being refreshed.
It also happened in one of many cases in window mode, then simply moving window helped. So seems like switching client from fullscreen to window mode also changes/re-sets display mode on the client mode and this is probably causing that the screen is again refreshed.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. obtain same display layout (extended screen: enabled; laptop_display: disabled;)
1. connect trough spice-client to any guest (happens on windows7x64 and rhel6)
2. switch to fullscreen mode (shift+f11)
3. do some mouse events for few seconds, open window
4. switch to window mode (shift+f11)
screen is not being refreshed in step 3
changes on display are displayed after step 4 and are continuing to be draw correctly expect one of many cases in which simple window movement helps (that are described in original description)
screen should be refreshed as normally in any case
1) email / ping lkocman to obtain access to guest/rhevm.
2) happens with both linux and window guest
2) does not happen on nvidia (following device was tested)
01:00.0 VGA compatible controller : nVidia Corporation GT218 [NVS 3100M] [10de:0a6c] (rev a2)
3) lspci -nn | grep -i vga
00:02.0 VGA compatible controller : Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07)
4) display layout
Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 8192 x 8192
LVDS1 connected (normal left inverted right x axis y axis)
1440x900 60.0 + 59.9 59.9 50.0
1280x800 59.8 59.9
1280x768 59.9 60.0
800x600 60.3 56.2
VGA1 disconnected (normal left inverted right x axis y axis)
HDMI1 disconnected (normal left inverted right x axis y axis)
DP1 disconnected (normal left inverted right x axis y axis)
HDMI2 connected 1680x1050+0+0 (normal left inverted right x axis y axis) 474mm x 296mm
1440x900 75.0 59.9
1024x768 75.1 75.0 70.1 60.0
800x600 72.2 75.0 60.3 56.2
640x480 72.8 75.0 66.7 60.0
DP2 disconnected (normal left inverted right x axis y axis)
DP3 disconnected (normal left inverted right x axis y axis)
5) Switching from qxl to vesa on rhel guest (not on the client) does not make any difference so it's not duplicate of Bug 37840
6) downgrading spice-client did not help.
Some customers might be affected by this issue as spice will be no longer a technology preview in 6.2
Correction: it's not a duplicate of a Bug 737840 due it's non-dependency on qxl driver.
Workaround: turning on Compiz or using different layout then mentioned.
Given the description of the issue and the workaround in comment #3, I suspect this is effectively the same issue as bug #608076. Said bug is no longer present in current 6.4 snapshots.
Can you reproduce this in a 6.4 snap?
Moving to xorg-x11-server and MODIFIED, this is almost certainly a dupe of 608076.
This request was evaluated by Red Hat Product Management for
inclusion in a Red Hat Enterprise Linux release. Product
Management has requested further review of this request by
Red Hat Engineering, for potential inclusion in a Red Hat
Enterprise Linux release for currently deployed products.
This request is not yet committed for inclusion in a release.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.