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

[Daniel Stone]

Hi,

On 27 September 2013 17:00, Bill Spitzak <spitzak at gmail.com> wrote:
> Daniel Stone wrote:
>> 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.

OK, so what's the point of focus in and out events, if they can be
sent randomly and in fact provide no indication of whether or not
focus is there?

>> 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.

I don't think you understand how the focus mechanism works within the
compositor.  Without this tracking, we cannot accurately deliver
focus.

The motivation behind removing the correctness guaranteed by these
events seems to be 'let's remove all this code from the compositor
(and replicate it in every client)'.  Given the enormous downside to
the former, and downside of the latter by the time you've repeated it
in the client, I still have no idea why it's being proposed.

Cheers,
Daniel