Red Hat Bugzilla – Bug 1181287
gnome 3 session inside vncserver changes initial resolution instead of using what was specified from "-geometry
Last modified: 2015-11-19 04:03:35 EST
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
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.
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. ?
Picking a different gnome based component as it appears it's not vnc related...
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.
Changing component back.
Upstream pull request: https://github.com/TigerVNC/tigervnc/pull/101
Great! If it is accepted upstream, would this patch be appropriate for el7?
I'd hope to get it in, yes.
In fact this patch is better: https://github.com/TigerVNC/tigervnc/pull/57
Fixed in tigervnc-1.3.1-1.el7.
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