I think the issue is probably similar/same impact that I have of video partially messed up when a laptop lid is closed, and you remote into that laptop.
This all occurred when Microsoft pushed out the last patch for Windows 10 (Patch 2004). It fundamentally changed the way video was handled to some degree. The previous ticket is Windows 10 - 2004 update patch issues
Can only hope that a subsequent/future patch resolves this or, RemoteUtilities comes up with a work-around.
Yes perhaps, the issue might have been caused by something contained in the Windows update. However, it only makes sense to try updating to the latest 220.127.116.11 Beta 2 version first to see if the issue still persists when using the latest version, as in the 18.104.22.168 Beta 2 version we've replaced the monitor blanking mechanism and discontinued the Monitor driver, as well as the method of fetching the list of displays in the multiple monitor configurations is different from the previous versions. In addition, we plan to implement the ability to map remote monitors to local ones in our future updates.
Just a heads up, I installed the beta 2 and its "interesting". When locking the displays, the center screen goes off fully, and the 2 side screens go "very dark". See picture https://photos.app.goo.gl/5UPWAaSWz5poegqVA . But it's important to realize that you can still see the text (but it's more difficult) -- https://photos.app.goo.gl/hkUab3PQjQTXXNdC8 so its something, I like it better than before ... but you could not consider it "very secure" ! Another problem is the host mouse is fully rendered and moves around so it draws the eye to the screen (which would help people release there is content on those screens) so it seems important to not render the host cursor. I have set "render host cursor" to "never", but it's always rendered and tracking in locked display or unlocked display (I think that is probably a bug?). I would consider it progress though
I've checked with our developers on the issue - unfortunately, this is expected behavior which is also enhanced by the brightness settings of the remote monitors. However, we will try to improve the blanking screen feature in our future updates in order to make the monitors in the multimonitor setup darker.
Meanwhile, in case if you do have the brightness levels adjusted on the remote monitors - please try resetting the brightness level to the default values and see if this helps to resolve the issue.
I figured this was the solution to the display problem, but just wanted you to know it doesnt work “fully”. I actually have the monitors at 100% brightness, so I did drop it to 50% but if you know to look, you can still read the text. The real problem is you can see the mouse moving around and its NOT dimmed at all, its full brightness so it really stands out on the black background, this white mouse moving around. This causes people to come over it see whats going on, so can you please make the devs aware that the “render host mouse” options are not working. I think if the mouse was NOT moving, (or was changed to a single pixel, something like that). most people would be fooled by the very-dark overlay being applied and ignore the screens. Overall I think its better than collapsing to a single display (like RDP) that the previous version did, so I am glad it’s progressing, if they could stop the mouse, I would be content with this solution myself.
In addition to what James is experiencing I am also seeing poor image quality, see attached. Also, the mouse back/forth functions on the remote mouse are not being sent over to the host, was this ever supported?
Is there a paid version of the software? We'd like to get faster response similar to [censored] , specially during the "work from home" period.