Somebody porting a board has to work on the application side before the
keyboard driver exists, and somebody reviewing that work often does not
have the board at hand at all.
With -i the tool goes the other way and writes into a uinput keyboard,
either what it reads from its own stdin or every key of another keyboard.
So an application reading /dev/ukeyboard is driven from the serial
console, or from whatever is on the far end of it, and a real keyboard
and an injected one can drive it at the same time, which neither can do
on its own since an application opens a single device.
Nothing in the application changes: it is reading a keyboard like any
other, which is the point.
Validated on a Linum STM32H753BI, forwarding a USB HID keyboard and the
serial console into the same virtual keyboard, with the LVGL terminal
reading it. 24 press and release pairs survived the crossing with no
duplicate, no orphan and three keys held at once.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
The hidkbd and keyboard examples do the same thing for one kind of
keyboard each: hidkbd reads a USB HID keyboard as a byte stream, and
keyboard reads an upper half keyboard as events. Neither works with the
other, so bringing up a new keyboard means picking the right example
first, and there is no answer for somebody whose keyboard is neither.
Every keyboard registered with keyboard_register() is read the same way,
so one tool covers them all: USB HID, matrix, simulator, virtio, VNC.
The payload follows INPUT_KEYBOARD_BYTESTREAM rather than a switch of
its own. An application has no business knowing what hardware is behind
the device, and a build cannot mix the two formats anyway.
The two examples stay for now. They are what the in-tree configurations
still name, and removing them has to wait until those configurations
have been moved over.
Signed-off-by: Jorge Guzman <jorge.gzm@gmail.com>
