Unresponsive Windows in Second Monitor, and Incorrect Dialog Placement in Certain Programs

[StoicDeveloper]

How to file a helpful issue

Qubes OS release

4.1.1

Brief summary

I'm experience various issues with my windowing system on 4.1.1. One of the issues is confined to using libreoffice, but I thought it made more sense to submit the issue here, since the issue began upon upgrading from 4.0 to 4.1, without changing libreoffice versions. The first issue is that when opening dialogs in a program, the dialogs are likely to be placed incorrectly. See screenshots. The may open in the middle of the window, or overlap other elements. Reopening the dialog can fix it momentarily, but the issue always reappears eventually.

Second, a window open in my second monitor will often become unresponsive. The window itself can still be controlled from its top panel, but its content will be static. The window is not frozen due to an error in the program, because simply moving the window to the primary monitor will make the window responsive. I can even place the window half in one monitor and half in the primary monitor, and the later half will be responsive and the former not. This seems to occur randomly, since it can be the case that windows from one VM are responsive in the second monitor, while windows from another VM are not.

Steps to reproduce

First issue - Open libreoffice. Select a drop-down menu 1 or more times. Eventually a menu will be placed incorrectly. Select sub-menus on a dropdown, see that they are also place incorrectly. The problem can be reproduced by nearly any activity that brings up a new dialog/menu.

Second issue - Connect a second monitor with an HDMI cable. Open firefox, move the firefox window to the second monitor, see that the program GUI can no longer accept input. The problem can occur with any program though.

Expected behavior

Menus should be placed correctly. Windows should be responsive in a second monitor.

Actual behavior

Incorrect placement. Unresponsive windows. In regards to the second issue, I've also noticed that when I click and drag inside an unresponsive program window, whose monitor is to the right of the primary monitor, it controls the scrollbar on this webpage, which is in the primary monitor. So it is as though any cursor activity on the second monitor is interpreted as occurring at the far right of the primary monitor.

[andrewdavidwong]

It looks like you've reported two bugs that may or may not turn out to have the same cause. Please note that every issue must be about a single, actionable thing. If the two bugs turn out to have the same cause, then having just this one issue for both is probably fine. However, in the event that they turn out not to have the same cause, this issue will be be devoted to only one of them, and you should open a separate issue for the other one.

[StoicDeveloper]

I understand. It was because both problems have something to do with the windowing system that I suspect they may have the same cause, and placed them in the same issue. If someone more qualified than myself determines that they are not cause by the same bug, then I'll gladly separate them.

[biergaizi]

I have been experiencing this problem for years. I suspect the problem occurs because the coordinate transformation code in the DomU agent doesn't correctly handle two monitors with mismatched sizes.

To replicate it, install two monitors, one set to horizontal and one vertical. Place the second vertical monitor at the right side of the first monitor, and center it vertically at the middle (so that the top most and bottom most areas of the second monitor are unique to the second monitor, as their Y coordinates are invalid for the first monitor).

Now, open a Gnome Terminal, drag it to the top side of the second monitor, then click a menu item, such as "File", "Edit", or "Help". Watch the location that the popup appears - it doesn't appear at the topmost position of the screen as one would expect, but it appears at somewhere at the center of the screen, with its coordinates aligned to the topmost Y axis of the first monitor. In general, any window placed at the top or bottom area of the vertical monitor behaves erratically.

So my guess is that Qubes Dom0/DomU agent assumes the desktop is a single rectangle and its coordinate system doesn't correctly handle two monitors with misaligned Ymin and Ymax.

[kainz]

This seems related to #9059, and I think you can currently trigger this on boot by having >2 monitors (maybe any monitor right-of-primary-display) by having any appVM set to startup-on-boot

[biergaizi]

Affects 4.2

[kainz]

FWIW my earlier posted repro is a 4.2 with debian domUs repro, as that's all I've used, qubes-wise.