Ian Romanick wrote:
That aside, I think we should be able to remove xf86drmCompat.c now.
Unless I'm mistaken, libdrm.a is statically linked into the *_dri.so. If
that's the case, and all of the client-side drivers have been updated to
not use the functions in xf86drmCompat.c, why do we need it?
Michel DÃnzer wrote:
On Wed, 2003-10-22 at 23:49, Ian Romanick wrote:
I added Keith's proposed struct with int64_t as the value, and I added
'#include ' to xf86drmCompat.c. Everything compiled fine.
Easy enough. :)
I've updated
http://penguinppc.org/~daenzer/DRI/radeon-memory-transition.diff,
Alex Deucher wrote:
The question is, can we start ripping it out now, or will there be a
xfree86 4.5 and 4.6, etc.
As much as I would like to, I don't think we should start ripping yet.
I think that will raise to many support questions like, "The new DRI
drivers won't load!" :) I think putting
On Wed, 2003-10-22 at 23:49, Ian Romanick wrote:
> I added Keith's proposed struct with int64_t as the value, and I added
> '#include ' to xf86drmCompat.c. Everything compiled fine.
Easy enough. :)
I've updated
http://penguinppc.org/~daenzer/DRI/radeon-memory-transition.diff,
addressing the fe
On Fri, 2003-10-24 at 16:15, Alex Deucher wrote:
> The question is, can we start ripping it out now, or will there be a
> xfree86 4.5 and 4.6, etc.
Until there's an official roadmap for 5.x, I'd assume the next release
to be 4.x.
--
Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI
The question is, can we start ripping it out now, or will there be a
xfree86 4.5 and 4.6, etc.
Alex
--- Ian Romanick <[EMAIL PROTECTED]> wrote:
> Jens Owen wrote:
>
> > We can definitely remove the xf86drmCompat layer for XFree86 5.0.
> I
> > believe it's well understood that major version cha
Jens Owen wrote:
We can definitely remove the xf86drmCompat layer for XFree86 5.0. I
believe it's well understood that major version changes will break
existing binary interfaces.
Oh goodie! There's a whole ton of crap that will get ripped out of
lib/GL/glx/glx{cmds,ext}.c then! All of the s
Ian Romanick wrote:
Michel Dänzer wrote:
On Wed, 2003-10-22 at 20:38, Ian Romanick wrote:
Eric Anholt wrote:
Would we ever be setting pointers through a setparam interface? I
think
making it an int makes it relatively clear that it's a 32-bit value,
though it might be valuable to use [u]intXX_
Michel Dänzer wrote:
On Wed, 2003-10-22 at 20:38, Ian Romanick wrote:
Eric Anholt wrote:
Would we ever be setting pointers through a setparam interface? I think
making it an int makes it relatively clear that it's a 32-bit value,
though it might be valuable to use [u]intXX_t for the drm (and dri
On Wed, 2003-10-22 at 20:38, Ian Romanick wrote:
> Eric Anholt wrote:
>
> > Would we ever be setting pointers through a setparam interface? I think
> > making it an int makes it relatively clear that it's a 32-bit value,
> > though it might be valuable to use [u]intXX_t for the drm (and dri
> > s
Eric Anholt wrote:
Would we ever be setting pointers through a setparam interface? I think
making it an int makes it relatively clear that it's a 32-bit value,
though it might be valuable to use [u]intXX_t for the drm (and dri
screen private?) sruct definitions everywhere to make things clear.
A
> systems will break, we don't need to add more. On PPC64 where mixed
> mode is supported, sizeof(int) != sizeof(void*). I assume
> the same is true on IA-64, x86-64, and SPARC64.
x86-64 Linux (gcc)
sizeof(int) == 4
sizeonf(long) == 8
sizeof(void*) == 8
x86-64 Windows (VC)
sizeof(int) =
On Tue, 2003-10-21 at 11:55, Ian Romanick wrote:
> Keith Whitwell wrote:
>
> > Would you consider creating a DRM_RADEON_SETPARAM ioctl instead of
> > DRM_RADEON_FB_LOCATION, with an ioctl struct like:
> >
> > #define RADEON_SETPARAM_FB_LOCATION 1
> >
> > typedef struct drm_radeon_setparam
On Tue, 2003-10-21 at 20:55, Ian Romanick wrote:
> Keith Whitwell wrote:
>
> > Would you consider creating a DRM_RADEON_SETPARAM ioctl instead of
> > DRM_RADEON_FB_LOCATION, with an ioctl struct like:
> >
> > #define RADEON_SETPARAM_FB_LOCATION 1
> >
> > typedef struct drm_radeon_setparam
On Wed, 2003-10-22 at 01:59, Vladimir Dergachev wrote:
> >
> > Anyway, I think the most important point is that the DRM should be able
> > to deal with whatever you throw at it this way; the details can still be
> > changed later. Agreed?
>
> DRM and DRI drivers. :)
What do you mean? Old 3D driv
> > > > time.
> > >
> > > Any idea how soon that will be? I was originally hoping to sneak this
> > > into XFree86 4.4, but that's getting less likely by the day.
> >
> > No idea unfortunately. I'll be very busy the next three weeks and to make
> > tests I would need to port GATOS code to DRI CVS.
On Tue, 2003-10-21 at 17:13, Vladimir Dergachev wrote:
> On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dnzer wrote:
>
> > On Tue, 2003-10-21 at 03:53, Vladimir Dergachev wrote:
> > > On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dnzer wrote:
> > >
> > > > On Tue, 2003-10-21 at 03:35, Vladimir Dergachev wro
Keith Whitwell wrote:
Would you consider creating a DRM_RADEON_SETPARAM ioctl instead of
DRM_RADEON_FB_LOCATION, with an ioctl struct like:
#define RADEON_SETPARAM_FB_LOCATION 1
typedef struct drm_radeon_setparam {
int param;
int value;
} drm_radeon_setparam_t;
If this is done, I w
On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dänzer wrote:
> On Tue, 2003-10-21 at 03:53, Vladimir Dergachev wrote:
> > On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dnzer wrote:
> >
> > > On Tue, 2003-10-21 at 03:35, Vladimir Dergachev wrote:
> > >
> > > > 2) I would have expected SetFBLocation functi
On Tue, 2003-10-21 at 11:06, Keith Whitwell wrote:
>
> In r200_screen.c, you check for drmMinor >= 10 before issuing the FB_LOCATION
> ioctl, but it's not clear what happens if drmMinor < 10 -- will the driver
> function correctly? [...]
Yes. The driver determines the memory layout from the chi
On Tue, 2003-10-21 at 03:53, Vladimir Dergachev wrote:
> On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dnzer wrote:
>
> > On Tue, 2003-10-21 at 03:35, Vladimir Dergachev wrote:
> >
> > > 2) I would have expected SetFBLocation function to make sure that
> > > the card is idle. Maybe this is done
On Tue, 2003-10-21 at 05:14, Eric Anholt wrote:
>
> One small problem in radeon_fb_location ioctl: For OS-independence, so
> far filp has been an opaque void pointer. I'm wondering if maybe we
> want to pass the drm_file_t * as part of DRM_IOCTL_ARGS, or just
> resurrect DRM_PRIV to get the drm_
Michel Dänzer wrote:
On Wed, 2003-10-08 at 04:34, Vladimir Dergachev wrote:
On Wed, 8 Oct 2003, Michel [ISO-8859-1] Dnzer wrote:
Does the aperture ever (have to) move during the X server life though?
I would not care. However, I know that at least Window 98 drivers have
default position (0) unle
Michel Dänzer wrote:
On Wed, 2003-10-08 at 04:34, Vladimir Dergachev wrote:
On Wed, 8 Oct 2003, Michel [ISO-8859-1] Dnzer wrote:
Does the aperture ever (have to) move during the X server life though?
I would not care. However, I know that at least Window 98 drivers have
default position (0) unle
On Tue, 21 Oct 2003, Michel [ISO-8859-1] Dänzer wrote:
> On Tue, 2003-10-21 at 03:35, Vladimir Dergachev wrote:
> > I do like the patch.
>
> Cool.
>
> > Few questions/comments:
> >
> > 1) Did you check that it works with non-zero fbLocation ?
> > In particular, not all offsets need to hav
On Mon, 2003-10-20 at 18:14, Michel Dänzer wrote:
> On Wed, 2003-10-08 at 04:34, Vladimir Dergachev wrote:
> > On Wed, 8 Oct 2003, Michel [ISO-8859-1] Dnzer wrote:
> >
> > > > > Does the aperture ever (have to) move during the X server life though?
> > > >
> > > > I would not care. However, I know
I do like the patch. Few questions/comments:
1) Did you check that it works with non-zero fbLocation ?
In particular, not all offsets need to have fbLocation added,
however, the code appears to be correct - I just worry that
it may add (or not add) fbLocation in the wrong place.
On Tue, 2003-10-21 at 03:35, Vladimir Dergachev wrote:
> I do like the patch.
Cool.
> Few questions/comments:
>
> 1) Did you check that it works with non-zero fbLocation ?
> In particular, not all offsets need to have fbLocation added,
> however, the code appears to be correct - I j
On Wed, 2003-10-08 at 04:34, Vladimir Dergachev wrote:
> On Wed, 8 Oct 2003, Michel [ISO-8859-1] Dnzer wrote:
>
> > > > Does the aperture ever (have to) move during the X server life though?
> > >
> > > I would not care. However, I know that at least Window 98 drivers have
> > > default position (
On Wed, 8 Oct 2003, Michel [ISO-8859-1] Dänzer wrote:
> On Tue, 2003-10-07 at 15:02, Vladimir Dergachev wrote:
> > > >
> > > > I would suggest adding more ioctls:
> > > >
> > > > 1. Lock the drm driver against future connections from 3d driver(s).
> > > >
> > > > 2. Return the number of
On Tue, 2003-10-07 at 15:02, Vladimir Dergachev wrote:
> > >
> > > I would suggest adding more ioctls:
> > >
> > > 1. Lock the drm driver against future connections from 3d driver(s).
> > >
> > > 2. Return the number of current connections.
> > >
> > > 3. Move the aperture - should only
> >
> > I would suggest adding more ioctls:
> >
> > 1. Lock the drm driver against future connections from 3d driver(s).
> >
> > 2. Return the number of current connections.
> >
> > 3. Move the aperture - should only succeed when nothing else is connected.
> >
> > Also, when aperture is
On Mon, 2003-10-06 at 17:38, Vladimir Dergachev wrote:
> On Mon, 6 Oct 2003, Michel [ISO-8859-1] Dnzer wrote:
>
> > A proposal for this has been developed in
> > http://bugs.xfree86.org/show_bug.cgi?id=314 (first idea in comment #20,
> > refinement inspired by
> > http://www.mail-archive.com/[EMAI
On Mon, 6 Oct 2003, Michel [ISO-8859-1] Dänzer wrote:
>
> A proposal for this has been developed in
> http://bugs.xfree86.org/show_bug.cgi?id=314 (first idea in comment #20,
> refinement inspired by
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg11659.html in comment #27)
Very interesting,
34 matches
Mail list logo
