Programming

Hi all experts in linux and programming!

I want to make work the following setup:
2 usb keyboards connected to a normal x86
One keyboard working as usual in xorg, but I need that the other one doesn't send anything to xorg but instead I want to process its keystrokes with some kind of background process.

How can it be done?

First a bit of theory: you communicate with a UNIX system by using a "tty": a "terminal" consisting of a keyboard and a screen, usually connected via a serial line.

If you connect to a UNIX system over a network you use a so-called "terminal emulator program" (many times "xterm", but that is not the only one) to emulate such a terminal and its serial connection is emulated via the network connection.

There is a special form of a tty, which is called console. This is not connected via the standard serial line but directly attached to the computer. Perhaps the local screen attached to your VGA-card and the (first) keyboard form this console.

Now, after that much theory, to your specific question: this might work, but not necessarily with a USB-attached keyboard and definitely not with a background process. Background processes are part of a process hierarchy, headed by some foreground process: this is usually the shell from which you initiated the background process, typically by issuing the command:

Code:

$ /path/to/command -someoptions &

Since the shell you typed that in was already connected to some tty (the one which keyboard you used to type it, probably the console) the background process inherited this connection. You can cut it off from this (by using the nohup command) but per default itis attached to the one you used to call it. Furthermore, a single USB-attached keyboard is not a terminal.

I hope this helps.

bakunin

There are devices such as bar code readers that can be connected to act like a keyboard. So - in principle, I guess your request should be doable, while I don't have a solution at hand.
Does it make sense to connect a keyboard without a screen enabling people control over what they typed in?

Before attempting ANYTHING that hits the hardware hard, read up on any protocols required for the USB ports, plus how they work and this includes the keyboard and mouse for those ports too. KB and mouse use USB version 1.1, [1.0?], minimum and do not require I/O speeds greater than about 1.5Mbs data rate.

In Linux flavours, or at least most, there are __accessable__ devices that can be read from and/or written to. I have no idea if this is true of professional UNIX tools however. The protocol for the keyboards being sent and received can be read easily using basic code in differing languages but not necessarily sync'd at all. The data being sent by the KB has many bytes in it in binary form; the same goes for the pointing device,(mouse).

Writing to a USB port via one of these devices is not the same animal however.

Unless you have at least studied how this/these __serial__ interfaces work be careful as they are __effectively__ in __parallel__. As bakunin has implied these could be allocated tty[?] device names in the UNIX domain but can be COM[?], usually COM1 and COM2 for KB and mouse respectively, in the Windows domain, but I have no idea what they are in the Apple OSX !0.7.x and above domain, perhaps also tty[?]. The Linux domains could be special devices and/or tty[?].

IMO it is certainly not an easy task for a novice to intercept a second KB's I/O and redirect from its main duty as user input on any machine in question.

(I would like to be proven wrong however.)

Bazza.

I can't say anything about Linux, but in FreeBSD it would not be really hard.

You just have to tell devd (and possibly Xorg) to ignore that specific keyboard. If can do that, you are free to read /dev/ukbd0 (or ukbd1) as you please. What you get from there might be ascii or scancodes, or you might be able to choose.

It should be similar in Linux, devd is called udev there, I think.

Juha

Here is a snapshot of reading KB event6 in Ubuntu 16.04 64 bit...
It is in /dev/input/ ...
As I quoted in most Linux flavours reading is easy, understanding the protocol is NOT!
As you can see with this snapshot of the 'Ubuntu Terminal', to run it from the '/dev/input/' directory requires 'sudo'...
sudo cat event6
Note there were only 3 keys pressed and 1 combination of keys...
Now see how difficult it is to monitor any KB knowing its device, just think how difficult it is if you have disabled said KB and required data from it.

Okay, I was assuming too much.

Juha