Changes between Version 1 and Version 2 of Ticket #19784, comment 2

Timestamp:: Jun 16, 2023 10:55:19 PM (2 years ago)
Author:: Jim Avera

Legend:

: Unmodified
: Added
: Removed
: Modified

Ticket #19784, comment 2

-              v1
+              v2
+Still reproduced using VirtualBox 7.0, either between a VM and bare-metal system or two VMs.   It seems to depend on certain screen-size ratios.   I suspect (not sure) that the bug occurs when the "assisting" system's screen is vertically taller than the "assisted" machine's screen.
+[Revised with specific instructions to repro every time]
+I will attach a screenshot showing the problem with two Win10 VMs running as guests on linux host.
+Still reproduced using VirtualBox 7.0, either between a VM and bare-metal system or two VMs.   It seems to depend on certain screen-size ratios.   **I suspect (not sure) that the bug occurs when one of the screens has "odd" dimensions, e.g. not divisible by 2.**
+The overall window sizes *on the host* (from xwininfo) were:
+Here are instructions to repro every time using two VMs running Windows 10.  I used the 'xdotool' to set the window sizes, but probably you can do it manually as well.
+REPRO WITH TWO VMs on a Linux host:
 {{{
+[upper left] "assisted" : Width: 1331, Height: 529
+[lower right]"assisting": Width: 1073, Height: 724 (corruption visible)
+. sudo apt install xdotool # if necessary
+. Obtain a Windows 10 VM, called "A" here
+. Make a clone, called "B" here.  I used "Linked Clone" and "Generate new MAC..." options.
+    (do not re-use UUIDs or else the VMs can not run simultaneously)
+. Start both Windows VMs.  Put "A" in upper-left corner, "B" in lower-right.
+   Then in a terminal:
+. xdotool windowsize $(xwininfo | perl -n -e '/.*Window id: (\S*)/ && print $1') 997 777
+   Click in VM "A" to set it's window size
+. xdotool windowsize $(xwininfo | perl -n -e '/.*Window id: (\S*)/ && print $1') 1024 640
+   Click in VM "B" to set it's window size.
+. In both VM's run the "Quick Assist" app (type "Quick" into the Search bar to find it)
+a. In "B" (the 1024x640 one), click "Help someone", sign in (I used Github), and copy the security code it displays
+b. In "A" paste the code; click "Submit"; click "Allow" screen sharing
 }}}
 Note that the "assisted" machine (in upper left) is vertically shorter than the "assisting" machine in lower right.
+RESULTS: Corrupted screen image in maching "B".  See attached screenshot.
+I though this might be a Microsoft bug unrelated to VBox video, although at this point it would be surprising because their own support people would suffer from it.  I tried a VM "assisting" machine with large screen and a smaller bare-metal (laptop) "assisted" machine and did not see the problem.  Obviously not conclusive, but it's one datapoint indicating that the problem has somehow to do with VBox video on one end.  Especially because the problem *did* appear the other way around, i.e. if the VM window was vertically shorter than the laptop's screen.  Sorry but I don't have a large-screen bare-metal Windows box...
+The problem does not occur if machine A is an even size like 1000 x 768 instead of 997 x 777.   In general the size is set by users and difficult to control.
+**
+''Suggestion: If there is no easy way to support "odd" dimensions, then make VM windows (on the host) respond to resize events by snapping to the nearest even number of pixels.  So for example, when I told "A" to resize to 997 x 777, it would instead become 996 x 776.''**
+This ''might'' be a Microsoft bug unrelated to VBox video.  I can repro if "A" is the VM with size 997 x 777 and "B" is a bare-metal Windows box (laptop) with 1600 x 900.  I could not figure out how to use non-standard video modes on the laptop, so could not try the other way around.   The above suggestion would probably work around the bug if it is Microsoft's.
 I hope this helps.