![[lang]](/images/eye.png)
Cuecat |
2008-05-18
|
So I got some cuecats off of ebay. They actually just work straightaway, although it took me some time to figure out that there were no drivers to download and compile by hand :) All the documentation on the web seems outdated and seems to mention there are no 2.6 drivers, while they are just in the kernel.
So, I can now scan some barcodes, and they arrive as if they're typed by the keyboard. I guess that's useful for a POS computer, but for me it's a little annoying.
My question to you cuecat owners or Linux specialists - what should I use to programatically see that these digits are coming from the Cuecat device, so that I can intercept them without them coming in as keyboard events ?
One idea I'd like to implement is for my Elisa box to have a cuecat, and when I scan a CD I already own, it would start playing it.
As I recall, the cuecats just show up as a USB HID device (or a PS/2 device, in the case of that variety), which is why they just work with no special driver. That’s basically how all barcode readers work. It ensures that they can be easily used with just about any program, and that they are easy to support. I also seem to remember them doing some weird encryption to the output or something, but I assume that the ones you got have already had that disabled. Maybe the USB / HID sub system could be asked which device the key codes are coming from and that could be used to tell the output is coming from the cuecat? Other than that, I got nothing. Since they are designed to “look like a keyboard”, telling that it isn’t a keyboard seems like it would be tough.
Comment by qhartman — 2008-05-18 @ 13:21
Set up a hal addon that listens in on this particular device, and make the addon eat the events, and spit them out through a dbus interface.
Comment by Bastien — 2008-05-18 @ 13:23
I’d guess you can steal some python code from gnome-lirc-properties, which probably does similar things to allow testing of input-device remote controls. It does some stuff with HAL.
Comment by Murray Cumming — 2008-05-18 @ 15:01
The ones I’ve seen could be configured to spit out one specific keycode before the actual data of the barcode. If your ‘elisa box’ (links welcome ;-) always runs a piece of software in the foreground that accepts keyboard input, you might want to configure it so that a particular keystroke signals to the software that barcode data is following… do make sure the response to that keystroke is instant (or semi-instant), because the hardware isn’t going to wait…
perhaps it is even smart enough to do stuff like ‘alt+f, p’ or some such. I dunno.
Comment by Wouter Verhelst — 2008-05-19 @ 01:53
Umm, why not simply open the corresponding /dev/input/eventX device exclusively from whatever application you want to use? There’s an ioctl() to get exclusive access meaning that the key codes coming from the device won’t show up to any other applications, which is exactly what you seem to want, since you need some sort of special application handling it anyway.
Comment by Johannes Berg — 2008-05-19 @ 13:58
I’ve had one of the original cuecats. It still works just fine. Mine is the ps/2 variety and sits between (as a passthru) the ps/2 port and the keyboard, so it generates hardware ps/2 keyboard events, which ends up making a stream of text in whatever window has input focus. Presumably the USB variety generates USB HID keyboard events (and maybe there’s some way in the linux USB stack to capture a particular HID device’s events?)
Then you just have to “decrypt” the output.
The issue I’ve had with mine is that it doesn’t handle just any barcode. It seems to do OK on UPCs and ISBN codes, but it has trouble with general case bar codes. Plus, the scanner is just not reliable enough for day-to-day usage, though the Elisa plugin idea sounds slick. Just keep a scrapbook of the DVD and/or CD cover liners… very convenient.
Comment by Michael R. Head — 2008-05-19 @ 23:53