I was getting weird segfaults like that too. I'm using xorg-x11-6.7.0-2.i386.rpm
with FC2. The problem seems to be in the upgrade process, upgrading from
xorg-x11-6.7.0-0.5.i386.rpm to -2 did not delete somethings that needed to be
deleted (like the tls dirs). I whacked my X11R6 directories and rei
should I be able to using FC2, set LIBGL_DRIVERS_PATH to my Mesa built
drivers and have it work, or is that interface not one that stays stable?
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -150064480 (LWP 4593)]
0x007f189e in memset () from /lib/tls/libc.so.6
(gdb) b
On Thu, May 27, 2004 at 05:55:29PM -0700, Jon Smirl wrote:
| Why do you dynamically generate a dispatch for unknown functions instead of
| just returning null? ...
Since I'm one of the people who proposed that behavior, I guess I should
save Ian the trouble of explaining. :-)
There are several re
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> Here's the deal. glXGetProcAddress *NEVER* returns NULL. It returns a
> pointer to a dispatch function. If you request an unknown function, it
> will dynamically generate a dispatch for it. Try calling
> 'glXGetProcAddressARB((const GLubyte*)"glT
>
> The final file shuffling step will be to make the DRI tree and the Mesa tree
> use the libdrm.a build in the drm module. Right now we have *3* copies of the
> same code. There is a copy in each of: drm/libdrm, xc/xc/lib/GL/dri/drm, and
> src/mesa/drivers/dri/dri_client. That's just nuts (but
Stephane Marchesin wrote:
Jon Smirl wrote:
I'm using Redhat xorg-x11-6.7.0-2
The addresses coming back from these get_proc_address calls don't look
quit
right. When one is used in context->gl.get_program_iv_arb() it
segfaults. I'm
using an R128 which does not have hardware shaders.
Should these
Jon Smirl wrote:
I'm using Redhat xorg-x11-6.7.0-2
The addresses coming back from these get_proc_address calls don't look quit
right. When one is used in context->gl.get_program_iv_arb() it segfaults. I'm
using an R128 which does not have hardware shaders.
Should these calls be returning values as
Keith Packard wrote:
Around 12 o'clock on May 27, Ian Romanick wrote:
I'm pretty sure that XFree86 and Xorg will continue to want to build 3D
drivers as part of their distribution process. Even so, there are parts
of Mesa that are needed to build libGL.so and libglx.a.
With stable interfaces and
I'm using Redhat xorg-x11-6.7.0-2
The addresses coming back from these get_proc_address calls don't look quit
right. When one is used in context->gl.get_program_iv_arb() it segfaults. I'm
using an R128 which does not have hardware shaders.
Should these calls be returning values as if they were su
Around 12 o'clock on May 27, Ian Romanick wrote:
> I'm pretty sure that XFree86 and Xorg will continue to want to build 3D
> drivers as part of their distribution process. Even so, there are parts
> of Mesa that are needed to build libGL.so and libglx.a.
With stable interfaces and published M
Around 20 o'clock on May 27, Keith Whitwell wrote:
> If the X server starts dynamically loading XYZ_dri.so and falling back to
> software_dri.so if that fails, you mean?
That would be great; no GL bits inside the X server
> In that case, I guess X no longer needs an extras/Mesa, though they ma
Alex Deucher wrote:
--- Keith Whitwell <[EMAIL PROTECTED]> wrote:
As the xc/ tree will continue having to import Mesa to extras/Mesa,
the libGL
code could pick it up from there.
could that be avoided with a SW only DRI driver like we've discussed
several times on IRC and the ML? if libGLcore goes
Alex Deucher wrote:
--- Keith Whitwell <[EMAIL PROTECTED]> wrote:
Jon Smirl wrote:
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
I'm going to try and wrap up the remaining issues preventing a
single
driver binary. As part of that, I'm going to move the Mesa copies
of
dri_util.[ch] and glcontext
--- Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > --- Ian Romanick <[EMAIL PROTECTED]> wrote:
> >
> >>I'm going to try and wrap up the remaining issues preventing a
> single
> >>driver binary. As part of that, I'm going to move the Mesa copies
> of
> >>dri_util.[ch] and glco
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Thu, 2004-05-27 at 15:00, Mike Mestnik wrote:
> > --- Michel Dnzer <[EMAIL PROTECTED]> wrote:
> > > On Wed, 2004-05-26 at 12:34, Mike Mestnik wrote:
> > > > Attached is a screen shoot of the effect of adding 1024 to the
> > > > ColorOffset.
> >
There is another copy:
xc/lib/XvMC/hw/i810/xf86drm.c
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
---
Keith Whitwell wrote:
Which reminds me; we will need to get an uptodate Mesa into extras/Mesa
and go back to periodically updating it...
I was thinking that right after we get all this stuff taken care of
would be a perfect time. :)
---
This S
Keith Whitwell wrote:
Jon Smirl wrote:
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
I'm going to try and wrap up the remaining issues preventing a single
driver binary. As part of that, I'm going to move the Mesa copies of
dri_util.[ch] and glcontextmodes.[ch]. I'm also going to remove the
DRI
Jon Smirl wrote:
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
I'm going to try and wrap up the remaining issues preventing a single
driver binary. As part of that, I'm going to move the Mesa copies of
dri_util.[ch] and glcontextmodes.[ch]. I'm also going to remove the DRI
copies. Since dri_uti
Jon Smirl wrote:
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
I'm going to try and wrap up the remaining issues preventing a single
driver binary. As part of that, I'm going to move the Mesa copies of
dri_util.[ch] and glcontextmodes.[ch]. I'm also going to remove the DRI
copies. Since dri_uti
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> I'm going to try and wrap up the remaining issues preventing a single
> driver binary. As part of that, I'm going to move the Mesa copies of
> dri_util.[ch] and glcontextmodes.[ch]. I'm also going to remove the DRI
> copies. Since dri_util.[ch] ar
I'm going to try and wrap up the remaining issues preventing a single
driver binary. As part of that, I'm going to move the Mesa copies of
dri_util.[ch] and glcontextmodes.[ch]. I'm also going to remove the DRI
copies. Since dri_util.[ch] are only used by the drivers, I'm going to
move them
Tomas Carnecky wrote:
Each slash in 'Mesa/DRI/DRM' stands for an interface, which is more or
less predefined (for example drm_*.h in drivers/char/drm).
Why not 'OpenGL/Hardware'?
Oh for cryin' out loud. Have you read ANYTHING about how the DRI
architecture works, or are you just here to divert us
On Thu, 2004-05-27 at 15:00, Mike Mestnik wrote:
> --- Michel Dnzer <[EMAIL PROTECTED]> wrote:
> > On Wed, 2004-05-26 at 12:34, Mike Mestnik wrote:
> > > Attached is a screen shoot of the effect of adding 1024 to the
> > > ColorOffset.
> >
> > It's hard for me to recognize anything; can you des
# On 26-May-2004, [EMAIL PROTECTED] wrote:
# > Me and my friend run glxgears with 1024x768 and 16bpp.
# > Patrick, I compiled dri cvs, so it doesn't matter what version of xfree 4.3
# > 4.4 etc I have. And dri was enabled, as you could see from attached file.
#
# Okay, that gets us somewhere. DRI
--- Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2004-05-26 at 12:34, Mike Mestnik wrote:
> > Attached is a screen shoot of the effect of adding 1024 to the
> > ColorOffset.
>
> It's hard for me to recognize anything; can you describe your
> observations?
>
The data was shifted to the r
On Wed, 2004-05-26 at 12:34, Mike Mestnik wrote:
> Attached is a screen shoot of the effect of adding 1024 to the
> ColorOffset.
It's hard for me to recognize anything; can you describe your
observations?
> I still have to find where rmesa->state.color.drawOffset comes from and
> what effect
On Thu, 2004-05-27 at 14:14, Tomas Carnecky wrote:
> Michel DÃnzer wrote:
>
> >>The userspace dri driver is the only user of these kernel drivers.
> >
> >
> > No, there's also the DDX drivers, XvMC, ... and there could be more in
> > the future.
> >
>
> So you tell me that there are at least th
Attached is the patch I made to make more cliprects when > 2048. It
dosen't have any code to move the 3d-viewport, I'm still looking into how
that will work.
Where can I find docs on debuging the client GL driver? Just using ddd
didn't work and gave me a broken bt.
_
On Tue, 2004-05-25 at 21:55, Nicolai Haehnle wrote:
>
> As you may be aware, I was trying to get R300 support into a state where it
> is possible to start OpenGL applications, let them hang the CP and *not*
> bring down the entire machine.
>
> Looks like I was successful :)
Nice!
> The atta
Michel DÃnzer wrote:
The userspace dri driver is the only user of these kernel drivers.
No, there's also the DDX drivers, XvMC, ... and there could be more in
the future.
So you tell me that there are at least three (DRI/DDX/XvMC) libraries
which do basically the same thing?
If, and that's what so
> > The idea is to reduce the kernel mod to nothing more then device
> > enumeration and detection.
>
> However you solve it.. I don't care about how the kernel driver <-->
> userspace driver interface is defined or implemented. I just don't think
> there should be one interface for all devices, a
On Thu, 2004-05-27 at 12:04, Tomas Carnecky wrote:
>
> I just don't think there should be one interface for all devices, as it
> is now with DRM.
No, there isn't. There just happen to be some things common to all
drivers.
> The userspace dri driver is the only user of these kernel drivers.
No,
On Thu, 2004-05-27 at 11:27, Tomas Carnecky wrote:
>
> Each slash in 'Mesa/DRI/DRM' stands for an interface, which is more or
> less predefined (for example drm_*.h in drivers/char/drm).
No, it's not. Ian pointed that out, so why bring it up again?
--
Earthling Michel DÃnzer | Debian
Mike Mestnik wrote:
I think every thing Tomas Carnecky has said here about device driver
design is valid and dose apply to the DRM/dri. He may not know every
thing about system security, but we also all have our strangths and his
strangth is oviously device design. One way of interpeting what he
Am Montag, 26. April 2004 14:18 schrieb Dieter Nützel:
> Am Donnerstag, 5. Februar 2004 19:38 schrieb Dieter Nützel:
> > Have you seen, that it is much faster (hardware accelerate?) in the
> > "broken" area (on the right and right/below corner)?
> No progress.
>
> Any ideas how to disable some fea
I see this thread is also on your dri-devel list.
http://sourceforge.net/mailarchive/forum.php?thread_id=4573552&forum_id=7177
I responded in April, but not on this list. So I am replying again here.
-- Forwarded message --
Date: Mon, 26 Apr 2004 23:43:42 -0700 (PDT)
From: Jeremy C
--- Tomas Carnecky <[EMAIL PROTECTED]> wrote:
> David Bronaugh wrote:
> > Tomas Carnecky wrote:
> >
> >> David Bronaugh wrote:
> >>
> >>> Another option would be to design a generic, more low-level wrapper
> >>> for graphics hardware. In my opinion this is a huge undertaking
> (ever
> >>> read
David Bronaugh wrote:
Tomas Carnecky wrote:
David Bronaugh wrote:
Another option would be to design a generic, more low-level wrapper
for graphics hardware. In my opinion this is a huge undertaking (ever
read chip docs? You try integrating 3000 pages of information (that
would be around 5 differ
39 matches
Mail list logo
