Here's what I observe:
CentOS 5, Gnome 2.16.x:
-- Setting the resolution via the Screen Resolution applet has the same
immediate effect as using xrandr on the command line. For instance, my
client has a screen resolution of 1344x840. I start the TurboVNC Server
using its default geometry (1240x900.) I log in using the TurboVNC 2.0
Viewer (which supports automatic desktop resizing.) I change the server
resolution to 1600x1200, using either the Screen Resolution applet or
'xrandr -s 1600x1200'. This causes the TurboVNC Server to send a
1600x1200 resize request to the viewer. The viewer automatically clamps
this to 1344x769 in order to fit on the client's desktop, and this
triggers a remote resize request that is sent back to the server. If
the Screen Resolution applet was used to change the resolution, then it
stores the resolution in
GConf:/desktop/gnome/screen/default/0/resolution, so the next time Gnome
is started, it will automatically switch to the persistent resolution.
Running 'gconftool-2 -u /desktop/gnome/screen/default/0/resolution'
deletes the persistent resolution, so subsequent TurboVNC sessions will
respect the -geometry argument.
CentOS 5, KDE 3.5.x:
-- Same behavior as Gnome, with the following exceptions:
-- The applet used to set the persistent screen resolution is
Control Center-->Peripherals-->Display
-- The resolution is persistent only if you check "Apply settings on
KDE startup" prior to clicking "Apply." You can later uncheck "Apply
settings on KDE startup" and click "Apply" to delete the persistent
resolution, thus making subsequent TurboVNC sessions respect the
-geometry argument.
CentOS 6, Gnome 2.28.x:
-- Similar to CentOS 5, except that when the Screen Resolution applet is
used to change the resolution, it seems to aggressively try to maintain
that resolution within the current session. In my specific case, this
triggers an infinite loop whereby the server sends a 1600x1200 resize
request to the viewer, the viewer tries to clamp it to 1344x769 and send
back a remote resize request to the server, but the server immediately
sends back another 1600x1200 resize request. Rinse and repeat. Ugh.
Furthermore, the settings are no longer stored in GConf. They are
stored in ~/.config/monitors.xml. Removing the configuration section
for "TurboVNC" causes subsequent TurboVNC sessions to respect the
-geometry argument.
CentOS 6, KDE 4.3.x:
-- Changing the screen resolution under System Settings-->Display does
not cause the resolution to persist unless you configure krandrtray to
run whenever KDE starts. However, the Display applet does remember the
persistent resolution, so if you start a new TurboVNC session and then
launch the Display applet again, it will attempt to resize the screen to
the persistent resolution at that time.
-- KDE stores the persistent resolution in ~/.kde/share/config/krandrrc.
Deleting the "TurboVNC" section in that file removes the persistent
resolution setting.
CentOS 7, KDE 4.10.x:
-- Same as CentOS 6, except that the persistent resolution is stored
under ~/.kde/share/apps/kscreen/{some_unique_id}. One of the files in
that directory will have "TurboVNC" in it if there is a persistent
resolution stored for TurboVNC. Removing that file removes the
persistent resolution.
On 6/17/15 1:16 PM, Craig Ruff wrote:
>
> On Wed, Jun 17, 2015 at 11:45 AM, DRC <[email protected]
> <mailto:[email protected]>> wrote:
>
> This is a Gnome thing.
>
>
> ​Except I'm using KDE. :-) I did see the setting in the KDE Display
> control panel, but adjusting it does not persist and did not cause a
> resize. I'll have to dig into it further.
>
> When I started it as root, it did respect the -geometry set size in the
> resulting gnome session, but it failed when hardware acceleration was
> not available. I've not gotten that to work either even installing
> VirtualGL and starting vncserver -3dwm, but that isn't important for
> what I'm doing since I can use KDE.
>
>
> Craig Ruff
> NCAR/CISL
------------------------------------------------------------------------------
_______________________________________________
TurboVNC-Users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/turbovnc-users
