Re: Getting started
Alex Deucher wrote: - DRI enabled DDX (2d driver) (xorg tree) I think this is already done. Would this be the files in xc/programs/Xserver/hw/xfree86/drivers/trident ? - 3D driver library (mesa tree) I have to implement this. There are already some things done for the CyberbladeXP in Mesa/src/mesa/drivers/dri/trident, right? - kernel DRM to provide secure/multiple client access to the hardware (drm tree) Where can I find this? What are the meanings of the directories linux, linux-core, etc? Greetings, Sjoerd --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2225] Strange Distortion on an r200 card
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2225 --- Additional Comments From [EMAIL PROTECTED] 2005-01-05 03:18 --- I think this problem might be when using an RV2xx card or when using an R200 card and disabling tcl via environment variable or driconf. I recently found a demo (http://pouet.net/prod.php?which=7995 , needs wine) that works well in tcl mode, but is broken in configured non-tcl mode. The strange thing is that it has many tcl fallbacks but works well when autodetecting them but is totally broken when configured to do only sw-tnl. glxinfo should show you that you dont have hw-tcl. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
FIXED: MergedFB and pageflipping
Ok, so last night I think I figured out why pageflipping was borked with mergedfb. Unfortunately the fix requires changes to the drm and sarea. I'm wondering what the best way to do this is and maintain compatability. When crtc1 is at offset 0 pageflipping should work with a simple patch to radeon_driver.c::RadeonDoAdjustframe(). the backbuffer offset was being added to the base address after the crtc2_base info was updated in the sarea. That's an easy fix. For situations where crtc2 is at offset 0 and crtc1 is at a higher offset, changes to the drm and sarea are required. I think the easiest solution would be to add a crtc1_base to the sarea and update that in RadeonDoAdjustframe() just like crtc2_base. The problem is that in the drm in radeon_state.c::radeon_cp_dispatch_flip() the offset of crtc1 is calculated from the sarea frame info which could be crtc1 or crtc2 depending on their orientation. It should really be calcluated in RadeonDoAdjustframe() just like crtc2 base. So how to I do it in a compatible way? Thanks, Alex --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FIXED: MergedFB and pageflipping
Alex Deucher wrote: Ok, so last night I think I figured out why pageflipping was borked with mergedfb. Unfortunately the fix requires changes to the drm and sarea. I'm wondering what the best way to do this is and maintain compatability. When crtc1 is at offset 0 pageflipping should work with a simple patch to radeon_driver.c::RadeonDoAdjustframe(). the backbuffer offset was being added to the base address after the crtc2_base info was updated in the sarea. That's an easy fix. For situations where crtc2 is at offset 0 and crtc1 is at a higher offset, changes to the drm and sarea are required. I think the easiest solution would be to add a crtc1_base to the sarea and update that in RadeonDoAdjustframe() just like crtc2_base. The problem is that in the drm in radeon_state.c::radeon_cp_dispatch_flip() the offset of crtc1 is calculated from the sarea frame info which could be crtc1 or crtc2 depending on their orientation. It should really be calcluated in RadeonDoAdjustframe() just like crtc2 base. So how to I do it in a compatible way? Thanks, Alex, It might be easer to understand the issues if you post a non-compatible version of the fix, so that there's something concrete to talk about. Keith --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FIXED: MergedFB and pageflipping
On Wed, 05 Jan 2005 14:35:30 +, Keith Whitwell [EMAIL PROTECTED] wrote: Alex Deucher wrote: Ok, so last night I think I figured out why pageflipping was borked with mergedfb. Unfortunately the fix requires changes to the drm and sarea. I'm wondering what the best way to do this is and maintain compatability. When crtc1 is at offset 0 pageflipping should work with a simple patch to radeon_driver.c::RadeonDoAdjustframe(). the backbuffer offset was being added to the base address after the crtc2_base info was updated in the sarea. That's an easy fix. For situations where crtc2 is at offset 0 and crtc1 is at a higher offset, changes to the drm and sarea are required. I think the easiest solution would be to add a crtc1_base to the sarea and update that in RadeonDoAdjustframe() just like crtc2_base. The problem is that in the drm in radeon_state.c::radeon_cp_dispatch_flip() the offset of crtc1 is calculated from the sarea frame info which could be crtc1 or crtc2 depending on their orientation. It should really be calcluated in RadeonDoAdjustframe() just like crtc2 base. So how to I do it in a compatible way? Thanks, Alex, It might be easer to understand the issues if you post a non-compatible version of the fix, so that there's something concrete to talk about. I'll post a patch later today. Thanks, Alex Keith --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
New Debian packages built from Xorg
I was feeling a bit frisky yesterday and built new DRI packages for Debian Unstable using the Xorg xc tree. Any feedback would be greatly appreciated. http://www.nixnuts.net/files/experimental/ I'm still wondering where /usr/X11R6/lib/modules/codeconv/ went though. Is there a define to build these libraries that isn't in the sample host.def for Xorg? Are they necessary for languages other than English? John signature.asc Description: This is a digitally signed message part
Re: FIXED: MergedFB and pageflipping
On Wed, 05 Jan 2005 14:35:30 +, Keith Whitwell
[EMAIL PROTECTED] wrote:
Alex Deucher wrote:
Ok, so last night I think I figured out why pageflipping was borked
with mergedfb. Unfortunately the fix requires changes to the drm and
sarea. I'm wondering what the best way to do this is and maintain
compatability. When crtc1 is at offset 0 pageflipping should work
with a simple patch to radeon_driver.c::RadeonDoAdjustframe(). the
backbuffer offset was being added to the base address after the
crtc2_base info was updated in the sarea. That's an easy fix. For
situations where crtc2 is at offset 0 and crtc1 is at a higher offset,
changes to the drm and sarea are required. I think the easiest
solution would be to add a crtc1_base to the sarea and update that in
RadeonDoAdjustframe() just like crtc2_base. The problem is that in
the drm in radeon_state.c::radeon_cp_dispatch_flip() the offset of
crtc1 is calculated from the sarea frame info which could be crtc1 or
crtc2 depending on their orientation. It should really be calcluated
in RadeonDoAdjustframe() just like crtc2 base. So how to I do it in a
compatible way?
Thanks,
Alex,
It might be easer to understand the issues if you post a non-compatible
version of the fix, so that there's something concrete to talk about.
Keith
I'm not at my pc at the moment, but I threw this together quickly to
give you all an idea of what I'm talking about:
http://www.botchco.com/alex/mfb-fix.patch
--- radeon_driver.c.orig2005-01-05 10:03:39.660423035 -0500
+++ radeon_driver.c 2005-01-05 10:07:11.867000308 -0500
@@ -7536,13 +7536,16 @@
pSAREAPriv = DRIGetSAREAPrivate(pScrn-pScreen);
- if (clone || info-IsSecondary) {
- pSAREAPriv-crtc2_base = Base;
- }
-
if (pSAREAPriv-pfCurrentPage == 1) {
Base += info-backOffset;
}
+
+if (clone || info-IsSecondary) {
+pSAREAPriv-crtc2_base = Base;
+} else {
+pSAREAPriv-crtc1_base = Base;
+}
+
}
#endif
--- radeon_drm.h.orig 2005-01-05 10:03:51.709730361 -0500
+++ radeon_drm.h2005-01-05 10:09:08.057034243 -0500
@@ -359,6 +359,7 @@
int pfState;/* number of 3d windows (0,1,2ormore) */
int pfCurrentPage; /* which buffer is being displayed? */
int crtc2_base; /* CRTC2 frame offset */
+int crtc1_base;
} drm_radeon_sarea_t;
/* WARNING: If you change any of these defines, make sure to change the
--- radeon_sarea.h.orig 2005-01-05 10:04:05.904558219 -0500
+++ radeon_sarea.h 2005-01-05 10:08:01.756851008 -0500
@@ -226,6 +226,7 @@
int pfAllowPageFlip; /* set by the 2d driver, read by the client */
int pfCurrentPage; /* set by kernel, read by others */
int crtc2_base;/* for pageflipping with CloneMode */
+int crtc1_base;
} RADEONSAREAPriv, *RADEONSAREAPrivPtr;
#endif
--- radeon_state.c.orig 2005-01-05 10:04:17.660930998 -0500
+++ radeon_state.c 2005-01-05 10:10:31.661350159 -0500
@@ -1330,9 +1330,7 @@
BEGIN_RING(6);
RADEON_WAIT_UNTIL_3D_IDLE();
- OUT_RING_REG(RADEON_CRTC_OFFSET,
-((sarea-frame.y * dev_priv-front_pitch +
- sarea-frame.x * (dev_priv-color_fmt - 2)) ~7)
+ OUT_RING_REG(RADEON_CRTC_OFFSET, dev_priv-sarea_priv-crtc1_base
+ offset);
OUT_RING_REG(RADEON_CRTC2_OFFSET, dev_priv-sarea_priv-crtc2_base
+ offset);
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FIXED: MergedFB and pageflipping
Alex Deucher wrote:
On Wed, 05 Jan 2005 14:35:30 +, Keith Whitwell
[EMAIL PROTECTED] wrote:
Alex Deucher wrote:
Ok, so last night I think I figured out why pageflipping was borked
with mergedfb. Unfortunately the fix requires changes to the drm and
sarea. I'm wondering what the best way to do this is and maintain
compatability. When crtc1 is at offset 0 pageflipping should work
with a simple patch to radeon_driver.c::RadeonDoAdjustframe(). the
backbuffer offset was being added to the base address after the
crtc2_base info was updated in the sarea. That's an easy fix. For
situations where crtc2 is at offset 0 and crtc1 is at a higher offset,
changes to the drm and sarea are required. I think the easiest
solution would be to add a crtc1_base to the sarea and update that in
RadeonDoAdjustframe() just like crtc2_base. The problem is that in
the drm in radeon_state.c::radeon_cp_dispatch_flip() the offset of
crtc1 is calculated from the sarea frame info which could be crtc1 or
crtc2 depending on their orientation. It should really be calcluated
in RadeonDoAdjustframe() just like crtc2 base. So how to I do it in a
compatible way?
Thanks,
Alex,
It might be easer to understand the issues if you post a non-compatible
version of the fix, so that there's something concrete to talk about.
Keith
I'm not at my pc at the moment, but I threw this together quickly to
give you all an idea of what I'm talking about:
http://www.botchco.com/alex/mfb-fix.patch
--- radeon_driver.c.orig 2005-01-05 10:03:39.660423035 -0500
+++ radeon_driver.c 2005-01-05 10:07:11.867000308 -0500
@@ -7536,13 +7536,16 @@
pSAREAPriv = DRIGetSAREAPrivate(pScrn-pScreen);
- if (clone || info-IsSecondary) {
- pSAREAPriv-crtc2_base = Base;
- }
-
if (pSAREAPriv-pfCurrentPage == 1) {
Base += info-backOffset;
}
+
+if (clone || info-IsSecondary) {
+pSAREAPriv-crtc2_base = Base;
+} else {
+pSAREAPriv-crtc1_base = Base;
+}
+
}
#endif
--- radeon_drm.h.orig 2005-01-05 10:03:51.709730361 -0500
+++ radeon_drm.h 2005-01-05 10:09:08.057034243 -0500
@@ -359,6 +359,7 @@
int pfState; /* number of 3d windows (0,1,2ormore) */
int pfCurrentPage; /* which buffer is being displayed? */
int crtc2_base; /* CRTC2 frame offset */
+int crtc1_base;
} drm_radeon_sarea_t;
/* WARNING: If you change any of these defines, make sure to change the
--- radeon_sarea.h.orig 2005-01-05 10:04:05.904558219 -0500
+++ radeon_sarea.h 2005-01-05 10:08:01.756851008 -0500
@@ -226,6 +226,7 @@
int pfAllowPageFlip; /* set by the 2d driver, read by the client */
int pfCurrentPage; /* set by kernel, read by others */
int crtc2_base; /* for pageflipping with CloneMode */
+int crtc1_base;
} RADEONSAREAPriv, *RADEONSAREAPrivPtr;
#endif
--- radeon_state.c.orig 2005-01-05 10:04:17.660930998 -0500
+++ radeon_state.c 2005-01-05 10:10:31.661350159 -0500
@@ -1330,9 +1330,7 @@
BEGIN_RING(6);
RADEON_WAIT_UNTIL_3D_IDLE();
- OUT_RING_REG(RADEON_CRTC_OFFSET,
- ((sarea-frame.y * dev_priv-front_pitch +
- sarea-frame.x * (dev_priv-color_fmt - 2)) ~7)
+ OUT_RING_REG(RADEON_CRTC_OFFSET, dev_priv-sarea_priv-crtc1_base
+ offset);
OUT_RING_REG(RADEON_CRTC2_OFFSET, dev_priv-sarea_priv-crtc2_base
+ offset);
I don't think there's actually any problem with this patch - old
clientside drivers won't use the new sarea field, but they didn't handle
this right anyway it isn't as if you are breaking an already-working setup.
There might be an argument for validating crtc2_base in radeon_state.c
before using its value as it could conceivably be nonsense.
Keith
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FIXED: MergedFB and pageflipping
On Wed, 05 Jan 2005 15:20:41 +, Keith Whitwell
[EMAIL PROTECTED] wrote:
Alex Deucher wrote:
On Wed, 05 Jan 2005 14:35:30 +, Keith Whitwell
[EMAIL PROTECTED] wrote:
Alex Deucher wrote:
Ok, so last night I think I figured out why pageflipping was borked
with mergedfb. Unfortunately the fix requires changes to the drm and
sarea. I'm wondering what the best way to do this is and maintain
compatability. When crtc1 is at offset 0 pageflipping should work
with a simple patch to radeon_driver.c::RadeonDoAdjustframe(). the
backbuffer offset was being added to the base address after the
crtc2_base info was updated in the sarea. That's an easy fix. For
situations where crtc2 is at offset 0 and crtc1 is at a higher offset,
changes to the drm and sarea are required. I think the easiest
solution would be to add a crtc1_base to the sarea and update that in
RadeonDoAdjustframe() just like crtc2_base. The problem is that in
the drm in radeon_state.c::radeon_cp_dispatch_flip() the offset of
crtc1 is calculated from the sarea frame info which could be crtc1 or
crtc2 depending on their orientation. It should really be calcluated
in RadeonDoAdjustframe() just like crtc2 base. So how to I do it in a
compatible way?
Thanks,
Alex,
It might be easer to understand the issues if you post a non-compatible
version of the fix, so that there's something concrete to talk about.
Keith
I'm not at my pc at the moment, but I threw this together quickly to
give you all an idea of what I'm talking about:
http://www.botchco.com/alex/mfb-fix.patch
--- radeon_driver.c.orig 2005-01-05 10:03:39.660423035 -0500
+++ radeon_driver.c 2005-01-05 10:07:11.867000308 -0500
@@ -7536,13 +7536,16 @@
pSAREAPriv = DRIGetSAREAPrivate(pScrn-pScreen);
- if (clone || info-IsSecondary) {
- pSAREAPriv-crtc2_base = Base;
- }
-
if (pSAREAPriv-pfCurrentPage == 1) {
Base += info-backOffset;
}
+
+if (clone || info-IsSecondary) {
+pSAREAPriv-crtc2_base = Base;
+} else {
+pSAREAPriv-crtc1_base = Base;
+}
+
}
#endif
--- radeon_drm.h.orig 2005-01-05 10:03:51.709730361 -0500
+++ radeon_drm.h 2005-01-05 10:09:08.057034243 -0500
@@ -359,6 +359,7 @@
int pfState;/* number of 3d windows (0,1,2ormore) */
int pfCurrentPage; /* which buffer is being displayed? */
int crtc2_base; /* CRTC2 frame offset */
+int crtc1_base;
} drm_radeon_sarea_t;
/* WARNING: If you change any of these defines, make sure to change the
--- radeon_sarea.h.orig 2005-01-05 10:04:05.904558219 -0500
+++ radeon_sarea.h2005-01-05 10:08:01.756851008 -0500
@@ -226,6 +226,7 @@
int pfAllowPageFlip; /* set by the 2d driver, read by the client */
int pfCurrentPage; /* set by kernel, read by others */
int crtc2_base; /* for pageflipping with CloneMode */
+int crtc1_base;
} RADEONSAREAPriv, *RADEONSAREAPrivPtr;
#endif
--- radeon_state.c.orig 2005-01-05 10:04:17.660930998 -0500
+++ radeon_state.c2005-01-05 10:10:31.661350159 -0500
@@ -1330,9 +1330,7 @@
BEGIN_RING(6);
RADEON_WAIT_UNTIL_3D_IDLE();
- OUT_RING_REG(RADEON_CRTC_OFFSET,
- ((sarea-frame.y * dev_priv-front_pitch +
-sarea-frame.x * (dev_priv-color_fmt - 2)) ~7)
+ OUT_RING_REG(RADEON_CRTC_OFFSET, dev_priv-sarea_priv-crtc1_base
+ offset);
OUT_RING_REG(RADEON_CRTC2_OFFSET, dev_priv-sarea_priv-crtc2_base
+ offset);
I don't think there's actually any problem with this patch - old
clientside drivers won't use the new sarea field, but they didn't handle
this right anyway it isn't as if you are breaking an already-working setup.
what if you use an old DDX with a new drm? The old DDX wouldn't set
sarea_priv-crtc1_base right; it wouldn't even know about it. In
radeon_cp_dispatch_flip() something bogus would get written to
RADEON_CRTC_OFFSET.
Alex
There might be an argument for validating crtc2_base in radeon_state.c
before using its value as it could conceivably be nonsense.
Keith
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FIXED: MergedFB and pageflipping
Alex Deucher wrote:
On Wed, 05 Jan 2005 15:20:41 +, Keith Whitwell
[EMAIL PROTECTED] wrote:
Alex Deucher wrote:
On Wed, 05 Jan 2005 14:35:30 +, Keith Whitwell
[EMAIL PROTECTED] wrote:
Alex Deucher wrote:
Ok, so last night I think I figured out why pageflipping was borked
with mergedfb. Unfortunately the fix requires changes to the drm and
sarea. I'm wondering what the best way to do this is and maintain
compatability. When crtc1 is at offset 0 pageflipping should work
with a simple patch to radeon_driver.c::RadeonDoAdjustframe(). the
backbuffer offset was being added to the base address after the
crtc2_base info was updated in the sarea. That's an easy fix. For
situations where crtc2 is at offset 0 and crtc1 is at a higher offset,
changes to the drm and sarea are required. I think the easiest
solution would be to add a crtc1_base to the sarea and update that in
RadeonDoAdjustframe() just like crtc2_base. The problem is that in
the drm in radeon_state.c::radeon_cp_dispatch_flip() the offset of
crtc1 is calculated from the sarea frame info which could be crtc1 or
crtc2 depending on their orientation. It should really be calcluated
in RadeonDoAdjustframe() just like crtc2 base. So how to I do it in a
compatible way?
Thanks,
Alex,
It might be easer to understand the issues if you post a non-compatible
version of the fix, so that there's something concrete to talk about.
Keith
I'm not at my pc at the moment, but I threw this together quickly to
give you all an idea of what I'm talking about:
http://www.botchco.com/alex/mfb-fix.patch
--- radeon_driver.c.orig 2005-01-05 10:03:39.660423035 -0500
+++ radeon_driver.c 2005-01-05 10:07:11.867000308 -0500
@@ -7536,13 +7536,16 @@
pSAREAPriv = DRIGetSAREAPrivate(pScrn-pScreen);
- if (clone || info-IsSecondary) {
- pSAREAPriv-crtc2_base = Base;
- }
-
if (pSAREAPriv-pfCurrentPage == 1) {
Base += info-backOffset;
}
+
+if (clone || info-IsSecondary) {
+pSAREAPriv-crtc2_base = Base;
+} else {
+pSAREAPriv-crtc1_base = Base;
+}
+
}
#endif
--- radeon_drm.h.orig 2005-01-05 10:03:51.709730361 -0500
+++ radeon_drm.h 2005-01-05 10:09:08.057034243 -0500
@@ -359,6 +359,7 @@
int pfState;/* number of 3d windows (0,1,2ormore) */
int pfCurrentPage; /* which buffer is being displayed? */
int crtc2_base; /* CRTC2 frame offset */
+int crtc1_base;
} drm_radeon_sarea_t;
/* WARNING: If you change any of these defines, make sure to change the
--- radeon_sarea.h.orig 2005-01-05 10:04:05.904558219 -0500
+++ radeon_sarea.h2005-01-05 10:08:01.756851008 -0500
@@ -226,6 +226,7 @@
int pfAllowPageFlip; /* set by the 2d driver, read by the client */
int pfCurrentPage; /* set by kernel, read by others */
int crtc2_base; /* for pageflipping with CloneMode */
+int crtc1_base;
} RADEONSAREAPriv, *RADEONSAREAPrivPtr;
#endif
--- radeon_state.c.orig 2005-01-05 10:04:17.660930998 -0500
+++ radeon_state.c2005-01-05 10:10:31.661350159 -0500
@@ -1330,9 +1330,7 @@
BEGIN_RING(6);
RADEON_WAIT_UNTIL_3D_IDLE();
- OUT_RING_REG(RADEON_CRTC_OFFSET,
- ((sarea-frame.y * dev_priv-front_pitch +
-sarea-frame.x * (dev_priv-color_fmt - 2)) ~7)
+ OUT_RING_REG(RADEON_CRTC_OFFSET, dev_priv-sarea_priv-crtc1_base
+ offset);
OUT_RING_REG(RADEON_CRTC2_OFFSET, dev_priv-sarea_priv-crtc2_base
+ offset);
I don't think there's actually any problem with this patch - old
clientside drivers won't use the new sarea field, but they didn't handle
this right anyway it isn't as if you are breaking an already-working setup.
what if you use an old DDX with a new drm? The old DDX wouldn't set
sarea_priv-crtc1_base right; it wouldn't even know about it. In
radeon_cp_dispatch_flip() something bogus would get written to
RADEON_CRTC_OFFSET.
Ah right, I see it now.
It's a little tricky - I guess you'll need some way of informing the
kernel which way it is supposed to calculate crtc1_base, either by a new
call to the SET_PARAMETER ioctl, or via the ABI version setting
interface. I don't have a good understanding of the latter, the former
sounds like an easy option, just ensure that there is a root-only check
on that parameter.
Keith
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FIXED: MergedFB and pageflipping
Keith Whitwell wrote:
Alex Deucher wrote:
On Wed, 05 Jan 2005 15:20:41 +, Keith Whitwell
[EMAIL PROTECTED] wrote:
Alex Deucher wrote:
On Wed, 05 Jan 2005 14:35:30 +, Keith Whitwell
[EMAIL PROTECTED] wrote:
Alex Deucher wrote:
Ok, so last night I think I figured out why pageflipping was borked
with mergedfb. Unfortunately the fix requires changes to the drm and
sarea. I'm wondering what the best way to do this is and maintain
compatability. When crtc1 is at offset 0 pageflipping should work
with a simple patch to radeon_driver.c::RadeonDoAdjustframe(). the
backbuffer offset was being added to the base address after the
crtc2_base info was updated in the sarea. That's an easy fix. For
situations where crtc2 is at offset 0 and crtc1 is at a higher
offset,
changes to the drm and sarea are required. I think the easiest
solution would be to add a crtc1_base to the sarea and update that in
RadeonDoAdjustframe() just like crtc2_base. The problem is that in
the drm in radeon_state.c::radeon_cp_dispatch_flip() the offset of
crtc1 is calculated from the sarea frame info which could be crtc1 or
crtc2 depending on their orientation. It should really be calcluated
in RadeonDoAdjustframe() just like crtc2 base. So how to I do it
in a
compatible way?
Thanks,
Alex,
It might be easer to understand the issues if you post a
non-compatible
version of the fix, so that there's something concrete to talk about.
Keith
I'm not at my pc at the moment, but I threw this together quickly to
give you all an idea of what I'm talking about:
http://www.botchco.com/alex/mfb-fix.patch
--- radeon_driver.c.orig 2005-01-05 10:03:39.660423035 -0500
+++ radeon_driver.c 2005-01-05 10:07:11.867000308 -0500
@@ -7536,13 +7536,16 @@
pSAREAPriv = DRIGetSAREAPrivate(pScrn-pScreen);
- if (clone || info-IsSecondary) {
- pSAREAPriv-crtc2_base = Base;
- }
-
if (pSAREAPriv-pfCurrentPage == 1) {
Base += info-backOffset;
}
+
+if (clone || info-IsSecondary) {
+pSAREAPriv-crtc2_base = Base;
+} else {
+pSAREAPriv-crtc1_base = Base;
+}
+
}
#endif
--- radeon_drm.h.orig 2005-01-05 10:03:51.709730361 -0500
+++ radeon_drm.h 2005-01-05 10:09:08.057034243 -0500
@@ -359,6 +359,7 @@
int pfState;/* number of 3d windows (0,1,2ormore) */
int pfCurrentPage; /* which buffer is being displayed? */
int crtc2_base; /* CRTC2 frame offset */
+int crtc1_base;
} drm_radeon_sarea_t;
/* WARNING: If you change any of these defines, make sure to change the
--- radeon_sarea.h.orig 2005-01-05 10:04:05.904558219 -0500
+++ radeon_sarea.h2005-01-05 10:08:01.756851008 -0500
@@ -226,6 +226,7 @@
int pfAllowPageFlip; /* set by the 2d driver, read by the
client */
int pfCurrentPage; /* set by kernel, read by
others */
int crtc2_base; /* for pageflipping with CloneMode */
+int crtc1_base;
} RADEONSAREAPriv, *RADEONSAREAPrivPtr;
#endif
--- radeon_state.c.orig 2005-01-05 10:04:17.660930998 -0500
+++ radeon_state.c2005-01-05 10:10:31.661350159 -0500
@@ -1330,9 +1330,7 @@
BEGIN_RING(6);
RADEON_WAIT_UNTIL_3D_IDLE();
- OUT_RING_REG(RADEON_CRTC_OFFSET,
- ((sarea-frame.y * dev_priv-front_pitch +
-sarea-frame.x * (dev_priv-color_fmt - 2)) ~7)
+ OUT_RING_REG(RADEON_CRTC_OFFSET, dev_priv-sarea_priv-crtc1_base
+ offset);
OUT_RING_REG(RADEON_CRTC2_OFFSET, dev_priv-sarea_priv-crtc2_base
+ offset);
I don't think there's actually any problem with this patch - old
clientside drivers won't use the new sarea field, but they didn't handle
this right anyway it isn't as if you are breaking an already-working
setup.
what if you use an old DDX with a new drm? The old DDX wouldn't set
sarea_priv-crtc1_base right; it wouldn't even know about it. In
radeon_cp_dispatch_flip() something bogus would get written to
RADEON_CRTC_OFFSET.
Ah right, I see it now.
It's a little tricky - I guess you'll need some way of informing the
kernel which way it is supposed to calculate crtc1_base, either by a new
call to the SET_PARAMETER ioctl, or via the ABI version setting
interface. I don't have a good understanding of the latter, the former
sounds like an easy option, just ensure that there is a root-only check
on that parameter.
In fact, the new parameter could be called something like
RADEON_DDX_VERSION, so it could be useful for future two-way handshaking.
Of course, it's entirely likely that this is just re-inventing the
existing version setting code.
Keith
---
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt
--
___
Dri-devel mailing list
Re: DRI Wiki has bad snapshots links.
Adam, On Tue, Dec 28, 2004 at 06:30:49PM -0500, Adam Jackson wrote: On Tuesday 28 December 2004 15:11, Adam Jackson wrote: This is probably a good time to mention that I've copied the wiki pages across to dri.freedesktop.org. Many links are busted because they're not proper WikiWords, and it's still immutable because the ownership on the files needs fixing. The first I can fix with a bit of sed magic, for the second I'll need a sitewrangler... As an update, it's no longer read-only. You'll need to create a login first, of course. FYI, I've reimplemented my customization to the DRI wiki as a plugin, to avoid difficulties when upgrading MoinMoin in the future. I've put an adapted version of /usr/lib/python2.3/site-packages/MoinMoin/parser/wiki.py as /srv/dri.freedesktop.org/moin/data/plugin/parser/extwiki.py and set the default_markup to 'extwiki' in moin_config.py . The modifications allow any existing single word topic as a WikiName and generate automatic hyperlinks to Doxygen documentation. This works fine in my computer with the MoinMoin's test standalone HTTP server in my machine, but it refuses to load the extwiki plugin on dri.freedesktop.org by some mysterious reason. Do you have any clue? José Fonseca --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FIXED: MergedFB and pageflipping
If we are going to fix this, can we go all the way and let crtc0_base and crtc1_base both have any value and not force crtc0 to zero? That would make it easier to do something like an OOPs display when X is running. The OOPs display could use a new scan out buffer and not disturb the one with a problem. -- Jon Smirl [EMAIL PROTECTED] --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FIXED: MergedFB and pageflipping
On Wed, 5 Jan 2005 11:48:08 -0500, Jon Smirl [EMAIL PROTECTED] wrote: If we are going to fix this, can we go all the way and let crtc0_base and crtc1_base both have any value and not force crtc0 to zero? That would make it easier to do something like an OOPs display when X is running. The OOPs display could use a new scan out buffer and not disturb the one with a problem. that's the plan. see my makeshift patch. If you can think of a more flexible approache let me know. Alex -- Jon Smirl [EMAIL PROTECTED] --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FIXED: MergedFB and pageflipping
Also, I think the clear code in the radeon driver is hardwired to assume a scan out buffer starting at zero. Clear is using the 2D engine. There was some reason I was going to switch it to using the 3D one but I forget why. The reason was related to moving the scan out buffer away from zero. -- Jon Smirl [EMAIL PROTECTED] --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New Debian packages built from Xorg
On Wed, Jan 05, 2005 at 07:50:50AM -0600, John Lightsey wrote: I was feeling a bit frisky yesterday and built new DRI packages for Debian Unstable using the Xorg xc tree. Any feedback would be greatly appreciated. http://www.nixnuts.net/files/experimental/ Works for me! (Well, apart from the fact that UT2003 is completely borked that is. But that's been the case for a while with the DRI builds. Foliage and enemies are rendered but the landscape simply isn't there. It looks like you can see the skybox in all directions actually, but it might be a different texture. It looks the same regardless of whether hardware TCL is turned on or not.) Nice FPS boost (Radeon 9200SE) with HyperZ turned on in Quake3 -- makes it reasonably playable in 1280x1024. cheers, Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt signature.asc Description: Digital signature
Building DRI snapshots for sarge once stable, big problems if nothing is done.
I have not heard from the debian X ppl on if, at this late hour, thay will accept patches for things like this. --- Michel Dänzer [EMAIL PROTECTED] wrote: On Thu, 2004-12-30 at 12:33 -0800, Mike Mestnik wrote: --- Michel Dnzer [EMAIL PROTECTED] wrote: * X server from the X.Org tree. Will building the X.Org binarys and puting them on a system expecting Xfree86 binarys work? Hmm, there may indeed be issues, in particular related to stuff like XKB. Someone would have to try... or, if you (or anybody else, for that matter) want to make snapshots from XFree86 CVS instead, go ahead. This is what I'v beed trying to say. 1. The old xc tree is dead. 2. It's currently the only way to build Xfree86 server for Debian. Look at the recent(2004.11.23) source! 3. This has recently stoped working. Can we fix this as an easy way out? 4. It would be nice to fold these changes into Debian's Xfree86. 5. What are these changes? 6. Replacing Xorg for Xfree86 on Debian stable(sarge)... Dosen't seem like a good idea, the day for this may come but it is not this day. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer __ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250 --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FIXED: MergedFB and pageflipping
Keith Whitwell wrote: It's a little tricky - I guess you'll need some way of informing the kernel which way it is supposed to calculate crtc1_base, either by a new call to the SET_PARAMETER ioctl, or via the ABI version setting interface. I don't have a good understanding of the latter, the former sounds like an easy option, just ensure that there is a root-only check on that parameter. Keith Couldn't you add some flag to the drm radeon init ioctl ? It has no flag field unfortunately, but I figured you can just put 16 bit worth of flags to for instance the front_pitch variable, since the upper 16 bits are all zero anyway. Though you'd need to check the radeon drm version before doing that. (That's at least what I'm doing for now for initializing with color tiling enabled, it IS a hack but there didn't seem to be an easy clean solution.). That SET_PARAMETER ioctl sounds promising though, never heard of it before ;-). Roland --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: amd64 + r300.sf.net drivers
https://bugs.freedesktop.org/show_bug.cgi?id=1819 This is not linux specific, this also locked up my FreeBSD5.3 box. Thanks for the hint! When i disable AGPFastWrite and switch BIOS and xorg.conf to AGPMode 4 it works. xorg.log tells me dri is enabled but glxinfo still tells me i don't have direct rendering. I compiled and installed mesa as stated in the README. Is it normal that glxinfo prints Direct Rendering: No? Try doing export LIBGL_DEBUG=verbose glxinfo This should give you a hint as to what is wrong. Chances are you have installed the driver or it does not have permissions set properly. Alternative /dev/dri might not be accessible. best Vladimir Dergachev Greetings Jan Regards, Andreas Streichardt --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New Debian packages built from Xorg
Philip Armstrong wrote: On Wed, Jan 05, 2005 at 07:50:50AM -0600, John Lightsey wrote: I was feeling a bit frisky yesterday and built new DRI packages for Debian Unstable using the Xorg xc tree. Any feedback would be greatly appreciated. http://www.nixnuts.net/files/experimental/ Works for me! (Well, apart from the fact that UT2003 is completely borked that is. But that's been the case for a while with the DRI builds. Foliage and enemies are rendered but the landscape simply isn't there. It looks like you can see the skybox in all directions actually, but it might be a different texture. It looks the same regardless of whether hardware TCL is turned on or not.) I'm not seeing this, but it sounds like it could be related to texgen changes some months ago. Nice FPS boost (Radeon 9200SE) with HyperZ turned on in Quake3 -- makes it reasonably playable in 1280x1024. Should get even better with color tiling soon enough :-). Roland --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: amd64 + r300.sf.net drivers
On Tuesday 04 January 2005 00:06, Jan Kreuzer wrote: I saw that you have Option AGPFastWrite on in your xorg.conf, try to disable it. My system also locks up when it is on (same symptoms as yours), but works when i disable it. It seems this is the same behaviour as described in the following bur reports: https://bugs.freedesktop.org/show_bug.cgi?id=2012 https://bugs.freedesktop.org/show_bug.cgi?id=1819 This is not linux specific, this also locked up my FreeBSD5.3 box. Thanks for the hint! When i disable AGPFastWrite and switch BIOS and xorg.conf to AGPMode 4 it works. xorg.log tells me dri is enabled but glxinfo still tells me i don't have direct rendering. I compiled and installed mesa as stated in the README. Is it normal that glxinfo prints Direct Rendering: No? Greetings Jan Regards, Andreas Streichardt --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] Latest r300_driver on PPC
Hi, I was able to compile the latest r300_driver as of this writing. glxgears now gets ~650fps but the actual image is drawn below the window. I also tried a couple NeHe demos and the show the same drwaing problem. I took a screenshot of the problem http://pimpstation.org/Screenshot.png . One question I had was did I only need to build r300_dri.so or all of Mesa? The README wasn't clear so I only copied the dri driver into X. My machine: Ubuntu 4.10 Powerbook 15 1Ghz RV350 [Mobility Radeon 9600 M10] Thanks, -- Keith Conger [EMAIL PROTECTED] http://pimpstation.org --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: amd64 + r300.sf.net drivers
Nope glxinfo should state directrendering yes. Try LIBGL_DEBUG=verbose glxinfo and post the output. Greetings Jan -- +++ GMX - die erste Adresse für Mail, Message, More +++ 1 GB Mailbox bereits in GMX FreeMail http://www.gmx.net/de/go/mail --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New Debian packages built from Xorg
On Wed, Jan 05, 2005 at 10:04:50PM +0100, Roland Scheidegger wrote: Philip Armstrong wrote: (Well, apart from the fact that UT2003 is completely borked that is. But that's been the case for a while with the DRI builds. Foliage and enemies are rendered but the landscape simply isn't there. It looks like you can see the skybox in all directions actually, but it might be a different texture. It looks the same regardless of whether hardware TCL is turned on or not.) I'm not seeing this, but it sounds like it could be related to texgen changes some months ago. It's been like that for a while. Certainly since last Nov IIRC. UT2004 also has a problem with the menus where they have a pure white background instead of the expected image. The game seems to run OK however (although not particularly speedily on my hardware). Oh, and DOOM III segfaults on startup. Nice FPS boost (Radeon 9200SE) with HyperZ turned on in Quake3 -- makes it reasonably playable in 1280x1024. Should get even better with color tiling soon enough :-). :) Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 2229] New: glReadPixel (or glDrawPixel) causes segfaults
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2229 Summary: glReadPixel (or glDrawPixel) causes segfaults Product: Mesa Version: CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Drivers/DRI/r200 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: [EMAIL PROTECTED] demos/readpix will segfault when moving the window completely out of the screen (I pushed it to bottom/left). With R200_DEBUG set to pixel, this is what I got: r200ReadPixels r200TryReadPixels r200TryReadPixels: dest not GART r200DrawPixels r200TryDrawPixels r200TryDrawPixels: not GART memory r200DrawPixels r200TryDrawPixels r200TryDrawPixels: not GART memory r200ReadPixels r200TryReadPixels r200TryReadPixels: dest not GART Speicherzugriffsfehler I have no backtrace unfortunately, be warned that the segfault obviously happens after a LOCK_HARDWARE()... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New Debian packages built from Xorg
Philip Armstrong wrote: On Wed, Jan 05, 2005 at 10:04:50PM +0100, Roland Scheidegger wrote: Philip Armstrong wrote: (Well, apart from the fact that UT2003 is completely borked that is. But that's been the case for a while with the DRI builds. Foliage and enemies are rendered but the landscape simply isn't there. It looks like you can see the skybox in all directions actually, but it might be a different texture. It looks the same regardless of whether hardware TCL is turned on or not.) I'm not seeing this, but it sounds like it could be related to texgen changes some months ago. It's been like that for a while. Certainly since last Nov IIRC. That would coincide well with the texgen/tex coord submission changes. UT2004 also has a problem with the menus where they have a pure white background instead of the expected image. The game seems to run OK however (although not particularly speedily on my hardware). Don't have issues with the menus. I think I've heard of that problem some time ago though, iirc it was related to s3tc (not sure though). If so it might be fixed in a newer version. ut2k3 / ut2k4 indeed have a performance problem, they are stuck somewhere in the tnl code (glDraw[Range]Elements) for way too many cpu cycles since about Mesa 6. Oh, and DOOM III segfaults on startup. Sounds like the doom3 not loading libGL correctly to me. Fixed in newer versions, or try LD_PRELOAD=/usr/lib/libGL.so when starting doom3 (note though the old version also has some problem with detecting s3tc extension, so if you don't have the external library installed it might not work at all). Roland --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: FIXED: MergedFB and pageflipping
On Wed, 2005-01-05 at 17:04 +0100, Roland Scheidegger wrote: Keith Whitwell wrote: It's a little tricky - I guess you'll need some way of informing the kernel which way it is supposed to calculate crtc1_base, either by a new call to the SET_PARAMETER ioctl, or via the ABI version setting interface. I don't have a good understanding of the latter, the former sounds like an easy option, just ensure that there is a root-only check on that parameter. Keith Couldn't you add some flag to the drm radeon init ioctl ? It has no flag field unfortunately, but I figured you can just put 16 bit worth of flags to for instance the front_pitch variable, since the upper 16 bits are all zero anyway. Though you'd need to check the radeon drm version before doing that. (That's at least what I'm doing for now for initializing with color tiling enabled, it IS a hack but there didn't seem to be an easy clean solution.). That SET_PARAMETER ioctl sounds promising though, never heard of it before ;-). We've got the setversion ioctl already for dealing with just this issue. You'd need to add the driver hook to it I think (since no drivers have needed a version setting before) but that should be easy. Bump the driver-dependent minor version, and when the minor gets set to this version or better, set the I've got the new field flag in the DRM. In this case, you'd probably check that for root capability in the driver before setting the flag, since only the server should be setting the yes the sarea has the new field value. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1698] RFE: Minimize symbol table in DRI drivers
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=1698 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-01-05 20:42 --- fixed in CVS since a while ago, closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
