[3.0] Mouse does not work in AppVMs on second monitor

[v6ak]

Summary

For apps in dom0, it works perfectly. For AppVMs, it seems some GUI daemon (not sure if the dom0 part or the domU part) positions the mouse cursor wrong.

My setup

• Laptop with internal screen (1600×900) and external screen (1280×1024).
• The external screen is placed right to the internal screen.
• Configured by arandr in Xfce with KWin, but this probably does not matter.
• Qubes 3.0.
• DomU: Both Fedora 23 and Debian 8 (they behave the same).

Behavior

Apps on left (internal) screen: Everything is OK.

Apps on right (external) screen: Interactions with Kwin and dom0 apps work. Mouse interactions with domU apps don't work (silently ignored). (Of course, I can move the window by mouse, but I can't interact with the content.) Keyboard interactions with these domU apps work correctly.

DomU apps on both screens: This seems to be the most interesting part. When I have some domU app on both screens, mouse interactions work on left screen, but they are buggy on the right screen. When I click the right screen, it clicks on the rightmost point of the left screen (i.e. bad x coordinate and good y coordinate). I hope this behavior suggests where the bug is.

[marmarek]

Most likely VM didn't receive proper screen layout, so it thinks that your right screen doesn't exists. I guess you've connected external screen after starting those VMs, right?

There is a tool qubes-monitor-layout-notify (run with VM name as parameter, or no parameter to notify all the VMs), which is responsible for passing dom0 screen layout to VMs. And there is a second tool /usr/libexec/qubes/watch-screen-layout-changes, which register itself for Xrandr notifications and call the before mentioned tool when screen layout changed. So I guess there is a problem with the later tool.

[marmarek]

Most likely VM didn't receive proper screen layout, so it thinks that your right screen doesn't exists. I guess you've connected external screen after starting those VMs, right?

There is a tool qubes-monitor-layout-notify (run with VM name as parameter, or no parameter to notify all the VMs), which is responsible for passing dom0 screen layout to VMs. And there is a second tool /usr/libexec/qubes/watch-screen-layout-changes, which register itself for Xrandr notifications and call the before mentioned tool when screen layout changed. So I guess there is a problem with the later tool.

[v6ak]

Good point. When I start a new DVM, the problem does not occur. So, you guess looks right.

I've tried running qubes-monitor-layout-notify manually and it has solved the issue for all running VMs. Moreover, I can't reproduce the issue now. So, the /usr/libexec/qubes/watch-screen-layout-changes seems to be working now.

[v6ak]

Good point. When I start a new DVM, the problem does not occur. So, you guess looks right.

I've tried running qubes-monitor-layout-notify manually and it has solved the issue for all running VMs. Moreover, I can't reproduce the issue now. So, the /usr/libexec/qubes/watch-screen-layout-changes seems to be working now.

[marmarek]

If it happens more than once for you, can you attach strace to watch-screen-layout-changes? And send output from missed event? Recommended strace command line:

strace -fttv -s 300 -o some-file.strace -p `pidof watch-screen-layout-changes`

[marmarek]

If it happens more than once for you, can you attach strace to watch-screen-layout-changes? And send output from missed event? Recommended strace command line:

strace -fttv -s 300 -o some-file.strace -p `pidof watch-screen-layout-changes`

[v6ak]

This was the first time I have the issue encountered. But I don't use multiple monitors so frequently.

I've saved the command and I will debug it if it occurs again. Anyway, thanks for pointing to the workaround.

[v6ak]

This was the first time I have the issue encountered. But I don't use multiple monitors so frequently.

I've saved the command and I will debug it if it occurs again. Anyway, thanks for pointing to the workaround.

[v6ak]

It seems I've encountered the opposite issue now. After removing a monitor, a VM still seems to consider it being present. At least Iceweasel renders some dropdown menus outside of the screen. A newly started DVM does not do this.

There is xrandr output from the affected AppVM:

% xrandr 
Screen 0: minimum 64 x 64, current 1600 x 900, maximum 32767 x 32767
DUMMY0 connected 1600x900+0+0 0mm x 0mm
   QB2880x1024   48.63 +
   QB1600x900    59.95* 
DUMMY1 disconnected
DUMMY2 disconnected
DUMMY3 disconnected

I don't understand the xrandr output. It suggests that the resolution (1600×900) is OK, but I don't know that the line QB2880x1024 48.63 + means. The dimension 2880×1024 looks like when both monitors are connected.

