libweston: explicitly cancel start_drag if no matching input device is found
Otherwise, the client will assume that dragging is in progress and remains in that state forever. This can happen when weston processes the mouse up event just before the start_drag() arrives.
Signed-off-by: Michael Olbrich email@example.com
I'm not sure if this is the correct solution. The API doc says "the client must have an active implicit grab that matches the serial.". But the client cannot ensure this because weston can see a 'up' event (which breaks this requirement) before the start_drag() arrives. There is no hint what should happen in this case.
I tried to find a way to handle this in the client, but I found no real workable solution. The only indication seems to be the mouse event that arrives. And 'We got a mouse event after start_drag() so it failed' is not really a good solution.