Xpra: Ticket #1229: Mouse grab / capture


Some applications like games, virtual machines may require programs to the graphics capabilities capture the mouse (Mouse grab). Xpra from version to version is getting better software for remote operation, so I think that this option should be added.

Fri, 17 Jun 2016 04:47:04 GMT - Antoine Martin: owner changed

That's already the case as of r12645 (trunk), see ticket:1195#comment:1 for details.

Please close if that works for you.

Fri, 17 Jun 2016 16:17:26 GMT - fervi:

@antoine Don't know how (?)

Right Control does not capture the mouse or keyboard. Or maybe I don't understand this function

Perhaps the feature does not work (other shortcuts like Alt + Shift + F2 function)

Fri, 17 Jun 2016 16:18:49 GMT - Antoine Martin:


Fri, 17 Jun 2016 19:09:47 GMT - fervi:


Xpra was installed with the package; version 0.18.1 (17-Jun-2016 08:57) It is true that it comes from the repository winswitch http://winswitch.org/beta/

But checksum packet agrees with the sum of control repository xpra (beta).

In xpra --help is the shortcut key.

--key-shortcut = KEY_SHORTCUT
                         Define key shortcuts That will trigger specific
                         actions.If no shortcuts are defined, it defaults to:
                         Control_R: toggle_keyboard_grab

Maybe xpra must work in the "shadow" and not "multiple windows"? Or it may not work with qemu.

If, of course, you can check with each other; try and work with qemu-system-i386.

Surely this option allows you to capture mouse?

Sat, 18 Jun 2016 02:42:18 GMT - Antoine Martin:

What platform? Please try running with -d keyboard and post the output.

FYI: xpra and winswitch repositories are identical (symlinked).

Sat, 18 Jun 2016 09:47:53 GMT - fervi:


https://www.youtube.com/watch?v=SBZDwlzOMWY&feature=youtu.be no ctrl - Control button is not pressed ctrl - Control button was pressed (several times for tests)


Server and my computer have newest Xpra version; I have Debian Stretch (Devuan Ascii), Server - Debian Jessie

Tue, 12 Jul 2016 16:51:50 GMT - Antoine Martin: milestone changed

Milestone renamed

Sun, 31 Jul 2016 06:23:59 GMT - Chris J Harrington:

Duplicate of #139? fervi appears to be talk about mouse grab, antoine appears to be talking about keyboard grab.

Sun, 31 Jul 2016 16:05:35 GMT - Chris J Harrington: cc set

Mon, 01 Aug 2016 04:28:35 GMT - Antoine Martin:

Done in for pointer grabs in r13144. Use the "Menu" key to toggle pointer grabs. We confine the pointer to the window which had focus. We could also do an unconfined pointer grab if needed. (would require yet another key shortcut)

This is almost identical to #1195 but for grabbing the pointer instead of keyboard.

Mon, 01 Aug 2016 04:28:45 GMT - Antoine Martin: milestone changed

Tue, 02 Aug 2016 06:17:10 GMT - Antoine Martin:

Important: the shortcuts have just been changed, see r13169

Tue, 02 Aug 2016 12:49:59 GMT - Chris J Harrington: owner changed

Replying to antoine's ticket:139#comment:37:

Ran with ...

Should be something like (paths may vary):

PYTHONPATH=~/xpra/lib64/python/ ~/xpra/bin/xpra ...

Otherwise you will be using the system installed version.