Interesting fact: qubes-monitor-layout-notify does not fix that.

I've also some strace output from it, but I am unsure if the interesting info is there. I had the command running permanently with output to console and the timestamps suggest that the start is missing. But I can post what I have. I also can post report from stracing qubes-monitor-layout-notify. Maybe the qubes-monitor-layout-notify is called always properly, but it maybe fails in some situations.

[v6ak]

It seems I've encountered the opposite issue now. After removing a monitor, a VM still seems to consider it being present. At least Iceweasel renders some dropdown menus outside of the screen. A newly started DVM does not do this.

There is xrandr output from the affected AppVM:

% xrandr 
Screen 0: minimum 64 x 64, current 1600 x 900, maximum 32767 x 32767
DUMMY0 connected 1600x900+0+0 0mm x 0mm
   QB2880x1024   48.63 +
   QB1600x900    59.95* 
DUMMY1 disconnected
DUMMY2 disconnected
DUMMY3 disconnected

I don't understand the xrandr output. It suggests that the resolution (1600×900) is OK, but I don't know that the line QB2880x1024 48.63 + means. The dimension 2880×1024 looks like when both monitors are connected.

Interesting fact: qubes-monitor-layout-notify does not fix that.

I've also some strace output from it, but I am unsure if the interesting info is there. I had the command running permanently with output to console and the timestamps suggest that the start is missing. But I can post what I have. I also can post report from stracing qubes-monitor-layout-notify. Maybe the qubes-monitor-layout-notify is called always properly, but it maybe fails in some situations.

[marmarek]

On Mon, Jan 11, 2016 at 03:58:12AM -0800, Vít Šesták wrote:

It seems I've encountered the opposite issue now. After removing a monitor, a VM still seems to consider it being present. At least Iceweasel renders some dropdown menus outside of the screen. A newly started DVM does not do this.

There is xrandr output from the affected AppVM:

% xrandr 
Screen 0: minimum 64 x 64, current 1600 x 900, maximum 32767 x 32767
DUMMY0 connected 1600x900+0+0 0mm x 0mm
   QB2880x1024   48.63 +
   QB1600x900    59.95* 
DUMMY1 disconnected
DUMMY2 disconnected
DUMMY3 disconnected

I don't understand the xrandr output. It suggests that the resolution (1600×900) is OK, but I don't know that the line QB2880x1024 48.63 + means. The dimension 2880×1024 looks like when both monitors are connected.

This looks ok - like X server see only one output. Maybe it fixed
somehow itself somehow in between checks? Are you sure you are checking
the right VM?

Interesting fact: qubes-monitor-layout-notify does not fix that.

I've also some strace output from it, but I am unsure if the interesting info is there. I had the command running permanently with output to console and the timestamps suggest that the start is missing.

Like terminal buffer was too small, or like nothing happened?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Mon, Jan 11, 2016 at 03:58:12AM -0800, Vít Šesták wrote:

It seems I've encountered the opposite issue now. After removing a monitor, a VM still seems to consider it being present. At least Iceweasel renders some dropdown menus outside of the screen. A newly started DVM does not do this.

There is xrandr output from the affected AppVM:

% xrandr 
Screen 0: minimum 64 x 64, current 1600 x 900, maximum 32767 x 32767
DUMMY0 connected 1600x900+0+0 0mm x 0mm
   QB2880x1024   48.63 +
   QB1600x900    59.95* 
DUMMY1 disconnected
DUMMY2 disconnected
DUMMY3 disconnected

I don't understand the xrandr output. It suggests that the resolution (1600×900) is OK, but I don't know that the line QB2880x1024 48.63 + means. The dimension 2880×1024 looks like when both monitors are connected.

This looks ok - like X server see only one output. Maybe it fixed
somehow itself somehow in between checks? Are you sure you are checking
the right VM?

Interesting fact: qubes-monitor-layout-notify does not fix that.

I've also some strace output from it, but I am unsure if the interesting info is there. I had the command running permanently with output to console and the timestamps suggest that the start is missing.

Like terminal buffer was too small, or like nothing happened?

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[v6ak]

This looks ok - like X server see only one output.

OK, I have looked deeper and found that a new instance of Iceweasel behaves correctly. Also, Iceweasel restart (without restarting the VM) corrected the behavior. So, this issue is probably unrelated to the original issue and also probably unrelated to Qubes at all.

