On 26 June 2001 12:44 GMT, Hans Zauner wrote in
>> > Hello,
>> > I am developing a C application that operates a barcode reader. The
>> > reader hardware uses a PS/2 keyboard interface, with a split cable;
>> > one for the barcode reader, and one to plug the keyboard into.
>> > This is being developed under RedHat 6.2, with kernel 2.2.16. The
>> > problem is how I can open the local physical keyboard directly. I
>> > can't seem to find any /dev special file that correlates to the
>> > keyboard,
Would /dev/kbd be it? I'm looking at the 2.4.4 kernel docs, so maybe
it isn't in 2.2.x? See what devices.txt says in /usr/src/linux/Documentation
It is a character device under major # 11 minor # 0. If it's there
then the kernel should support it, just use mknod if a file hasn't
been created for you.
Otherwise, /dev/tty corresponds to the current virtual terminal,
and /dev/tty* corresonds to a specific virtual terminal. /dev/console
refers to the system console. These are the devices normally used
for keyboard input.
Quote:>> > and when I open stdin it seems the kernel always deals with
>> > the ingress data before handing it to me. For instance, when I hit
>> > Alt-F2, it changes consoles, instead of letting me read the data
>> > directly.
I think raw keyboard mode will do this. As I remember, svgalib
trapped the virtual terminal switching so that it could change
to/from text/graphics mode when the user pressed Alt-Function key.
Try looking at the source for svgalib where it handles the
keyboard. I imagine it did something like set raw mode, when
it detected an alt-function keypress, it executed the correct
command (probably an ioctl to /dev/console) and switched the
terminal--you could just leave out this last step. 'man 4 console'
and 'man 4 console_ioctl' may be helpful to you as well.
Quote:>> > Is it possible to "cut in front" of the kernel on the stdin
>> > device, so I can handle the input, and pass it to the kernel for
>> > normal processing, or drop it, or deal with it myself.
Not sure how to do this, I don't think the kernel has the capability
to send keyboard data to a specific process, allow it to read/filter
the data, then receive data from the process and handle it as usual.
Maybe you need a kernel module?
Quote:> For one, there is no programming example. The issue is this barcode
> reader is in a public place, and as a result a lot of garbage (from
> people leaning on the keyboard for example) comes in through stdin.
> At the same time however, certain admins need to use the keyboard. I
> know we could unplug the keyboard and plug it back in when we need,
> but I want to do it in a better fashion than that. There must be some
> way to intercept stdin.
I'm not sure what you want? Are you trying to get raw data from
the keyboard, or do you want to reroute keypresses to your program?
If you want raw mode tcsetattr will allow you to make changes to
how the data is handled and I think it will allow you to set RAW
mode--cfmakeraw is probably what you want.
If you are trying to intercept key input and do some processing
on it then send it to another program, using pipes may work for
If you need to intercept all input from the keyboard for all
processes, I'm not sure how to do this in userland...you may
need to modify the kernel or make a kernel module to do this.
Quote:> Maybe assembly would be best?
No need to revert to assembly--nearly everything done in Linux
is and can be done with C. From what I understand the only
commonly used code written in assembly are the bootsector for
LILO and a small percentage of the kernel.
Quote:> What would be
> a good newsgroup to post to as well?
This is probably the correct one for you, unless you decide
to make a kernel module, then comp.os.linux.development.system
is the one you want.
It may be helpful to know: Is the program you are writing an
application that needs routines to read the barcode scanner's
data (and therefore doesn't have to worry about giving keyboard
data to other programs), or is it more of a driver that intercepts
the keyboard and catches the scanner's data, which then you
want to send the vaild keypresses to the process that would
normally receive them?