Bug 4286

Summary:	Suggestion - implement ability to switch away from windows which have grabbed input
Product:	xorg	Reporter:	Frank <fyhuang>
Component:	Server/General	Assignee:	Xorg Project Team <xorg-team>
Status:	RESOLVED MOVED	QA Contact:	Xorg Project Team <xorg-team>
Severity:	enhancement
Priority:	highest	CC:	andersk, benderamp, jasa.david, noel, peter.hutterer
Version:	unspecified
Hardware:	x86 (IA32)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description Frank 2005-08-28 17:51:38 UTC

Currently, fullscreen/normal windows which have 'grabbed' the input (i.e. using
SDL_WM_GrabInput() - mouse cannot move past window boundaries, WM doesn't
recieve most keyboard events) have complete and utter control of the input
system (except for a few special keys of course).

My suggestion is to set a couple more key combinations as 'un-grabbable' - i.e.
they get passed to the WM no matter what. An alternative is to let the WM tell
the X server which keys it wants un-grabbed (so that people who use different
key combos from, say, ALT+TAB can still be satisfied - see below).

I think this presents a problem for users who need to multitask when one of the
applications has grabbed the input. For example, on Windows (Windows comparison
:), ALT+TAB will be handled no matter whether DXGrab is on or not, so that
crashed applications can be closed or so that you can switch away from a window
to do something else. Unfortunately, ALT+TAB is handled by the WM in X, and
since an app that has grabbed the input prevents the WM from catching that key
combination, there is effectively no way to switch away from most applications
that grab the keyboard input (unless they provide a way to un-grab the input,
and I have seen few apps that do this). This is especially useful for gamers,
but I think has the potential to useful elsewhere too.

Cheers!

Comment 1 Erik Andren 2006-04-28 03:02:53 UTC

Flagging as an enhancement

Comment 2 Daniel Stone 2007-02-27 01:27:45 UTC

Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.

Comment 3 Peter Hutterer 2009-09-06 23:25:16 UTC

*** Bug 9208 has been marked as a duplicate of this bug. ***

Comment 4 Peter Hutterer 2009-09-07 17:13:38 UTC

Current idea is to route around that with grab priorities. i.e. the WM can implement such grabs with a higher priority than the applications and thus override an application grab.

Possibly scheduled for XI2.1.

Comment 5 Anders Kaseorg 2010-10-14 21:53:41 UTC

This is not just a problem for gamers.  Most toolkits implement pop-up menus by grabbing the keyboard and mouse while the menu is open.  This currently prevents global shortcut keys from working and the screen from locking during this time.  See http://mail.gnome.org/archives/gtk-devel-list/2010-June/msg00154.html .

Comment 6 benderamp 2011-04-16 03:38:55 UTC

sorry for pinging, but just wondering if there is any chance to see this issue fixed anytime soon. a number of new native game titles has appeared recently (braid, aquaria and other games from HIBs and not only from HIBs) and almost none of them care about handling alt+tab combination to allow to exit the game temporarily as it seems that they have many other more important problems to solve (like graphic card driver compatibility and distributive-specific bugs).

Comment 7 Peter Hutterer 2011-04-17 21:09:23 UTC

Unlikely to happen soon. Problem is simply that the grab event model is a card house and adding grab priorities on top of it is like building a card house on top of that.

Comment 8 Adam Jackson 2018-06-12 16:16:01 UTC

*** Bug 19946 has been marked as a duplicate of this bug. ***

Comment 9 GitLab Migration User 2018-12-13 22:15:38 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/333.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.