Like terminal buffer was too small, or like nothing happened?

Terminal buffer was too small.

[v6ak]

This looks ok - like X server see only one output.

OK, I have looked deeper and found that a new instance of Iceweasel behaves correctly. Also, Iceweasel restart (without restarting the VM) corrected the behavior. So, this issue is probably unrelated to the original issue and also probably unrelated to Qubes at all.

Like terminal buffer was too small, or like nothing happened?

Terminal buffer was too small.

[marmarek]

On Mon, Jan 11, 2016 at 04:30:54AM -0800, Vít Šesták wrote:

Terminal buffer was too small.

Use -o something to log to file. Then you can tail -f that file to
watch it, if you want.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Mon, Jan 11, 2016 at 04:30:54AM -0800, Vít Šesták wrote:

Terminal buffer was too small.

Use -o something to log to file. Then you can tail -f that file to
watch it, if you want.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[ChipWolf]

Experiencing the same issue. qubes-monitor-layout-notify does not appear to solve the problem

[ChipWolf]

Experiencing the same issue. qubes-monitor-layout-notify does not appear to solve the problem

[roughshod]

Hello, having a similar issue on 3.2 running 3x4k displays on a Radeon HD 7850. Upgraded to qubes-gui-dom0-3.2.8-1.fc23 per #2421 and no change. The mouse only works when app VM windows are positioned on the primary display. No change in resolution is taking place, it boots up with the correct configuration. When I try to issue qubes-monitor-layout-notify appvm it seems to exit clean with no errors however the condition persists. Running qubes-monitor-layout-notify with no arguments hangs on Waiting for qubes-session...

[roughshod]

Hello, having a similar issue on 3.2 running 3x4k displays on a Radeon HD 7850. Upgraded to qubes-gui-dom0-3.2.8-1.fc23 per #2421 and no change. The mouse only works when app VM windows are positioned on the primary display. No change in resolution is taking place, it boots up with the correct configuration. When I try to issue qubes-monitor-layout-notify appvm it seems to exit clean with no errors however the condition persists. Running qubes-monitor-layout-notify with no arguments hangs on Waiting for qubes-session...

[marmarek]

Does the VM see a correct screen layout (xrandr command in VM)?

[marmarek]

Does the VM see a correct screen layout (xrandr command in VM)?

[kravietz]

Same here on 3.2 - after moving AppVM window to the second screen, mouse events stop working. Keyboard still works fine. Xrandr seems to only see one monitor:

$ xrandr
Screen 0: minimum 64 x 64, current 1920 x 1080, maximum 32767 x 32767
DUMMY0 connected 1920x1080+0+0 325mm x 182mm
   QB1920x1080   46.10*+
DUMMY1 disconnected

[kravietz]

Same here on 3.2 - after moving AppVM window to the second screen, mouse events stop working. Keyboard still works fine. Xrandr seems to only see one monitor:

$ xrandr
Screen 0: minimum 64 x 64, current 1920 x 1080, maximum 32767 x 32767
DUMMY0 connected 1920x1080+0+0 325mm x 182mm
   QB1920x1080   46.10*+
DUMMY1 disconnected

[marmarek]

Try running `qubes-monitory-layout-notify` tool in dom0.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[marmarek]

Try running `qubes-monitory-layout-notify` tool in dom0.

…

-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?

[jaseg]

I have that same issue reproducibly every time I disconnect and reconnect a second monitor. In my case, manually running qubes-monitor-layout-notify manually fixed it temporarily. Attached is an strace of the running watch-screen-layout-changes process as suggested by @marmarek in #1599 (comment) .

Edit: The trace is of the daemon while a second monitor has been attached. The geometry before was 1366x768, after 3926x1440 with the second monitor being 2560x1440 positioned right of and aligned flush to the top with the first monitor.

strace.txt

[jaseg]

I have that same issue reproducibly every time I disconnect and reconnect a second monitor. In my case, manually running qubes-monitor-layout-notify manually fixed it temporarily. Attached is an strace of the running watch-screen-layout-changes process as suggested by @marmarek in #1599 (comment) .

Edit: The trace is of the daemon while a second monitor has been attached. The geometry before was 1366x768, after 3926x1440 with the second monitor being 2560x1440 positioned right of and aligned flush to the top with the first monitor.

strace.txt