This fixes an edge case with the resize logic. At the moment, given where we are with v0.10 user acceptance testing, I suggest this stays on devel and gets back-ported if necessary.
This means we need to branch off v0.10 before merging this PR.
A call to rdpClientConProcessMsgClientRegionEx() from xrdp with the frame number set to MAX_INT acks all outstanding frames. This is useful when a decoder has been deleted for a resize.
A second feature of this call is that it ensures the next frame sent is a key frame in progressive mode.
This is fine for a single monitor system. On a multi-monitor system however, this logic for this breaks one of the assumptions made by rdpDeferredUpdateCallback() which is that only updates for a single monitor are sent at one time. In heavy output situations, this can result in some corruption on a multi-monitor resize.
This PR separates out the key frame request from the frame ACK, and moves it into the memory allocation logic. Following a memory allocation or re-allocation, a key frame will always need to be sent for each monitor.
Getting a multi-monitor resize request with mstsc.exe is a challenge, but possible. The key is using the 'display' window of the settings application to change a monitor resolution when mstsc.exe is full screen. Do this as follows:-
1) Start the settings application, and find the 'Display' tab
2) Start a GFX multimon xrdp session
3) Run glxgears in two monitor windows to generate lots of rectangles
3) Hit CTRL-ALT-DEL and choose 'task manager' to bring the Windows taskbar to the foreground
4) Move to the settings app by using the taskbar and change the resolution of one of the monitors.
This will confuse mstsc.exe a bit, but it will recover by coming out of full-screen and re-entering full-screen.
This fixes an edge case with the resize logic. At the moment, given where we are with v0.10 user acceptance testing, I suggest this stays on devel and gets back-ported if necessary.
This means we need to branch off v0.10 before merging this PR.
A call to rdpClientConProcessMsgClientRegionEx() from xrdp with the frame number set to MAX_INT acks all outstanding frames. This is useful when a decoder has been deleted for a resize.
A second feature of this call is that it ensures the next frame sent is a key frame in progressive mode.
This is fine for a single monitor system. On a multi-monitor system however, this logic for this breaks one of the assumptions made by rdpDeferredUpdateCallback() which is that only updates for a single monitor are sent at one time. In heavy output situations, this can result in some corruption on a multi-monitor resize.
This PR separates out the key frame request from the frame ACK, and moves it into the memory allocation logic. Following a memory allocation or re-allocation, a key frame will always need to be sent for each monitor.
Getting a multi-monitor resize request with mstsc.exe is a challenge, but possible. The key is using the 'display' window of the settings application to change a monitor resolution when mstsc.exe is full screen. Do this as follows:-
1) Start the settings application, and find the 'Display' tab 2) Start a GFX multimon xrdp session 3) Run glxgears in two monitor windows to generate lots of rectangles 3) Hit CTRL-ALT-DEL and choose 'task manager' to bring the Windows taskbar to the foreground 4) Move to the settings app by using the taskbar and change the resolution of one of the monitors.
This will confuse mstsc.exe a bit, but it will recover by coming out of full-screen and re-entering full-screen.