The relation between tty driver and line discipline

Originally, "tty" had two definitions: the hardware (now the emulator) and the driver (interfaced through /dev/pty* or /dev/tty*).

The hardware/emulator was/is responsible for:

• Taking a stream of data and presenting it; this included interpreting control sequences like "move cursor left", "blinking cursor", "clear-screen" although these control sequences were often different among manufacturers.
• Sending keycodes for keys typed by the user; most of these were standard ASCII characters, but some terminals sent propriety keycodes for even standard keys.

The 'tty' driver was responsible for:

• Managing the buffering, in raw or canonical mode; for example, buffering a line of characters until Enter is pressed.
• Managing the control flow; e.g. being able to stop/continue with Cntl-s/Cntl-q.
• Translating propriety keycodes to standard ASCII, where applicable.
• Intercepting certain control characters (like Cntl-c and Backspace) and processing them appropriately (send SIGINT on a Cntl-c or signal an EOF on Cntl-d.
• Canonical display of characters, for example, if echo is turned off, then do not send feedback (character typed) back to the terminal.

The terminfo and termcap databases managed what terminal control characters should be sent for an operation (like 'clear-screen'). These control sequences were/are not interpreted by the driver, but by the hardware/emulator.

Was the idea behind the controller to be able to control devices from a different manufacturers with the same driver?

No. The primary purpose is to provide part of the interface between devices and the processor. A controller has its own driver; this is in addition to any drivers necessary for the devices connected to it.

The reason the interface is necessary is that the processor is highly specialized; controllers are sort of translators from the specialized world of the processor to the multiverse of devices. The processor only has one physical data connection to the outside (the bus), not a variety of them, and in fact, generally intermediary between controllers and the processor are bridges which connect the processor to the motherboard. Device controllers are then connected to the motherboard and communicate via a bridge. So there are four discrete physical entities in the chain: processor -> bridge -> controller -> device, all of which involve their own software drivers (a driver for the processor, for the bridge chipset, then for each of the controllers, and for each of the devices).

If you look at the diagram below from this wikipedia article, the blue boxes at the bottom represent device controllers.

[By Alexander Taubenkorb, Creative Commons Attribution-Share Alike 3.0]