Take note that sometimes you’ll have a headless system and so remote desktop solutions like VNC won’t work, an ssh approach might mitigate some of the problem, but if you have a process running you won’t be able to access its stdin just your ssh shell’s stdin.

One solution to that problem could be to create a custom input device driver to use on your system that would receive the data in some other way, that is a good solution although a bit complicated. The developers of the Linux kernel gave us a simpler way than writing our own driver, and from userspace. They have created a special module that allows us to do just that and its called /dev/uinput. uinput is a kernel module that makes it possible to emulate input devices from userspace.

Some possible use cases:

1. You would like to remotely control the navigation of a device (drone/car).
2. You have a CPU running Linux inside your system you can’t reach and you want to give it input directly.
3. You want to create a remote controller for your Android based media streamer.
4. Your system has a custom set of buttons and keys and you would like to develop its software on a PC with standard input and deploy it as is to the target.
5. You are an Android app developer or QA and want to create and recreate frequent usage scenarios and run it automatically on the device.
6. You want to duplicate one input to several devices that are connected in some way.

A virtual custom input device will work for all these cases, but how to do it? the documentation for the uinput module in kernel.org states that: By writing to /dev/uinput (or /dev/input/uinput) device, a process can create a virtual input device with specific capabilities. Once this virtual device is created, the process can send events through it, that will be delivered to userspace and in-kernel consumers.

All the information you need can be found in The Linux Input Documentation, I will mention here a few basics for you to get started, all the code I show including a wrapper class and a tester script can be found in this repo. The process of building this kind of virtual input device is made of a few steps:

First you need to open a file descriptor to the module:

m_fd = open(“/dev/uinput”, O_WRONLY | O_NONBLOCK);

After that comes the stage of configuring and creating the device using several ioctls, first you’ll setup the type of events the device can create, you will probably use one or more of the following:

• EV_KEY — for key press events (like a keyboard)
• EV_REL — for relative movement input (like a mouse)
• EV_ABS — for absolute location events (like a touch screen)

ioctl(m_fd, UI_SET_EVBIT, EV_KEY);

Second is registering the keys you want the device to be able to emulate. all key codes can be found in the input-event-codes.h header file

for (int i = 0; i < sizeof(m_keys)/sizeof(m_keys[0]); i++)
{
ioctl(m_fd, UI_SET_KEYBIT, m_keys[i]); // register all wanted keys
}

Third comes some general information such as vendor and bus type and the device creation itself

memset(&usetup, 0x0, sizeof(usetup));
usetup.id.bustype = BUS_USB;
usetup.id.vendor = 0x1209; // Generic vendor
usetup.id.product = 0x5678;
strcpy(usetup.name, m_name);
ioctl(m_fd, UI_DEV_SETUP, &usetup); // setup the device
ioctl(m_fd, UI_DEV_CREATE); // create the device

The last part is the generation of an event, a value of 1 means pressed and 0 means released

Emit(int type, int code, int val)
{
struct input_event ie;
ie.type = type;
ie.code = code;
ie.value = val;
/* timestamp values below are ignored */
ie.time.tv_sec = 0;
ie.time.tv_usec = 0;
write(m_fd, &ie, sizeof(ie));
}

Emit(EV_KEY, code, 1);
Emit(EV_KEY, code, 0);

to finalize and sync the input and actually send all the events a sync event is generated

Emit(EV_SYN, SYN_REPORT, 0);

I made a small POC using a Raspberry Pi + Screen, a laptop and a Wi-Fi connection, all sources can be found here.

The Raspberry Pi is connected to a screen and to a Wi-Fi network (no keyboard), the PC is connected to the same Wi-Fi network.

On the Raspberry Pi I ran a small app that creates a virtual keyboard with a set of keys and listens to a UDP port to receive instructions for keys pressed and creates input accordingly, for some relevant keys I implemented a toggle mechanism.

On the PC I wrote a python script that sends instructions using a UDP client. The instructions are encoded as ASCII characters which will be parsed on the target. Lowercase letters and whitespaces as their values and uppercase letters for special keys.

Finally, the end result is a terminal console opening, an arcade game (Dangerous Dave) being run via dosbox and a gameplay of the first level. I captured the screen output of the Raspberry Pi in the next video:

A word of warning - in this POC I focused on functionality, it is in no way a good idea to use this clear-text, no authentication, direct access protocol on a real system for obvious security reasons, a real system should implement a more secure credential based protocol.

Notes:

1. root privileges are required to access /dev/uinput.
2. I recommend reading “The Linux Input Documentation” at https://www.kernel.org/doc/html/v4.12/input/index.html, specifically the section on the uinput module.
3. There is a wrapper library that provides interfaces to create uinput devices called libevdev, it’s worth mentioning as it can help implement some of the functionality shown above.

As an embedded developer, a hardware, firmware, FPGA or software engineer you have probably found yourself using Linux to some extent in your system. Many vendors use Linux in their SOCs, SOMs and platforms. Xilinx, Nvidia, TI, RaspberryPi and BeagleBoard to name a few.

When working on embedded systems it is common for software to interact with hardware elements and to need access to physical memory (memory blocks, registers, PCI mapped regions etc.).

Some possible use cases:

1. You are working on a SOC that has some capabilities that can be controlled through registers.
2. You have a system with two processing units connected using PCIe bus and you want to transfer data between them using the PCI mapped regions.
3. You are working on a SOC with an FPGA and want to share a buffer between the CPU and the FPGA. Decode a sound sample using a vocoder and pass to the FPGA to calculate the FFT for example.
4. You have multiple register values presets on files in the filesystem and you want to load and switch between them on runtime.

In the Linux operating system the virtual memory is divided to two regions — Kernel space and User space. Kernel space is where the kernel (the core of the operating system) runs and provides services, User space is where all user processes (processes that are not part of the operating system) run. In Kernel space it is possible to access physical addresses, but writing kernel code requires a bit more experience with C and operating systems, furthermore, since the Linux kernel is written solely in C you will be limited to that language only.

Fortunately for us, Linux has a mechanism to allow memory access from User space using device drivers.

We have a few options, the first is accessing a memory address from CLI. If we want to read or write an integer value at a specific address we can use a utility called devmem, it is available as part of the busybox software suite. This option is also useful in shell scripting.

But sometimes this isn’t enough, if we need to access a bigger chunk of memory or we want to control and integrate the memory access into our process, we need another option, a device driver called /dev/mem, it is a character device file that is an image of the main memory, byte addresses in mem are interpreted as physical memory addresses. What we need to do is map these addresses and then use them to access the physicals memory addresses.

We get the requested offset and size of the memory we want to access, we calculate the nearest memory page aligned address, open the memory device driver and then map the memory using mmap() to get a pointer to a R/W memory block with the requested size.

As an example of using this method I used my Raspberry Pi 4 that has a timer mechanism (see pg. 157 here) that can be set and read using registers, I load the value to 8000, start the timer, sample it 3 times to show changes and then stop the timer and sample 3 times again to see stable values.

The code for the example in C can be found here and in Python here.

Notes:

1. root privileges are required to access /dev/mem.
2. I recommend reading the mem and mmap man pages for better understanding of the mapping.
3. if you are having problems accessing some memory regions a possible cause can be that a kernel configuration option that limits access called CONFIG_STRICT_DEVMEM is set, you can check your kernel config options to make sure.