Rex and the Newport.

Rex and the Newport.

[Alex deVries]

Miguel,

	As per the discussions on #linux, could you let us know when you
have the tar of the rex example you have?  Many thanks.

- Alex

-- 
Alex deVries
"romantic engsoc guy who runs marathons" - csilcock@chat.carleton.ca
http://www.engsoc.carleton.ca/~adevries/ .

Re: Rex and the Newport.

[ralf]

On Wed, Apr 29, 1998 at 02:32:46PM -0400, Alex deVries wrote:

> 	As per the discussions on #linux, could you let us know when you
> have the tar of the rex example you have?  Many thanks.

Btw, whe really should switch all MIPS machines to fbcon or will never
have a kernel with reasonable fast console and support for multiple
GFX types in kernel binary.

  Ralf

Re: Rex and the Newport.

[Alan Cox]

> Btw, whe really should switch all MIPS machines to fbcon or will never
> have a kernel with reasonable fast console and support for multiple
> GFX types in kernel binary.

fbcon assumes direct memory access to the display. abscon is probably
what you want.

Alan

Re: Rex and the Newport.

[ralf]

On Wed, Apr 29, 1998 at 11:38:25PM +0100, Alan Cox wrote:

> > Btw, whe really should switch all MIPS machines to fbcon or will never
> > have a kernel with reasonable fast console and support for multiple
> > GFX types in kernel binary.
> 
> fbcon assumes direct memory access to the display. abscon is probably
> what you want.

Sorry, yes.  I had the G364 based video card for Magnum 4000 /
Olivetti M700-10 in mind which in fact is just a dumb fb.

  Ralf

Re: Rex and the Newport.

[Olivier Galibert]

On Thu, Apr 30, 1998 at 12:34:04AM +0200, ralf@uni-koblenz.de wrote:
> Btw, whe really should switch all MIPS machines to fbcon or will never
> have a kernel with reasonable fast console and support for multiple
> GFX types in kernel binary.

Why not KGI ?

<dodging the fireballs>

  OG.

Re: Rex and the Newport.

[Alan Cox]

> > Btw, whe really should switch all MIPS machines to fbcon or will never
> > have a kernel with reasonable fast console and support for multiple
> > GFX types in kernel binary.
> 
> Why not KGI ?
> <dodging the fireballs>

As of about now KGI provides accelerator and mode switching modules to
fbcon/abscon. Whatever the peanut gallery may be doing the KGI heads
_are_ clueful

Re: Rex and the Newport.

[Alan Cox]

> > Btw, whe really should switch all MIPS machines to fbcon or will never
> > have a kernel with reasonable fast console and support for multiple
> > GFX types in kernel binary.
> 
> Why not KGI ?
> <dodging the fireballs>

As of about now KGI provides accelerator and mode switching modules to
fbcon/abscon. Whatever the peanut gallery may be doing the KGI heads
_are_ clueful

Re: Rex and the Newport.

[Olivier Galibert]

On Wed, Apr 29, 1998 at 11:54:32PM +0100, Alan Cox wrote:
> As of about now KGI provides accelerator and mode switching modules to
> fbcon/abscon. Whatever the peanut gallery may be doing the KGI heads
> _are_ clueful

I do  think so   too  actually.  They  just  have  a  "let's  reinvent
everything" tendancy that plays against them. And very very bad PR.

The only problem I have seen with GGI (reading thier documentation) is
that  non-framebuffer    devices   does   not seem   to     be  really
supported... if  I'm wrong it may  be easier to  use KGI/GGI for video
support on sgi instead of filling the gaps in XFree86.

This would have the additional side effect to allow the use of SVGAlib
programs and maybe open the way to a nice Mesa integration.

  OG.

Re: Rex and the Newport.

[Alan Cox]

> > As of about now KGI provides accelerator and mode switching modules to
> > fbcon/abscon. Whatever the peanut gallery may be doing the KGI heads
> > _are_ clueful
> 
> I do  think so   too  actually.  They  just  have  a  "let's  reinvent
> everything" tendancy that plays against them. And very very bad PR.

Not the  clueful bits - the noisy bits yes

> The only problem I have seen with GGI (reading thier documentation) is
> that  non-framebuffer    devices   does   not seem   to     be  really
> supported... if  I'm wrong it may  be easier to  use KGI/GGI for video

They are not well supported.

> support on sgi instead of filling the gaps in XFree86.

Its easier to make XAA work on mips and go from there.

> This would have the additional side effect to allow the use of SVGAlib
> programs and maybe open the way to a nice Mesa integration.

Svgalib apps will run under X with the svgalib/ggi on ggi/xshm on X ..

Re: Rex and the Newport.

[Alan Cox]

> > As of about now KGI provides accelerator and mode switching modules to
> > fbcon/abscon. Whatever the peanut gallery may be doing the KGI heads
> > _are_ clueful
> 
> I do  think so   too  actually.  They  just  have  a  "let's  reinvent
> everything" tendancy that plays against them. And very very bad PR.

Not the  clueful bits - the noisy bits yes

> The only problem I have seen with GGI (reading thier documentation) is
> that  non-framebuffer    devices   does   not seem   to     be  really
> supported... if  I'm wrong it may  be easier to  use KGI/GGI for video

They are not well supported.

> support on sgi instead of filling the gaps in XFree86.

Its easier to make XAA work on mips and go from there.

> This would have the additional side effect to allow the use of SVGAlib
> programs and maybe open the way to a nice Mesa integration.

Svgalib apps will run under X with the svgalib/ggi on ggi/xshm on X ..

Re: Rex and the Newport.

[Olivier Galibert]

On Thu, Apr 30, 1998 at 12:12:04AM +0100, Alan Cox wrote:
> Svgalib apps will run under X with the svgalib/ggi on ggi/xshm on X ..

ITYM "crawl". HTH. HAND.

:-)

  OG.