> >> Wow, this is getting ugly fast. I wonder if I can get the original
> >> scancode from KeyPress and KeyRelease X events. Then I could mush them
> >> down to the showkey equivalent io and normalize from there. I would
> >> also like to support Putty so if I'm going to hack in support for key
> >> events into it I might as well make the wire protocol as trivial as
> >> possible. Provided I can negotite a keymap with Putty, I could support
> >> the console a la showkey, XTerm a la demoted X Key events, and Putty on
> >> Win32 a la custom trivial networking protocol.
> > The purpose of X windows is to remove you from the hardware details,
> > such as things like scan codes! Ditto for the OS... The XKeyEvent will
> > tell you about key up/down events and the keycode used. Of course X is a
> > message passing client server architecture and running on top of a fair
> > share scheduler. Thus response times are not guaranteed...
> > Handling real time events is the job of the kernel. If you want to
> > implement this sort of thing then do it there, if you want apps to see
> > scan codes, then make a /proc entry that can be polled or that a process
> > can go to sleep on waiting for a key stroke ... Or get a small micro
> > embedded system with no OS to do it. A basic stamp would do nicely...
> This doesn't help me with remote X clients and Putty. And I think there is
> already work along these lines scheduled to go into 2.5.
> I think what I have to do is introduce a new terminal io mode similar to
> how an xterm can switch between ascii and utf-8 mode. It will be necessary
> to hack the clients to interpret a funny sequence of bytes as an
> instruction to switch into this new mode. The new mode is simply the
> ~(ICANON | ECHO) but with scancodes for both presses and releases. I
> suppose the high-bit could indicate whether or not it's a press or
> Incedentally, the showkey example shows that the keycodes read from stdin
> are only 7 bit values (the 8th bit is used to indicate press/release). How
> are the upper 127 keys represented?
When do you think a key is "pressed"?
When the user thinks so?
When the key contacts close?
When the keyboard scanner detects that closure?
When the interrupt happens on the processor?
When the key is handled by the interrupt routine?
When the X system returns from the read and timestamps it?
When an application gets it?
What do you set the timestamp to?
How do you ensure the clock is accurate?
What if the computer and keyboard are in different time zones?
What if the client is in a different time zone than the server?
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them