Why pseudo-terminal infers keystrokes from /dev/pts/{number}
(and) X-session infers keystrokes from /dev/input/by-id/{keyboard-device-name}?
I understand pseudo-terminal are running on-top of X-session.
Why is pseudo-terminal so special that it has a separate file location to read/write the data which will be subsequently displayed in the UI terminal view?
How did Kernel knew the difference between a pseudo-terminal and other applications such that it wrote to 2 different file locations?
Why is pseudo-terminal so special that it has a separate file location to read/write the data which will be subsequently displayed in the UI terminal view?
Because there are two fundamentally different views of the user input in play on your desktop.
The display server (X11 or your Wayland compositor) handles all the input from hardware, through /dev/input/... (when using libinput at least). X11 and Wayland clients receive the corresponding events through the respective protocols.
Programs which aren’t X11 and Wayland clients, but need to receive input, are run using some form of emulation. A terminal emulator is one such emulation: as its name suggests, it emulates a terminal, and is helped in this by pseudoterminals which involve /dev/pts/... devices.
Thus when you run a program in a terminal emulator, your keystrokes follow this path:
keyboard → kernel → display server → terminal emulator (as a higher-level event) → pseudoterminal → program
This provides the final program with the illusion that it’s running with its input (and output) connected to a terminal.
How did Kernel knew the difference between a pseudo-terminal and other applications such that it wrote to 2 different file locations?
It doesn’t know about applications and where they receive their input. It knows about the keyboard and feeds events from that through input devices; and separately, it knows about pseudoterminals, and allows controlling programs to transmit events through them.
