Anyone get these to compile with XFree86-4.2.0 and DRI?
It's not finding GL includes, but I'm not sure where to
change them, or where to point them. I have /usr/include/GL
form glut-3.7 and /usr/X11R6/include/GL from XFree86.
glut.h tries to include but doesn't find it.
Is gult wrong or is th
Here's a bit more info on what I've found. I tried running a GL program
of mine in gdb, and here's what happens:
I turned off double buffering to see what's going on. The glClear calls
the clear ioctl in the DRM and works, the window background is cleared to
black (which is what the program
I've overcome this, but sursprisingly there is no further segfault. I see
all the debuging statements scrolling in my terminal without stoping.
This either means that the problem is at the locking mechanism or in the
register programming in _tris.c.
I'm really suspicious about the locking beca
On Fri, 1 Mar 2002, José Fonseca wrote:
...
> > With locking disabled, I got a segfault in mach64CopyBuffer at line 139,
> > where box (mmesa->pClipRects) was null. Then I re-enabled locking (still
>
> This segfault is fixed with the attached patch that allows to enter into
> mach64GetLock to
On 2002.03.01 18:30 Leif Delgass wrote:
> On Fri, 1 Mar 2002, José Fonseca wrote:
>
> > I've overcome this, but sursprisingly there is no further segfault. I
> see
> > all the debuging statements scrolling in my terminal without stoping.
> >
> > This either means that the problem is at the lockin
José Fonseca wrote:
>
> I've found the problem. It was the GET_VIEWPORT_MAT() which was defined to
> 0 but when there is no hw viewport (as in our case) this is used to get
> the viewport matrix. Strangely the viewport matrix is stored in a context
> variable named hw_viewport. Hence my confusion
Michael wrote:
>
> On Mon, Feb 25, 2002 at 05:53:51PM -0500, Adam K Kirchhoff wrote:
> >
> > On Mon, 25 Feb 2002, Keith Whitwell wrote:
> >
> > >
> > > OK, great - it looks like some things work for you... That's an improvement,
> > > anyway...
> > >
> > > What would be helpful would be to look
I've found the problem. It was the GET_VIEWPORT_MAT() which was defined to
0 but when there is no hw viewport (as in our case) this is used to get
the viewport matrix. Strangely the viewport matrix is stored in a context
variable named hw_viewport. Hence my confusion and previous decision to
n
On Mon, Feb 25, 2002 at 05:53:51PM -0500, Adam K Kirchhoff wrote:
>
> On Mon, 25 Feb 2002, Keith Whitwell wrote:
>
> >
> > OK, great - it looks like some things work for you... That's an improvement,
> > anyway...
> >
> > What would be helpful would be to look at Mesa/samples, and identify wh
> Automated binary snapshots of the mach64-0-0-3-branch built in every 4
> hours from now on are available on
> http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/bleeding-edge/ .
Great!
> Be aware though that at this moment this won't be of much use unless you
> also want to help debugging the
Automated binary snapshots of the mach64-0-0-3-branch built in every 4
hours from now on are available on
http://mefriss1.swan.ac.uk/~jfonseca/dri/packages/bleeding-edge/ .
Be aware though that at this moment this won't be of much use unless you
also want to help debugging the segfaults.
Rega
On 2002.03.01 07:25 Leif Delgass wrote:
> I've commited the last major chunk of the Mesa 4 merge, mainly in
> mach64_tris.c. The branch should now compile and run, but it needs
> debugging, as glxgears is still segfaulting.
>
That's great Leif!
I'm working on it. It seems that the problem is o
> I haven't started working on these, so if you choose one of these to work
> there there wouldn't be chance of we repeating same work.
> I'll keep updating all other mach64_* files until their are in sync with
> Mesa 4.x and then start on the file of these that you don't choose or help
> in an
13 matches
Mail list logo
