Who Decides Which Application Receives Keyboard Signals?

signalsterminal

My current understanding of signals from keyboard in terminal is (based largely on trying to map my observations to what can be found on google) following:

User presses C-c
This is sent to input buffer of terminal as a byte which is computed by clearing 2 leftmost bits from 7 bit ascii value of c

After this it starts to be really foggy, because the configuration what input means what signal is done in terminal (stty). I suppose it means that the terminal itself is sending the signal to the process. But I also though that terminal does not know about application that is reading it.

How does sending a signal by keyboard in terminal work from end to end?

Best Answer

Pressing C while Ctrl is pressed sends a keypress followed by keyrelease X11 event to the terminal emulator.

Upon that event (generally the keypress one), the terminal emulator writes the 0x3 byte (^C) to its file descriptor on the master side of the pseudo-tty device.

If the isig termios setting of the device is on and if the intr setting is set to that 0x3 byte, then the kernel sends the SIGINT signal to all the members of the foreground process group of the terminal device (another attribute stored in the pty device). In that case, the 0x3 byte will not be available for reading on the slave side of the pty.

It's usually interactive shells that create process groups (with setpgid()) for shell jobs, and decide which one to put in foreground (with tcsetpgrp() to set that attribute of the pty device) or not.

For instance when you run at the prompt of an interactive shell:

foo | bar

The shell starts a new process groups with two processes (in which it executes foo and bar after having connected their stdin/out with a pipe) and puts that group in foreground. Both processes would receive the SIGINT if you pressed Ctrl-C.

In:

foo | bar &

Same but the process group is not put in foreground (and the shell also doesn't wait for it so you can enter other commands). Those processes would not get the SIGINT upon Ctrl-C but could be suspended if they try to read from the tty device.

More reading at: What are the responsibilities of each Pseudo-Terminal (PTY) component (software, master side, slave side)?

Related Solutions

Relations between control characters, signals and terminal

The terminal driver (part of the operating system) establishes the relationship between special characters and signals. Your terminal settings, e.g., using stty, are what it uses to decide what (if anything) to do with characters that you type. You can reassign those special characters as needed with a few caveats:

only one special character per function
only single-byte characters are used

controlC and controlD are conventional: while a few applications may hardcode these values, the terminal driver does not require that.

The terminal driver is software, not part of your terminal. For some keyboards you may find different assignments of special characters more convenient than others (and for different operating systems, a few choices of the default values for the special characters may differ).

Xorg – How Does Xorg Work?

Your description doesn't quite match your diagram, and is more correct than your diagram.

The X server does not use the tty driver for either input or output. It reads inputs directly from the drivers for the various input devices and sends output directly to the graphics card drivers.

You can list the input devices with xinput and then get further information with xinput list-props. For example:

$ xinput | tail -n 1
    ↳   USB Keyboard                            id=10   [slave  keyboard (3)]
$ xinput list-props 10 | tail -n 1
        Device Node (263):      "/dev/input/event2"

You can see that my X server obtains input from my USB keyboard by reading from /dev/input/event2.

For output, I don't know if there's a similar user-level tool. xrandr --listproviders lists the graphics drivers that are in use or available, but does not list /dev entries. You can see which graphics device the X server has open with lsof -p$(pgrep Xorg) or less /var/log/Xorg.0.log.

The concept of controlling terminal was designed for text mode sessions. An X server may or may not have a controlling terminal depending on how it was launched. An X program that was started from a GUI menu typically doesn't have a controlling terminal, because the window manager doesn't have one. An X program started from a shell running in a terminal does have that terminal as a controlling terminal.

Best Answer

Related Solutions

Relations between control characters, signals and terminal

Xorg – How Does Xorg Work?

Related Question