Add mouse cursor warping

[Daniel van Vugt]

Add mouse cursor warping - an API (for nested shells at least if not all clients) to limit and reposition the mouse cursor.

This is one of three missing Mir features that is preventing Unity8 from using Mir's built-in mouse cursor. The other two issues are:
  * Android performance bug 1373696
  * Mesa hardware cursor does not rotate with screen.

See also: https://trello.com/c/sDnxldwa

[Daniel van Vugt (vanvugt)]

Hmm, on second thoughts maybe we need an explicit barrier/friction API, or maybe we just need pointer grabs (still :) in combination with warping.

[Gerry Boland (gerboland)]

I don't see any advantage in having Mir implement pointer barrier. The mouse should live in the shell's scene, and thus be positioned where the shell desires it to be - that is how we've implemented it currently. Implementing barriers in mir will take scene state outside of the shell, confusing responsibilities.

An API to allow unity8 to tell Mir where the mouse should be drawn should be sufficient.

[Daniel van Vugt (vanvugt)]

> Implementing barriers in mir will take scene state outside of the shell, confusing responsibilities.
That's not entirely true.

Mir already has (partially implemented?) input regions where the mouse cursor varies between regions of a surface. I'm not sure it's fully implemented yet, but the initial goal there is to have the Mir server change your cursor for you automatically based on the input regions (widgets) you have defined. All normal toolkit functionality. And we could easily extent that to include motion limitations too. Certainly we will need to look into this area anyway to implement grabs for gaming in future.

So considering that Unity8 is just a client of USC, it seems quite simple and reasonable that in future Unity8 (like any Mir client) would just define regions of unusual pointer behaviour. It's not confusing responsibilities as much as simply using the Mir client API that should exist in future.

[Daniel van Vugt (vanvugt)]

> An API to allow unity8 to tell Mir where the mouse should be drawn should be sufficient.

Agreed on that one, but the implementation details are up for debate. My main concern is that you don't want the client reacting retrospectively and moving the cursor away from a barrier after it has been crossed. It needs to be proactively prevented from crossing some barrier, because a reactive solution would just look buggy.

Remember the hardware cursor as the kernel renders it, is a few frames ahead of the client and even a little ahead of the system compositor.

[Michał Sawicz (saviq)]

Syncing task from Mir.