[PATCH weston] input: don't send to clients key events eaten by bindings

[Bill Spitzak]

On 11/21/2014 10:59 AM, Daniel Stone wrote:

>     And the other is "a useless event that must be sent before the key
>     map changed event".
>
> Which you respond to by ceasing _all_ actions related to your current
> keyboard state, such as cancelling key repeat. So, also not useless.

You are right, it is the "stop repeating keys" event. I didn't think of 
that. Depending on exactly what keystrokes the server is consuming, it 
will have to send this, and right away, rather than deferring it to 
immediately before the enter event, as I was thinking of.

I personally feel it is a mistake to have the client do repeat rather 
than the compositor, because complexities of timing will not be 
identical between clients, and because it makes it really difficult to 
do remote display on a system that does the repeat itself. However this 
event would still be necessary to cancel "key held down for this long" 
timeouts.

> The way you detect repeat in _core_ X11, is by a stream of paired
> KeyPress and KeyRelease events. Look it up. Clients rely on this, and
> conformance relies on it too. I don't know if you've heard of an
> extension called the X Keyboard Extension (obscure name, I know), but
> since its inclusion in X11R6.1 in 1996, the XkbSetDetectableAutorepeat
> function has allowed you to request key repeat be sent as a stream of
> press-press-press-press-release events, rather than
> press-release-press-release-press-release. For bonus points, it's even
> part of the core libX11.so.6 API/ABI. And it works perfectly, and every
> real toolkit I've seen has made good use of it.

The "old" keyboard api (I think this is what you meant by core) in X 
sent repeated press events. This was certainly true for IRIX and I 
believe it was true for the first versions on Linux, because the errors 
would be obvious if it was different. Forms, XForms, FLTK, Tk and 
whatever Amazon paint used assumed it worked this way. Prisms and Alias 
Wavefront did too but they fixed them pretty quick.

You can blame it on the documentation that I never saw 
XkbSetDetectableAutorepeat. The books we were using for reference 
predate the change. Because of the enter+exit problem, the toolkit had 
peek-ahead code for the event stream already, so it was pretty easy to 
modify this. I suppose if X had done the enter+exit events correctly the 
peek-ahead code would not have existed and I might have searched harder 
and found this call.

Also it looks like this function is allowed to fail and return false. 
This makes it pretty useless as the look-ahead solution has to be 
implemented anyway as a fallback. Due to the need to minimize code paths 
to reduce chances of bugs I certainly would not have used this call at 
all and used the fallback always. But I also suspect this is 
documentation over-kill and it actually always works: it should not have 
been defined as returning a failure code. This sort of mistake is what 
leads to misuse on non-use of documented API.

There are also indications that various bugs make it return true but not 
work anyway: https://bugs.freedesktop.org/show_bug.cgi?id=22515. 
Encountering such a bug would also certainly have stopped us using the call.

> So I don't know who took the decision to not use a toolkit but instead
> write their own, to write a toolkit without seemingly looking at any
> prior art,

You may be unaware of the conditions of things in 1996 but the 
alternative to writing your own toolkit was to use Motif. I can assure 
you that the decision was not hard.

Looking at Motif source code is pretty near useless as it is obfuscated 
beyond belief (it also would not have contained this call for obvious 
reasons). I based our code on the source for Forms and Tk and GLUT and 
samples from the web and from reading the blue X11 reference books. GTK 
was the Gimp Toolkit then and considered part of Gimp (in fact Stallman 
sent me letters because they were considering using FLTK as the base 
toolkit, I screwed up on getting the necessary permissions so this did 
not happen). The K desktop had just appeared, so I guess a rudimentary 
version of Qt was available, but we never looked at that either.

> or to apparently abandon an entire product on the basis that
> peeking ahead in the event stream was more difficult than five minutes
> on Google

The product was closed source and they were not maintaining the Unix 
version. And Google did not exist in 1996.

> This is not something which has ever changed in X11, ever. It's not a
> recent development that someone panicked and changed the X server to do
> it; it's the same behaviour we've had since 1987, in which time people
> have worked out how to deal with it. Or most people, anyway.

No I have absolute proof that on Irix and early Linux it did not work 
this way. The documentation for XkbSetDetectableAutorepeat here 
http://linux.die.net/man/3/xkbsetdetectableautorepeat seems to say that 
earlier X servers did not work this way. Perhaps the X11 standard 
claimed it worked this way (I am not going to read the book to try to 
find any statement one way or another), but the implementations did not, 
and the implementations win over the documentation all the time.

Anyway I'm sorry about being mad, but the experience certainly did piss 
me off at that time, enough that I am still pretty upset about it 20 
years later. I had (and still have) great hopes for Wayland, but I am 
disturbed to see some of the same mistakes from then being repeated.