[Dri-devel] Incomplete scene with OpenGL + direct rendering + mga

2003-11-25 Thread Jan Gukelberger
[I'm not sure this is a problem with DRI itself, but DRI is definitely involved and a guy in comp.os.linux.x told me to ask this list - so I'm trying my luck here.] I have tried to compile and run some simple OpenGL programs. But lots of them don't display anything or only part of the scene if

Re: [Dri-devel] Incomplete scene with OpenGL + direct rendering + mga

2003-11-26 Thread Jan Gukelberger
> You should try the daily snapshots available from the DRI website... I did so yesterday. I also had to install the XFree86 binary from the 'extra' section and ln -s libexpat.so.0 libexpat.so.1 However, it didn't solve any problem. The examples of my first message still produce the same r

Re: [Dri-devel] Incomplete scene with OpenGL + direct rendering + mga

2003-11-26 Thread Jan Gukelberger
> Doing a glFlush() before glutSwapBuffers() makes the last triangle > visible. That's right! At least, this is a temporary workaround so I can go on experimenting with OpenGL programming. But I really hate not being able to play bzflag during lunch time ;-( Nevertheless it's good that I

Re: [Dri-devel] Incomplete scene with OpenGL + direct rendering + mga

2003-11-27 Thread Jan Gukelberger
> Both problems are now fixed. Wow, that was really quick! I've just tried several OpenGL examples and bzflag and you're absolutely right: It's all fixed. Thanks a lot. :-))) > It's a good thing you reported this because your missing triangle was the > same bug that caused the mouse curs

[Dri-devel] Lightweighted graphics for realtime application

2003-11-27 Thread Jan Gukelberger
Having my starting problems with OpenGL and DRI fixed (thanks again @Ville) I'm now going for the 'real' project. We are developping an application displaying graphics and animations in realtime for scientific purpose. For programming these graphics on a high level we don't want to use som

Re: [r200] Lockups...

2005-03-13 Thread Jan Gukelberger
On Sat, 2005-03-12 at 21:10 -0500, Adam K Kirchhoff wrote: [snip] > [drm:radeon_cp_reset] *ERROR* radeon_cp_reset called without lock held, > held 0 owner ec8fce80 f7669180 > [drm:radeon_cp_start] *ERROR* radeon_cp_start called without lock held, > held -2147483648 owner ec8fce80 f7669180 > irq

Re: FB model basic issues (WAS: radeon, apertures & memory mapping)

2005-03-15 Thread Jan Gukelberger
On Tue, 2005-03-15 at 09:29 -0500, Jon Smirl wrote: > Aonther approach would be to just say you have to choose to run one of > X, DirectFB, FBUI, XGL and you can't switch between them. Other than > developers I don't know if anyone really runs more than one of these > at a time. FWIW, yes we do.

Unreliable timing of glXWaitVideoSyncSGI

2006-08-27 Thread Jan Gukelberger
Hi, I'm trying to port an application that presents visual stimuli for experiments in neuroscience from DirectFBGL to X/DRI. A main requirement is reliable timing of the drawing code, i.e. on every VSYNC a new frame must be ready in the back buffer so that the buffers can be swapped. For this pur

Re: Unreliable timing of glXWaitVideoSyncSGI

2006-08-28 Thread Jan Gukelberger
Hi Ville, On Sun, 2006-08-27 at 23:39 +0300, Ville Syrjälä wrote: > On Sun, Aug 27, 2006 at 07:36:31PM +0200, Jan Gukelberger wrote: > > Hi, > > > > I'm trying to port an application that presents visual stimuli for > > experiments in neuroscience from DirectF

Re: Unreliable timing of glXWaitVideoSyncSGI

2006-08-30 Thread Jan Gukelberger
On Mon, 2006-08-28 at 12:06 -0700, Ian Romanick wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Jan Gukelberger wrote: > > > I'm trying to port an application that presents visual stimuli for > > experiments in neuroscience from DirectFBGL to