Menu
▾
▴
linuxconsole-dev
|
From: James S. <jsi...@ac...> - 2000-08-27 03:06:34
|
Hi! It's been some time since I have posted here with what I'm doing. At first I was playing with the idea of a universal VC switching function. This lead to my discovery of how vgacon and screenbuf inter act. TO discribe what my goals are I have to first describe what I understand of the console system. If I have a misconcept tell me I'm wrong. In the current console system (ruby) each struct vc_data represents each vitrual console. Only one is active at a time on each VT. Now each struct vc_data has a vc_screenbuf which is a shadow buffer where text values are stored. This allows text to be written to non visible consoles. Only for the visible VC is the text inside of show buffer is actually drawn with functions defined in struct consw. This is true for all drivers except vgacon. Why? Because the console system was originally designed around the VGA text hardware mode. Because of this the shadow buffer layout matches the VGA text mode layout. Now to describe this shadow buffer. The shadow buffer is a buffer that is x columns wide and y rows high. For normal VGA text mode this is usually 80x25. 80 columns wide ----------------- | | | | 25 rows. | | | | ----------------- So the shadow buffer is (80x25 * 2) wide. The reason for the 2 is each component is 16 bits wide. The high 8 bits represent the text attributes. These are blinking, underline etc. The low 8 bits represent the text value, usually a acsii character. For vgacon the shadow buffer of the visible VC points directly to the VGA text buffer. Now VGA hardware has built in font images. So a mapping happens from the value in buffer to the font images in the cards memory. Now for the next step in the evolution of the console system. Well I made a discovery today. Their exist vga cards (JEGA, AX-VGA) that can display asian characters. I also discovered some old BIOS calls that might lead to figuring out if double byte fonts could be supported. The BIOS call int 10h, ah=18h, al=0,1 which can get/set a font pattern. This leads to me to believe it might be possible for VGA to support double byte fonts. This of course would mean a rethinking of how the shadow buffer should be done. Any ideas anyone? MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: Vojtech P. <vo...@su...> - 2000-08-27 10:01:08
|
On Sat, Aug 26, 2000 at 11:17:56PM -0400, James Simmons wrote: > Now for the next step in the evolution of the console system. Well I > made a discovery today. Their exist vga cards (JEGA, AX-VGA) that can > display asian characters. I also discovered some old BIOS calls that might > lead to figuring out if double byte fonts could be supported. The BIOS > call int 10h, ah=18h, al=0,1 which can get/set a font pattern. This leads > to me to believe it might be possible for VGA to support double byte > fonts. This of course would mean a rethinking of how the shadow buffer > should be done. Any ideas anyone? Well, it might be possible, though I never have seen a card that would be capable of that. Even the version of Ralf Brown's interrupt list doesn't say anything about that. What might be interesting, though, is using the feature that int 10, ah 11, al 3 allows. It can be easily set via registers as well. 512-character font could be very useful for Unicode mappings. Another cute feature possible would be to use the font page in the VGA card (be it 256 or 512 characters) as a cache of letter images, and only use those that are displayed on screen. This would allow using huge fonts (> 512 chars), assuming that one never uses all the letters at once. Full Unicode support, for example. -- Vojtech Pavlik SuSE Labs |
|
From: James S. <jsi...@ac...> - 2000-08-27 14:15:32
|
> > Now for the next step in the evolution of the console system. Well I > > made a discovery today. Their exist vga cards (JEGA, AX-VGA) that can > > display asian characters. I also discovered some old BIOS calls that might > > lead to figuring out if double byte fonts could be supported. The BIOS > > call int 10h, ah=18h, al=0,1 which can get/set a font pattern. This leads > > to me to believe it might be possible for VGA to support double byte > > fonts. This of course would mean a rethinking of how the shadow buffer > > should be done. Any ideas anyone? > > Well, it might be possible, though I never have seen a card that would > be capable of that. Even the version of Ralf Brown's interrupt list > doesn't say anything about that. It is there. Int 10/AH=18h. Their is also a AH=19h (Japanese VIDEO - DOUBLE-BYTE CHARACTER SET SHIFT). Not much info tho :-( As for the text modes (mode 52h) that support 16 bit characters appears to be actually vga 16 color graphics modes. I still like to know where those extra fonts are stored. Maybe in regular memory. We do have vgafb which could be made to support 16 bit characters. Since vgafb is supported on any platform that vgacon is this expands the range of languages linux can support. The only problem is ... > What might be interesting, though, is using the feature that int 10, ah > 11, al 3 allows. It can be easily set via registers as well. > 512-character font could be very useful for Unicode mappings. > > Another cute feature possible would be to use the font page in the VGA > card (be it 256 or 512 characters) as a cache of letter images, and only > use those that are displayed on screen. This would allow using huge > fonts (> 512 chars), assuming that one never uses all the letters at > once. Full Unicode support, for example. ... how to handle so many fonts. I like the idea of a cache of X amount of characters. Even for fbcon this would be useful. As for the layout of the shadow buffer. We really need to reconsider its layout. With the idea of a font cache how about this. 16 bits is used to represent each character. The high 8 bits are a index to different font caches. This allows 256 different font caches. The lower 8 bits acts as a index into the font cache. Now what to do with the attributes? The idea of having 24 bits to represent a text charachter botehrs me. I prefere if it was 32 bits. We have to do alot of shifting bits around to get to work otherwise. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: Petr V. <van...@vc...> - 2000-08-27 21:56:57
|
On Sun, Aug 27, 2000 at 10:26:55AM -0400, James Simmons wrote:
> > > call int 10h, ah=18h, al=0,1 which can get/set a font pattern. This leads
> > > to me to believe it might be possible for VGA to support double byte
> > > fonts. This of course would mean a rethinking of how the shadow buffer
> > > should be done. Any ideas anyone?
>
> It is there. Int 10/AH=18h. Their is also a AH=19h (Japanese VIDEO -
> DOUBLE-BYTE CHARACTER SET SHIFT). Not much info tho :-( As for the
> text modes (mode 52h) that support 16 bit characters appears to be
> actually vga 16 color graphics modes. I still like to know where those
> extra fonts are stored. Maybe in regular memory. We do have vgafb which
If you'll insist on 8x16 font (16 bytes per character) and only 65536
characters, it is 1MB only... Yes, if you want different character
sets (different font slices) on each VT, it can get memory consuming,
but in such case - create kernel thread which will have access to
swappable memory and swap unused characters out. Or leave whole
font delivery on userspace...
> could be made to support 16 bit characters. Since vgafb is supported on
> any platform that vgacon is this expands the range of languages linux can
> support. The only problem is ...
> ... how to handle so many fonts. I like the idea of a cache of X amount of
> characters. Even for fbcon this would be useful. As for the layout of the
> shadow buffer. We really need to reconsider its layout. With the idea of
> a font cache how about this. 16 bits is used to represent each character.
> The high 8 bits are a index to different font caches. This allows 256
> different font caches. The lower 8 bits acts as a index into the font
> cache. Now what to do with the attributes? The idea of having 24 bits to
> represent a text charachter botehrs me. I prefere if it was 32 bits. We
> have to do alot of shifting bits around to get to work otherwise.
I do not think that font cache idea is best... Leave it on user - if he
has hardware which is not capable of displaying more than 512 different
characters simultaneously, give him two choices:
(1) select which 512 characters he'll use or
(2) limit his screen to 512 characters only and change character generator
instead of screen contents
Yes, shadow buffer layout needs to be changed. Do not forget Martin Mares
ideas when doing it - currently slowest thing during screen scroll is
shifting buffer in memory. Having array of pointers to lines can
make this operation much faster.
For character, either make it 4:4:24, where
first 4=one of 16 currently selected colors,
4=one of 16 currently selected colors,
24=character number; either Unicode 0-10FFFF, or arbitrary font
encoding..., or, if you want, 32:32:32:32,
where 32=reserved,
32=foreground color, 8:8:8:8 RGBA or 16:5:6:5 or 24unused:8 or...
32=background color,
32=character number
I do not think that anything else is reasonable. And do not forget that
for 32:32:32:32 one on-screen character consumes 16 bytes, 80x25 screen
then consuming 32K instead of current 4KB...
Petr Vandrovec
van...@vc...
|
|
From: James S. <jsi...@ac...> - 2000-08-30 12:15:33
|
> If you'll insist on 8x16 font (16 bytes per character) and only 65536 > characters, it is 1MB only... Yes, if you want different character > sets (different font slices) on each VT, it can get memory consuming, > but in such case - create kernel thread which will have access to > swappable memory and swap unused characters out. Or leave whole > font delivery on userspace... Yeap. It should be handled as much as possible in userspace. I believe we should allow only one font type per VT at boot time. If possible share that font with as many VTs as possible. This way we can use COW techniques to save on memory consumation. In fact the new code in CVS points works this way. I have a default font in struct vt_struct and every vc_data that is attached to that vt_stuct have its own font point pointing to the default font. When userland changes this then the pointer will point to the new font. If the user uses the default font which is the most common case then only one copy of the font exist in memory for all those VCs. > I do not think that font cache idea is best... Leave it on user - if he > has hardware which is not capable of displaying more than 512 different > characters simultaneously, give him two choices: > (1) select which 512 characters he'll use or > (2) limit his screen to 512 characters only and change character generator > instead of screen contents True if it is a harware limitation. If it is not then its gets a little tricky. Maybe all we need is 512 to get threw the boot process for w_char based languages. After boot time let userland handle it. > Yes, shadow buffer layout needs to be changed. Do not forget Martin Mares > ideas when doing it - currently slowest thing during screen scroll is > shifting buffer in memory. Having array of pointers to lines can > make this operation much faster. Interesting idea. Also what is really slow is bmove. Inserting a character and moving all the characters to the left of it can be pretty tricky. The thing I never understood is way the shadow buffer is the exact same size as the visible area of the display. Why not make it bigger and just move a pointer in the shadow buffer. We can 99% of the time use harware panning to move the characters up and then just read the buffer further down in the buffer to display them. Yes sooner or later we have to flip this shadow buffer. > For character, either make it 4:4:24, where > first 4=one of 16 currently selected colors, > 4=one of 16 currently selected colors, > 24=character number; either Unicode 0-10FFFF, or arbitrary font > encoding..., This is closer to what is really needed. We also need a byte for attributes. Maybe we can squeeze it in 4 bits. This will consume less memory as you pointed out. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: Steffen S. <se...@ph...> - 2000-09-11 08:27:31
|
James Simmons wrote: > Now for the next step in the evolution of the console system. Well I > made a discovery today. Their exist vga cards (JEGA, AX-VGA) that can > display asian characters. I also discovered some old BIOS calls that might > lead to figuring out if double byte fonts could be supported. The BIOS > call int 10h, ah=18h, al=0,1 which can get/set a font pattern. This leads > to me to believe it might be possible for VGA to support double byte > fonts. This of course would mean a rethinking of how the shadow buffer > should be done. Any ideas anyone? Designing the KGI console system, I had a similar problem. The solution I have implemented is not to make any assumption about how the graphics card stores the displayed text. Basically it works this way: The console layer handles the glyph information to be displayed using full UNICODE-2.0 (or it's successor, the ISO norm for 32bit character codes). Using the font and attribute information, this is translated into a font-specific code, which is stored in the shadow buffer using a pattern defined by the graphics driver only. Then the graphics driver does the rendering from the shadow buffer, it never gets involved with the glyph-code -> font position translation. This way it is up to the graphics driver, which attributes and how many font characters it supports. However, due to the current (VGA compatible) shadow buffer layout used by KGI only 256 font characters are possible. Hope this is of help, Steffen _______________________________________________________________________________ Steffen Seeger mailto:se...@ph... TU-Chemnitz http://www.tu-chemnitz.de/~sse |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X