[PATCH 2/2] XKB: Work around broken interps from old xkbcomp

[Daniel Stone]

Hi,
I thought you were just going to pick up on the workaround only being
commented in xkmread.c and not xkb.c ...

On Tue, Jul 05, 2011 at 08:20:50AM +1000, Peter Hutterer wrote:
> On Mon, Jul 04, 2011 at 04:41:05PM +0100, Daniel Stone wrote:
> > See xkbcomp commits 2a473b906943ffd807ad81960c47530ee7ae9a60 and
> > 3caab5aa37decb7b5dc1642a0452efc3e1f5100e for more details.
> 
> I wonder if it'd be better to add proper version export to xkbcomp, release
> it and make xkeyboard-config simply depend on the new xkbcomp.

Well, kind of, but it wouldn't really help.  We'd have to add
dependsOnAtLeast = 1.2.3 or whatever to the dataset in that case, and
have xkbcomp itself do the version comparison.  Which falls apart a
little bit.

If you want to make xserver depend on xkbcomp, that still seems a bit
harsh, and your options are either do it at build-time (which is hardly
robust), or do it at runtime by forking xkbcomp again just to get the
version number, which seems unpleasant.

> This seems a bit like a hack in already convoluted code and we have little
> guarantee that the next thing we add won't require a similar hack to it.

Well, yes, it is.  But at this point we're pretty much just screwed; the
problem also occurs with clients which compile their own keymaps with
xkbcomp, and then send us a broken keymap down the wire.  Like, say,
GNOME.  (I was wondering why my original fix in xkmread.c didn't work
until I saw that GNOME was stomping the server-compiled keymap with its
own.)

So, it's unpleasant, but I'm not entirely sure what else to do.
Normally I'd just give up and try to document it well, but the failure
mode of your entire keyboard other than VT switching and zapping
appearing to do nothing is serious enough that I feel it's warranted.

> Plus, having xkbcomp properly export the version can only be useful.

Kind of; see next mail.

Cheers,
Daniel