Bug 1181287 - gnome 3 session inside vncserver changes initial resolution instead of using what was specified from "-geometry
Summary: gnome 3 session inside vncserver changes initial resolution instead of using ...
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: tigervnc
Version: 7.0
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: rc
: ---
Assignee: Tim Waugh
QA Contact: Robin Hack
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-01-12 19:41 UTC by Wade Berrier
Modified: 2015-11-19 09:03 UTC (History)
3 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2015-11-19 09:03:35 UTC


Attachments (Terms of Use)
tigervnc-randr-geometry.patch (F21 patch) (995 bytes, patch)
2015-01-14 13:38 UTC, Tim Waugh
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:2233 normal SHIPPED_LIVE Moderate: tigervnc security, bug fix, and enhancement update 2015-11-19 09:11:46 UTC

Description Wade Berrier 2015-01-12 19:41:42 UTC
Description of problem:

Using gnome 3 in a vncserver doesn't allow specifying a custom geometry.  Several standard resolutions can be used in gnome 3 via Xrandr after the fact, but my monitor resolution is not in that list (1440x900).  This disallows an unscaled fullscreen vnc client session.

Version-Release number of selected component (if applicable):  tigervnc-server-1.2.80-0.30.20130314svn5065.el7.x86_64

How reproducible: every time

Steps to Reproduce:
1. start vnc server with: vncserver -geometry 1440x900

Actual results:

Gnome 3 appears to pick a resolution based of saved preferences.

Expected results:

The resolution specified should be used.

Additional info:

Based on this mailing list message, the issue seems to be related to tigervnc not advertising the custom resolution to Xrandr:

https://groups.google.com/forum/#!topic/tigervnc-users/_SWnXVZCmpk

Comment 2 Tim Waugh 2015-01-13 12:11:39 UTC
Xvnc supports the RANDR extension. GNOME queries this extension to discover supported display sizes, and resizes its desktop accordingly.

What happens is that when you connect vncviewer, it asks the VNC server (using the RFB protocol) to dynamically resize its display based on the window size it has.

You can tell vncviewer not to do this by giving it the -RemoteResize=0 option.

Comment 3 Wade Berrier 2015-01-13 17:40:39 UTC
Thanks for the explanation.  Unfortunately, using -RemoteResize=0 still didn't work because it appears the remote (gnome 3 window manager?) had already changed the resolution before connecting with a client.

I tried with another window manager (openbox from epel) to compare with a simple test:

$HOME/.vnc/xstartup contents:

openbox &

------

$ vncserver -geometry 1440x900

$ vncviewer localhost:2 -RemoteResize=0

# xrandr output inside the vncviewer:

$ xrandr

Screen 0: minimum 32 x 32, current 1440 x 900, maximum 32768 x 32768
VNC-0 connected 1440x900+0+0 0mm x 0mm
   1920x1200      60.0  
   1920x1080      60.0  
   1600x1200      60.0  
   1680x1050      60.0  
   1400x1050      60.0  
   1360x768       60.0  
   1280x1024      60.0  
   1280x960       60.0  
   1280x800       60.0  
   1280x720       60.0  
   1024x768       60.0  
   800x600        60.0  
   640x480        60.0  
  1440x900 (0x4a)   77.8MHz
        h: width  1440 start    0 end    0 total 1440 skew    0 clock   54.0KHz
        v: height  900 start    0 end    0 total  900           clock   60.0Hz

-------

Notice that it's using a "custom" resolution of 1440x900.

----------------------------------------------------------------

Same test with Gnome 3:

$HOME/.vnc/xstartup contents:

gnome-session &

------

# started from a virtual terminal (didn't seem to work when starting within a gnome 3 session)
$ vncserver -geometry 1440x900

$ vncviewer localhost:2 -RemoteResize=0

# xrandr output inside the vncviewer:

$ xrandr

Screen 0: minimum 32 x 32, current 1920 x 1200, maximum 32768 x 32768
VNC-0 connected primary 1920x1200+0+0 0mm x 0mm
   1920x1200      60.0* 
   1920x1080      60.0  
   1600x1200      60.0  
   1680x1050      60.0  
   1400x1050      60.0  
   1360x768       60.0  
   1280x1024      60.0  
   1280x960       60.0  
   1280x800       60.0  
   1280x720       60.0  
   1024x768       60.0  
   800x600        60.0  
   640x480        60.0  

Notice that it's set to 1920x1200, and there is no "custom" 1440x900 resolution, even though I requested the original resolution to be 1440x900 as well as disabling RemoteResize.

Because of my specific scenario (using xrdp to work around a corporate remote login situation), this prevents me from using gnome 3 in fullscreen mode on my 1440x900 monitor (openbox works, but I'd rather use gnome 3).

Doesn't the above illustrate gnome 3 changing to a resolution when it shouldn't?

It almost appears that if a resolution isn't requested via rfb, it arbitrarily picks the highest resolution advertised from xrandr.

?

Comment 4 Wade Berrier 2015-01-14 00:05:11 UTC
Picking a different gnome based component as it appears it's not vnc related...

Comment 5 Tim Waugh 2015-01-14 13:38:41 UTC
Created attachment 980017 [details]
tigervnc-randr-geometry.patch (F21 patch)

Actually I think this might be a tigervnc issue after all. The attached patch seems to fix in on Fedora 21. I'll discuss it upstream and see if they agree it's the right fix.

Comment 6 Tim Waugh 2015-01-14 13:42:44 UTC
Changing component back.

Comment 7 Tim Waugh 2015-01-14 13:52:49 UTC
Upstream pull request:
https://github.com/TigerVNC/tigervnc/pull/101

Comment 8 Wade Berrier 2015-01-14 23:32:11 UTC
Great!

If it is accepted upstream, would this patch be appropriate for el7?

Comment 9 Tim Waugh 2015-01-15 15:20:47 UTC
I'd hope to get it in, yes.

Comment 10 Tim Waugh 2015-01-15 15:46:53 UTC
In fact this patch is better:
https://github.com/TigerVNC/tigervnc/pull/57

Comment 11 Jan Grulich 2015-05-14 12:02:19 UTC
Fixed in tigervnc-1.3.1-1.el7.

Comment 14 errata-xmlrpc 2015-11-19 09:03:35 UTC
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/RHSA-2015-2233.html


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