>>106544684
https://github.com/emacs-mirror/emacs/blob/master/src/keyboard.h
>Each KBOARD represents one logical input stream from which Emacs gets input. If we are using ordinary terminals, it has one KBOARD object for each terminal device.
>Usually each X display screen has its own KBOARD, but when two of them are on the same X server, we assume they share a keyboard and give them one KBOARD in common.
>Emacs has two states for reading input:
>** Any kboard. Emacs can accept input from any KBOARD, and as soon as any of them provides a complete command, Emacs can run it.
>** Single kboard. Then Emacs is running a command for one KBOARD and can only read input from that KBOARD.
>All input, from all KBOARDs, goes together in a single event queue at interrupt level. read_char sees the events sequentially, but deals with them in accord with the current input state.
>In the any-kboard state, read_key_sequence processes input from any KBOARD immediately. [...] It switches to the single-kboard state for the execution of that command, so that the command can get input only from its own KBOARD.
>While in the single-kboard state, read_char can consider input only from the current KBOARD. If events come from other KBOARDs, they are put aside for later in the KBOARDs' kbd_queue lists.
It sounds like it may be natively possible (e.g. without multiseat) by running two emac processes in terminals reading from /dev/input/by-id/usb-*1-kbd and /dev/input/by-id/usb-*2-kbd respectively, as the x backend otherwise muxs keyboards together. Then share either an indirect-buffer or a regular file hooked with revert-buffer