On Llu, 2005-10-24 at 02:46 -0500, Travis H. wrote:
> Ideally any mechanism would be flexible enough that I could have it
> deliver me timings between key-down, key-up-to-key-down, or up/down to
> up/down timings. And it should be efficient enough that it can
> deliver most of them unprocessed to some userland collector daemon
> which does the filtering of outliers and whatnot.
The keyboard layer abstracts out up/down events, repeat key
functionality and extensions in the normal case. You can put the
keyboard into raw mode and do the work yourself (X does this) and then
feed the results to an application using a pseudo-terminal (see man
openpty).
For networks you are somewhat screwed as the network protocols have
their own timing info and most (telnet, ssh etc) don't pass key up/down
info and batch characters when appropriate. X events might be usable
this way.
> Since I'm on the subject, a related project I had in mind would be
> hacking the keyboard to do its raster-scan in a pseudo-random order
> that was synchronized with the terminal driver such that the signal on
> the wire was, if not encrypted, at least scrambled enough to be
> difficult to convert back into plaintext. What would this involve on
> the kernel side?
Write a new keyboard driver for the new keyboard you've built. PC
hardware can't do it but we already support keyboard drivers for a
variety of devices and PDAs which are different to the PC world.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]