Xpra: Ticket #139: forward input grabs to the client

Hello,

some applications, in particular games, grab the mouse pointer and keyboard input. This is needed e.g. when you play a first-person-shooter (where you aim with the mouse) in a window. In this case you expect the mouse to stay inside the game's window. This behavior is broken in Xpra.

See X11_GrabInputNoLock(_THIS, SDL_GrabMode mode) in SDL's source code for how it's done - the X11 functions seem to be the following two:

Calling those must, I assume, give some kind of feedback to the WM that we can use to forward the grab commands to the client.



Thu, 27 Sep 2012 15:20:29 GMT - Antoine Martin: status, description, milestone changed


Fri, 15 Nov 2013 14:09:39 GMT - Antoine Martin: status, version, milestone changed

will try to deal with this as part of focus/input work in 0.12


Mon, 20 Jan 2014 11:15:36 GMT - Antoine Martin: owner, status changed


Mon, 03 Feb 2014 14:22:07 GMT - Antoine Martin: attachment set

captures NotifyGrab? and NotifyUngrab? events


Mon, 03 Feb 2014 14:45:11 GMT - Antoine Martin:

For some background, see: Input Event Processing

As per Grab Processing, the attachment/ticket/139/pointer-grab-stub.patch allows us to see when the client application requests a pointer grab and when it releases it.

We get those events on the composite helper because it recursively selects addXSelectInput on all the window's parents as part of the damage handle code... and the event is delivered to a parent window we aren't managing. This is a bit nasty.

Anyway, once we get one of those events, we can keep track of which window is meant to get all input, and make sure we deliver the events there. We can also forward the grab state to the client, which can try to honour it... For example, with gtk: gtk.gdk.pointer_ungrab But because this is all over the network and asynchronous, I'm not sure how well this can work.

For the keyboard, the events would be: Input Focus Events. (I think keyboard grabs are a lot less important than pointer grabs)


Mon, 03 Feb 2014 15:54:15 GMT - Antoine Martin: attachment set

implements pointer grabbing in gtk2


Mon, 03 Feb 2014 16:00:30 GMT - Antoine Martin: owner, status changed

The patch attachment/ticket/139/pointer-grab-v1.patch works surprisingly well in my limited testing, even on win32. Anything that shows a drop down menu is likely to trigger this, for testing see:

Please test more thoroughly (browser drop downs, context menus, etc), I am not committing this yet because this can cause complete display lockups if we grab the pointer without ungrabbing it...

