Re: VSTa update

I think you have a minor misunderstanding of the FB support. The Linux kernel
text attribute support is not the same as the framebuffer.

The Kernel level framebuffer is a full graphics driver (non-acceperated) to a
graphical device .. it has very little to do with text support. When your
running a "text console" in FB, you actually running "emulated text" .. or
rather .. rendered text. With framebuffer there is very little need for the
svgalib at all. Acceleration of the device can still be done via user land
interfaces. Perhaps a quote from the kernel's docs on the framebuffer can
describe this better then my tired mind can.

----
The frame buffer device provides an abstraction for the graphics hardware. It
represents the frame buffer of some video hardware and allows application
software to access the graphics hardware through a well-defined interface, so
the software doesn't need to know anything about the low-level (hardware
register) stuff.
The device is accessed through special device nodes, usually located in the
/dev directory, i.e. /dev/fb*.
---
Part of the design flaws with the old ggi was basicly it attempted to shuv a
nasty chunk of bloat into kernel land.  The newly revised ggi family breaks it
down into the KGI (framebuffer patches) and the libggi .. where libggi is
capable of locating the best "interface" for the job.  It will attempt KGI,
FB, X, svgalib .. (I think in that order but I havn't beat on it in so long I
forget).  
Anyway .. the linux kernel FB is an abstract interface to a graphics adapter
that allows for the userland application to supply it's own acceleration.
Thusly a new svgalib, or libggi, or X11 need supply the graphical acceleration
for the FB device.  Linux FB is not a textmode thing at all.
On Fri, Mar 10, 2000 at 09:19:43PM -0800, David Jeske wrote:
> On Fri, Mar 10, 2000 at 04:56:11PM -0800, Andy Valencia wrote:
> > [David Jeske <jeske@chat.net> writes:]
> > >I looked into it a while back and thought that the kernel portion of
> > >LinuxGGI would fit nicely into a VSTa server. (it basically arbitrates
> > >access to the video hardware so applications don't need root/sys.sys
> > >access to control the screen)
> > 
> > The problem I had was that I couldn't find any graphics hardware support in
> > it; it appeared to depend on the Linux kernel FB support.  And *that* stuff
> > looked pretty deeply embedded in the kernel.  To the extent that svgalib
> > looked much easier to adopt.  Has this changed?
> 
> Now that I looked deeper at what they have, it does not seem far
> enough along to be consider a "big-win" IMO. 
> 
> --
> 
> Given that, however...
> 
> I don't understand what you are referring to exactly. The Linux kernel
> FB support is just support for basic text modes. The biggest thing the
> Linux kernel FB stuff does is provide an API for telling user-level
> software to "let go" of the hardware and restore it to a known
> state. That's how switching virtual consoles with X works...
> 
> The single biggest goal of GGI is to provide _one_ place where
> hardware specific drivers live, in GGI. In 1998 they released a sample
> implementation that had hardware support for a number of graphics
> cards. They now have a new implementation based on what they learned
> which unfortunatly only has dumb framebuffer support for four types of
> hardware (VGA, S3 ViRGE, Matrox G200/G400, Permidia). Acceleration
> support is non-existant. 
> 
> FYI: Here is a summary of where I understand code to live in GGI and
> non-GGI Linux setups.
> 
> 1. non-GGI    
> 
>   Text modes:      linux kernel             
>   svgalib:         card-specific userspace library      
>   X-windows:       card-specific xwindows executable      
> 
> 2. GGI
> 
>   Text modes:   card-specific in-kernel GGI driver
>   svgalib:      card-specific in-kernel GGI driver + 
>                    svgalib-compatible userspace library
>   X-windows:    card-specific in-kernel GGI driver + 
>                    generic Xggi X server
> 
> 
> -- 
> David Jeske (N9LCA) + http://www.chat.net/~jeske/ + jeske_at_chat.net
> 
-- 
        "That is precisely what common sense is for, to be jarred into
         uncommon sense."
	     ++ Eric Temple Bell, Mathmatics: Queen of the Sciences
   Mark Ferrell    :   Major'Trips'
   Lead Programmer :   Chaotic Dreams Development Team
   URL             :   http://www.planetquake.com/chaotic
   E-Mail          :   major@planetquake.com