[PATCH 1/2] Handle SYN_DROPPED, filter keys with a bitmap

[Bill Spitzak]

I feel like this unreliability can be passed on to the clients.

Clients are probably going to be written to assume there may be bugs in 
the compositor and that events will get mangled. Even if the compositor 
is perfect, most toolkits can mangle events themselves (ie they skip 
events when no widget has focus, etc). Thus in the end the clients end 
up doing all this work themselves. Except they can be a good deal 
simpler if they are only interested in "are any buttons down" rather 
than which ones,  which actually covers a lot of potential clients.

Also moving code to the clients seems to be more Wayland-ish.

So I would just send the press/release events exactly as the device 
reported them to the client. Clients can easily handle multiples in 
exactly the same way the compositor does, and they can do it at whatever 
layer in their own code that they  want to be reliable. On SYN_REPORT I 
would send an event that says exactly how the buttons are right now.

The compositor does have to know whether any buttons are held down 
because that determines whether device events are sent to the client 
that got the last down event or to the client that now has focus (I 
think this is called "passive grab", and is why you can push a button in 
a window, drag outside the window, and release, and that client knows 
you let go.

Because of this the compositor should send this very important 
information, so we are guaranteed that the client and compositor agree 
on this, even if some press/release events were mangled or interpreted 
differently by them. This could be any of:
   1. A flag on the release event saying there are now no buttons down
   2. A special "there are no buttons down" event sent after release
   3. Send the buttonmap event (with no buttons down) after release.

Martin Minarik wrote:
> Since evdev keys are unreliable, they might randomly get dropped, such
> as, on SYN_DROPPED. Even SYN_DROPPED is sometimes not delivered.
> Clients, compositor are not able to recover from duplicate press/release.
> This fixes this bug, thereby making the compositor and clients useable
> even under critical system conditions such as, but not limited to, high
> system load, device malfunction. This improves reliability.
> 
> Every device contains a key bitmap. Each passing key press/release
> is checked and recorded. Duplicated presses, releases are handled by
> emitting the opposite type event in between (the time is faked -1 time unit).
> This is a last resort solution and happens only very rarely.
> 
> When a SYN_DROPPED is detected:
> 1 wait until after the next SYN_REPORT.
> 2 Ask the kernel for the actual state of buttons
> 3 Compare the buttons with the internal key bitmap, to see what changed.
> 4 Send each different key via notify to the compositor, with timestamp.
> 5 Update the internal key bitmap to match the kernel's
> 
> Disadvantages of this approach
> Each evdev device consumes 96 bytes more memory.
> Table lookup+bit toggle for almost key.
> Don't know the timestamp of missing keys.
> The key_notify from kernel bitmap compare occurs later the real missing event.
> That's a timestamp issue.