-
Notifications
You must be signed in to change notification settings - Fork 921
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
Comments
This appears to be fixed in 1.8.0. Thanks! |
I am still seeing this with 1.8.0-1.el7 as packaged in CentOS 7.x. |
That works fine for me. What does |
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
my systemd unit file:
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.
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
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 |
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 |
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. |
Alright. So let's reopen this issue and see if someone can have a look at implementing it. |
[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:
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.
The text was updated successfully, but these errors were encountered: