On Tue, 16 May 2000, Stefan Seefeld wrote:
> Marcus Sundberg wrote:
> >
> > "Jon M. Taylor" <[EMAIL PROTECTED]> writes:
> >
> > > On Tue, 16 May 2000, Antony Suter wrote:
> > > > SDL already has OpenGL support in place as of version 1.1.
> > >
> > > GGIMesa.
> >
> > Like Joseph said GGImesa is useless for anything except testing,
> > and very simple drawing on fast machines, as noone is currently
> > working on bringing HW-support into it.
> >
> > However I already have a working LibGGIGL extension which integrates
> > LibGGI with the OpenGL API, with HW acceleration. Currently it only
> > supports using GLX on the X target, but it can easily be made to
> > (transparently) support GLX, GGIMesa and Win32 OpenGL on their
> > respective targets.
> >
> > There are some issues with the extension mechanism that needs to
> > be sorted out before it is fully functional, but I'll try to commit
> > the current version to CVS this weekend.
>
> Interesting. My concern is, as I already said, with the hacked double
> buffer in GGIMesa. We tried to run berlin on /dev/fb on a conference in
> November and it turned out that Jon had set the second pointer to point
> to the same memory as the first, i.e. circumventing double buffering
> without the client's notice.
I've been wanting to fix this, but I lost my CVS privs when Mesa
CVS moved to SourceForge and I can't seem to get hold of anyone over
there. Also the current CVS doesn't link properly, so I can't even
produce patches |-/. Sorry guys, maybe you should consider switching to
Marcus' GGIGL extension for a while. It sounds like it might be a better
solution for you in the short term than GGIMesa, which I really don't have
time to work on seriously now anyway.
> Since the next conference is approaching rapidly (Stuttgart, end of June)
> I'd really like to be able to run berlin without X, first, because
> this is what berlin is intended for and second, because it will (hopefully)
> be much faster due to the avoided crossblitting.
? What crossblitting? What do you mean? There _was_
crossblitting with Uwe's old GGIMesa doublebuffer scheme - render into the
backbuffer visual, crossblit it to the frontbuffer visual every SYNC.
Slow as hell and prohibits hardware acceleration from being used, which is
why I took it out.
> Any propositions concerning how to run berlin on /dev/fb would be very
> welcome.
The linux console is a pretty nightmarish thing sometimes, and
while Marcus has done a really good job trying to make it all work
smoothly in the fbdev target and linvtsw helper, problems still happen.
I have recently gone throught this myself with some code I'm writing for
work.
It is odd to see a program work perfectly with the X target, and
then watch it freeze or block waiting on events. But I have seen this
behavior with both fbdev and Glide targets on the Linux console. The
problem with such freezes is that, because the fbdev target puts the
console into MEDIUMRAW mode, VC switching is disabled and so is
ctrl-alt-del. You just locked up your console, and therefore your machine
unless you enabled the magic sysrq key and know how to use it or can
telnet in and reboot.
I have been able to make this go away by using the
GGI_FBDEV_OPTIONS=-novt option to make the fbdev target avoid opening a
new VT. You might want to try that. I'm not sure why this isn't the
default anyway... Marcus? It does leave the console cursor active and the
console still owns STDIN, but you can change that with a few ioctls.
Jon
---
'Cloning and the reprogramming of DNA is the first serious step in
becoming one with God.'
- Scientist G. Richard Seed