(See ticket:139#comment:36) I verified in two different ways that the local build was running, both in the console and in the tray application's "About" menu. PYTHONPATH was exported in my environment.

With grab logging, no events are logged when I press the Menu or Control_R keys.

Please attach the client output with -d keyboard,grab. We want to verify the keyboard shortcuts are parsed correctly and that they are caught as well.

Will attempt again this evening with -d keyboard,grab. How do you want me to report my results? Attachment or inline? I imagine there will be a fair amount of output.

Replying to antoine's ticket:139#comment:38:

Important: the shortcuts have just been changed, see r13169

Noted; I'll checkout and build r13169.

Tue, 02 Aug 2016 12:51:20 GMT - Chris J Harrington: owner, status changed

Derp, fixing assign; meant to do that for #139, not this ticket.

Tue, 02 Aug 2016 15:54:11 GMT - Antoine Martin:

Attachment or inline?

Small: inline, big: attachment. Where small is roughly less than a page.

Wed, 10 Aug 2016 04:48:15 GMT - Antoine Martin:

Bump! (new beta builds posted)

Wed, 07 Sep 2016 10:57:37 GMT - Antoine Martin: owner, status changed

Not heard back.

@afarr: just a FYI, feel free to close. (see comment:10, the "Shift+Menu" key shortcut toggles pointer confinement)

Thu, 08 Sep 2016 23:12:34 GMT - fervi:

Still nothing. SUPER + Shift and Right_Control - not change anything

Fri, 09 Sep 2016 01:58:37 GMT - Antoine Martin:

@fervi: no debug info... so not likely to change since this is tested and working here.

Fri, 30 Sep 2016 02:24:27 GMT - alas: owner changed

Well, for what it's worth, I took a stab with 1.0 r13888 windows client against 1.0 r13912 fedora 23 server.

Control-R seems to trigger a (reverse-i-search)`'.

Meanwhile, Control_R (the right control button) seems to be recognized by the gtk_view_keyboard.py tool, but doesn't seem to allow me to do anything obvious in something like an xterm (nothing is outputted, no sign of any effect, pressing that key).

The keyboard tool recognizes it as follows:

down   Control_R       65508   109    1 0 ['2']
up     Control_R       65508   109    1 0 ['2', 'C']

The "Menu" key, meanwhile, outputs a '~' when typed into an xterm, but doesn't seem to have any other effect. In the keyboard tool, it outputs:

down   Menu    65383   117   0 0 ['2']
up     Menu    65383   117   0 0 ['2']

Just in case it seems relevant, the "Super" key (windows icon thing, from what I've managed to read) outputs this on the keyboard tool.

down    Alt_L       65513   64   1 0 ['2']
up      Alt_L       65513   64   1 0 ['2, '1']

Likewise, trying to use Control_R + Super, I see the following, (mostly) exactly as expected:

down    Control_R    65508   109   1 0 ['2']
down    Alt_L        65513   64    1 0 ['2', 'C']
up      Alt_L        65513   64    1 0 ['2', 'C', '1']
up      Control_R    65508   109   1 0 ['2', 'C']

Since SUPER + Shit is mentioned in the above comment... well, keyboard tool gives me the following for shift (left shift) + SUPER:

down    Shift_L      65505    50    1 0 ['2']
down    Meta_L       65511    64    1 0 ['2', 'S']
up      Meta_L       65511    64    1 0 ['2', 'S', '1']
up      Shift_L      65505    50    1 0 ['2', 'S']

Let me know if any more keyboard tests are needed.

Fri, 30 Sep 2016 07:10:29 GMT - Antoine Martin: owner changed

Turns out that GTK does not support pointer grabs at all on win32, so I've added support for it using ClipCursor via pywin32 in r13923. (behaviour is unlikely to be 100% identical to X11 clients). Keyboard grabs are not handled by GTK either, we already have pywin32 custom code for that too (see #1152 for details). OSX: not supported by GTK since this is not supported by the os: #1326

Summary of what this feature does for testing purposes:

Fri, 30 Sep 2016 23:37:18 GMT - J. Max Mena: owner changed

Tested with r13937 Windows 8.1 Client and a Fedora 23 r13941 trunk Client against a Fedora 23 r13941 trunk server:

However there are a couple caveats:

Passing back to you.

Mon, 10 Oct 2016 07:35:25 GMT - Antoine Martin: owner changed

@maxmylyn: is this specific to win 8.1 or does this occur with all version of windows? please include the "-d grab" log output and attach the output of "Native_gui.exe".

The problem is likely to be because of http://stackoverflow.com/a/34143777/428751: Windows 10 has thin invisible borders..

r14095 now uses SM_CYCAPTION (GetSystemMetrics) if the window has a caption. Maybe this will work better already? (r14096 will also log the vista-onwards-only DWMWA_EXTENDED_FRAME_BOUNDS) Hopefully we can calculate the correct inner window dimensions.

Works fine for me on XP and win7: tested with a simple xterm or xev, all the events land in the window, I cannot resize of move it whilst the grab is active.

I don't understand the "re-center" issue at all, can you include a screenshot?

Mon, 24 Oct 2016 22:35:37 GMT - J. Max Mena: status changed; resolution set

Upped server to r14271 (now Fedora 24), and client to r14228:

Since both issues I found have been fixed, and I can't induce any more, I'm gonna go ahead and close this ticket (finally).

Sat, 23 Jan 2021 05:18:29 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1229