Please also check if we can reverse r5176 (see #490) - in which case I would do a partial revert: only use the ugly osx workaround for servers that do not support grabs.


Mon, 03 Feb 2014 16:11:02 GMT - onlyjob: cc set


Tue, 04 Feb 2014 04:56:14 GMT - Antoine Martin: attachment set

better patch, should prevent client grab lockups


Tue, 04 Feb 2014 08:15:51 GMT - Antoine Martin:

Much cleaner implementation merged in r5346 (will make it easier to test): instead of coopting the composite helper, we create a new helper class, better able to track what we want.


Fri, 07 Feb 2014 20:36:37 GMT - J. Max Mena:

Tested it in Win7 using r5383 and got the following behavior:

Using Chrome I went to http://interfacelift.com/wallpaper/downloads/date/any/ and clicked on an arbitrary drop-down(I use this site a lot as the drop-down menus are quite large) and got the following behaviour:

Repeating the same test in Firefox, everything works as expected. Both alt-tabbing and clicking out causes the same drop-down to disappear.


Sat, 08 Feb 2014 07:51:45 GMT - Antoine Martin: owner changed

All the issues with Alt-Tabbing away are due to the fact we don't grab the keyboard, and until I can figure out how to get keyboard grab events from the X11 server, it will remain this way.

Which only leaves:

Drop downs won't disappear if you change focus to a different window in Windows


Is this by clicking? (the other sentences mention click or alt-tab explicitly, this one does not) How does this differ from the positive results posted above it?

Note: I have now reverted r5176 in r5396 (see #490), please re-test to ensure that the behaviour has not regressed.


Sat, 08 Feb 2014 15:46:01 GMT - Antoine Martin:

Update: the keyboard grabs don't do anything on win32 - AFAICT there is no such thing, so I have come up with an ugly hack as an alternative:

See commit messages for more details.

This solves the Alt-Tab problem for me. AFAIK, this should only leave one question to answer from comment:9


Sun, 09 Feb 2014 04:40:45 GMT - Antoine Martin:


Thu, 13 Feb 2014 18:36:34 GMT - J. Max Mena:

Sorry about not being specific enough, let me clarify:

On that website http://interfacelift.com/wallpaper/downloads/date/any/ in chrome, either clicking OR alt-tabbing out of Xpra wouldn't make the drop down disappear.

Also relevant, alt-tabbing into another Xpra window won't make it disappear, only by clicking in another Xpra window makes it disappear.

edit: Retested with r5444, behavior is still the same with interfacelift.


Fri, 14 Feb 2014 07:33:15 GMT - Antoine Martin: status changed; resolution set

It's worse than I thought...

Running a well behaved application in the client with -d win32, I see:

callbacks for event WM_ACTIVATEAPP: [<bound method ClientExtras.activateapp of <xpra.platform.win32.gui.ClientExtras object at 0x01E7F730>>]
2014-02-14 06:47:20,809 WM_ACTIVATEAPP: 0/2700 UNGRAB_KEY=Escape, \
    client=XpraClient object at 0x1d17148 (xpra+client+gtk2+client+XpraClient at 0x104c460)>
lost focus whilst window has grab, simulating keypress: (65307, 'Escape', 27, 0, 0)

And on the server with -d keyboard:

world window lost focus
world window got focus
focus wid=20 has_focus=20
make_keymask_match(()) current mask: set(['mod2']), wanted: set([]), ignoring=9/['Escape'], keys_pressed={}
keynames(mod2)=set(['Num_Lock']), keycodes=[77], nuisance=False
make_keymask_match(remove) () modifier mod2 using 77, success: False
remove mod2 with keycode 77 did not work - trying to undo it!
handle_key(20,True,Escape,65307,9,()) keyboard_sync=True
handle keycode pressing 9: key Escape
fake_key(9, True)
cancelling key repeat timer: 9122 for Escape / 9
scheduling key repeat timer with delay 750 for Escape / 9
focus wid=20 has_focus=20
make_keymask_match(()) current mask: set(['mod2']), wanted: set([]), ignoring=9/['Escape'], keys_pressed={9: 'Escape'}
keynames(mod2)=set(['Num_Lock']), keycodes=[77], nuisance=False
make_keymask_match(remove) () modifier mod2 using 77, success: True
handle_key(20,False,Escape,65307,9,()) keyboard_sync=True
handle keycode unpressing 9: key Escape
fake_key(9, False)
cancelling key repeat timer: 9445 for Escape / 9
make_keymask_match(('mod2',)) current mask: set([]), wanted: set(['mod2']), ignoring=None/['lock'], keys_pressed={}
keynames(mod2)=set(['Num_Lock']), keycodes=[77], nuisance=False
make_keymask_match(add) ('mod2',) modifier mod2 using 77, success: True

Showing that we detect the loss of focus client side with the WM_ACTIVATEAPP event, and then press and release the Escape key on the server, causing the drop down menu to disappear. (the focus change detection code works with both clicks and alt-tab)

So all is working well and I am closing this ticket, feel free to re-open if I've missed anything.


The problem with chrome is different and I am moving it to #519


Sat, 19 Apr 2014 03:49:48 GMT - Antoine Martin: status changed; resolution deleted

Got broken by the fixes in #556 ...

Which is annoying because r6120 added a better way of ungrabbing windows: using a dedicated packet rather than faking a keypress.


Sun, 20 Apr 2014 08:07:27 GMT - Antoine Martin: attachment set

fixes grabs but also crashes the server with X11 errors..


Sun, 20 Apr 2014 08:08:08 GMT - Antoine Martin:

AFAICT, the problem is that we cannot reliably determine the window which owns the grab by watching the focus NotifyGrab events.

The solution adopted in the patch attached:

And now I have to figure out why this causes crashes running gtkperf...


For reference, here are the docs on Focus Events Generated by Grabs


Sun, 20 Apr 2014 08:36:47 GMT - Antoine Martin: owner, status changed

Applied in r6133. The crashes were due to a call to get_geometry done outside the usual X11 locking (via trap.call).

This is a server side only fix, which will not be backported to v0.12 because it is too intrusive. Grabs will remain disabled for v0.12x.


Please re-test, especially on OSX and platforms I tend to test less (though I did test this quite a bit with XP as client).

Applications useful to test with (many at once is even better):

etc..


Mon, 21 Apr 2014 22:11:36 GMT - alas:

Testing with 0.13.0 r6140 server side and 0.12.3 r6067 with both windows and osx...

However, testing drop down and context menus behaves differently with each browser, in each OS.

OSX.

(Running client in -d focus mode, while testing the context menu, it looks like there is an update_focus([winID], False) _focused=[winID], where [winID]=chrome window id, while there is no sign of a focus mention of the POPUP_MENU window. Once the local window is clicked, this is followed by a send_focus(0) when focus shifts to the local window ... in case that helps.)

Meanwhile, on windows...

Many of these issues have been ongoing, but the firefox crash with OSX seems like it merits a closer look, and the apparent regression of the chrome popups appearing "behind" the window on OSX seems like it might be worth a closer look as well.

Let me know which permutations with which -d mode you'd like me to capture next.


Tue, 22 Apr 2014 14:23:59 GMT - Antoine Martin:

Apart from the obvious one (Firefox crashing - which I will investigate further), which ones are regressions?

FYI: the debug string for grabs is: -d grab, focus is also worth having since the two are related. send_focus(0) means that the focus is not on any of our windows (0 is the default "root window").


Tue, 22 Apr 2014 23:17:55 GMT - alas:

The google-chrome on OSX is a regression - where the POPUP_WINDOWs are displayed "behind" the google-chrome window (I just use facebook.com's signin page drop-downs for date of birth for checking).

A search of closed tickets reveals that it is a reversion of one of the cases of #490 (which seems to have been fixed by the attachment/ticket/490/focus-force-transientfor.patch?).

As you described in #490, the chrome seems to define the popups as a NORMAL rather than transient-for window... and the server does indeed seem to then pop the chrome window to the top since the popup click is a click on that window.

Here's an excerpt from the client-side -d grab, focus output:

2014-04-22 15:14:05,961 send_focus(17)
2014-04-22 15:14:05,961 send_focus(0)
2014-04-22 15:14:08,075 using audio codec: MPEG 1 Audio, Layer 3 (MP3)
2014-04-22 15:14:12,706 focus-in-event for wid=17
2014-04-22 15:14:12,707 ClientWindow(17) focus_change((ClientWindow(17), <GParamBoolean 'has-toplevel-focus'>)) has-toplevel-focus=True, _been_mapped=True
2014-04-22 15:14:12,707 update_focus(17, True) _focused=None
2014-04-22 15:14:12,707 send_focus(17)
2014-04-22 15:24:22,260 _unfocus() wid=23
2014-04-22 15:24:35,127 focus-out-event for wid=17
2014-04-22 15:24:35,127 ClientWindow(17) focus_change((ClientWindow(17), <GParamBoolean 'has-toplevel-focus'>)) has-toplevel-focus=False, _been_mapped=True
2014-04-22 15:24:35,128 update_focus(17, False) _focused=17

Checking the xpra info | grep window output I see that wid 17=google-chrome & window[23].window-type=('NORMAL',) ... and that window has no name. (At this point, it seems irrelevant to post the xpra info output, though I certainly can if you'd like me to.)

The remainder of the issues seem to be the issue of the hovering popups which refuse to relinquish top-level focus, which was a topic from #336, but was since moved here to #139... but which I didn't think had been fully addressed (though it looks like tickets were closed, so perhaps it was an issue that only persisted with lazarus?)


Wed, 23 Apr 2014 11:25:20 GMT - Antoine Martin:

afarr: the quoted "POPUP_MENU" and "POPUP_WINDOW" values from the comments above do not exist. As stated previously, chrome uses NORMAL. Please do not use code blocks for unverified or guessed values. Someone might be tempted to look them up and / or assume those were correct (extracted or cut & pasted from source or log files). And more importantly, it confuses me when I try to make sense of this bug report. Also transient-for and NORMAL are not mutually exclusive: transient-for is a flag that may be set, usually for override-redirect windows (another flag), NORMAL is one of the window-types.


Thu, 24 Apr 2014 11:25:19 GMT - Antoine Martin: attachment set

watch all the client windows and use the correct event mask


Thu, 24 Apr 2014 11:28:55 GMT - Antoine Martin:

With the grab-fix-watch.patch, grabs work again, even with chrome.

But we still have problems with osx, even some new ones:


Thu, 24 Apr 2014 15:10:05 GMT - Antoine Martin: attachment set

better patch, moving force ungrab code to common location


Thu, 24 Apr 2014 15:14:37 GMT - Antoine Martin:

Things left to do:


Fri, 25 Apr 2014 08:49:39 GMT - Antoine Martin:

Mostly merged the patch as-is in r6167 (client side refactoring) and r6168 (server side changes).

Still trying to figure out the Firefox problems on OSX (which does not rely on grabs, but still belongs here because these changes broke it, or just made it worse - AFAICT).

Comparing both client and server logs (-d all heavily edited) with OSX and Linux. From the moment we click outside the Firefox window (wid=2) which has a drop down menu shown.

With a Linux client (where the drop down disappears as expected), before we see the lost_window, we see a few:

damage Firefox

Whereas with an OSX client (where the whole window disappears), we see:

cursor_event (ignored - because on world window?)
lost_window: drop down menu
damage Firefox

Not sure why.


Client side:


Fri, 25 Apr 2014 08:55:13 GMT - Antoine Martin: attachment set

a much better test page to load (no ads, animations, etc - just a drop down and nothing else)


Fri, 25 Apr 2014 17:13:28 GMT - Antoine Martin:

Much improved in r6170: removed the helper class, use the actual window grab id from the event.

In order to catch all grabs, I think we need to modify the X11 server (ouch), as it shortcuts and skips sending grab events when the window with the grab is the current one (see GrabDevice -> ActivatePointerGrab -> DoEnterLeaveEvents ..)


Sat, 26 Apr 2014 05:17:22 GMT - Antoine Martin:

Just found out that the chrome drop down menus do set:

WM_WINDOW_ROLE(STRING) = "popup"

Which is better than nothing, and when choosing the window to use as parent we could also prefer the currently focused window (which is generally the browser window which generated the menu)


Sun, 04 May 2014 14:54:18 GMT - Antoine Martin:

I tried adding this patch to the Xorg server to be able to get grab notifications (added all the code before the return in dix/enterleave.c:DoEnterLeaveEvents):

    if (fromWin == toWin) {
        if (mode == NotifyGrab)
            CoreFocusEvent(pDev, FocusIn, mode, NotifyNonlinear, toWin);
        else if (mode == NotifyUngrab)
            CoreFocusEvent(pDev, FocusOut, mode, NotifyNonlinear, toWin);
        return;
    }

We get almost too many events (passive button grabs fire for example). Useful for debugging.


Sat, 17 May 2014 11:14:21 GMT - Antoine Martin: milestone changed

Re-scheduling.


Sat, 17 May 2014 14:27:15 GMT - Antoine Martin: owner, status changed

Re-assign.

Also some new pointers / examples:


Wed, 20 Aug 2014 23:07:53 GMT - alas:

Testing with osx 0.14.0-r7276 against a fedora 20 0.14.0-r7189 (trying to confirm behavior for this ticket vs. #490) ... I now find that pop-up menus no longer hold top-level focus when clicking focus over to a local application.

Works as expected with Windows and CentOS clients... and it works as expected with google-chrome on osx... but trying to click on a local application while a drop-menu is active on a firefox browser window is causing the firefox window to disappear.

Testing with the -d window flag active I saw the following logs, which seem to indicate that the window is getting a destroy command, perhaps mistakenly targeting the firefox window instead of the drop-menu window?:

2014-08-20 12:41:11,304 move_resize(31, 106, 710, 140, -1)
2014-08-20 12:41:11,305 resize(710, 140, 0)
2014-08-20 12:41:11,311 GL do_configure_event(<gtk.gdk.Event at 0x89a3b60: GDK_CONFIGURE x=31, y=106, width=710, height=140>)
2014-08-20 12:41:11,312 GLClientWindow(31 : GLPixmapBacking(31, (710, 140), None)).do_configure_event(<gtk.gdk.Event at 0x89a3b60: GDK_CONFIGURE x=31, y=106, width=710, height=140>)
2014-08-20 12:41:13,713 destroy_window(31, GLClientWindow(31 : GLPixmapBacking(31, (710, 140), None)))
2014-08-20 12:41:18,977 process_new_common: [32, 736, 601, 54, 322, {'opacity': -1, 'fullscreen': False, 'has-alpha': False, 'xid': '0xe00b53', 'pid': 14844, 'window-type': ('UTILITY',), 'maximized': False, 'transient-for': 30, 'override-redirect': True}], OR=True
2014-08-20 12:41:18,977 make_new_window(..) client_window_classes=[<class 'xpra.client.gl.gl_client_window.GLClientWindow'>, <class 'xpra.client.gtk2.border_client_window.BorderClientWindow'>], group_leader_window=<gtk.gdk.Window object at 0xd53e7b0 (GdkWindow at 0x117ac70)>
2014-08-20 12:41:18,977 GLClientWindow(..)
2014-08-20 12:41:18,977 <class 'xpra.client.gl.gl_client_window.GLClientWindow'>(<XpraClient object at 0x70db080 (xpra+client+gtk2+client+XpraClient at 0x18df240)>, <gtk.gdk.Window object at 0xd53e7b0 (GdkWindow at 0x117ac70)>, 32, 736, 601, 54, 322, {'opacity': -1, 'fullscreen': False, 'has-alpha': False, 'xid': '0xe00b53', 'pid': 14844, 'window-type': ('UTILITY',), 'maximized': False, 'transient-for': 30, 'override-redirect': True}, True, {})
2014-08-20 12:41:18,977 GLClientWindow(32 : None).apply_transient_for(30) window=GLClientWindow(30 : GLPixmapBacking(30, (1166, 949), YUV444P))
2014-08-20 12:41:18,977 set_window_type(['UTILITY']) hints=5
2014-08-20 12:41:18,978 GLClientWindow(32 : None).set_fullscreen(False)
2014-08-20 12:41:18,978 setup_window() has_alpha=False, <class 'xpra.client.gl.gl_window_backing.GLPixmapBacking'>.HAS_ALPHA=False
2014-08-20 12:41:18,978 make_new_backing(<class 'xpra.client.gl.gl_window_backing.GLPixmapBacking'>, 54, 322) effective backing class=<class 'xpra.client.gl.gl_window_backing.GLPixmapBacking'>, server alpha=False, window alpha=False
2014-08-20 12:41:18,987 GL do_configure_event(<gtk.gdk.Event at 0x89a3c98: GDK_CONFIGURE x=736, y=601, width=54, height=322>)
2014-08-20 12:41:18,988 GLClientWindow(32 : GLPixmapBacking(32, (54, 322), None)).do_configure_event(<gtk.gdk.Event at 0x89a3c98: GDK_CONFIGURE x=736, y=601, width=54, height=322>)
2014-08-20 12:41:18,988 GLClientWindow(32 : GLPixmapBacking(32, (54, 322), None)).window_state_updated(GLClientWindow(32 : GLPixmapBacking(32, (54, 322), None)), <gtk.gdk.Event at 0x89a3c68: GDK_WINDOW_STATE>) new_window_state=<flags 0 of type GdkWindowState>, fullscreen=False, maximized=False, iconified=False
2014-08-20 12:41:18,989 GLClientWindow(32 : GLPixmapBacking(32, (54, 322), None)).do_map_event(<gtk.gdk.Event at 0x89a3c68: GDK_MAP>) OR=True
2014-08-20 12:41:22,619 destroy_window(32, GLClientWindow(32 : GLPixmapBacking(32, (54, 322), None)))

Thu, 15 Jan 2015 10:37:44 GMT - Antoine Martin:

Found Find X.org pointer grab owner which is interesting: You can do this by pressing the XF86LogGrabInfo key


Thu, 30 Apr 2015 15:53:19 GMT - Antoine Martin: milestone changed

Re-scheduling, again.


Fri, 31 Jul 2015 00:06:54 GMT - alas:

Tested again osx client 0.15.4 r10055 against fedora 20 server 0.15.4 r10133,

It looks like the firefox is behaving the same as previously (open a pop-up, click on a local application with the pop-up open... the entire firefox window closes/crashes).

With -d window logs running client side, when I click on an outside application I get a similar destroy message:

2015-07-30 16:29:56,078 ClientWindow(6).do_map_event(<gtk.gdk.Event at 0x6bc68a8: GDK_MAP>) OR=True
2015-07-30 16:29:58,851 destroy_window(6, ClientWindow(6))

At this point the firefox window disappears, but the process doesn't seem to have ended in the xterm from whence it was launched. When I then use command-c to kill the firefox process I get indication that another window is being killed: 2015-07-30 16:51:24,910 destroy_window(4, ClientWindow(4)).

With chrome, the pop-ups behave as expected.

With a webkit based browser, like epiphany, I see the "older" behavior of the pop-up appearing as expected but not disappearing when focus is shifted to other applications (and not relinquishing top-level display focus even when other application windows are dragged "over" the pop-up, resulting in the other applications displaying as if they are being dragged "under" the pop-up).

In the case of epiphany, clicking on a pop-up generates: 2015-07-30 17:00:33,390 ClientWindow(15).do_map_event(<gtk.gdk.Event at 0x6bc6ce0: GDK_MAP>) OR=True.

Clicking on an outside application (& dragging it under the pop-up) seems to trigger the UI thread messaging:

2015-07-30 17:01:41,319 UI thread is now blocked
2015-07-30 17:01:41,320 UI thread is running again, resuming

Then clicking on one of the values of the pop-up destroys it: 2015-07-30 17:03:20,940 destroy_window(15, ClientWindow(15)) - though the value clicked on is retained in the proper field of the original window.


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

Milestone renamed


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

Is there a branch or a less stale patch somewhere that still implements pointer grabs? Happy to offer comprehensive testing and feedback on something closer to 0.17.x, as my usage case depends on mouse-look type behavior.


Mon, 01 Aug 2016 04:31:40 GMT - Antoine Martin: owner, status, summary changed

Is there a branch or a less stale patch somewhere that still implements pointer grabs?


This is now in trunk, see ticket:1229#comment:10.

Note: this is somewhat different from the original intent of this ticket (changed ticket title to reflect that): we don't (yet?) detect and forward when an application requests a grab, we just trigger it ourselves from a keyboard shortcut instead. Pure client side only, the server is not involved in any way and is not even aware that a grab is in effect client side.

@ironiridis: does this work for you?


Mon, 01 Aug 2016 21:49:03 GMT - Chris J Harrington: owner changed

Replying to antoine:

Is there a branch or a less stale patch somewhere that still implements pointer grabs?


This is now in trunk, see ticket:1229#comment:10.

Note: this is somewhat different from the original intent of this ticket (changed ticket title to reflect that): we don't (yet?) detect and forward when an application requests a grab, we just trigger it ourselves from a keyboard shortcut instead. Pure client side only, the server is not involved in any way and is not even aware that a grab is in effect client side.

@ironiridis: does this work for you?

Verified Menu key is being processed via xev. Built r13144 client with ./setup.py --without-csc_swscale --without-dec_avcodec2 --without-enc_x264 --without-enc_x265 --without-enc_ffmpeg --without-v4l2 --without-vpx --without-server --without-shadow build install --home=~/xpra/ Ran with DISPLAY=:0 xpra -d grab attach tcp:10.10.10.1:9997 Unfortunately no discernable difference. With grab logging, no events are logged when I press the Menu or Control_R keys. Verified that r13144 is running in both console output and Xpra tray menu "About" option.

Pure client side only, the server is not involved in any way and is not even aware that a grab is in effect client side.

I didn't modify the server build at all, which is running r12942.


Tue, 02 Aug 2016 03:56:14 GMT - Antoine Martin: owner changed

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.


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.

@ironiridis: can we move this to #1229, I want to keep #139 for the not-yet-implemented server grabs forwarding.


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

Important: the shortcuts have just been changed, see r13169


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

Replying to antoine:

@ironiridis: can we move this to #1229, I want to keep #139 for the not-yet-implemented server grabs forwarding.


Replied at ticket:1229#comment:13.


Sun, 21 Aug 2016 09:55:49 GMT - Antoine Martin: milestone changed

Milestone renamed


Wed, 15 Feb 2017 11:34:20 GMT - Antoine Martin: status changed; resolution set

As far as I am aware, we can only detect application requesting X11 server grabs by intercepting the API call using library tricks (ie: LD_PRELOAD), and we don't want to go down that route. #1229 should be enough for most purposes anyway.


Sat, 13 Apr 2019 06:12:33 GMT - Antoine Martin:

See also #1895 and #2270.


Sat, 23 Jan 2021 04:46:36 GMT - migration script:

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