Bug 1181287
| Summary: | gnome 3 session inside vncserver changes initial resolution instead of using what was specified from "-geometry | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Wade Berrier <wberrier> | ||||
| Component: | tigervnc | Assignee: | Tim Waugh <twaugh> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Robin Hack <rhack> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 7.0 | CC: | jgrulich, jscotka, rhack | ||||
| Target Milestone: | rc | Keywords: | Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | tigervnc-1.3.1-1.el7 | Doc Type: | Bug Fix | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-11-19 09:03:35 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Wade Berrier
2015-01-12 19:41:42 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. 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 |