NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/windows/x/15945

Internet Message Format | 1992-08-31 | 7.9 KB

Xref: sparky comp.windows.x:15945 comp.windows.x.apps:894
Newsgroups: comp.windows.x,comp.windows.x.apps
Path: sparky!uunet!stanford.edu!lucid.com!karoshi!jwz
From: Jamie Zawinski <[e-mail]>
Subject: Re: Attention Earthlings -- Cross-Vendor X11 Server Mess!
In-Reply-To: [e-mail]'s message of Sun, 30 Aug 1992 09:35:53 GMT
Message-ID: <[e-mail]>
Lines: 147
Sender: [e-mail]
Organization: Lucid, Inc., Menlo Park, CA
References: <[e-mail]>
Date: Mon, 31 Aug 92 23:01:06 GMT

In article <[e-mail]> [e-mail] (Barry Shein) wrote:
>
> 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.

I don't think this is because anyone is confused, I think it's because
it's simply not standardized at all.

> For example, XK_a and XK_A (and other alphabetics.)
>
> My understanding of the spec says it's almost always wrong to have
> both of these in your keysym table because most likely the key only
> displays one of these (typically, XK_A).

My understanding of the spec says that both are legal, and have well-defined
interpretations.  As far as I can tell, it doesn't say which is "right."

> HOWEVER, which is right in some larger sense?
>
> I don't know, consider a case like XK_equal (=) and XK_plus (+).

I'm not sure that it matters.  Consistency would be nice, but I don't think
one way is necessarily better than the other.  I also haven't found it a
problem that different vendors do differen  things w.r.t. XK_A and XK_a.

> 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)?

The rules that XLookupString follows for case-conversion and caps-lock
and shift-lock processing are really hairy, but I think it's well-defined
enough that there's no ambiguity.

> Consider, as a practical example, the Keycaps DA on a Macintosh.
>
> How would you write it (portably) under these circumstances?
>
> 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?)

Now we come to the heart of the matter.  First of all, I have implemented
this.  You can get it from export.lcs.mit.edu: contrib/xkeycaps.tar.Z.

I agree with you that the X keyboard model is a mess, but not for the
reason you mentioned.  The current system of querying the server to find
out what keysyms are generated by which keys is needlessly hairy and
confusing, but I believe it *works*.

The problem is that there is a good deal of information that you simply
cannot get at.

  -  There is no way to find out the physical layout of the keyboard,
     or the spatial relationship of various keys.

  -  There is no way to find out the name/type of the keyboard hardware
     which is in use.

  -  There is no portable way to reset the keyboard to a default (known)
     state.  The only way to do this is by knowing what kind of keyboard
     hardware is in use (see above.)

  -  There is no way to find out what is actually printed on the surfaces of
     the keys.  I think you were saying that you think that there should be
     a direct correspondence between the set of keysyms which a keycode
     generates and the text printed on the surface.  I don't think this is a
     good idea.  They are two different pieces of information, one of which
     you can change and one of which you can't.  (And, in the current system,
     one of which you can interrogate and one of which you can't.)

> (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.)

The only keyboard-specific information that xkeycaps absolutely needs that X
doesn't provide is data describing the physical shape of the various keyboards
it knows about.  Displaying the current mapping of keycodes to keysyms,
tracking the shift key, etc, can be accomplished with what the X server
provides.

However, I wanted to have a command to reset the keyboard to the default
state.  Since X doesn't give you any way to do this, so I also encoded the
default configuration of the various keyboards into the xkeycaps data files.

> As an example, Openwindows-3 seems to claim it has an F16 key which it
> clearly does not (although they may be referring to something on the
> keypad or something, there's reason to it, just not disciplined
> reason, there are other oddities in there as well, but I'm not picking
> on Sun, it's just weird out there.)

Possibly the reason that there is no way to find out what type of keyboard
hardware is in use (if we want to assign that much intentionality to it) is
that, philosophically speaking, you shouldn't care, because the keysyms will
be the same from keyboard to keyboard, only their physical position will
change.  If you bind something to F1, then it will work on any keyboard with
an F1 key.

Of course, whatever monster intellect was responsible for the Xsun server
decided that F15 was a really good name for the key which is physically
labeled both "Front" and "L5", so this notion breaks down pretty quickly.
It's not clear that this is a botch in the X standard, but it is most
certainly a botch.

The part of the X spec which was no doubt involved in this pinheaded decision
was the part that says that one should combine keys with similar intent: if
one keyboard calls it "Enter" and another calls it "Return", then this should
be transparent to the application.  That's fine for keys which are obviously
congruent in intent, but calling the "R1" key "F21" was just an incredibly
stupid idea.  I can't imagine why anyone thought this was a good idea.

And of course, Sun and MIT can't even agree on what the default keymap
should be for Sun's own keyboard hardware, so it's not enough to know what
keyboard you have sitting on your desk, you also have to know whose server
you're running.

And for those few vendor-defined keysyms that are actually useful, neither
Sun, nor DEC, nor HP, nor MIT can agree on what the names of them are.  For a
laugh, look at the XKeysymDB files shipped by various vendors.  MIT thinks
that Sun uses the prefix "SunFA_".  Sun disagrees: they use the prefix
"SunXK_FA_".  MIT thinks DEC's keysyms begin with "D".  Sun disagrees: they
think that DEC's keysyms begin with "DXK_".  I don't know what DEC thinks.
And so on for the various perumtations.  Nevermind the fact that the keysyms
in question serve the same purpose regardless of the vendor.

Another really big win is that it's not possible to write an xmodmap script
that can function without having special knowledge about either: what keyboard
hardware you're using, or: its current state of mungedness.  Since there is no
(standard) way to restore the keyboard to a default configuration (so that you
can use xmodmap's "keysym" commands), and there is no way to know what
keyboard hardware you're using (so that you can use xmodmap's "keycode"
commands) you're just hosed.  This could be called a bug in xmodmap, but
really it's a bug in the X spec, because the only way xmodmap could provide
this functionality is by doing what xkeycaps does: have lots of special
knowledge about the keyboard hardware in use.  The X server should provide
this information, since it must HAVE it to function.  X simply gives no way
to access it.

Basically, the whole X keyboard model is a complete mess.  It is as good as
no standard at all, because to get anything done, you need to have hardware-
and vendor-specific knowledge anyway.

    -- Jamie