linuxconsole-dev

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

[James S. <jsi...@tr...>]

> huh ???
> 
> What special hardware support is needed there. The card is just a multi
> function agp board, with both pm# having their own mmio and fb space, as well
> as the (unused by fbdev) gamma bridge.

This is what I mean. The card has to have two fully functional framebuffers, 
mmio regions and seperate accel engines if used. In a nut shell the hardware
has to have two independent states.

> It is just like a dual card setup. Is there a hardware reason you cannot keep
> vgacon on the first head, and have fbcon setting up a new console on the
> second head ? 

If the card can support being in a vga text state and a graphics state at
the same time then I see no problem. 

> I guess it is more limited by the software, isn't it ? Is it
> possible to have vgacon and fbcon active at the same time with 2.4.+ kernels ?

   Not with 2.4.X :-( The console system uses a gloal struct consw
(conswitchp). You really have to hack up the console system to get it to
work. For me I just rewrote the whole thing. 
   For ruby it is possible but I haven't done it yet. The biggest problem
right now is the current vgacon I have. Lots of global variables. I like
to be able to pass the register region and the text memory region to
vgacon. By default they would be 0x3C0 for the registers and A000 for the
text memory region. Well something like that. These regions are different
on different platforms. Now you could write a small wrapper that passes in
the pci regions. This is what I plan to do for the NVIDIA text mode
driver I have. It pretty much is vgacon except it uses the pci regions
instead. I also plan to vgacon firmware independent as well. 
   As for your case it would be a matter of coordinating both pm3con and
pm3fb together. They have to have the same initialization function to
ensure the correct regions go to the correct console display drivers.  	

> > then. Does the pm2 card have such a feature?
> 
> mmm, don't think so, will have to check it. But the problem is, i think, that
> thec chip don't really knows that something is going wrong.


Some cards can tell if something does go wrong. A example is the ATI
cards. They send out a irq when the accel engine goes bonkers. It is
really for debugging but I can see its use otherwise. Imagine a X server
ontop of ati fbdev and if the X server does something foolish then the
kernel driver would correct itself. This would be a really nice feature.
Plus you get the bonus info in syslog if you use printk to let you know
something went wrong.

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

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

On 14 Jun 01 at 21:51, Matan Ziv-Av wrote:
> On Thu, 14 Jun 2001, James Simmons wrote:
> > So basically I need a vga_ops struct that defines functions to access the
> > vga_region. Have any ideas what is needed? How is the linear aperture
> > arranged differently?
> 
> In vga: 
> char[n] is at mem[2n]
> attribute[n] is at mem[2n+1]
> 
> In nv3, linear aperture:
> char[n] is at mem[8n]
> attribute[n] is at mem[8n+1]

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.
                                        Petr Vandrovec
                                        van...@vc...
                                        

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

[James S. <jsi...@tr...>]

> > In vga: 
> > char[n] is at mem[2n]
> > attribute[n] is at mem[2n+1]
> > 
> > In nv3, linear aperture:
> > char[n] is at mem[8n]
> > attribute[n] is at mem[8n+1]
> 
> 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. 

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...
                                                    

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

[Matan Ziv-Av <ma...@sv...>]

On Thu, 14 Jun 2001, James Simmons wrote:

> > I guess it is more limited by the software, isn't it ? Is it
> > possible to have vgacon and fbcon active at the same time with 2.4.+ kernels ?
> 
>  Not with 2.4.X :-( The console system uses a gloal struct consw
> (conswitchp). You really have to hack up the console system to get it to
> work. For me I just rewrote the whole thing.
>  For ruby it is possible but I haven't done it yet. The biggest problem
> right now is the current vgacon I have. Lots of global variables. I like
> to be able to pass the register region and the text memory region to
> vgacon. By default they would be 0x3C0 for the registers and A000 for the
> text memory region. Well something like that. These regions are different
> on different platforms. Now you could write a small wrapper that passes in
> the pci regions. This is what I plan to do for the NVIDIA text mode
> driver I have. It pretty much is vgacon except it uses the pci regions
> instead. I also plan to vgacon firmware independent as well.

This won't exactly work - there are some ways to access the vga
registers - io (might be remapped from 0x3c0-03df to other address),
memory mapped (at any address) or other (nvidia uses other). Also the
memory in the linear aperture is organized differently (at least on the
nvidia) then the memory at 0xa0000-0xc0000. The solution is probably for
the chipset drivers to supply functions (incrtc, outcrtc, etc.)



-- 
Matan Ziv-Av.                         ma...@sv...

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

[James S. <jsi...@tr...>]

> This won't exactly work - there are some ways to access the vga
> registers - io (might be remapped from 0x3c0-03df to other address),
> memory mapped (at any address) or other (nvidia uses other). Also the
> memory in the linear aperture is organized differently (at least on the
> nvidia) then the memory at 0xa0000-0xc0000. The solution is probably for
> the chipset drivers to supply functions (incrtc, outcrtc, etc.)

So basically I need a vga_ops struct that defines functions to access the
vga_region. Have any ideas what is needed? How is the linear aperture
arranged differently?

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

[Matan Ziv-Av <ma...@sv...>]

On Thu, 14 Jun 2001, James Simmons wrote:

> 
> > This won't exactly work - there are some ways to access the vga
> > registers - io (might be remapped from 0x3c0-03df to other address),
> > memory mapped (at any address) or other (nvidia uses other). Also the
> > memory in the linear aperture is organized differently (at least on the
> > nvidia) then the memory at 0xa0000-0xc0000. The solution is probably for
> > the chipset drivers to supply functions (incrtc, outcrtc, etc.)
> 
> So basically I need a vga_ops struct that defines functions to access the
> vga_region. Have any ideas what is needed? How is the linear aperture
> arranged differently?

In vga: 
char[n] is at mem[2n]
attribute[n] is at mem[2n+1]

In nv3, linear aperture:
char[n] is at mem[8n]
attribute[n] is at mem[8n+1]

In other cards it is different from both, but I don't remember the
details.


-- 
Matan Ziv-Av.                         ma...@sv...