RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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 ...
Keywords:
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:
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)

Fixed In Version: tigervnc-1.3.1-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 09:03:35 UTC
Target Upstream Version:
Embargoed:

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
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:2233 0 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.