From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.windows.x,comp.windows.x.apps
Subject: Re: Attention Earthlings -- Cross-Vendor X11 Server Mess!
Date: 3 Sep 92 23:08:04 GMT
Organization: McGill Research Centre for Intelligent Machines

> Distribution: comp

Please don't misuse newsgroup hierarchy names as distribution lines.

In article <BZS.92Aug30043553@ussr.std.com>, bzs@ussr.std.com (Barry Shein) writes:

> The problem involves every different vendors' (server implementors')
> idea of what goes into the Keysym tables.

> Basically, the tool to use to investigate this is "xmodmap -pk".  If
> you run this on different platforms you will get wildly varying
> results indicating wildly different understandings of what should be
> there.

There's another problem: your failure to fully understand how X
keyboard facilities work.  Yes, there are problems, but this isn't one
of them.  Physical keys are numbered arbitrarily; these numbers are
keycodes.  There is no "should" about what goes in the keyboard
mapping, except that the ultimate mapping from physical keys to results
when they're typed should bear some resemblance to what the user wants.
The mapping "xmodmap -pk" prints is only one piece of this: the others
are the mapping between physical keys and keycode numbers (can vary
with keyboard manufacturer, operating system, X server, and probably
other things) and the actions the applications in use take when they
see keystrokes (beyond the scope of this discussion, mostly).

> The worst problems stem from a basic disagreement on whether the
> keysym tables hold what the keycaps say (my understanding of the
> spec) or everything the keyboard can generate.

Neither, quite.  The impression I get is that they would have liked to
take the former approach, but bowed to pragmatism and (a) merged
different names of identical function (eg, RETURN and ENTER), (b) split
identical names of different function (eg, ENTER on main keypad and
ENTER on numeric keypad).  (They also made some mistakes, like omitting
some things altogether.)

> I don't know, consider a case like XK_equal (=) and XK_plus (+).

> Most keyboards have this on the same key, and all tables I checked
> had both codes.  But this is only one key, the distinction being that
> one glyph is shifted [...].

This is actually a very good point, which I hadn't noticed until you
mentioned it.  The keyboard I'm using now has a key which is labeled as
if it were "SPACE" unshifted and "BACK" shifted, but of course it's
actually the backspace key.  Yet there's another key which *is* =
unshifted and + shifted, and it's not a += key.  This is where
pragmatism comes in: I don't expect a slavish adherence to labeling
every key with precisely what's on top of it; I'd much prefer a looser
approach that works better.  Which is what X does.

> But, for example, if as I understand the spec, that only one of XK_A
> or XK_a (usually XK_A) should (usually) be in the table as some
> vendors believe, how do I ever discover that there is another shifted
> or unshifted keycode also generated by that key (typically the
> unshifted is missing)?

Because of another botch (IMO): XLookupString is defined to be ISO
Latin-1 dependent.  It *knows* which keysyms correspond to alphabetic
characters that have both uppercase and lowercase forms.  (This is a
pain when you want something else, like ISO Latin-5...I understand Xmu
has some routines to help, though I've never looked for them myself.)

> Consider, as a practical example, the Keycaps DA on a Macintosh.

> How would you write it (portably) under these circumstances?

You can't, because as you point out there is no way to get the physical
layout.

> (Forget the physical layout problem, that's beyond redemption in X11
> right now, unless there's something I don't know about, amusingly OW3
> puts the keysyms into the table in the order, right-left/top-bottom,
> that they appear on the Sun Type-4 keyboard, but that's an exception
> in my experience, would you rely on it?  I wouldn't.)

Then OW is doing some mapping.  The type-2 and type-3 keyboards
generate keycodes that *are* in order like this, but the type-4 (and
type-5, I assume) moved some keys but wanted to be keycode-compatible,
so they aren't quite in order any longer.  Check carefully and I think
you'll find a few keys that aren't in physical row-by-row order...

> Now, if you hold down Shift in this Keycaps thing the image changes
> to display what the Shift of all the keys would send.

> And the same for their equivalent of Meta (Option or something like
> that), and Control, and combinations.

> I don't believe that program can be written even barely portably in
> X11 (and lo as far as I know nothing like it exists, nicht wahr?)

It can, for Shift and Caps_Lock/Shift_Lock, modulo physical layout
assumptions.  Interpretation of Control and other modifier bits is
sufficiently nonstandard (does that control-c mean interrupt, insert
character 3, or what?) that the other modifiers can't be handled.

> So I would conclude that the spec is kind of broken [...]

I've never heard of anyone who would disagree with this....

> in that a correct implementation leads to a less than generally
> useful result.

This doesn't always mean the spec needs work.  To pick another part of
X, it would be perfectly legal to draw (zero-width) lines as
axis-aligned rectangles of which the specified line is a diagonal.  Or
as circles of which the line is a diameter.  But nobody actually does
that.

> I personally think that XK_A and XK_a both in the table in a way that
> they can be determined to be the shifted/unshifted versions of the
> same key needs to be done or else there's just no way to query what
> the keyboard can generate usefully.

The keyboard doesn't generate both a and A.  It generates events for
the shift key and events for the A key.  It is the client's job,
typically via XLookupString, to convert A-key-with-shift-down into an
"A" character and A-key-with-shift-up into an "a" character.  If it
wants to convert them to characters at all, that is; not all
applications do.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
Xref: sparky comp.windows.x:15856 comp.windows.x.apps:875 comp.infosystems.gopher:313