[PATCH] xkb: Fix ISOLock

[wettstein509 at solnet.ch]

> It should be. Some of the tests rely on <linux/input.h> to get KEY_*
> definitions, but you could just copy that and it'll work fine. The
> only test which will break would be interactive.c.

It seems you are right.  I am not sure that how to run the tests
properly, but at least, I have been able to run test/state.

> Right. We've got a fairly comprehensive test suite covering the full
> keyboard mechanics, that covers a lot of dark corners you don't
> usually see in manual testing.

Very nice.

> That's why I'd like to see it there: so we can write tests ensuring it
> works, but also to ensure it doesn't break any other expectations.

That is a long way, I am afraid.  To demonstrate the correctness of the
X-server implementation by means of a libxkbcommon implementation, the
implementations and the environment they live in must be equivalent.
Even though the structure in src/state.c is very similar to that in
xkbActions.c, there are differences:

1. As far as I can see, libxkbcommon does not handle group latches,
   set/lock controls, and button actions.  That is half of the actions
   affected by ISOLock.

2. Autorepeat handling is completely different.  libxkbcommon seems to
   assume that it does receive balanced press/release events (this is
   what I gather from reference count handling).  In the X-server,
   autorepeating key presses have no matching releases.

3. Modifier latch handling in libxkbcommon is quite different to what is
   now in the X-server, and looks suspicious:
   - Autorepeat handling is missing.  If I am right about how autorepeat
     in libxkbcommon works, there is no way to tell autorepeat from
     regular presses/releases.  Is autorepeat handling even possible?
   - Base modifiers can get stuck.  The same issue used to be in the
     X-server, see http://patchwork.freedesktop.org/patch/13192/.

Regards,

Andreas