Very Computer

>>If, for example, I depressed the left Alt key, followed by the Enter
>>key, and then released the Enter key and the Alt key I would like to be
>>able to fire four events for those four actions as they happen (or
>>within some reasonable amout of time (e.g. 100ms)) and I would like to
>>do this without modification to the Kernel.

>>Can someone point me in the right direction please?

> You want to look at the source code to _showkey(1)_, which is part of
> the kbd-1.06.tar.gz package.  You can find it on most any distribution
> site under linux/utils/kbd/.

>>>If, for example, I depressed the left Alt key, followed by the Enter
>>>key, and then released the Enter key and the Alt key I would like to be
>>>able to fire four events for those four actions as they happen (or
>>>within some reasonable amout of time (e.g. 100ms)) and I would like to
>>>do this without modification to the Kernel.

>>>Can someone point me in the right direction please?

>> You want to look at the source code to _showkey(1)_, which is part of
>> the kbd-1.06.tar.gz package.  You can find it on most any distribution
>> site under linux/utils/kbd/.

>Actually I saw that, but it looked like the technique didn't work in X.
>I would like the module to be general purpose enought that it work in X
>as well as on the console. Is there any way to do that or do I have to
>detect that situation and use X code if connected to a pty?

> >>>>I want to write a keyboard event module.
> <snip>
> >>>>Can someone point me in the right direction please?

> >>> You want to look at the source code to _showkey(1)_, which is part of
> >>> the kbd-1.06.tar.gz package.  You can find it on most any distribution
> >>> site under linux/utils/kbd/.

> >>Actually I saw that, but it looked like the technique didn't work in X.
> >>I would like the module to be general purpose enought that it work in X
> >>as well as on the console. Is there any way to do that or do I have to
> >>detect that situation and use X code if connected to a pty?

> > You will certainly have to do it differently for X than for any other
> > terminal.

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

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

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