On 06/07/11 09:37, Михайло Падалка wrote: > Tue, 05 Jul 2011 13:18:54 +0200 > Mads Kiilerich<m...@kiilerich.com> писали: > >> Simon Guerrero wrote, On 07/05/2011 11:58 AM: >>> Hi >>> >>> I've been looking at the connect/disconnect sequences within freerdp >>> and trying to understand how the RDP session aligns with the Windows >>> session. >>> >>> Once a connection has been made and the user has logged in, is it >>> technically possible to change the session graphical characteristics >>> (e.g. width, height, bit depth) without having to re-enter the user >>> password? >> It is apparently not possible in the RDP protocol to resize a session on >> the fly. The client can emulate it by closing the session and creating a >> new one. > Please, do this: > 1) Login to terminal server with mstsc > 2) Open task manager, switch to 'Users' tab > 3) Right-click on any active user, which screen size differs from yours, and > select 'Remote control' > 4) mstsc will resize it's window to user's session size. > > So, width/height can be changed, at least in this special case. FreeRDP AFAIK > does not support this yet. >
Thanks guys for the responses. At the moment I'm using a wrapper script for this. But this obviously has re-authentication issues (assuming the user hasn't supplied the password on the command line ;-) I have two observations on the comments made - firstly, the purpose of this is to try and make connections more efficient when latency is high. So any change of resolution or depth can't just be a rendering change (i.e. client-side) as it defeats the point. Secondly, Windows 2008 (and maybe others) doesn't allow resolution change within an RDP session any more, at least not on any of the drivers I've tried. Any attempt to change it programmatically results in a return code of "RESTART NEEDED". This means that any solution can't rely on reacting to a change initiated from the remote server (e.g. by a virtual channel app). I am interested in the Server Save Session Info PDU mentioned earlier. How would that work? If I'm understanding correctly, it sounds as if it's a kind of "cookie" that we'd re-submit after disconnect and reconnect. But this would still require a full restart like I'm doing with the wrapper script, only I would be able to pass the "cookie" back in? Is this right, or am I missing the point? Many thanks Simon ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ Freerdp-devel mailing list Freerdp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freerdp-devel