Bug 1021841 - Can not keep right resolution after change back to graphics mode and send-key ctrl+alt+backspace
Can not keep right resolution after change back to graphics mode and send-key...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-viewer (Show other bugs)
6.5
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Virt Viewer Maint
Virtualization Bugs
:
Depends On: 1179477
Blocks: 1009648 1032971 1033447
  Show dependency treegraph
 
Reported: 2013-10-22 04:09 EDT by CongDong
Modified: 2015-07-22 02:30 EDT (History)
11 users (show)

See Also:
Fixed In Version: virt-viewer-2.0-1.el6
Doc Type: Bug Fix
Doc Text:
When the agent terminated unexpectedly or was disconnected and reconnected again, virt-viewer did not update the information about windows geometry and the guest resolution was not restored accordingly. With this update, the function responsible for updating the displays geometry is called, thus fixing the bug.
Story Points: ---
Clone Of:
: 1032971 1033447 (view as bug list)
Environment:
Last Closed: 2015-07-22 02:30:41 EDT
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)
virt-viewer and spice log (267.33 KB, text/x-log)
2013-10-22 04:09 EDT, CongDong
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2015:1322 normal SHIPPED_LIVE virt-viewer and spice-gtk bug fix and enhancement update 2015-07-20 13:53:14 EDT

  None (edit)
Description CongDong 2013-10-22 04:09:32 EDT
Created attachment 814885 [details]
virt-viewer and spice log

Description of problem:
The display got wrong resolution after I change the guest back to the graphics mode and send-key ctrl+alt+backspace

Version-Release number of selected component (if applicable):
# rpm -qa virt-viewer spice*
spice-gtk-0.20-9.el6.x86_64
virt-viewer-0.5.6-8.el6.x86_64
spice-glib-0.20-9.el6.x86_64
spice-server-0.12.4-6.el6.x86_64
spice-vdagent-0.14.0-2.el6.x86_64
spice-gtk-python-0.20-9.el6.x86_64

How reproducible:
100%

Steps to Reproduce:
1.Have a guest with graphics desktop
# virt-viewer rhel6.4 -f
2.Open the send-key menu, and send ctrl+alt+f1, change the guest to the text mode
  Send-key -> ctrl+alt+f1
3.Change the guest back to the graphics mode.
  Send-key -> ctrl+alt+f7
4. Send-key -> ctrl+alt+backspace

Actual results:
After step4, the guest change back to graphics mode, but the resolution is not same with the physical monitor.

Expected results:
The display should keep the right resolution.

Additional info:
Comment 1 Marc-Andre Lureau 2013-12-01 19:28:45 EST
The current resolution is sent to the guest when the agent is connected, this is to set the requested resolution as soon as possible.

But the current resolution is updated whenever the guest resolution changes. So when switching back to desktop, the agent is reconnected and you get the console resolution.

My feeling is that the agent should not be disconnected when merely switching to console (when the CK active session is empty). Moving there for discussion.
Comment 2 Uri Lublin 2014-06-10 12:12:48 EDT
Can you please test with a more recent virt-viewer ?

If the problem still exists, please provide component versions on client and spice-vdagent version on guest.

