[PATCH weston] input: don't send to clients key events eaten by bindings
spitzak at gmail.com
Fri Nov 21 13:11:40 PST 2014
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"
> 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.
More information about the wayland-devel