Vincent Povirk wrote:
When the client receives a mouse-down event, it knows it is in this mode. The mode is exited when all the mouse buttons are released.
Um, wouldn't this mean that in order to get "normal" cursor behavior while a button is held down, all clients have to echo the mouse events they receive back to the server (and do so very quickly, or else you'll get noticeable input lag)?
Yes I now think this mode does not have to be entered until a pointer-warp is done. At that point the pointer stops moving and is controlled only by further pointer-warps. This is compatible with current behavior. The mouse will jitter once if the first warp is an echo of a previous position and the compositor has managed to display the pointer at a new position, but I don't think that is a real problem.
I guess the intent here is to grab the pointer as soon as the mouse goes down, so that you can't lose any events between pressing the user pressing the button and the client starting the grab, but the desire to "filter" mouse events in this way is weird enough that I think it has to be opt-in. And with this proposal there's a possibility of losing events before the mouse is released, if you're not able to warp the cursor in time.
No event are ever lost. As long as any mouse buttons are down the client will keep getting mouse-drag events that are exactly the same whether the pointer warp is done or not (ie they report where the mouse would be if the pointer warp was not done). This is exactly the same as the pointer-lock proposal.
I think that for any mouse input "filtering" system to work correctly (including pq's proposal), a client needs to inform the compositor when ending the grab of the last event that it was interested in (normally a mouse up)
The grab ends automatically when all the buttons are released, exactly like the implicit grab does already. It then acts as though the mouse jumped to the pointer-warp location, sending move/enter/exit events as necessary and changing the pointer focus.
The client can tell which events are which by whether they are before/after the release. Though not technically necessary, it would be helpful if keyboard and mouse release events to include an indicator that "nothing is held down anymore". This can be used to recover from a screw up where the client got out of sync remembering what was held down.
_______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
