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,
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)
I'd appreciate feedback on this from the GATOS developers, in particular
whether it
On Mon, Jun 23, 2003 at 09:53:43PM -0500, Warren Turkal wrote:
> I have a problem with the radeon drm in kernel 2.5.73. When modprobing the
> module, it comes back with "radeon: Unknown symbol flush_tlb_all" and won't
> load. This has been happening for at least 5 kernel versions I believe. Is
On Tuesday 24 June 2003 07:07 am, Alexander Stohr wrote:
> i am reading the list and i have not seen a fix for this.
> maybe the root cause is somewhere else,
> like using an uniprocessor config of an alternate CPU
> or a non current CPU desing (
> if you hear about an answer, then please post to t
04:54
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: [Dri-devel] radeon drm in 2.5.73
>
>
> I have a problem with the radeon drm in kernel 2.5.73. When
> modprobing the
> module, it comes back with "radeon: Unknown symbol
> flush_tlb_all" and wo
On Tue, 2003-06-24 at 04:53, Warren Turkal wrote:
> I have a problem with the radeon drm in kernel 2.5.73. When modprobing the
> module, it comes back with "radeon: Unknown symbol flush_tlb_all" and won't
> load. This has been happening for at least 5 kernel versions I believe. Is
> there a know
I have a problem with the radeon drm in kernel 2.5.73. When modprobing the
module, it comes back with "radeon: Unknown symbol flush_tlb_all" and won't
load. This has been happening for at least 5 kernel versions I believe. Is
there a known fix or patch that has not made it into the kernel proper
Hi folks,
Just to report a minor problem with the latest radeon drivers, in case
this isn't already on somebody's todo list. This is with a Radeon M7,
XFree86 4.3 with 9 June DRI CVS. All works fine until I log out and
the display manager resets the X server (I'm using gdm). Then there's
a problem
Hi Michel,
Thanks for the speedy reply.
O.K. That got rid of the drm message and screen paint problem.
Now I am getting the following message when logging out from
KDE :
*** /var/log/messages ***
Mar 4 15:48:35 roglinux kernel: mtrr: no MTRR f
On Don, 2002-02-28 at 10:05, Roger While wrote:
> I am getting the following (permanent) error on logging out
> from KDE :
> [drm]radeon_cp_indirect - process using buffer owned by 0
>is the PID of the X server and the "owned by" is always 0.
> The effect is that
Hi Anybody,
Hope you can help me.
I am getting the following (permanent) error on logging out
from KDE :
[drm]radeon_cp_indirect - process using buffer owned by 0
is the PID of the X server and the "owned by" is always 0.
The effect is that the top
44 matches
Mail list logo
