[PATCH libinput 1/4] evdev: Ignore key/button release events if key was never pressed

[Bill Spitzak]

On 08/03/2014 10:07 PM, Peter Hutterer wrote:
> On Mon, Jul 28, 2014 at 10:03:25AM -0700, Bill Spitzak wrote:
>>
>>
>> On 07/27/2014 11:48 PM, Ran Benita wrote:
>>> Hi Jonas,
>>>
>>> On Sun, Jul 27, 2014 at 11:28:28PM +0200, Jonas Ådahl wrote:
>>>> The kernel may send a 'release' event without ever having sent a key
>>>> 'pressed' event in case the key was pressed before libinput was
>>>> initiated. Ignore these events so that we always guarantee a release
>>>> event always comes after a pressed event for any given key or button.
>>>
>>> Would it be possible to describe in the docs the invariants that
>>> libinput is keeping w.r.t. key press/release ordering and count?
>>> If the user can rely on such invariants, it can simplify how he
>>> interfaces with e.g. libxkbcommon, which expects a coherent key event
>>> stream (things like modifier press with a missed release can cause some
>>> fun).
>>
>> IMHO such invariants are a waste of time, and add complexity to each
>> software layer for no benefit.
>
> strict, well-defined behaviour that maps the real world and expectations of
> the users and developers and guarantees no suprises is not a waste of time.

I meant that enforcing a "you won't get a release without getting a 
press" invariant, which is what these changes are doing, is a waste of time.

Clients rely on the invariant "after a press you will get a release 
event". Throwing away release events actually makes it harder to enforce 
this invariant, since you must not throw away one required by this.

It is hard to imagine any possible client that will actually fail on 
excess release events. Real clients rely on "after a press you will 
either get a release, or lose focus, or the surface will get destroyed, 
or you will request that a surface will get destroyed, or you will 
destroy a Qt widget which the compositor does not know about, or..." 
invariant. Any such client already has the ability to ignore excess 
release events since the compositor will still send them in these cases.