GNOME Bugzilla – Bug 681082
port to use xinput2 instead of core events
Last modified: 2013-02-09 20:22:03 UTC
So we can enable multidevice in Gdk and handle touch events. There's this branch from Carlos Garnacho, which would have to be rebased and ported to the XInput2.2 API as it was released: http://git.gnome.org/browse/mutter/log/?h=wip/multitouch I'm not sure whether it's a good idea to recognize gestures in Mutter's core with libXi, I would prefer to do that in the plugins using Clutter's event and gesture APIs.
The port to XInput2 is at: http://git.gnome.org/browse/mutter/?h=wip%2Fxinput2 Then you can add multitouch support.
(In reply to comment #1) > The port to XInput2 is at: > http://git.gnome.org/browse/mutter/?h=wip%2Fxinput2 > Then you can add multitouch support. Anybody knows what is blocking the merge of that branch?
(In reply to comment #2) > (In reply to comment #1) > > The port to XInput2 is at: > > http://git.gnome.org/browse/mutter/?h=wip%2Fxinput2 > > Then you can add multitouch support. > > Anybody knows what is blocking the merge of that branch? There's still some rough edges in that branch, as it also aimed to handle multiple keyboard/pointer pairs. there's open questions about things like: - how to represent visually several windows focused by several users - how to concede windows to other users, whether focus can be stolen or not - whose window remains on top - generally, who can alt-tab or change the window hierarchy I ended up thinking about the Virtual Core Pointer/Keyboard acting as host devices, hence having a priority on those questions above, and having all other master device pairs behave as guest devices with a more limited behavior, but that didn't fully flesh out into code.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > The port to XInput2 is at: > > > http://git.gnome.org/browse/mutter/?h=wip%2Fxinput2 > > > Then you can add multitouch support. > > > > Anybody knows what is blocking the merge of that branch? > > There's still some rough edges in that branch, as it also aimed to handle > multiple keyboard/pointer pairs. there's open questions about things like: > > - how to represent visually several windows focused by several users > - how to concede windows to other users, whether focus can be stolen or not > - whose window remains on top > - generally, who can alt-tab or change the window hierarchy By user, you mean seat? > I ended up thinking about the Virtual Core Pointer/Keyboard acting as host > devices, hence having a priority on those questions above, and having all other > master device pairs behave as guest devices with a more limited behavior, but > that didn't fully flesh out into code. Could we focus for now in the mouse+keyboard+touchscreen scenario and consider other configurations unsupported? Or am I missing something?
(In reply to comment #4) > By user, you mean seat? I mostly meant about master pointer/keyboard pairs > > > I ended up thinking about the Virtual Core Pointer/Keyboard acting as host > > devices, hence having a priority on those questions above, and having all other > > master device pairs behave as guest devices with a more limited behavior, but > > that didn't fully flesh out into code. > > Could we focus for now in the mouse+keyboard+touchscreen scenario and consider > other configurations unsupported? Or am I missing something? well... the purpose of the xinput2 branch was to handle XInput2, you may argue about the importance of such features. IMO this is sort of like pulling a thread, unless you renounce to handle *all* events from any master device different to the VCP/VCK, you need at least a minimal support, which in turn needs other things to be in place, surely "a few oddities" is a better scenario than "mutter enters in inconsistent states".
There's also the wip/multitouch branch.
(In reply to comment #5) > (In reply to comment #4) > IMO this is sort of like pulling a > thread, unless you renounce to handle *all* events from any master device > different to the VCP/VCK Well, that wouldn't be that bad, right? I think it would be great if we could progressively improve in this area. To be more explicit, moving to XInput2 just for the VCP and VCK and ignoring all events coming from other devices could be a good first step. A second step could be handling touch events. Or am I missing any downsides?
I'm willing to work on this, but first I would like to agree with the Mutter maintainers on what functionality do we want.
Thanks for taking the time to report this bug. This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed. It should be solved in the next software version. You may want to check for a software upgrade. *** This bug has been marked as a duplicate of bug 688779 ***