Re: key codes table.

[Ray Andrews <rayandrews@xxxxxxxxxxx>]

On 02/28/2014 09:08 PM, Bart Schaefer wrote:
> Eventually Ray is going to regret asking me these questions ...
Eventually Bart is going to give up in despair ;-)
> Unfortunately the set of key sequences you've listed here is likely
> very specific to the environment you just described.  As you've noticed,
> it's not even the same for the console terminals on the same OS.
No surprise there. I know this is a layer cake sort of thing with 
hardware/kernel/zsh/X/xfce/app each having their
own kick at the keyboard. Anyway, it was an interesting exercise seeing 
what I have here on a grey colored PC runing debian/zsh/xfce in Canada 
on Tuesday.
> Do you begin to see why we don't bother attempting to create a static
> table of all this?
I sure do! Still some automated way of coughing it all up as a table 
would be nice. It would
be good to know what KB resources one has at one's disposal in any given 
situation, remembering that it
could all change on Wednesday. That's what I was trying to accomplish.
Sorta like 'bindkey' shows what bindings are currently active, one might
have a dump of all possible bindings in the current environment. One 
might then plan some sort of
personal coordinated keyboard layout that can plan around existing keys. 
Mean time, I wrote a sort of
souped up 'showkey'

pts/2 HP-y5-10-Debian1 root /aWorking/Zsh/Zkbd $ . ./x

Type the keycode you want, then 'space' to see what it is bound to.
TAB exits the program.

Key ... ^A
                "^A" bound to:  beginning-of-line
Key ... ^Z
                     (unused)
Key ... ^Zc
                     (unused)
Key ... ^Xc
               "^Xc" bound to:  _correct_word
Key ... ^Xnuns
            "^Xnuns" bound to:  "Nuns fret not at their convents narrow 
room"
Key ... z

output (cat /tmp/keys_tmp):

                "^A" bound to:  beginning-of-line
                     (unused)
                     (unused)
               "^Xc" bound to:  _correct_word
            "^Xnuns" bound to:  "Nuns fret not at their convents narrow 
room"

pts/2 HP-y5-10-Debian1 root /aWorking/Zsh/Zkbd $ l

==============================


 Could be an artifact of some other (possibly historical/disused) keyboard
layout such as the Sun keyboard that zkbd partly supports.  Could even be
related to the wiring of the circuit board in some keyboard from the 80s
that became a defacto standard.  A lot of this stuff was invented when
most Unix keyboards were an integral part of the terminal device and
there was no such thing as separate, independent monitor and keyboard.

Eventually those things will be lost in the mists of time. It's hardly 
important.
> } Don't forget that:
> }
> } /-Shift-Ctrl = Bksp      = '^?'
>
> Actually that is ASCII DELete not Backspace.  Backspace is ^H ... but
> of course the Del key might send any of ^? or ^H or ^[[3~ etc., and
> the key labeled Backspace often sends ^?.
Mere anarchy.
> Consider all the layers that a key press has to pass through to reach
> your shell or other program running in your xterm:
>
> - Circuit board in the keyboard itself
> - Motherboard or graphics card hardware
> - BIOS
> - Operating system device driver
> - Input event device
>    [<
> - X server event handler
> - Session manager
> - Desktop manager
> - Window manager
> - Terminal emulator
>    >]
> - (Pseudo-) TTY device
> - Kernel I/O layer
> - User-space system call interface
I AM sorry I asked ;-)
> (In DOS, roughly speaking, things go directly from the OS driver to
> the I/O layer and skip everything I listed in between, which is why
> there is so little variation or complexity in behavior.)
That's right. I actually understood all this stuff in DOS. Now we have 
'XKB' which the Devil
himself probably does not understand.
....
> As for whether the assignments are changeable: yes!  At effectively
> every layer from the session manager down to the terminal emulator;
> though exactly what they are allowed to do at each layer varies,
> and you might have to change several layers to get a particular key
> combination to be visible to the terminal emulator, which may break
> something else in ways you don't expect.
>
> Does that clear things up? :-)
That made it about as clear as it could be, which is still somewhat 
beyond my abilities. Sheesh,
this started when I noticed that the key between my left Ctrl and Alt 
keys (which currently outputs '<')
produces a different scan code than the other '<' which is the shifted 
comma key,
and I was wondering if I could morph it into a 'Meta' key. And never in 
my life have I been so sorry
that I looked into something ;-) I know how Pandora felt. This is not 
something that an ordinary mortal
should get involved with.