Display changes lead to weird Xorg behaviour

[3hhh]

How to file a helpful issue

Qubes OS release

4.2

Brief summary

Switching to a different display leads to areas of the new display becoming unusable. Clicking on certain areas leads to clicks on other areas of the screen.

Steps to reproduce

1. I use my T530 without dock (Qubes OS booted, some VMs started, some windows open).
2. Attach it to the dock.
3. Attempt to work on the non-laptop display with the attached keyboard & mouse.

Expected behavior

Mouse clicks happen where the mouse is pointed at.

Actual behavior

Mouse clicks happen elswhere.

Notes

• This worked ~2-3 months ago, i.e. this is a regression.
• Restarting the dom0 display manager (awesomeWM in my case) doesn't help.
• Restarting the VMs with the unusable windows appears to help. It's however sometimes painful to do that (e.g. for sys-net to re-gain access to the tray icon functionality).

[0spinboson]

See the top of this guide -> https://www.qubes-os.org/doc/gui-troubleshooting/

[3hhh]

On 10/13/24 12:12, Foppe wrote:

See the top of this guide -> https://www.qubes-os.org/doc/gui-troubleshooting/

Hm, interesting. I had never needed that, but it was working ~2-3 months ago.

Anyway I just tried it with (25601440 + 19201080)*4/1024 = 22500 as I have a 2k and a FHD monitor, but it unfortunately did not resolve the issue.

[marmarek]

I just tried it with (25601440 + 19201080)*4/1024 = 22500 as I have a 2k and a FHD monitor

That's not enough, it's about rectangle covering them all. See the xrandr output (or the long xrandr command in the doc) to get the accurate number easily.

[3hhh]

I just tried it with (2560_1440 + 1920_1080)*4/1024 = 22500 as I have a 2k and a FHD monitor

That's not enough, it's about rectangle covering them all. See the xrandr output (or the long xrandr command in the doc) to get the accurate number easily.

The xrandr command returns 14400, i.e. even less.

xrandr output (without --verbose as it was too long) with both displays connected:

Screen 0: minimum 320 x 200, current 2560 x 1440, maximum 16384 x 16384
LVDS-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 193mm
   1920x1080     60.02*+  60.01    59.97    59.96    50.03    59.93  
   1680x1050     59.95    59.88  
   1400x1050     59.98  
   1600x900      59.99    59.94    59.95    59.82  
   1280x1024     60.02  
   1400x900      59.96    59.88  
   1280x960      60.00  
   1440x810      60.00    59.97  
   1368x768      59.88    59.85  
   1280x800      59.99    59.97    59.81    59.91  
   1280x720      60.00    59.99    59.86    59.74  
   1024x768      60.04    60.00  
   960x720       60.00  
   928x696       60.05  
   896x672       60.01  
   1024x576      59.95    59.96    59.90    59.82  
   960x600       59.93    60.00  
   960x540       59.96    59.99    59.63    59.82  
   800x600       60.00    60.32    56.25  
   840x525       60.01    59.88  
   864x486       59.92    59.57  
   700x525       59.98  
   800x450       59.95    59.82  
   640x512       60.02  
   700x450       59.96    59.88  
   640x480       60.00    59.94  
   720x405       59.51    58.99  
   684x384       59.88    59.85  
   640x400       59.88    59.98  
   640x360       59.86    59.83    59.84    59.32  
   512x384       60.00  
   512x288       60.00    59.92  
   480x270       59.63    59.82  
   400x300       60.32    56.34  
   432x243       59.92    59.57  
   320x240       60.05  
   360x202       59.51    59.13  
   320x180       59.84    59.32  
VGA-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
DP-1 disconnected (normal left inverted right x axis y axis)
HDMI-2 disconnected (normal left inverted right x axis y axis)
HDMI-3 disconnected (normal left inverted right x axis y axis)
DP-2 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 553mm x 311mm
   2560x1440     59.95*+
   2048x1152     60.00  
   1920x1200     59.88  
   1920x1080     60.00    50.00    59.94    30.00    25.00    24.00    29.97    23.98  
   1920x1080i    60.00    50.00    59.94  
   1600x1200     60.00  
   1680x1050     59.95  
   1280x1024     75.02    60.02  
   1200x960      59.99  
   1152x864      75.00  
   1280x720      60.00    50.00    59.94  
   1024x768      75.03    60.00  
   800x600       75.00    60.32  
   720x576       50.00  
   720x480       60.00    59.94  
   640x480       75.00    60.00    59.94  
   720x400       70.08  
DP-3 disconnected (normal left inverted right x axis y axis)

But ok, I'll try the rectangle covering it all, i.e. (2560 + 1920)*1440*4/1024 = 25200...

[3hhh]

But ok, I'll try the rectangle covering it all, i.e. (2560 + 1920)*1440*4/1024 = 25200...

No, that still didn't fix the issue. :(

[3hhh]

Btw I mirror the displays (and the larger one is sometimes disconnected) instead of extending them, i.e. 14400 is probably indeed the correct value.

Nonetheless that value doesn't work either: I can correctly click on the upper left area of the larger screen, but not on the lower right area.

[3hhh]

The recent updates apparently fixed this for most windows. The only very prominent exception is firefox (131.0.3 & 128.3.1esr), which refuses to accept right mouse clicks on websites (address and search bar right clicks tend to work) after a laptop undock followed by a dock. Interestingly, chromium doesn't have that issue.

A potentially relevant error message from firefox:

ATTENTION: default value of option mesa_glthread overridden by environment.
[GFX1-]: RenderCompositorSWGL failed mapping default framebuffer, no dt

Explicitly disabling firefox hardware acceleration doesn't work.

I can reliably reproduce this on two different WMs (awesomeWM & qtile, haven't tried XFCE yet), i.e. I'm pretty sure that this is either a Qubes OS GUI daemon or a firefox issue.

Dom0 kernel: 6.11.2-1, Xen 4.17.5

[3hhh]

P.S.: Resetting/Removing my firefox profile doesn't help.

[3hhh]

PPS: I just noticed that thunderbird is affected, too. Restarting the application (not the entire VM) works. Of course that's not an option in disposables which directly started the application (i.e. for firefox).

[3hhh]

Now it's happening more often and with other applications again... :(

[3hhh]

Hm, chromium appears to register itself for raw Xorg events (one can see that from e.g. xinput test-xi2 --root inside a VM - chromium uses raw event types, firefox doesn't), whereas firefox uses events processed by the Qubes OS keyboard driver (not sure how the usual event flow works)? Imho this indicates that there's likely some issue in the Qubes OS VM-side X event processing code as chromium manages to get the job done correctly, i.e. dom0 (incl. the Qubes GUI code & WM) must be fine. Btw I can see the right click both in dom0 xinput as well as in the VM, but firefox doesn't react anyway.

I believe it may be some kind of focus issue as I can now even reproduce it by opening a terminal inside a VM, starting firefox, clicking a bit around in firefox (right click works), clicking on the terminal, clicking back to firefox and right click doesn't work anymore. Switching workspaces sometimes also triggers it.

Do right clicks e.g. require EnterNotify/LeaveNotify events? I usually don't see those anymore once the issue occurs. If not these events, what kind of events does a successful right click need?

[3hhh]

Seems like this was mostly a WM issue/mistake: https://github.com/qtile/qtile/issues/5067.

Thanks for your support @marmarek !

[github-actions[bot]]

This issue has been closed as an "upstream issue." This means that the issue pertains to software that does not belong to the Qubes OS Project and that we do not develop or control. We suggest that you file this issue in the appropriate project's issue tracker instead. For more information, see Why don't you fix upstream bugs that affect Qubes OS?

We respect the time and effort you have taken to file this issue, and we understand that this outcome may be unsatisfying. Please accept our sincere apologies and know that we greatly value your participation and membership in the Qubes community.

If anyone reading this believes that this issue was closed in error or that the resolution of "upstream issue" is not accurate, please leave a comment below saying so, and we will review this issue again. For more information, see How issues get closed.