Works for me with virt-viewer-0.5.6-8.el6_5.3.x86_64 when using remote-viewer (remote-viewer -f auto-conf spice://host:port)
But sometimes fails with virt-viewer-0.6.0-5.el6.x86_64 when using remote-viewer
(remote-viewer -f spice://host:port), so likely the problem is not
with the agent.
Comment 3 CongDong 2014-06-10 22:45:37 EDT
(In reply to Uri Lublin from comment #2)
> Can you please test with a more recent virt-viewer ?
> 
> If the problem still exists, please provide component versions on client and
> spice-vdagent version on guest.
> 
> Works for me with virt-viewer-0.5.6-8.el6_5.3.x86_64 when using
> remote-viewer (remote-viewer -f auto-conf spice://host:port)
> But sometimes fails with virt-viewer-0.6.0-5.el6.x86_64 when using
> remote-viewer
> (remote-viewer -f spice://host:port), so likely the problem is not
> with the agent.

I can reproduce this.

steps:
1. # remote-viewer spice://$ip:$port -f
2. Send-key -> ctrl+alt+f1
3. Send-key -> ctrl+alt+f7
4. Send-key -> ctrl+alt+backspace
5. Sometimes need repeat step2-step4 for about 5 times

Version:
Client:
# rpm -qa virt-viewer spice*
spice-server-0.12.4-9.el6.x86_64
virt-viewer-0.6.0-5.el6.x86_64
spice-glib-0.22-3.el6.x86_64
spice-gtk-0.22-3.el6.x86_64
spice-gtk-python-0.22-3.el6.x86_64
spice-xpi-2.7-25.el6.x86_64
spice-vdagent-0.14.0-3.el6.x86_64

Guest:
xorg-x11-drv-qxl-0.1.1-12.el6.x86_64
spice-vdagent-0.14.0-3.el6.x86_64
Comment 4 Marc-Andre Lureau 2014-07-03 11:08:43 EDT
(In reply to Marc-Andre Lureau from comment #1)
> The current resolution is sent to the guest when the agent is connected,
> this is to set the requested resolution as soon as possible.
> 
> But the current resolution is updated whenever the guest resolution changes.
> So when switching back to desktop, the agent is reconnected and you get the
> console resolution.
> 
> My feeling is that the agent should not be disconnected when merely
> switching to console (when the CK active session is empty). Moving there for
> discussion.

We need to send the autoconf/user config when agent is connected (added by 801f10d). But perhaps it is simpler to not send monitor config after agent restart and leave that to client (in spice-gtk main_handle_agent_connected().)

The "bug" would still occur if you initially connect to a console (or non-connected agent guest) and then switch to or start a vdagent console.  

A better option imho, is for agent to ignore monitor configuration when switching back to graphic console.
Comment 5 Fabiano Fidêncio 2014-08-17 12:57:40 EDT
(In reply to Marc-Andre Lureau from comment #4)
> (In reply to Marc-Andre Lureau from comment #1)
> > The current resolution is sent to the guest when the agent is connected,
> > this is to set the requested resolution as soon as possible.
> > 
> > But the current resolution is updated whenever the guest resolution changes.
> > So when switching back to desktop, the agent is reconnected and you get the
> > console resolution.
> > 
> > My feeling is that the agent should not be disconnected when merely
> > switching to console (when the CK active session is empty). Moving there for
> > discussion.
> 
> We need to send the autoconf/user config when agent is connected (added by
> 801f10d). But perhaps it is simpler to not send monitor config after agent
> restart and leave that to client (in spice-gtk
> main_handle_agent_connected().)
> 
> The "bug" would still occur if you initially connect to a console (or
> non-connected agent guest) and then switch to or start a vdagent console.  
> 
> A better option imho, is for agent to ignore monitor configuration when
> switching back to graphic console.

About the solution described as "better option", there is no way, from the agent, to know when the user is switching back to graphic console and then ignore monitor configuration. The only part who knows about entering/leaving VT is the QXL driver, which probably could provide this info to the agent (but I'm still not sure how).
Comment 6 Marc-Andre Lureau 2014-08-17 13:19:06 EDT
(In reply to Fabiano Fidêncio from comment #5)
> > A better option imho, is for agent to ignore monitor configuration when
> > switching back to graphic console.
> 
> About the solution described as "better option", there is no way, from the
> agent, to know when the user is switching back to graphic console and then
> ignore monitor configuration. The only part who knows about entering/leaving
> VT is the QXL driver, which probably could provide this info to the agent
> (but I'm still not sure how).

The system agent controls which session agent is active (see update_active_session_connection()), so it may well send a special message to inform that it may ignore update client monitor config. Note: i haven't checked the details, but I believe it's doable.
Comment 7 Fabiano Fidêncio 2014-08-17 19:25:23 EDT
(In reply to Marc-Andre Lureau from comment #6)
> (In reply to Fabiano Fidêncio from comment #5)
> > > A better option imho, is for agent to ignore monitor configuration when
> > > switching back to graphic console.
> > 
> > About the solution described as "better option", there is no way, from the
> > agent, to know when the user is switching back to graphic console and then
> > ignore monitor configuration. The only part who knows about entering/leaving
> > VT is the QXL driver, which probably could provide this info to the agent
> > (but I'm still not sure how).
> 
> The system agent controls which session agent is active (see
> update_active_session_connection()), so it may well send a special message
> to inform that it may ignore update client monitor config. Note: i haven't
> checked the details, but I believe it's doable.

Hmm. First thing, there are two different problems in this bug report.
1) Cannot keep resolution after Ctrl+Alt+Backspace.
There is a patch (https://www.redhat.com/archives/virt-tools-list/2014-August/msg00064.html) that fixes the problem, even if the intent of the patch was to solve another issue.

2) Cannot keep resolution after switch to VT mode and come back to graphic mode.
For this, there is the Marc-André's suggestion that kind-of works. However, there are drawbacks.
Consider the following situation:
a) Connect to the guest (in the normal mode, *not* fullscreen)
b) Switch to VT mode
c) Change the client to fullscreen
d) Switch to graphic mode
As we ignore the message, when the guest switches back to the graphic mode, it will keep the old resolution, even if it window is fullscreen now.

For me, it seems to be a minor issue compared to the original one, but still, want to know Marc-André's opinion on that.
Comment 8 Marc-Andre Lureau 2014-08-18 05:34:22 EDT
(In reply to Fabiano Fidêncio from comment #7)
> 2) Cannot keep resolution after switch to VT mode and come back to graphic
> mode.
> For this, there is the Marc-André's suggestion that kind-of works. However,
> there are drawbacks.
> Consider the following situation:
> a) Connect to the guest (in the normal mode, *not* fullscreen)
> b) Switch to VT mode
> c) Change the client to fullscreen
> d) Switch to graphic mode
> As we ignore the message, when the guest switches back to the graphic mode,
> it will keep the old resolution, even if it window is fullscreen now.
> 
> For me, it seems to be a minor issue compared to the original one, but
> still, want to know Marc-André's opinion on that.

Good point, this is pretty bad. So I wouldn't fix that second part, the guest resolution must keep following the client window resolution. (even if it means switching to VT and back will change the X resolution).
Comment 9 Fabiano Fidêncio 2014-08-18 07:06:10 EDT
(In reply to Marc-Andre Lureau from comment #8)
> (In reply to Fabiano Fidêncio from comment #7)
> > 2) Cannot keep resolution after switch to VT mode and come back to graphic
> > mode.
> > For this, there is the Marc-André's suggestion that kind-of works. However,
> > there are drawbacks.
> > Consider the following situation:
> > a) Connect to the guest (in the normal mode, *not* fullscreen)
> > b) Switch to VT mode
> > c) Change the client to fullscreen
> > d) Switch to graphic mode
> > As we ignore the message, when the guest switches back to the graphic mode,
> > it will keep the old resolution, even if it window is fullscreen now.
> > 
> > For me, it seems to be a minor issue compared to the original one, but
> > still, want to know Marc-André's opinion on that.
> 
> Good point, this is pretty bad. So I wouldn't fix that second part, the
> guest resolution must keep following the client window resolution. (even if
> it means switching to VT and back will change the X resolution).

Okay, so I'm changing the status of the bug to POST, considering that a patch for the first scenario was already sent to ML (and ACKed as well).
About the second scenario, we are not going to fix this, as it seems to behave according to the design (guest resolution following the client window resolution) as explained above. Also, the possible fix would introduce more problems than advantages.
Comment 10 Christophe Fergeau 2014-09-19 06:12:53 EDT
The patch you mentioned ( https://www.redhat.com/archives/virt-tools-list/2014-August/msg00064.html ) is for virt-viewer, and since the 2nd scenario is not going to be fixed, this bug should be reassigned to virt-viewer, right?
Comment 11 Fabiano Fidêncio 2014-09-19 09:29:46 EDT
(In reply to Christophe Fergeau from comment #10)
> The patch you mentioned (
> https://www.redhat.com/archives/virt-tools-list/2014-August/msg00064.html )
> is for virt-viewer, and since the 2nd scenario is not going to be fixed,
> this bug should be reassigned to virt-viewer, right?

Yes, you're right. Just reassigned.
Comment 12 CongDong 2014-10-09 04:14:15 EDT
I can reproduce with: virt-viewer-0.6.0-6.el7.x86_64

VERIFY with virt-viewer-0.6.0-7.el7.x86_64

Steps:
1.Have a guest with graphics desktop
# virt-viewer rhel6.4 -f
2.Open the send-key menu, and send ctrl+alt+f1, change the guest to the text mode
  Send-key -> ctrl+alt+f1
3.Change the guest back to the graphics mode.
  Send-key -> ctrl+alt+f7
4. Send-key -> ctrl+alt+backspace

Result:
The resolution is not change.

As the result, set VERIFIED.
Comment 13 CongDong 2014-10-09 21:50:43 EDT
(In reply to CongDong from comment #12)
> I can reproduce with: virt-viewer-0.6.0-6.el7.x86_64
> 
> VERIFY with virt-viewer-0.6.0-7.el7.x86_64
> 
> Steps:
> 1.Have a guest with graphics desktop
> # virt-viewer rhel6.4 -f
> 2.Open the send-key menu, and send ctrl+alt+f1, change the guest to the text
> mode
>   Send-key -> ctrl+alt+f1
> 3.Change the guest back to the graphics mode.
>   Send-key -> ctrl+alt+f7
> 4. Send-key -> ctrl+alt+backspace
> 
> Result:
> The resolution is not change.
> 
> As the result, set VERIFIED.

Sorry for add the comment to this bug, re-set the status to previous: POST
Comment 14 Fabiano Fidêncio 2014-10-10 03:13:42 EDT
Cong Dong,

I do not understand you. You can reproduce with virt-viewer-0.6.0-6.el7.x86_64, right? That's okay, because the fix was introduced in virt-viewer-0.6.0-7.el7.x86_64. About the virt-viewer-0.6.0-7.el7.x86_64, you said that you can *not* reproduce anymore, is it? If this is the case, please, change the status to VERIFIED instead of POST.
Comment 15 Fabiano Fidêncio 2014-10-10 03:15:05 EDT
(In reply to Fabiano Fidêncio from comment #14)
> Cong Dong,
> 
> I do not understand you. You can reproduce with
> virt-viewer-0.6.0-6.el7.x86_64, right? That's okay, because the fix was
> introduced in virt-viewer-0.6.0-7.el7.x86_64. About the
> virt-viewer-0.6.0-7.el7.x86_64, you said that you can *not* reproduce
> anymore, is it? If this is the case, please, change the status to VERIFIED
> instead of POST.

Ah, RHEL 6. Got it.
Comment 16 Jonathon Jongsma 2015-02-09 11:40:16 EST
Will be fixed by rebase to 2.0
Comment 18 CongDong 2015-03-11 07:25:41 EDT
I can reproduce with:
spice-gtk-0.20-9.el6.x86_64
virt-viewer-0.5.6-8.el6.x86_64
spice-glib-0.20-9.el6.x86_64
spice-gtk-python-0.20-9.el6.x86_64

Steps:
1.Have a guest with graphics desktop
# virt-viewer rhel6 -f
2.Open the send-key menu, and send ctrl+alt+f1, change the guest to the text mode
  Send-key -> ctrl+alt+f1
3.Change the guest back to the graphics mode.
  Send-key -> ctrl+alt+f7
4. Send-key -> ctrl+alt+backspace

Result:
After step4, the guest change back to graphics mode, but the resolution is not same with the physical monitor.

Verify with:
spice-glib-0.26-3.el6.x86_64
spice-gtk-python-0.26-3.el6.x86_64
virt-viewer-2.0-3.el6.x86_64
spice-gtk-0.26-3.el6.x86_64

Result:
The resolution is not changed after step 4.

As the result, move to VERIFIED.
Comment 21 errata-xmlrpc 2015-07-22 02:30:41 EDT
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.

https://rhn.redhat.com/errata/RHBA-2015-1322.html

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