From: Emmanuel Marty <core@suntech.fr>
  To  : ggi-develop@eskimo.com
  Date: Fri, 24 Jul 1998 11:08:33 +0000

Re: FW: Cyrix MediaGX fbcon work

Rodolphe Ortalo wrote:

> [BTW Emmanuel: didn't you say that the MediaGX had no text mode ? (Not
> even a vga compatible one.)
> Alan will have a hard time trying to emulate vga text, no ?

No, that wasn't the problem. Alan was asking what he should put in the
mediaGX registers when removing the driver, so as to restore a mode
suitable for console text display. He hadn't realized he just had to
put back a 640x480 mode, since the Cyrix VSA (virtual system
architecture, i don't think i'm allowed to explain how it works, but
basically it provides software emulation of vga hardware registers
behavior) will then render text written into the pc textmode memory
as graphics automatically (slowly, but automatically).

I exchanged emails with Alan this morning, and all should be set
for his driver to exit fine now. I can't give him information protected
by the NDA I signed, but there is enough public info for him to
work out a working driver, from the cyrix gxvideo reference code
and my sources.


As for emulating textmode, this is particularily not a problem on
fbcon, since it means.. framebuffer consoles. m68K machines such
as the amiga have no hardware textmode and that was the whole
purpose of creating fbcon.. emulating a text console on them :)

The fbcon mediaGX driver uses fbcon text rendering, actually. I
hope it makes use of the gx blitter soon.



> While asking this...
>
> I would be interested in having your opinion (and possibly Alan's)
> on the difference and {assets,drawbacks} of the two implementations
> of the MediaGX driver (the one on KGI and the one on fbcon).
>
>

Both are drivers inside the kernel, there will be no functional difference
between kgicon + the KGI mediaGX driver, and the mediaGX fbcon
driver.

One could wonder why kernel hackers and fbcon developers
don't help with kgicon at all - answer is, as usual, we haven't
asked. That's really a problem we have. [Jon, what's the status of
kgicon by the way ?]



> The reason is that one of the most common criticism against KGI is the
> fact that it is probably unsafe to include graphic card drivers in the
> kernel: because they are usually, let's say, bad pieces of software.
> Once again, I heard someone stating such opinion this week here at
> LAAS (and the man is one of the maintainer of XFree86, and a very
> nice guy, so such point of view surely has a very hard life).
>  But this is a criticism we all know very well now...

Well, sure, running display drivers at ring 3 in userspace where every I/O
access is checked is safer, and slower. NT4 moving drivers in kernelspace is
the reason NT 3.51 is more stable about that, if there is such a thing.
In theory a driver running at full IO privileges has more chances of freezing
the machine than when the kernel checks that every IO access is valid.

This said, drivers do _not_ belong inside the X server. What other
*nix does that? Solaris and IRIX split the two, as far as I know. Drivers
inside XFree, is nothing else than an hack.

Drivers for boards using memorymapped registers will crash as much in
ring 3 than in ring 0 once the memory has been remapped, too. Most modern
boards use that. Somehow the XFree people always get around the
subject.

On top of that, I think (but that's just me) that there are more odds than
the driver will freeze the machine by messing up the registers of the board
it drives (and has access to, even in ring 3), than by writing to registers
it shouldn't touch (that running in ring 3 would refuse).

>Fbcon, like KGI, provides a framework for writing hw drivers. But,



> as I hear Alan Cox, who is surely a much better programmer than me, being
> disturbed by something like a vga text emulation (while I was never
> disturbed by such thing while working for KGI), I'm annoyed. Maybe this
> specific point is not very interesting, but, nevertheless, I think we
> should take the opportunity of such similar development to have an
> _experimental_ comparison of KGI and fbcon, with respect to the
> "quality" of the drivers.

Again Alan has no text emulation problem, see above. In the standard
kernel, KGI drivers will run through fbcon, so quality will be comparable.
KGI has much stronger acceleration capabilities though. fbcon is
more greased to work with standard kernel mechanisms.

> I trust both Alan and Emmanuel and would appreciate if they could provide
> me with their practical feelings on fbcon and KGI.

Thanks for the trust.. Here you go :)

> [1] We could try fault injection and probabilistic dependability
> assessment later if you want, I have several experts near me for that...
>  ;-))

I don't understand plurisyllabic words such as those ;)

--
Emmanuel