> > > Neomagic card on a Notebook?
> > AFAIK there is no KGI driver for the neomagic,
> > One would have to write a driver for KGIcon to run on the neomagic.
> > Is information on the neomagic available by now, or are they still
> > "protecting" their design flaws ;-) ?
> Funny... It seems som
> Should libggi2d support arbitrary clipping - or would it be acceptable to
> have a 'small' version with only rectangular clipping ? (But with decent
> drawing functions.)
I don't think LibGGI2D should have arbitraty clipping. I'd leave that to
a windowing library or a 3D package.
I only know
[EMAIL PROTECTED] writes:
> The X target should also send expose events, as is suggested by
>
> bash-2.03$ grep evExpose */*.c
> xwin/input.c: giiev.any.type = evExpose;
>
Yep found that code. Its in GII_xwin_evenpoll.
> See my other post on this. Please tell us, if expose d
[EMAIL PROTECTED] writes:
> AFAIK there is no KGI driver for the neomagic, but it is known to work with
> the generic vesafb driver in the kernel.
>
> Note, that this driver has severe limitations like not being able to change
> the mode it is running in, but allows to use many cards that impl
Thomas Mittelstaedt <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] writes:
>
> > The X target should also send expose events, as is suggested by
> >
> > bash-2.03$ grep evExpose */*.c
> > xwin/input.c: giiev.any.type = evExpose;
> >
>
> Yep found that code. Its in GII_xwin_
James A Simmons <[EMAIL PROTECTED]> writes:
> > > The g400 has an advantage however in that I have yet to convinced this
> > > thing (Voodoo3) to run in a window. When I tell it to run in a window it
> > > ends up full-screen anyway and it tries to use this LAME framebuffer copy
> > > hack which
On 5 Mar 2000, Marcus Sundberg wrote:
> James A Simmons <[EMAIL PROTECTED]> writes:
>
> > > > The g400 has an advantage however in that I have yet to convinced this
> > > > thing (Voodoo3) to run in a window. When I tell it to run in a window it
> > > > ends up full-screen anyway and it tries
teunis <[EMAIL PROTECTED]> writes:
> I'm just remembering that GGI -> svgalib emu -> GGI isn't allowed...
That should work:
App does ggiOpen("svga", NULL), gets svgalib target which uses
svgalib emu.
Svgalib emu does ggiOpen(NULL), which returns another target.
What does not work is:
SVGAlib a
libggi.conf.in has the variable DLLEXT, which is supposed to be
replaced with "so" or "DLL" or something during the make process. This is
not happening, and the @DLLEXT@ is remaining in the final libggi.conf. I
just blew away my whole degas/ tree and tried it again with a fresh
checkout,
"Jon M. Taylor" wrote:
>
> libggi.conf.in has the variable DLLEXT, which is supposed to be
> replaced with "so" or "DLL" or something during the make process. This is
> not happening, and the @DLLEXT@ is remaining in the final libggi.conf. I
> just blew away my whole degas/ tree and tri
> > Note, that this driver has severe limitations like not being able to change
> > the mode it is running in, but allows to use many cards that implement
> > the most important stuff of VESA 2.0
> Thank you for the hint. Does 'severe limitations' mean still good enough
> to do development on??
On Sun, Mar 05, 2000 at 05:08:59PM -0500, James Simmons wrote:
> > > > > The g400 has an advantage however in that I have yet to
> > > > > convinced this thing (Voodoo3) to run in a window. When I tell
> > > > > it to run in a window it ends up full-screen anyway and it tries
> > > > > to use thi
12 matches
Mail list logo
