Comment 110 for bug 1690719

Thomas G, you catch the idea and this is a good point. Will be nice to know how to adapted the same idea to this issue. The difference will be the complexity, because there are a toolkit in the middle in this case. Clutter is who really use the libinput backend, not actually the shell (mutter), so if you move Clutter outside of the main process (the compositor) with all it have, will be an equivalent solution to this problem (and also better). An alternative that can solve this issue also is move just libinput outside the clutter toolkit and handled it asynchronous in mutter, but not all clutter itself (just lib input).

The last possibility will also resolved this particular problem of the mouse, but as there are a toolkit working embedded with the whole shell in the same thread, will not be only the input events who can freeze the shell, anything else that occurs in an synchronous way inside the main thread and require some relatively complex processing, will continues blocking the compositor in the present and in the future and this is not nice. Also, you will need to make a hard dependency between Clutter and Mutter with that solution and this mean clutter can not be used outside the a mutter context, with it absurd in my point of view.

Both ideas to handled this was proposed by Jonas Ådahl some comments ago. Anyway, this is pretty complex to be done. Is not a change to the next weekend or something like this. So, that required rethinking first what is more convenient to gnome from the future and also what are the inconvenience in the middle and how difficult will be move all this.

For all this reason i think is better think it as task to Gnome Shell 4, and not for the next weekend.

Olav Vitters: Thanks for your nice comment. Read the André Klapper main page (https://wiki.gnome.org/AndreKlapper)... My comment was to be friendly with him, not the opposite.