Jon Smirl wrote:
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
There are still other places where the drivers use glXGetProcAddress.
That one isn't going to go away. If I had it to do over again, I
probably would have picked a different name for the GetProcAddress
function used by the drivers.
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> There are still other places where the drivers use glXGetProcAddress.
> That one isn't going to go away. If I had it to do over again, I
> probably would have picked a different name for the GetProcAddress
> function used by the drivers. Probably
Alex Deucher wrote:
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
Some creative googling revealed that the document *used to be*
available
at http://www.cirrus.com/ftp/pub/gd5465trm.pdf. Since it used to be
publicly available, perhaps you could just ask the nice folks at
Cirrus
Logic for it?
You
Jon Smirl wrote:
Why do the drivers need to look this up instead of linking straight to
_gl_context_modes_create() in common?
create_context_modes = (PFNGLXCREATECONTEXTMODES)
glXGetProcAddress( (const GLubyte *) "__glXCreateContextModes" );
Direct linking would get rid of the last
I found that "rb3d_coloroffset:0x1c40" gets emited in both the [1]client
and the [2]DRM.
1. At init time and 3 other places.
2. At emit state from the ctx.
I was wondering how I should procede in making changes to the way this reg
gets used(how to set it to a diffrent value, globaly). I think th
> but with the current DRM interface >=1.1 the devname is not being
> set in DRM(set_busid).
>
> Attached is patch to fix.
thanks applied to CVS, I'll push to bitkeeper for Linus inclusion later..
Dave.
>
>
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
A minor issue which has been bugging me for a while is the radeon
kernel module is not setting the dev->devname for display in
/proc/interrupts (under Linux). Instead is shown.
The dev->devname being passed to request_irq in drm_irq.h is null.
With the old DRM interface, the devname was set in D
> Can you fix the 500 compiler warnings while you're in there?
I actually have the fixes for all those warnings in a tree already,
however they defo require testing as they are to do with building the
vertex info for sending to the card..
Dave.
>
> --- Dave Airlie <[EMAIL PROTECTED]> wrote:
>
Can you fix the 500 compiler warnings while you're in there?
--- Dave Airlie <[EMAIL PROTECTED]> wrote:
>
> okay I'll have a go and making the m64 use the Mesa stuff tonight if I can
> drag myself away from nwn :-)
>
> Dave.
>
> On Sun, 6 Jun 2004, Jon Smirl wrote:
>
> > CPU_TO_LE32() etc seem
okay I'll have a go and making the m64 use the Mesa stuff tonight if I can
drag myself away from nwn :-)
Dave.
On Sun, 6 Jun 2004, Jon Smirl wrote:
> CPU_TO_LE32() etc seems to already be defined in mesa/main/glheader.h. Should
> mach64 be using that version?
>
> =
> Jon Smirl
> [EMAIL PROT
CPU_TO_LE32() etc seems to already be defined in mesa/main/glheader.h. Should
mach64 be using that version?
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/
On Mon, 2004-06-07 at 00:52 +0100, Dave Airlie wrote:
> >
> > I'm afraid that's glibc specific.
>
> If I use on FreeBSD can I do the same thing?
>
> it'll look messy but to avoid the X includes we should do it ..
>
> #ifdef __linux__
> #include
> #else
> #include
> #define __BYTE_ORDER BYTE_O
I see use of MESA_BIG_ENDIAN in the other drivers, could you use that instead?
mach64 is the only driver using the X headers.
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
Friends. Fun. Try the all-new Yahoo! Messenger.
http://me
How about a copy/rename of teh X include and then s/X/dri/ it till it's
good to go. This would make (re)porting a no task task.
--- Dave Airlie <[EMAIL PROTECTED]> wrote:
> >
> > I'm afraid that's glibc specific.
>
> If I use on FreeBSD can I do the same thing?
>
> it'll look messy but to avoi
Dave Airlie wrote:
>>I have a big problem, because the compilation of the mach64 module runs
into
>>some errors.
>>
>>Here is the output of make using this command: make
>>LINUXDIR=/usr/src/kernel-source-2.6.6 DRM_MODULES="mach64" 2> error.log
>
>
>have you actually build the kernel? it you built
>
> I'm afraid that's glibc specific.
If I use on FreeBSD can I do the same thing?
it'll look messy but to avoid the X includes we should do it ..
#ifdef __linux__
#include
#else
#include
#define __BYTE_ORDER BYTE_ORDER
#define __LITTLE_ENDIAN LITTLE_ENDIAN
#define __BIG_ENDIAN BIG_ENDIAN
#en
On Mon, 2004-06-07 at 00:32 +0100, Dave Airlie wrote:
> I've changed it to include /usr/include/endian.h rather than Xarch, it
> should work...
I'm afraid that's glibc specific.
--
Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer
Libre software enthusiast| http://s
I've changed it to include /usr/include/endian.h rather than Xarch, it
should work... but I can't test it until I get back to my laptop...
Dave.
On Sun, 6 Jun 2004, Jon Smirl wrote:
> The mach64 driver includes Xarch.h. In the mesa-solo model it can't do this
> since there is no X around. Is th
> I have a big problem, because the compilation of the mach64 module runs into
> some errors.
>
> Here is the output of make using this command: make
> LINUXDIR=/usr/src/kernel-source-2.6.6 DRM_MODULES="mach64" 2> error.log
have you actually build the kernel? it you built the kernel using
O=/path/
On Gwe, 2004-06-04 at 01:10, Dave Airlie wrote:
> Do you know if the VIA DRM is considered secure with respect to DMA
> buffers and the like? I've been thinking of pushing it to Linus,
It certainly needs further review. As I understand it the VIA one should
be ok, but the S3 one that went over the
The mach64 driver includes Xarch.h. In the mesa-solo model it can't do this
since there is no X around. Is there some other way to achive the correct byte
ordering without relying on X include files?
#include "X11/Xarch.h"
#if X_BYTE_ORDER == X_LITTLE_ENDIAN
=
Jon Smirl
[EMAIL PROTECTED]
On Sul, 2004-06-06 at 05:34, Alex Deucher wrote:
> > at http://www.cirrus.com/ftp/pub/gd5465trm.pdf. Since it used to be
> > publicly available, perhaps you could just ask the nice folks at
> > Cirrus
> > Logic for it?
>
> You might also still be able to get it on the internet archive.
Cirrus
Why do the drivers need to look this up instead of linking straight to
_gl_context_modes_create() in common?
create_context_modes = (PFNGLXCREATECONTEXTMODES)
glXGetProcAddress( (const GLubyte *) "__glXCreateContextModes" );
Direct linking would get rid of the last GLX reference i
In r200_lock.c r200UpdatePageFlipping:
rmesa->pClipRects[0].x2 seams to allways have the correct value while x1
dose not. Here is the code I added.
if ( rmesa->numClipRects == 1 )
{
printf("%d\n", rmesa->pClipRects[0].x1);
}
Here is the output I got...
930 <--- Move
779 <-
--- Stephane Marchesin <[EMAIL PROTECTED]> wrote:
> Ian Romanick 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
Hello list,
I have a big problem, because the compilation of the mach64 module runs into
some errors.
Here is the output of make using this command: make
LINUXDIR=/usr/src/kernel-source-2.6.6 DRM_MODULES="mach64" 2> error.log
content of the error.log:
In file included from /usr/src/laptop/drm/l
Ian Romanick 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*)"glThisFunctionDoesntExist");".
Get
I've fixed the FXT support but DXT1 RGB is still knackered and probably
won't be fixed...
http://www.skynet.ie/~airlied/patches/dri/i830_texcmp.diff
Roland can you update your patch with this verson?
Dave.
--
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied at skynet.ie
28 matches
Mail list logo
