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.