Mouse grab / capture

[totaam]

Issue migrated from trac ticket # 1229

component: client | priority: major | resolution: fixed

2016-06-15 14:44:24: fervi created the issue

---

Hello

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.

[totaam]

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

Please close if that works for you.

[totaam]

2016-06-17 17:17:27: fervi commented

---

@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)

[totaam]

@fervi:

• how: press right control key
• Perhaps the feature does not work: are you sure you are running the latest code? download from https://xpra.org/beta if needed.

[totaam]

2016-06-17 20:09:48: fervi commented

---

@antoine

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?

[totaam]

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

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

[totaam]

2016-06-18 10:47:54: fervi commented

---

@antoine

EDIT: dead youtube link
no ctrl - Control button is not pressed
ctrl - Control button was pressed (several times for tests)

http://gmclan.org/uploader/6184/keyboard.txt

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

[totaam]

2016-07-31 07:23:59: ironiridis commented

---

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

[totaam]

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.

[totaam]

Important: the shortcuts have just been changed, see r13169

[totaam]

2016-08-02 13:50:00: ironiridis commented

---

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

Ran with ...
[[BR]]
Should be something like (paths may vary):

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

Otherwise you will be using the system installed version.
[[BR]]
(See #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.
[[BR]]

With grab logging, no events are logged when I press the Menu or Control_R keys.
[[BR]]
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.

[[BR]]

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 #139#comment:38:

Important: the shortcuts have just been changed, see r13169
[[BR]]
Noted; I'll checkout and build r13169.

[totaam]

2016-08-02 13:51:20: ironiridis commented

---

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

[totaam]

Attachment or inline?

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

[totaam]

Not heard back.

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

[totaam]

2016-09-09 00:12:35: fervi commented

---

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

[totaam]

2016-09-09 02:58:37: antoine commented

---

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

[totaam]

2016-09-30 03:24:27: afarr commented

---

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.

[totaam]

• the keyboard shortcuts defined are found in "40_client.conf", you can modify them there if needed - no Control_R or Alt_L in there...
• with the current builds, the defaults are: "Control+Menu:toggle_keyboard_grab" and "Shift+Menu:toggle_pointer_grab", you can see this with "xpra showconfig"
• for debugging, include "-d grab" (add "keyboard" for more)
• virtualbox's mouse integration interferes with pointer grabs, turn it off for testing
• virtualbox's "host" key can interfere with keyboard grabs (it defaults to the right menu key), change the key to something else for testing

---

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:

• with keyboard grab: keys normally intercepted by the OS (ie: the "windows" key, Alt-Tab), should be forwarded to the server whilst the grab is active
• the pointer grab should be obvious: the pointer is confined to the window which has the grab until the grab is broken (ie: Alt-Tab away, a new window is shown, "Escape" key, etc) - this should work even with strange multi monitor setups

[totaam]

2016-10-01 00:37:19: maxmylyn commented

---

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

• Mouse grab works in the sense that it will hold the mouse within the confines of the window.

However there are a couple caveats:

• Moving the cursor to the bare edge of the top of window in Windows will cause the cursor to be ~1 pixel above the actual top of the window, up onto the actual window border. If you're playing a game that relies on the mouse to move around, you're going to end up in a really really weird state. I had to force quite Red Orchestra because it was moving in circles and I was concerned I was going to get motion sickness. If you were playing an RTS that uses mousing along the edge of a window to pan the camera, you're going to end up in a similar state where it's just endlessly moving.

• When cursoring into a window, upon clamping the mouse to the window, you have to move the mouse all the way from one side to the other to get it to "re-center" if you're using an application with a custom cursor that hides the real cursor. Example: games or applications that use a custom cursor - initially mousing in causes the fake cursor and the real cursor to desync, not allowing you to cursor all the way over to one side.

Passing back to you.

[totaam]

@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/11707312/428751]: Windows won't give you the correct value. And it's worse in Windows 10: [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?

[totaam]

2016-10-24 23:35:38: maxmylyn commented

---

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

• No longer seeing the "re-center" issue at all.

• It was basically application's cursor and the system cursor being somewhat near each other or not near each other while showing up at the same time.

• I'm also not able to the cursor up to the title bar decoration anymore in Windows 8. It looks like the changes in r14095 and r14096 seems to have done the trick here.

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).