[PATCH 2/2] input: Warn if the touch point up and down events get out of sync

[Bill Spitzak]

Daniel Stone wrote:

>> Clients should just be
>> prepared for excess up and down events, and excess focus in/out. Avoiding
>> them becomes nearly impossible as you are probably noticing, and pretty much
>> means the compositor must maintain the state of *EVERY* button for *EVERY*
>> client.
> 
> Yes.  If your starting point is that the thing directing your input
> events and focus shouldn't have to know where to direct its input
> events or focus, then we disagree on something I consider axiomatic.

I think you seriously misunderstood what I am proposing.

Yes the compositor has to direct input events just like now.

However there appears to be a lot of work in the compositor so that it 
does not send multiple focus-in events or multiple button-down or 
button-up events.

The problem is that things feeding events to the compositor, in 
particular input methods, are not producing matching events. So the 
compositor itself has to be ready for these multiple events, by tracking 
the state of every button for every client, just so it can avoid sending 
a multiple event. However it would be much easier for clients to do 
this. Not only that but I bet 99% of clients are doing it anyway, making 
the code in the compositor a total waste.

> A more useful starting point might be a prototype of a system where
> the compositor didn't track of this, which actually functioned in any
> meaningful way in the real world.

Easy: remove all the if statements around where it sends button, key, 
and focus events that are simply testing to see if they were sent 
before. Replace stuff like this:

   if (!surface->has_gotten_focus_in_event) {
     surface->has_gotten_focus_in_event = TRUE;
     send_focus_in_event(surface);
   }

with:

   send_focus_in_event(surface);

I in no way am proposing that it send focus-in event to a random surface 
or to every surface, or whatever you thought I was proposing.