This is an old revision of the document!
dev : vtc(4)
The vtc(4) driver – life after syscons
Notes
- vtc(4) stands for Virtual Terminal and Console
- The vtc(4) driver will have 2 main parts: the system console handling and the virtual terminal handling. Each part should use its own hardware abstraction. Hardware drivers for the system console are not necessarily usable for the VT and vice versa. For example, one may have to use the firmware for low-level console I/O and use a real device driver for the VT. However, it's also possible that a single hardware driver (like a VGA driver) can be used for both. Thus, the hardware abstractions must allow preemption in the sense that a VGA driver maybe used for the system console, but a driver for the actual accelerated 2D/3D card may be loaded/used during bus enumeration.
- We should have a proper vga(4) driver, as well as a proper tga(4) and/or tga2(4) driver. I see no point in supporting CGA, EGA or any other legacy standard. So, elementary drivers would suffice. These should probably work in graphics mode if at all possible, because text modes may be ugly on LCD screens (such as on my Vaio PCG-R505GL). I think sparc64 and powerpc will more often have graphics-only hardware anyway. Graphic drivers should be loadable as Plugins.
- Keyboard handling may be a bit tricky on some platforms, but in general an AT keyboad or USB keyboard should work. On sparc64 we also support UART based keyboards. On ia64 we should be able to get the necessary information from EFI or ACPI I would expect. I think it makes sense to enhance cninit() to allow for a two-phase initialization. That way vtc(4) can first deal with the output devices, after which it may be selected as the console. It will then have a chance to see if there are any input devices while being able to print to the console and so give feedback to the user as to whether an imput device was found or not.
- Maybe we need to integrate pointing devices and other means to interact with the console. This could be the vehicle to support internet or multimedia keyboards or whatever they are called. In general this probably boils down to having multiple distinct hardware drivers feeding into a single TE/TTY device or vice versa. I need to study this. Maybe someone already has some experience with this.
- On top of graphical output drivers and input drivers we need a TE (Terminal Emulator). The TE feeds into the TTY layer. It's probably a good idea to prototype something simple to get the feel for it.
- I need to spend some time figuring out how [“KGI”] relates to all this. Note that on ia64 it's not possible to use a X server without also doing some significant VM work. The problem is that we have no way for a process to mmap(2) uncachable memory. Even if we extend the mmap(2) flags, we still have a problem forwarding it to the PMAP layer. So, the console doesn't have to support X, provided the X server supports GGI (which it does even on the basis of the Xorg implementation).
- Unicode/UCS – We probably want to use Unicode 3.2 (which corresponds to ISO 10646-2:2001) or Unicode 4.0 (which corresponds to the third version of ISO 10646). UCS stands for Universal Character Set and this is what ISO 10646 defines. USC-2 is a 16-bit encoding and USC-4 is a 32-bit encoding (actually just 31 bits, but the encoding takes 4 bytes). Unicode corresponds to UCS at implementation level 3 (read: fully compliant). The best way to interface with vtc(4) would be to use the UTF-8 encoding. UTF-8 is compatible with 7-bit ASCII and uses multiple bytes to respresent characters beyond what ASCII can encode. Hence it's a multi-byte encoding. It's main feature is that it allows Unicode (or USC) to be used on Unix without much pain. Time to get the Unicode standard…