Re: keysym->keycodes weirdness, with lousy patch

Daniel Barlow <[email protected]> writes:
> Richard M Kreuter <[email protected]> writes:
>
> Thanks for this mail.  All that's clear to me right now is that you
> understand more of the issues here than I do. That said, I'm picking
> up a clear impression that you think the C bindings are arguably
> broken in this respect, so in the interests of getting a CLX 0.6 out
> sooner rather than later, I'm going to hold off on this patch until
> I've done the necesary background work to know what you're talking
> about.  

I didn't explain the problem too well. keysym->keycodes asks the X
server for the entire keymap (display-keyboard-mapping, which boils
down to the core protocol request +x-getkeyboardmapping+), then
iterates through the keymap, looking for the keysym specified. The
current implementation of the analogous function in the C binding,
XKeysymToKeycode, gets the size of the keymap (by sending the same
request as display-keyboard-mapping), but doesn't actually use the
keymap data. Instead, it sends an XKeycodeToKeysym request for each
possible keycode, as determined by the size of the keymap.

In the absence of any other information, CLX is more efficient, since
it only sends 1 request to the X server, albeit an expensive one,
whereas the C sends that request, and then sends a large number (in
the normal case, a few hundred) followup requests.

However, as a consequence of not using the data the X server sends in
response to a getkeyboardmapping request, the C binding allows the
user to have an X server that sends back anything in response to an
+x-getkeyboardmapping+, provided the reply contains enough bytes. As
it turns out, there's at least one way to configure XFree86 that
causes the X server to do this, but programs that use the C binding to
the core protocol never notice, which may mean that there are others
out there in the same situation as I am: the only things that don't
work as coded are the CLX programs, though in some sense it's the X
server that's the culprit.

For the record, there are a couple other obvious calls to
display-keyboard-mapping in translate.lisp, which may need to be
changed, if the callers use the keymap data. I haven't really looked
at those yet.

> (I have an irrational prejudice against Xkb... if anyone could point
> me at some good documentation describing what it does, that would
> certainly help)

I don't like xkb any more than the next guy, I just needed to mess
with it in order to get something configured as it had been before
XFree86 started pushing the xkb way of setting up the keyboard. I
certainly didn't understand what I was doing, but eventually got it to
the point that things looked to be working.

That said, the xkb protocol specification, which tries to explain the
motivation for the thing, is available here:

http://ftp.xfree86.org/pub/XFree86/4.3.0/doc/PostScript/XKBproto.PS

It's not clear to me, having skimmed it, that that document is at all
useful for understanding how to actually control the XFree86/X.org xkb
implementation.

Thanks,
Richard


_______________________________________________
Portable-clx mailing list
[email protected]
http://lists.metacircles.com/cgi-bin/mailman/listinfo/portable-clx
cvs -d :ext:cvs.telent.net:/usr/local/src/cvs co clx  # over ssh
cvs -d :pserver:[email protected]:/cvs co clx  # anonymous