Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!sdd.hp.com!ucsd!ucbvax!bloom-beacon!dont-send-mail-to-path-lines
From: mouse@lightning.mcrcim.mcgill.EDU
Newsgroups: comp.windows.x
Subject: Re: PC/AT Keyboard X Keysym Proposal - R.F.C.
Message-ID: <9101240005.AA01670@lightning.McRCIM.McGill.EDU>
Date: 24 Jan 91 00:05:32 GMT
Sender: daemon@athena.mit.edu (Mr Background)
Organization: The Internet
Lines: 48

Dave Lapp writes about the problems raised by IBM AT keyboards (and
clones thereof).  I'm not going to get into the morass of whether we
should or shouldn't use (for example) Next and Prev for PgUp and PgDn.
But further text on the subject of NumLock provokes a response.

> X11 expects that locking modifiers are mechanically locked.  Since
> most keyboards don't do this the server software must simulate this
> behaviour.  Generally the server 'eats' alternate upcode/downcode
> pairs for CapsLock/ShiftLock keys to simulate this behaviour.  The
> server must use the keycode(s) which have been assigned to Lock
> Modifier to decide when to do this.  But X11 has a single Lock
> modifier and this is normally used for Caps Lock.

I think it should be possible to specify to the server exactly which
keys should lock down.  (It would be acceptable for this to be
restricted to modifier keys.)  I'm not sure whether this should be
specified and/or stored in terms of KeyCodes or KeySyms.

Of course, we could always just say that any KeySym whose name ends in
"Lock" should lock :-)

> Sooo problem one - How to identify NumLock as a modifier?

Now about the same way Meta is?  Any modifier bit bound to a Meta_L or
Meta_R key is considered to be a meta modifier.  Similarly, it would be
easy enough to consider any modifier bit bound to a NumLock key as a
NumLock modifier bit.

> Any translation due to NumLock would take place in Xlib NOT in the
> server.

Agreed; as with Lock, the server simply maintains the modifier state;
it doesn't actually do the modifications.

> Problem two - Xlib needs to be changed to recognize the NumLock
> modifier (given whatever convention is decided on) and act on it
> appropriately.  This requires a whole bunch of vendors changing their
> Xlibs.

What I would prefer to see is some sort of extensible mechanism in Xlib
so that Xlib - regardless of whose - can be reconfigured in ways like
this.  (I know this is very vague.  I'm not sure exactly what I want
here myself.)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu