[PATCH weston 1/2] libinput: Ignore non seat wide pointer button events

[Bill Spitzak]

On 01/28/2015 07:21 PM, Peter Hutterer wrote:
> On Wed, Jan 28, 2015 at 01:09:09PM -0800, Bill Spitzak wrote:
>> I would greatly prefer to get an event when this happens. The user expects
>> something to happen when they push a button. You cannot just throw it away.

> the alternative is leave button/key release behaviour up to the client,
> resulting in duplicated code across the various clients/toolkits,
> inconsistent behaviour across clients, increased chance of implementation
> bugs, etc.

My main compliant is that I have to put this code in the client anyway, 
therefore you have not saved me any effort, and you are throwing away 
information that I *might* find useful.

It is very difficult to write a non-trivial client any other way. This 
is because the client has it's own internal processing (such as 
directing events to widgets) and it has to account for things like 
widgets being destroyed while the mouse is down which may cause the 
release event to go to a widget that did not get the press. For this 
reason the widgets already deal with extra events. Trying to deal with 
this at any higher level, such as event dispatch, introduces endless 
complexity and bugs, as I think you are finding when you need to add 
these patches.

> a 11-line fix (times 2 for key events) doesn't strike me as "vastly
> complicate the code".

Did you count how many patches are adding 11 lines? There have been 
dozens posted on this list.

> Anyway, you've made it clear multiple times in the past that you are a
> proponent of laxer guarantees regarding paired events from the compositor
> stack and leaving the messy details to the clients. It has been rejected
> every single time so far, I think at this point you should either drop the
> topic or spec out an implementation that explains why it is technically
> superior and that actually convinces us.

If you send enter events for the next window before exit events for the 
previous ones, a client can implement a non-flickering display without 
having to peek ahead in the event queue. I think that is a pretty simple 
example of a technical superiority.