Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Initial screen size not saved as available RRMode #16

Open
jojothe opened this issue Jul 18, 2014 · 7 comments
Open

Initial screen size not saved as available RRMode #16

jojothe opened this issue Jul 18, 2014 · 7 comments
Labels
enhancement New feature or request

Comments

@jojothe
Copy link

jojothe commented Jul 18, 2014

[Originally posted on SourceForge just before the move. Apologies for the duplicate if you already saw it there. This version has better information anyway.]

If the initial screen size (i.e. the "-geometry" argument to "vncserver") is not one of the built-in defaults (in unix/xserver/hw/vnc/xvnc.cc vncRandRWidths[]/vncRandRHeights[]), then the non-default mode is first created in vncRandRInit(), used to set the initial screen size, and promptly destroyed with RRModeDestroy(). As a result, this screen size continues to work until you switch to something else, then you can never switch back to it.

The specific example that bites me:
% vncserver -geometry 2560x1600
[connect to it with viewer; works perfectly at 2560x1600]
% xrandr -s 1920x1080 [works as expected]
% xrandr -s 2560x1600 [fails - "not found in available modes"]

The solution is (probably) to modify vncRandRCrtcCreate() to check whether pScreen's size matches one of the default sizes, and if not, make an extra call to:

vncRandRModeGet(pScreen->width, pScreen->height);

This will effectively register pScreen's non-default initial size as one of the permanently available modes; the extra "create" here ensures that the create/destroy pair in vncRandRInit() will not eliminate it. Note that the 1.2 branch does essentially the same thing in vncRandRGetInfo(), hence it does not suffer from this bug.

@jojothe
Copy link
Author

jojothe commented Aug 30, 2017

This appears to be fixed in 1.8.0. Thanks!

@jgeorgeson
Copy link

I am still seeing this with 1.8.0-1.el7 as packaged in CentOS 7.x.

@CendioOssman
Copy link
Member

That works fine for me. What does xrandr list as modes once you've switched to 1920x1080?

@jgeorgeson
Copy link

In trying to nail down the sequence of configurations and steps I've discovered it's the combination of TigetVNC viewer and server (at least having a client that is able to send resize commands). It seems to only support one custom resolution at a time, which is marked in the xrandr output with a +.

The culprit seems to be the two resize options in the client. When I use Resize remote session to the local window and the remote session is already set >= resolution than my local display (such as having set remote to 1920x1080 when connecting from a QHD monitor and then later connecting from a 1920x1080 laptop monitor so both remote and local are 1920x1080, which is precisely when I want to change it to 1440x900) it replaces the 1440x900 that I set using -geometry with the resized version of the existing resolution (1920x1080 becomes 1920x1053, which replaces 1440x900 in xrandr's list of resolutions).

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

my systemd unit file:

[Unit]
Description=Remote desktop service (VNC)
After=syslog.target network.target

[Service]
Type=forking
# Clean any existing files in /tmp/.X11-unix environment
ExecStartPre=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'
ExecStart=/sbin/runuser -l hbl4218  -c "/usr/bin/vncserver %i -depth 24 -geometry 1440x900"
PIDFile=/home/hbl4218/.vnc/%H%i.pid
ExecStop=/bin/sh -c '/usr/bin/vncserver -kill %i > /dev/null 2>&1 || :'

[Install]
WantedBy=multi-user.target

Awkwardly, if I restart the server, and connect with both the resize remote session options disabled, then I am given a remote session 1920x1080, instead of the 1440x900 specified in the systemd file, but 1440x900 is retained as the custom resolution and I can switch back and forth.

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

If I use the Resize remote session on connect option and specify something that fits within my local resolution but is not in the xrandr permanent resolutions then I again lose 1440x900 from the list

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

I could use the Resize remote session on connect but there will be just as many times when I don't want it to resize but forget. So I'd have to always remember to check the options every time before connecting. I could have separate config files for each resolution with the resize on connect option but I can't open those sessions with OS default file associations (ie double-click, #38), so I'm back to having to click through the GUI. So ultimately I think that the server supporting -randr for us to add our desired resolutions as "permanent" in would eliminate these shenanigans.

@CendioOssman
Copy link
Member

Ah. That would explain why it is seemingly random. Would need something explicit for this then.

However this would not prevent things from resizing if the client requests it. We have the setting AcceptDesktopSize that might be more what you are after?

@jgeorgeson
Copy link

Disabling the resizing features is just a means to end in this instance and not any real goal unto itself. In fact I really like that the capability is there as the lack has been my biggest gripe with VNC (compared to RDP on Windows) for quite some time. The real issue is that I want the resolution(s) I configured in the server to stay available to change back to when I need them. That would also let me use the resizing features when I want to.

@CendioOssman
Copy link
Member

Alright. So let's reopen this issue and see if someone can have a look at implementing it.

@CendioOssman CendioOssman reopened this Feb 7, 2018
@CendioOssman CendioOssman changed the title Initial screen size not saved as available RRMode Initial screen size not saved as available RRMode [$100] Apr 20, 2018
@CendioOssman CendioOssman added the bounty There is a bounty for this issue label Apr 20, 2018
@CendioOssman CendioOssman changed the title Initial screen size not saved as available RRMode [$100] Initial screen size not saved as available RRMode May 30, 2024
@CendioOssman CendioOssman removed the bounty There is a bounty for this issue label May 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants