linux background card swipe reader

Question

I currently have a USB card swipe attached to an embedded linux machine and from what I can tell and from what I have researched it acts as a keyboard, and inputs all the data as if I were typing. Now I have a perl script that takes all this data and saves it to a file. The only problem is, it only knows to take the data when the perl script is running in the foreground otherwise, where does the "keyboard" input to.

My question is how can I make this card swipe run the script every time it reads input? Or could I somehow capture the data with an app running in the background. I.E. in a c++ program, running in the background, will cin read ANY input to the machine?

I have never messed around with a card swipe reader so Im not 100% sure on how they work.

Any suggestions on this would be appreciated!

Answer 1

I have an idea, but it is very general.

Can you constantly be monitoring for data in another program, buffer it, and then pipe the results into your perl script when the buffer reaches a certain size or goes for a certain period of time without activity? If you pipe it in, you shouldn't have to modify your perl script, since it will still be on STDIN.

So, it would be like this:

Monitoring Program -> Collects Data -> Pipes it into your Perl program

I hope this idea is helpful.

-Brian J. Stinar-

Answer 2

cin will read input from the attached terminal input device. Without knowing more about your software design, my first hunch is reading the data from a Perl script isn't the best choice of design. I can read IR remotes on embedded Linux devices using a Perl script as you describe, but in general I interface directly with the hardware or a vendor supplied API from within my main application. Was there an API provided with your card reader?

What's the device name of the card reader when it's plugged into your machine (/dev/*)? I'd open that and read it that way.

Answer 3

I've never dealt with this in Linux. However this sounds very similar to what I've seen in Windows.

In my experience, a lot of these types of devices are automatically detected by the operating system as a keyboard-type of device. So any input from the reader is fed into the same keyboard stream that the real keyboard uses. By the time this reaches any actual programs running, there is no way to tell the difference between the card reader inputting data and a user just typing really really fast.

As a consequence, you get the behavior described in the original question: the card reader's input only goes where normal keyboard input goes - to the program in focus.

Your best option would be to investigate the manufacturer's website (or otherwise contact them) and find out if they provide some kind of driver that would allow a program to catch that input totally separately from the keyboard stream.

If the manufacturer doesn't provide such a thing, perhaps some 3rd-party does. But unfortunately, I've never investigated that so I don't know where to tell you to even start looking.

Answer 4

I have done almost exactly this (except with a USB barcode reader that appeared as a keyboard).

My system has custom USB hotplug rule that detects the USB device when it is plugged in based on its vendor and product ID. This rule creates a symlink to the corresponding event device in /dev/input/.

I then have a C daemon that runs at all times. It watches the /dev/input/ directory, and when it sees the symlink appear it opens the event device. It then uses the EVIOCGRAB IOCTL to grab the event device for exclusive use (this prevents the data appearing as keyboard input in other applications), and reads input events corresponding to keypresses. The daemon converts the keypresses into characters and stores them in a database.