Re: [Linux-fbdev-devel] Supporting various depth

[Petr V. <VAN...@vc...>]

On 14 Jun 01 at 13:34, James Simmons wrote:
> > On Matrox it is almost same, only constant differs. There are defined 
> > FB_AUX_TEXT_MGA_STEP8 and FB_AUX_TEXT_MGA_STEP16. Millennium1 and
> > G-series use STEP16, Mystique and MillenniumII use STEP8 ... nv3 driver
> > should use STEP8 - maybe after creating FB_AUX_TEXT_STEP8 and
> > obsoleting *_MGA_* values.
> 
> Yipes. What is in that extra space? 8 bytes for one cahracter? I rather
> keep the text modes and the fbdev modes seperate. I like to think of
> /dev/vcsa as for text modes where /dev/fb is the device for graphics
> modes. So I like to see a api developed for text modes. 

There is no discussion that /dev/vcsa interface should contain
<character,attribute> pairs and nothing else. But /dev/fb* in text
mode does not (and cannot) match /dev/vcsa layout, and apps may have
legitimate need for accessing framebuffer directly even in text mode
(although I cannot invent reason directly).

These unused bytes come from simple thing: VGA videoram is organized in
4 planes, and when you are in text mode, even-odd addressing is enabled
so memory looks like:

              0         4         8       12           <- framebuffer offset
plane 0     char0     unused    char1    unused
plane 1     attr0     unused    attr1    unused
plane 2     font0     font1     font2    font3
plane 3     unused    unused    unused   unused

(where font are font data as programmed to VGA) while 
through VGA interface you see:

            char0     attr0      char1    attr1
            
because of address bit A0 does not select bit A2 of memory address, but
instead connects to videoram's A0.

Just some background: in 16color graphics modes CPU bits
A0 -> A15 are connected to VRAM A2 -> A17 and A0,A1 are derived
from GDC's read-plane-select for read and from SEQ's write-plane-enable
for write (for write it is bitmap, for read just one plane is read
unless GDC is in read mode 1).

Nobody prevents you using same mode for text, but in such case interface
at B8000 is not compatible with VGA videomemory layout as remembered
by DOS gurus and as presented in /dev/vcsa (but you can use 128KB
A0000 window and write character at 0xAXXXX and attribute at 0xBXXXX).
If you'll use this layout, framebuffer will look:

char0 attr0 font0 unused
char1 attr1 font1 unused
char2 attr2 font2 unused
...

And you can also program VGA into dword fetch mode, in which memory
layout looks:

  0        4        8        12      16        20      24
char0    unused   unused   unused   char1    unused   unused
attr0    unused   unused   unused   attr1    unused   unused
font0    font1    font2    font3    font4    font5    font6
unused   unused   unused   unused   unused   unused   unused

Millennium1 uses this mode because of reads from framebuffer
returns random data for offsets 4-15 due to bug in their prefetch
circuity (and as stated in manual: when chip is in VGA mode, effect
of accesses through framebuffer is undefined).

G-series instead implement VGA memory not as 4-planes, but as 8-planes
videoram, so standard layout looks:

  0        8       16        24
char0    unused   char1    unused
attr0    unused   attr1    unused
font0    font1    font2    font3
unused   unused   unused   unused
unused   unused   unused   unused
unused   unused   unused   unused
unused   unused   unused   unused
unused   unused   unused   unused

Except for location of font data (they are at 2+X*8 and not at 2+X*4)
it is same as mode I used for Millennium1, and nobody should program
font through /dev/fb*, so I reused same FB_TEXT_AUX value.
                                                    Petr Vandrovec
                                                    van...@vc...