Re: key codes table.

[shawn wilson <ag4ve.us@xxxxxxxxx>]

If you want that chart, you should be able to come up with a script that
gets key bindings for \x00 - \x255 (or more realistically 80~200 -
printable characters) and we can run it through common environments? I
think that's what you're looking for anyway?
On Mar 1, 2014 3:45 PM, "Ray Andrews" <rayandrews@xxxxxxxxxxx> wrote:

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