NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: The Chthulhoid horror that is keyboard handling in Unix

On Thu, 1 Apr 2010, Johan van Zanten wrote:

That's a very sweet and wholesome concept, and i'm really amused by the
notion that you think we've passed out of the Stone Age.


But you are
ignoring the reality that we are still typing on mechanical keyboards

I'm just as ready as the next humanoid for the socket at the base of the
skull that translates my intent into pure, divine manifestation, but the
fact of the matter is that it just doesn't yet exist.

That would perhaps be nice, but I think you overestimate the magnitude of what I'm getting at here. (I love my Model M, and I plan on using it for at least another decade.)

What I mean is this: The up arrow key doesn't send a "move cursor up

Really? I think it does. Ahh, well maybe it's several bytes of key codes (characters), but you see what i mean, perhaps.

See, this is why I put the asterisk in there.  :-)

Right, so the keyboard wiggles the data line for a while to send a stream of bits to the keyboard controller. I don't really care whether it sends PS/2 or USB scancodes, or whether the PS/2 scancodes are set 1, 2, or 3, as long as they communicate my intent to the kernel. (I would bet real money that you don't particularly care about this either, as long as it works.)

In any case, since I am running X, the scan codes that X gets are Set 1, of Original IBM PC vintage; they are converted by the kernel if the keyboard controller hasn't already done the job. It's a stupid system, but seems to be what X expects. The X server translates it to an X keycode. I still don't care.

Somewhere in there though, another part of X converts the keycode, representing the physical key, into a keysym, representing a symbolic name. If all of the above worked as it's supposed to (and amazingly enough it did) the keysym that gets delivered to the program is "Up".

*This* I do care about. Not the details of how it got there, but "Up" is what I want.

The short version: Hit key, irrelevant implementation details, "Up" keysym. I hope you (all) will agree with me that the short version is easier to understand.

But we're not done yet, of course. The program in question is often a terminal emulator, and now we get into the perhaps more familiar territory of terminal emulations. (Although to me, it's a strange and frightening land, haunted by the ghosts of yesteryear...)

You know the deal; "Up" gets turned into some escaped sequence; shell / text editor receives escaped bytes and decodes it, and does what the user wants.

More can be said, but again, these are implementation details. Why should the user have to care? It should just work. I certainly didn't care before switching to Unix and had to fight against the system to get it to release my "national" characters.

Are there users who care strongly about what the terminal emulator sends? I guess there are quite a few, especially here, but xterm/rxvt aren't going away. However for a large number of users, the exact details are irrelevant. I would certainly trade VTnn compatibility for unambigious character encoding (let's hear it for UTF-32!) and having all special keys working out of the box, in normal daily use. That can't be so hard, can it?

 Asking users to set environment variables and mucking around with
dot files is the wrong way to go about things, unless the goal is to annoy

Don't fear the command line.  It's where the power is.

Oh please, not the "WIMPy GUI user" argument. I don't fear the command line. But I also know that as things stand today, it's lousy for some things; does it really make sense to *require* users to got intimate with obscure parts of the system before being able to speak to the system in their own alphabet?

(Would you find it acceptable if by default, 'q', 'w', and 'z' didn't work? "Oh yeah, you have to 'set input-meta on' to get those international characters." I assume you would at least be pretty annoyed. But that is the reality for a lot of us today. We rely on The Google, and passed-on but poorly understood fragments of configuration to get our systems into something resembling a usable state, and we still avoid using "international" characters if we have any sense. And that's even before getting into "properly" international things like UTF-8.)

But the short version: it could be better. So why not figure out the right way to do it?


Home | Main Index | Thread Index | Old Index