dev:vtc_4

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
dev:vtc_4 [2005/01/15 15:17] – NicholasSouchudev:vtc_4 [2013/07/25 16:58] (current) – MarcelMoolenaar
Line 3: Line 3:
 //The vtc(4) driver -- life after syscons// //The vtc(4) driver -- life after syscons//
  
-=== Notes ===+  * vtc(4) stands for Video Terminal and Console.
  
-  * vtc(4) stands for Virtual Terminal and Console+=== Video ===
  
-  * 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.+  * The vtc(4) driver will have 2 main parts: the system console handling and the video 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|Plugins]].+  * At a minimum, we should have a proper vga(4) driver. A proper VGA driver is one that allows us to use the video hardware for the system console, as well as for the VT. Of course nowadays the video hardware is much more capable than VGA, so for the VT we would like to have drivers that exploit the capabilities of the hardware. That allows us to get higher resolutions, deeper colours and/or higher performance. But a VGA driver would always give us basic functionality when the particular hardware is not supported as-is. 
 + 
 +  * The video hardware is expected to be used in graphics mode. The reasons for this are that 1) not all environments include text mode operations, 2) video hardware is all about 2D/3D graphics operations, and 3) user demand goes beyond the limitations of text mode. The down-side of graphics mode is that basic text-only use of the video hardware is likely to be slower without accelerated 2D hardware support. Luckily accelerated bitblt operations were the first to exist. 
 + 
 +  * The video hardware driver should be simple. It should be able to switch the hardware in a suitable graphics mode and should support bitblt operations. The bitblt is the basis upon which vtc(4) builds. The main objectives are to keep the hardware drivers small and to minimize the amount of redundant functionality as much as possible. 
 + 
 +=== Keyboard & mouse ===
  
   * 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.   * 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.   * 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.
 +
 +  * It's important to utilize the currently existing keyboard drivers. This means that we need to provide the interface(s) they expect to exist. Unfortunately, the current interfaces are kind of a kluge. It may be beneficial to improve upon this first, without breaking anything. The bottom line is that a keyboard provides codes, aka scancodes, and depending on the keyboard, those codes translate to functions and/or characters.
 +
 +=== Terminal emulation ===
  
   * 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.   * 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).+  * The TE should abstract the hardware by using KOBJ interfaces for the display, keyboard and keyclick/speaker. This avoids encoding hardware specifics into an otherwise hardware independent state machine and thus allows the TE to work in diverse situations. Advantages of the KOBJ abstraction for the keyclick/speaker include the ability to use pcm(4) for cute (read: annoying) audio samples :-) 
 + 
 +  * vtc(4) supports different TEs by means of a KOBJ interface. This allows different video terminals to use different terminal emulations. 
 + 
 +  * In total there are 4 KOBJ interfaces: 
 +    * the TTY-TE interface uses KOBJ to make it possible to configure different TEs for the video terminals 
 +    * the TE-video interface uses KOBJ to abstract the video hardware 
 +    * the TE-keyboard interface uses KOBJ to abstract the keyboard hardware 
 +    * the TE-audible interface uses KOBJ to abstract the bell/beep/speaker hardware
  
   * 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...   * 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...
 +
 +  * After some research, I came to the conclusion that it's best to start with a VT100 or VT102 terminal emulator: The reasons are:
 +    * It's currently the most often used TE in the context of UTF-8, including %%PuTTY%% and xterm.
 +    * It doesn't have dozens of hard-to-implement features that distract from the over-all objective.
 +    * It can be tested with vttest, making it possible to end up with a decent implementation.
 +    * It's still one of the most widely supported.
 +    * Tools like luit or pluto can be used to convert between the locale specific encoding or ISO 2022 to UTF-8, making full ISO 2022 support in VTC redundant.
 +
 +  * Given that decision, here are some random thoughts about implementation details:
 +    * The TE should operate on UTF-32 UNICODE only. As such, Conversion from UTF-8 to UTF-32 happens before the TE and is not a concern of the TE. This is in general the opinion of how it should be done.
 +    * The TE may or may not have support for switching of the character set. No support means that the TE is stateless in that respect and thus that it won't be a problem any more to have the display emit all kinds of graphic characters and/or dingbats after accidentally displaying a binary file (i.e. no need to reset your TE). On the other hand, it may be that enough applications depend on charset switching that it may still be beneficial.
 +    * At a minimum or at first, the TE is expected to operate with VGA hardware in graphics mode with a resolution of 640x480. The default VT100 screen size is 80x24. This means that the maximum font size is 8x20 in that case.
 +    * Followup: an 8x19 font leaves 24 pixel rows unused, which means that there's an additional text line plus 5 pixel rows. This allows us to have a 1-line on-screen status- and/or toolbar for on-screen configuration and things like that. Plus there's a 5-pixel row high seperator then that can double as a horizontal scrollbar, handy when using 132 column mode without trying to fit it all on screen.
 +    * Followup: A typical LCD with a resolution of 1024x768 probably needs fonts like 12x32 or 12x30.
 +    * To support the double-wide and/or double-height character modes, a graphics solution (again) shows favorable. Appropriate fonts are needed for that as well. I need to find out where I can get appropriate fonts, including of course the %%FreeBSD%% repository itself.
 +
 +=== KGI ===
 +
 +  * I need to spend some time figuring out how [[/KGI|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).
  
 === References === === References ===
Line 25: Line 62:
 Graphics: Graphics:
  
 +  * http://intellinuxgraphics.org/
 +  * http://www.osdever.net/FreeVGA/home.htm
   * http://people.freebsd.org/~nsouch/kgi4BSD/   * http://people.freebsd.org/~nsouch/kgi4BSD/
   * http://www.ggi-project.org/   * http://www.ggi-project.org/
Line 30: Line 69:
   * http://www.fresco.org/   * http://www.fresco.org/
  
-Terminal:+Hardware: 
 +  * DECchip 21030 (TGA): http://people.freebsd.org/~marcel/refs/graphics/21030.pdf 
 +  * DECchip 21130 (TGA2): http://people.freebsd.org/~marcel/refs/graphics/21130.pdf 
 + 
 +Terminals:
  
   * http://www.unicode.org/   * http://www.unicode.org/
   * http://vt100.net/   * http://vt100.net/
 +
 +VT100/VT102:
 +
 +  * http://vt100.net/docs/vt100-ug/contents.html
 +  * http://vt100.net/docs/vt102-ug/contents.html
  
  • dev/vtc_4.1105802251.txt.gz
  • Last modified: 2005/01/15 15:17
  • by NicholasSouchu