mouse events are not passed down to VM's Xorg (fc15)

[marmarek]

Reported by joanna on 4 Jan 2012 18:59 UTC
... but the log properly reports mouse events being delivered, e.g.:

[qubes](root@work)# tail -20 gui_agent.log 
received message type 126
received message type 126
received message type 126
received message type 125
send buttonevent, win 0x1800003 type=4 button=1
handle property _NET_WM_USER_TIME for window 0x1e000e9
received message type 125
send buttonevent, win 0x1800003 type=5 button=1
received message type 126
received message type 126
received message type 126
received message type 126
received message type 126
received message type 126
received message type 126
received message type 126
received message type 126
received message type 127
received message type 128
0x1800003 lost focus

This happened suddenly, after some hours of successful use of this VM. Kbd events are injected fine.

Migrated-From: https://wiki.qubes-os.org/ticket/409

[marmarek]

Comment by joanna on 4 Jan 2012 19:00 UTC
Interestingly, after I closed some apps in this VM, the mouse started working again...

[marmarek]

Comment by joanna on 4 Jan 2012 19:00 UTC
Interestingly, after I closed some apps in this VM, the mouse started working again...

[marmarek]

Comment by marmarek on 4 Jan 2012 19:01 UTC
This looks like one of catches found on FC15. Have you clicked a right-bottom corner of gnome-terminal window? I haven't found any other workaround than closing all gnome-terminal windows...

[marmarek]

Comment by marmarek on 4 Jan 2012 19:01 UTC
This looks like one of catches found on FC15. Have you clicked a right-bottom corner of gnome-terminal window? I haven't found any other workaround than closing all gnome-terminal windows...

[marmarek]

Comment by joanna on 4 Jan 2012 19:10 UTC
I didn't have any terminal opened in this VM :)

[marmarek]

Comment by joanna on 4 Jan 2012 19:10 UTC
I didn't have any terminal opened in this VM :)

[marmarek]

Comment by marmarek on 4 Jan 2012 19:16 UTC
Ok, but still I think it is the same problem. Will try to find what this specific operation is.
Can you try to find what click causes this?

[marmarek]

Comment by marmarek on 4 Jan 2012 19:16 UTC
Ok, but still I think it is the same problem. Will try to find what this specific operation is.
Can you try to find what click causes this?

[marmarek]

Comment by joanna on 10 Jan 2012 09:56 UTC
It was a click in the right-bottom corner of the nautilus window in fc15. Closing the nautilus windows restores mouse operation for other windows of the vm.

[marmarek]

Comment by joanna on 10 Jan 2012 09:56 UTC
It was a click in the right-bottom corner of the nautilus window in fc15. Closing the nautilus windows restores mouse operation for other windows of the vm.

[marmarek]

Comment by marmarek on 10 Jan 2012 10:16 UTC
Looks that the same bug/feature. I think it is global for this gtk/gnome version (note that Gnome 3 was mostly rewritten from scratch)... Xtrace shows that application send XIGrabDevice to X server and does not ungrab it. Looks like a try to tell a window manager to resize window, but there is no window manager inside of VM (which should be detected by application, but unfortunately isn't).
On baremetal FC15 (and 16) it works correctly when window manager is running (window resizing is started), but on plain X server - the same behavior.

Perhaps it is related to http://developer.gnome.org/wm-spec/ _NET_WM_MOVERESIZE.

Will try to find some workaround for it (somehow tell the application that resize was finished or canceled or sth).

[marmarek]

Comment by marmarek on 10 Jan 2012 10:16 UTC
Looks that the same bug/feature. I think it is global for this gtk/gnome version (note that Gnome 3 was mostly rewritten from scratch)... Xtrace shows that application send XIGrabDevice to X server and does not ungrab it. Looks like a try to tell a window manager to resize window, but there is no window manager inside of VM (which should be detected by application, but unfortunately isn't).
On baremetal FC15 (and 16) it works correctly when window manager is running (window resizing is started), but on plain X server - the same behavior.

Perhaps it is related to http://developer.gnome.org/wm-spec/ _NET_WM_MOVERESIZE.

Will try to find some workaround for it (somehow tell the application that resize was finished or canceled or sth).

[marmarek]

Comment by marmarek on 15 Jan 2012 03:10 UTC
GTK+ 3 has a fallback for move/resize. When its detect absence of window manager (or at least WM not supporting move resize) - it tries to do it itself. But this code looks like at lease not compatible with Qubes GUI agent (if working at all).
Interesting code (function gdk_x11_window_begin_resize_drag):
http://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkwindow-x11.c?h=gtk-3-0#n4497

Workarounded by pretending that GUI agent is a window manager with support for move/resize. All such requests will be (of course) ignored, but it is enough to disable broken GTK+ fallback.

[marmarek]

Comment by marmarek on 15 Jan 2012 03:10 UTC
GTK+ 3 has a fallback for move/resize. When its detect absence of window manager (or at least WM not supporting move resize) - it tries to do it itself. But this code looks like at lease not compatible with Qubes GUI agent (if working at all).
Interesting code (function gdk_x11_window_begin_resize_drag):
http://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkwindow-x11.c?h=gtk-3-0#n4497

Workarounded by pretending that GUI agent is a window manager with support for move/resize. All such requests will be (of course) ignored, but it is enough to disable broken GTK+ fallback.

[marmarek]

Modified by marmarek on 15 Jan 2012 03:13 UTC

[marmarek]

Modified by marmarek on 15 Jan 2012 03:13 UTC

[marmarek]

Comment by marmarek on 15 Jan 2012 03:59 UTC
http://git.qubes-os.org/gitweb/?p=marmarek/gui.git;a=commit;h=a8e6343994a36761e92deca8f459fd35efae8575

[marmarek]

Comment by marmarek on 15 Jan 2012 03:59 UTC
http://git.qubes-os.org/gitweb/?p=marmarek/gui.git;a=commit;h=a8e6343994a36761e92deca8f459fd35efae8575