How can I capture keyboard events and use a monitor as a text-display on Linux?

Question

I have a server running in multi-user mode that is connected to a keyboard and a monitor. On a separate computer, I would like to SSH to the server and run a program that captures input from the keyboard and prints text to the monitor. The keyboard and monitor will never be used for any other purpose.

Right now, when the server boots, a (text) login screen is displayed on the monitor. I know that I can write to the corresponding /dev/tty device. However, the keyboard also writes to the same place.

How can I capture keyboard events and use a monitor as a text-display on Linux?

I may be missing some of the basics around hardware interfacing on Linux. What do I need to know?

Running out of bounty time - If someone wants to flesh this out further I'll award accordingly:

I did the following to prevent any login programs from starting:

systemctl mask serial-getty@ttyO0
systemctl mask systemd-logind
systemctl mask getty@tty1

Then I am running my program when required with:

openvt -c 1 -f /path/to/my/program

This would be a fully satisfying solution, except for that pesky -f. What is running on tty1? Is there anything I can do to stop it? Should I stop it?

Notably, this solution does meet all of my needs -- As far as I understand it, I am taking over the tty and thus get access to its stdin (receiving output from keyboard) and stdout (printing to monitor).

Cyme

Why not just have sshd run the appropriate program on login? – Henriquez

Can you elaborate? I don't see the connection between "how to start the program" and "how does the program accomplish its goals". – Cyme

Oh, I see. The keyboard and monitor you want to interface with are connected to the server. That's what openvt is for. – Henriquez

You can replace that program displaying the login prompt and waiting for the keyboard input. That way your program would be in control of the console terminal (what your program writes to its standard output would get displayed on the console, what you type on your keyboard would get entered into the standard input of your program) instead of the original program there. – Mell

Okay, so a starting point on a systemd system would be to disable [email protected] and edit /etc/systemd/logind.conf to set NAutoVTs=0 and ReserveVT=0. Now no login prompt will be active and I can write to /dev/tty0 to print what I'd like. How can I then see what the keyboard is attached to? (ex. Alt-F2 will still try to change to tty2). – Cyme

No. Instead of disabling getty, you should replace it. Your program should be run there instead. – Mell

I don't understand how to do that... if I get dirty and replace ExecStart in /usr/lib/systemd/system/[email protected]... how do I set the keyboard as stdin? – Cyme

You don't have to, it's done automatically when your getty replacement is started by the system. – Mell

Answer 1

If you are willing to go to low level programming you don't have to handle stdin or stdout. Just talk to the keyboard device and the console device directly.

Take a look at the source code of input-events from input-utils. It uses raw data to read keyboard, mouse or any other input device.

To avoid the default processing of the keyboard it uses the grab mode (-g in the CLI), that translates to a:

ioctl(fd,EVIOCGRAB,1)

in the device file descriptor. Reading raw events from /dev/input/event* is more or less straightforward: #include <linux/input.h>, do the grab thing, and then read struct input_event structures from the device.

To write to the console, if you don't want to mess with the TTY madness, and now that you are in low level mode, you may prefer to write directly to /dev/vcs, or /dev/vcsa for color (a for attribute) output.

Basically the vcs has one byte per screen cell that contains the code of the character shown. In vcs there are two bytes: the character and the attributes. See man vcs for details.

Herta