Re: Problems with compiling new savage patch.
On Sat, 2004-10-30 at 04:06 +0100, Sérgio wrote: Can we change configuration of Xorg, for compile and install xorg without compile any source of Mesa and/or GLx ? You could try BuildGLXLibrary and/or BuildXF86DRI. I'm not sure of all the implications, but it sounds like the right direction. signature.asc Description: This is a digitally signed message part
[patch] Re: Making reclaim_buffers OS-independent
A patch is attached. It changes both linux/linux-2.6 and linux-core. I
tested that it compiles (linux-2.6 and linux-core) and loads all modules
(except radeon, which failed because I don't have the necessary i2c bits
in my kernel). Any objections to applying this?
Regards,
Felix
Am Sa, den 30.10.2004 schrieb Felix Kühling um 23:56:
Currenly in linux-core the driver callback reclaim_buffers is called
with a single argument filp. In reclaim_buffers you need OS-specific
knowledge to extract the device pointer from the filp. In the BSD DRM
reclaim_buffers takes two arguments, dev and filp. Could we change
the linux version to use the same API? This would allow implementing an
OS-agnostic reclaim_buffers function in a driver.
Regards,
Felix
--
| Felix Kühling [EMAIL PROTECTED] http://fxk.de.vu |
| PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 |
Index: linux/drmP.h
===
RCS file: /cvs/dri/drm/linux/drmP.h,v
retrieving revision 1.123
diff -u -r1.123 drmP.h
--- linux/drmP.h 9 Oct 2004 10:58:19 - 1.123
+++ linux/drmP.h 31 Oct 2004 10:20:46 -
@@ -528,7 +528,7 @@
void (*irq_preinstall)(struct drm_device *dev);
void (*irq_postinstall)(struct drm_device *dev);
void (*irq_uninstall)(struct drm_device *dev);
- void (*reclaim_buffers)(struct file *filp);
+ void (*reclaim_buffers)(struct drm_device *dev, struct file *filp);
unsigned long (*get_map_ofs)(drm_map_t *map);
unsigned long (*get_reg_ofs)(struct drm_device *dev);
void (*set_version)(struct drm_device *dev, drm_set_version_t *sv);
@@ -870,7 +870,7 @@
extern int DRM(dma_setup)(drm_device_t *dev);
extern void DRM(dma_takedown)(drm_device_t *dev);
extern void DRM(free_buffer)(drm_device_t *dev, drm_buf_t *buf);
-extern void DRM(reclaim_buffers)( struct file *filp );
+extern void DRM(core_reclaim_buffers)(drm_device_t *dev, struct file *filp);
/* IRQ support (drm_irq.h) */
extern int DRM(control)( struct inode *inode, struct file *filp,
Index: linux/drm_dma.h
===
RCS file: /cvs/dri/drm/linux/drm_dma.h,v
retrieving revision 1.34
diff -u -r1.34 drm_dma.h
--- linux/drm_dma.h 5 Sep 2004 10:54:58 - 1.34
+++ linux/drm_dma.h 31 Oct 2004 10:20:46 -
@@ -154,10 +154,8 @@
*
* Frees each buffer associated with \p filp not already on the hardware.
*/
-void DRM(core_reclaim_buffers)( struct file *filp )
+void DRM(core_reclaim_buffers)( drm_device_t *dev, struct file *filp )
{
- drm_file_t*priv = filp-private_data;
- drm_device_t *dev= priv-dev;
drm_device_dma_t *dma = dev-dma;
int i;
Index: linux/drm_drv.h
===
RCS file: /cvs/dri/drm/linux/drm_drv.h,v
retrieving revision 1.91
diff -u -r1.91 drm_drv.h
--- linux/drm_drv.h 8 Oct 2004 14:31:24 - 1.91
+++ linux/drm_drv.h 31 Oct 2004 10:20:56 -
@@ -857,7 +857,7 @@
if (drm_core_check_feature(dev, DRIVER_HAVE_DMA))
{
- dev-fn_tbl.reclaim_buffers(filp);
+ dev-fn_tbl.reclaim_buffers(dev, filp);
}
DRM(fasync)( -1, filp, 0 );
Index: linux/i810_dma.c
===
RCS file: /cvs/dri/drm/linux/i810_dma.c,v
retrieving revision 1.68
diff -u -r1.68 i810_dma.c
--- linux/i810_dma.c 23 Sep 2004 05:39:13 - 1.68
+++ linux/i810_dma.c 31 Oct 2004 10:20:56 -
@@ -996,10 +996,8 @@
}
/* Must be called with the lock held */
-void i810_reclaim_buffers(struct file *filp)
+void i810_reclaim_buffers(drm_device_t *dev, struct file *filp)
{
- drm_file_t*priv = filp-private_data;
- drm_device_t *dev= priv-dev;
drm_device_dma_t *dma = dev-dma;
int i;
@@ -1395,7 +1393,7 @@
static void i810_driver_release(drm_device_t *dev, struct file *filp)
{
- i810_reclaim_buffers(filp);
+ i810_reclaim_buffers(dev, filp);
}
static int i810_driver_dma_quiescent(drm_device_t *dev)
Index: linux/i810_drv.h
===
RCS file: /cvs/dri/drm/linux/i810_drv.h,v
retrieving revision 1.21
diff -u -r1.21 i810_drv.h
--- linux/i810_drv.h 17 Aug 2004 13:10:04 - 1.21
+++ linux/i810_drv.h 31 Oct 2004 10:20:57 -
@@ -99,7 +99,7 @@
extern int i810_dma_cleanup(drm_device_t *dev);
extern int i810_flush_ioctl(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
-extern void i810_reclaim_buffers(struct file *filp);
+extern void i810_reclaim_buffers(drm_device_t *dev, struct file *filp);
extern int i810_getage(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
extern int i810_mmap_buffers(struct file *filp, struct vm_area_struct *vma);
Index: linux/i830_dma.c
===
RCS file: /cvs/dri/drm/linux/i830_dma.c,v
retrieving revision 1.33
diff -u -r1.33
Re: [patch] Re: Making reclaim_buffers OS-independent
A patch is attached. It changes both linux/linux-2.6 and linux-core. I tested that it compiles (linux-2.6 and linux-core) and loads all modules (except radeon, which failed because I don't have the necessary i2c bits in my kernel). Any objections to applying this? Looks good to me apply away... Dave. Regards, Felix Am Sa, den 30.10.2004 schrieb Felix Kühling um 23:56: Currenly in linux-core the driver callback reclaim_buffers is called with a single argument filp. In reclaim_buffers you need OS-specific knowledge to extract the device pointer from the filp. In the BSD DRM reclaim_buffers takes two arguments, dev and filp. Could we change the linux version to use the same API? This would allow implementing an OS-agnostic reclaim_buffers function in a driver. Regards, Felix -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie pam_smb / Linux DECstation / Linux VAX / ILUG person --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
A few Savage Xv issues
Hi. While the current Xv implementation is far better than the old one there are still a few glitches I noticed so far: * 4 pixels always missing on the right side on the screen * The old shadowing effect is showed on certain conditions (depending on input sizes). I only tested a few sizes: 768 and smaller work, 924 (and probably greater) show that effect. I wanted to make this report because I noticed today that the shadowing effect still remains. I noticed it using the tv aplicattion tvtime and changing the horizontal resolution to 924. Unfortunately, I do not have any video file to test such big sizes. I'm using savage and common snapshots from 20041015. I hope these are not too old. Thank you for your time. --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [2.6 patch] DRM: remove unused functions
The patch below removes two unused functions from DRM. diffstat output: drivers/char/drm/i810_dma.c | 18 -- drivers/char/drm/i915_dma.c | 18 -- 2 files changed, 36 deletions(-) Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Acked-by: Dave Airlie [EMAIL PROTECTED] --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI build broken
On Sat, Oct 30, 2004 at 04:16:09AM +0200, Stephane Marchesin wrote:
../../../../../src/mesa/tnl_dd/t_dd_vbtmp.h: In function `emit_wg':
../../../../../src/mesa/tnl_dd/t_dd_vbtmp.h:387: error: `col_size'
undeclared (first use in this function)
It compiles for me after applying attached patch. I have no idea is this
correct solution :)
--
Free Software - find interesting programs and change them
NetHack - meet interesting creatures, kill them and eat their bodies
Usenet - meet interesting people from all over the world and flame them
Decopter - unrealistic helicopter simulator, get it from http://decopter.sf.net
diff -Naur Mesa/src/mesa/tnl_dd/t_dd_vbtmp.h Mesa-fixed/src/mesa/tnl_dd/t_dd_vbtmp.h
--- Mesa/src/mesa/tnl_dd/t_dd_vbtmp.h 2004-10-31 12:58:57.0 +0100
+++ Mesa-fixed/src/mesa/tnl_dd/t_dd_vbtmp.h 2004-10-31 13:28:36.350827680 +0100
@@ -344,7 +344,7 @@
LOCALVARS
struct vertex_buffer *VB = TNL_CONTEXT(ctx)-vb;
GLfloat (*col)[4];
- GLuint col_stride;
+ GLuint col_stride,col_size;
GLfloat (*coord)[4] = VB-NdcPtr-data;
GLuint coord_stride = VB-NdcPtr-stride;
GLfloat *v = (GLfloat *)dest;
@@ -384,6 +384,7 @@
UNCLAMPED_FLOAT_TO_UBYTE(c-red, col[0][0]);
UNCLAMPED_FLOAT_TO_UBYTE(c-green, col[0][1]);
UNCLAMPED_FLOAT_TO_UBYTE(c-blue, col[0][2]);
+col_size = VB-ColorPtr[0]-size;
if (col_size == 4) {
UNCLAMPED_FLOAT_TO_UBYTE(c-alpha, col[0][3]);
} else {
ARB float texture/framebuffer extensions are out
Hi! ARB released a couple of days ago the long waited float extensions.. http://oss.sgi.com/projects/ogl-sample/registry/ARB/color_buffer_float.txt http://oss.sgi.com/projects/ogl-sample/registry/ARB/half_float_pixel.txt http://oss.sgi.com/projects/ogl-sample/registry/ARB/texture_float.txt http://www.opengl.org/discussion_boards/cgi_directory/ultimatebb.cgi?ubb=get_topic;f=3;t=012662 There seems to be some IP issues.. does that mean these extensions can't be implemented in Mesa/DRI ? -- Pasi Kärkkäinen ^ . . Linux /-\ Choice.of.the .Next.Generation. --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Multiple hardware locks
Hi, list! With display cards that have more and more hardware on them, (TV-capture, mpeg decoders) etc. that can work independently of oneanother, but share the same DMA engine I've find the need for more than one hardware lock. I've done a simple implementation for the mpeg decoder of the via driver, but that one doesn't cover the DMA case. The question arises Why should I need to wait for DMA quiescent to check whether the decoder is done with a frame, if there is no decoder data in any of the pending DMA buffers? In the VIA / Unichrome case alone there is a need for even more such locks for different parts of the chip if one were to make a clean implementation of drivers for all features that are on the chip. My idea would be to extend drm with options for multiple locks, and I suspect not only VIA cards could benefit from this. I was thinking of. 1. A separate sarea to contain these locks, to avoid messing up the current sarea with binary incompatibilities as a consequence. 2. Other kernel modules should be able to take and release these locks. (V4L for example). 3. Each DMA buffer is marked (or in the VIA case, each submission to the ring-buffer is marked) wether it accesses the resource that is protected by a certain lock. 4. A resource will become available to a client when the client has taken the lock and there are no pending DMA buffers / parts of buffers that are marked touching this resource. 5. The client is responsible for reinitializing the resource once the lock is taken. These are just initial thoughts. Is there a mechanism for this in DRM today or could it be done in a better way? /Thomas --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
On Sun, 31 Oct 2004 16:52:35 +0100, Thomas Hellström [EMAIL PROTECTED] wrote: 1. A separate sarea to contain these locks, to avoid messing up the current sarea with binary incompatibilities as a consequence. It would probably be better to extend the current driver specific sarea. You can negotiate the driver interface version to enable the new functions. There should be room: #define SAREA_MAX 0x2000 Where is sarea allocated? I looked for five minutes and couldn't find it. 2. Other kernel modules should be able to take and release these locks. (V4L for example). 3. Each DMA buffer is marked (or in the VIA case, each submission to the ring-buffer is marked) wether it accesses the resource that is protected by a certain lock. 4. A resource will become available to a client when the client has taken the lock and there are no pending DMA buffers / parts of buffers that are marked touching this resource. 5. The client is responsible for reinitializing the resource once the lock is taken. These are just initial thoughts. Is there a mechanism for this in DRM today or could it be done in a better way? /Thomas --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
Jon Smirl wrote: On Sun, 31 Oct 2004 16:52:35 +0100, Thomas Hellstrm [EMAIL PROTECTED] wrote: 1. A separate sarea to contain these locks, to avoid messing up the current sarea with binary incompatibilities as a consequence. It would probably be better to extend the current driver specific sarea. You can negotiate the driver interface version to enable the new functions. There should be room: #define SAREA_MAX 0x2000 Where is sarea allocated? I looked for five minutes and couldn't find it Hi! The idea of using a separate sarea is that it would be easy to extend the number of locks and more suitable for more drivers than via. Otherwise one idea would be to fill the private sarea from the back, but that would break DDX tests for size of usable area. Different sareas are allocated using drmAddMap with type=DRM_SHM. The one containing the current hardware lock is specified with the flag DRM_CONTAINS_LOCK. /Thomas 2. Other kernel modules should be able to take and release these locks. (V4L for example). 3. Each DMA buffer is marked (or in the VIA case, each submission to the ring-buffer is marked) wether it accesses the resource that is protected by a certain lock. 4. A resource will become available to a client when the client has taken the lock and there are no pending DMA buffers / parts of buffers that are marked touching this resource. 5. The client is responsible for reinitializing the resource once the lock is taken. These are just initial thoughts. Is there a mechanism for this in DRM today or could it be done in a better way? /Thomas --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
On Sun, 31 Oct 2004 18:41:42 +0100, Thomas Hellström [EMAIL PROTECTED] wrote: The idea of using a separate sarea is that it would be easy to extend the number of locks and more suitable for more drivers than via. Otherwise one idea would be to fill the private sarea from the back, but that would break DDX tests for size of usable area. Different sareas are allocated using drmAddMap with type=DRM_SHM. The one containing the current hardware lock is specified with the flag DRM_CONTAINS_LOCK. Shouldn't the sarea have been allocated by the driver in the first place? Maybe this is another place for pemanent maps. I will probably have to change this for multihead support running indenpendent X servers. The current design assumes a master process that creates/deletes sarea and that isn't the case for indepenent multi-head. Code like this is a mistake: drmInfo.sarea_priv_offset = sizeof(drm_sarea_t); The first member of drm_sarea_t should have been an offset to the private sarea. Doing it that way would automatically adjust if the size of drm_sarea_t is changed. Offset should have been filled in by the DRM driver. I don't see any code computing sizeof(drm_sarea_t) + sizeof(drm_xxx_sarea_t). What is getting stored in the SAREA page after the private area? -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
Jon Smirl wrote:
On Sun, 31 Oct 2004 18:41:42 +0100, Thomas Hellstrm
[EMAIL PROTECTED] wrote:
The idea of using a separate sarea is that it would be easy to extend the
number of locks and more suitable for more drivers than via. Otherwise one
idea would be to
fill the private sarea from the back, but that would break DDX tests for
size of usable area.
Different sareas are allocated using drmAddMap with type=DRM_SHM. The one
containing the current hardware lock is specified with the flag
DRM_CONTAINS_LOCK.
Shouldn't the sarea have been allocated by the driver in the first
place? Maybe this is another place for pemanent maps. I will probably
have to change this for multihead support running indenpendent X
servers. The current design assumes a master process that
creates/deletes sarea and that isn't the case for indepenent
multi-head.
Code like this is a mistake:
drmInfo.sarea_priv_offset = sizeof(drm_sarea_t);
The first member of drm_sarea_t should have been an offset to the
private sarea. Doing it that way would automatically adjust if the
size of drm_sarea_t is changed. Offset should have been filled in by
the DRM driver.
I don't see any code computing sizeof(drm_sarea_t) +
sizeof(drm_xxx_sarea_t). What is getting stored in the SAREA page
after the private area?
X contains code like
/* For now the mapping works by using a fixed size defined
* in the SAREA header
*/
if (sizeof(XF86DRISAREARec)+sizeof(VIASAREAPriv) SAREA_MAX) {
xf86DrvMsg(pScrn-scrnIndex, X_ERROR,
"Data does not fit in SAREA\n");
return FALSE;
}
pDRIInfo-SAREASize = SAREA_MAX;
So if locks are going to be squeezed in somewhere I'd either have to
fit them in the
XF86DRISAREARec or put them into every driver's private area.
BTW, The "Old" drm functionality and design was very well documented by
precision insight / VAlinux. Now that permanent maps are introduced
and new requirements are made on the hw-specific drivers, is there a
chance that these documents could be updated?
Regards
Thomas
Re: Multiple hardware locks
On Sun, 31 Oct 2004 19:41:03 +0100, Thomas Hellström
[EMAIL PROTECTED] wrote:
/* For now the mapping works by using a fixed size defined
* in the SAREA header
*/
if (sizeof(XF86DRISAREARec)+sizeof(VIASAREAPriv) SAREA_MAX) {
xf86DrvMsg(pScrn-scrnIndex, X_ERROR,
Data does not fit in SAREA\n);
return FALSE;
}
pDRIInfo-SAREASize = SAREA_MAX;
So if locks are going to be squeezed in somewhere I'd either have to fit
them in the XF86DRISAREARec or put them into every driver's private area.
You can't put them into XF86DRISAREARec because of code like this:
drmInfo.sarea_priv_offset = sizeof(drm_sarea_t);
drm_sarea_t is the same structure as XF86DRISAREARec.
Are the locks generic enough that all hardware needs them?
You can extend VIASAREAPriv (drm_via_sarea_t) without messing up the
above check. drm_via_sarea_t is much smaller than SAREA_MAX.
You will still need to negotiate an interface version since some
servers will know about the extended locks and others won't. You'll
have to revert to the big lock if all of the clients don't know about
the new lock scheme.
--
Jon Smirl
[EMAIL PROTECTED]
---
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88alloc_id065op=click
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
Thomas Hellström wrote: Hi, list! With display cards that have more and more hardware on them, (TV-capture, mpeg decoders) etc. that can work independently of oneanother, but share the same DMA engine I've find the need for more than one hardware lock. The first question is - have you found that lock contention is actually a problem? I've done a simple implementation for the mpeg decoder of the via driver, but that one doesn't cover the DMA case. The question arises Why should I need to wait for DMA quiescent to check whether the decoder is done with a frame, if there is no decoder data in any of the pending DMA buffers? But this question isn't really answered by having multiple locks - it sounds more like you want some sort of IRQ notification or timestamping mechanism. Under normal circumstances grabbing the lock doesn't mean waiting for DMA quiescence. In the VIA / Unichrome case alone there is a need for even more such locks for different parts of the chip if one were to make a clean implementation of drivers for all features that are on the chip. My idea would be to extend drm with options for multiple locks, and I suspect not only VIA cards could benefit from this. I was thinking of. For many cards, there is a single dma-driven command queue, and the lock is used to protect that queue. All sorts of stuff (video, 2d, 3d) is delivered on the same queue. It sounds like the VIA driver follows a similar single-queue model. 1. A separate sarea to contain these locks, to avoid messing up the current sarea with binary incompatibilities as a consequence. 2. Other kernel modules should be able to take and release these locks. (V4L for example). 3. Each DMA buffer is marked (or in the VIA case, each submission to the ring-buffer is marked) wether it accesses the resource that is protected by a certain lock. 4. A resource will become available to a client when the client has taken the lock and there are no pending DMA buffers / parts of buffers that are marked touching this resource. 5. The client is responsible for reinitializing the resource once the lock is taken. But it still sounds like there is a single ring buffer, right? Won't you need a lock to protect the ringbuffer? Won't everything have to grab that lock? Also, how does direct framebuffer access work? The X server presumably now has to grab all of the locks, and likewise 3d fallbacks, to prevent all access to the framebuffer? These are just initial thoughts. Is there a mechanism for this in DRM today or could it be done in a better way? I guess I'm not sure which problem you're trying to solve. There are a couple I can think of so I'll list them here: - Lock contention. Under what circumstances? - Unnecessary flushing of the DMA queue/ringbuffer. IE. If you want to write to/read from a surface in video ram, how do you know when the video card has finished with it? - Something else? Keith --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
DRI causes system lookups ?
Hi, I have radeon7500 and installed Xorg Mesa and drm from CVS.. Glxinfo shows that Direct Rendering is enabled but I get everything locked up with glxgears... and I have to reboot. I found on google people with the same problems but no solutions were given. I include output from glxinfo with export LIBGL_DEBUG=verbose http://www.rafb.net/paste/results/bhKzcI23.html And my Xorg.0.log http://www.rafb.net/paste/results/aFdQxC52.html Can you fix it ? Thanks in advance, -- Mateusz Kaduk Jid: [EMAIL PROTECTED] ; GPG public key at: pgp.mit.edu --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
--- Thomas Hellström [EMAIL PROTECTED] wrote: Hi, list! With display cards that have more and more hardware on them, (TV-capture, mpeg decoders) etc. that can work independently of oneanother, but share the same DMA engine I've find the need for more than one hardware lock. I've done a simple implementation for the mpeg decoder of the via driver, but that one doesn't cover the DMA case. The question arises Why should I need to wait for DMA quiescent to check whether the decoder is done with a frame, if there is no decoder data in any of the pending DMA buffers? In the VIA / Unichrome case alone there is a need for even more such locks for different parts of the chip if one were to make a clean implementation of drivers for all features that are on the chip. My idea would be to extend drm with options for multiple locks, and I suspect not only VIA cards could benefit from this. I was thinking of. 1. A separate sarea to contain these locks, to avoid messing up the current sarea with binary incompatibilities as a consequence. 2. Other kernel modules should be able to take and release these locks. (V4L for example). 3. Each DMA buffer is marked (or in the VIA case, each submission to the ring-buffer is marked) wether it accesses the resource that is protected There is a problem with A client being able to lock/unlock resources it may/may not be using. It's important that Client's arn't able to DOS the system by submitting junk cmds /wo setting the right locs for that junk. by a certain lock. 4. A resource will become available to a client when the client has taken the lock and there are no pending DMA buffers / parts of buffers that are marked touching this resource. 5. The client is responsible for reinitializing the resource once the lock is taken. These are just initial thoughts. Is there a mechanism for this in DRM today or could it be done in a better way? /Thomas --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
Keith Whitwell wrote: Thomas Hellström wrote: Hi, list! With display cards that have more and more hardware on them, (TV-capture, mpeg decoders) etc. that can work independently of oneanother, but share the same DMA engine I've find the need for more than one hardware lock. The first question is - have you found that lock contention is actually a problem? I've done a simple implementation for the mpeg decoder of the via driver, but that one doesn't cover the DMA case. The question arises Why should I need to wait for DMA quiescent to check whether the decoder is done with a frame, if there is no decoder data in any of the pending DMA buffers? But this question isn't really answered by having multiple locks - it sounds more like you want some sort of IRQ notification or timestamping mechanism. Under normal circumstances grabbing the lock doesn't mean waiting for DMA quiescence. The typical case here: I want a DRI client to flip a video frame to screen, using a hardware entity called the HQV. This is a rather time critical operation. To do this I have to take the hardware lock. While this is happening, another thread is waiting for the mpeg decoder to complete a frame. To to that, this thread needs to take the hardware lock, wait for quiescent DMA, and then wait for the mpeg decoder to signal idle. It might be that the DMA command queue does not even contain mpeg data. This waiting delays the frame flip enough to create a visible jump in the video. With multiple locks: The first thread checks the HQV lock, it is available and frame flipping is done immediately. The other thread meanwhile takes the MPEG engine lock, waits until the DMA engine has processed all MPEG commands in the command queue and then waits for the MPEG engine to be idle. DMA might still be processing 3D commands. In the VIA / Unichrome case alone there is a need for even more such locks for different parts of the chip if one were to make a clean implementation of drivers for all features that are on the chip. My idea would be to extend drm with options for multiple locks, and I suspect not only VIA cards could benefit from this. I was thinking of. For many cards, there is a single dma-driven command queue, and the lock is used to protect that queue. All sorts of stuff (video, 2d, 3d) is delivered on the same queue. It sounds like the VIA driver follows a similar single-queue model. Yes. 1. A separate sarea to contain these locks, to avoid messing up the current sarea with binary incompatibilities as a consequence. 2. Other kernel modules should be able to take and release these locks. (V4L for example). 3. Each DMA buffer is marked (or in the VIA case, each submission to the ring-buffer is marked) wether it accesses the resource that is protected by a certain lock. 4. A resource will become available to a client when the client has taken the lock and there are no pending DMA buffers / parts of buffers that are marked touching this resource. 5. The client is responsible for reinitializing the resource once the lock is taken. But it still sounds like there is a single ring buffer, right? Won't you need a lock to protect the ringbuffer? Won't everything have to grab that lock? Only while submitting command buffer data. This will hopefully be a very fast operation. The IOCTL copying this data to the ringbuffer will check that all locks are held for the hardware entities that the submitted command batch touches. The user will have to tell the IOCTL which entities these are, or possibly the command verifier checks this but I consider that an overkill since that is more of a bug-check than a security check. Also, how does direct framebuffer access work? The X server presumably now has to grab all of the locks, and likewise 3d fallbacks, to prevent all access to the framebuffer? The current heavyweight lock will protect framebuffer areas that are not managed by the drm memory manager. The IOCTL checking dma submission will check that this lock is held for 3d and 2d engine command submissions that touch this area. This will guarantee compatibility with the current DRI locking mechanism. Still, it will be possible to submit, for example. mpeg data to the command queue without taking the heavywieght lock, or submit 2d engine commands that blits one off-screen mpeg frame-buffer to another. These operations should not need to wait for software rendering into other parts of the frame-buffer. These are just initial thoughts. Is there a mechanism for this in DRM today or could it be done in a better way? I guess I'm not sure which problem you're trying to solve. There are a couple I can think of so I'll list them here: - Lock contention. Under what circumstances? - Unnecessary flushing of the DMA queue/ringbuffer. IE. If you want to write to/read from a surface in video ram, how do you know when the video card has finished with it? - Something else? Keith
Re: Multiple hardware locks
Mike Mestnik wrote: --- Thomas Hellstrm [EMAIL PROTECTED] wrote: Hi, list! With display cards that have more and more hardware on them, (TV-capture, mpeg decoders) etc. that can work independently of oneanother, but share the same DMA engine I've find the need for more than one hardware lock. I've done a simple implementation for the mpeg decoder of the via driver, but that one doesn't cover the DMA case. The question arises "Why should I need to wait for DMA quiescent to check whether the decoder is done with a frame, if there is no decoder data in any of the pending DMA buffers"? In the VIA / Unichrome case alone there is a need for even more such locks for different parts of the chip if one were to make a clean implementation of drivers for all features that are on the chip. My idea would be to extend drm with options for multiple locks, and I suspect not only VIA cards could benefit from this. I was thinking of. 1. A separate sarea to contain these locks, to avoid messing up the current sarea with binary incompatibilities as a consequence. 2. Other kernel modules should be able to take and release these locks. (V4L for example). 3. Each DMA buffer is marked (or in the VIA case, each submission to the ring-buffer is marked) wether it accesses the resource that is protected There is a problem with A "client" being able to lock/unlock resources it may/may not be using. It's important that Client's arn't able to DOS the system by submitting junk cmds /wo setting the right locs for that junk. Such a case would be a client submitting 2D engine commands while the X server waits for 2D engine idle. Either this has to be implemented in the command verifier or considered acceptable behaviour. Today any dri client can continously clear the screen without taking the hardware lock. by a certain lock. 4. A resource will become available to a client when the client has taken the lock and there are no pending DMA buffers / parts of buffers that are marked touching this resource. 5. The client is responsible for reinitializing the resource once the lock is taken. These are just initial thoughts. Is there a mechanism for this in DRM today or could it be done in a better way? /Thomas --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel __ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com
Re: Multiple hardware locks
--- Thomas Hellström [EMAIL PROTECTED] wrote: Such a case would be a client submitting 2D engine commands while the X server waits for 2D engine idle. Either this has to be implemented in the command verifier or considered acceptable behaviour. Today any dri client can continously clear the screen without taking the hardware lock. There are many factors that come into play. However if a potentialy hamfull interface can be fixed easily there may be no reason not to. __ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
Jon Smirl wrote:
On Sun, 31 Oct 2004 19:41:03 +0100, Thomas Hellstrm
[EMAIL PROTECTED] wrote:
/* For now the mapping works by using a fixed size defined
* in the SAREA header
*/
if (sizeof(XF86DRISAREARec)+sizeof(VIASAREAPriv) SAREA_MAX) {
xf86DrvMsg(pScrn-scrnIndex, X_ERROR,
"Data does not fit in SAREA\n");
return FALSE;
}
pDRIInfo-SAREASize = SAREA_MAX;
So if locks are going to be squeezed in somewhere I'd either have to fit
them in the XF86DRISAREARec or put them into every driver's private area.
You can't put them into XF86DRISAREARec because of code like this:
drmInfo.sarea_priv_offset = sizeof(drm_sarea_t);
drm_sarea_t is the same structure as XF86DRISAREARec.
Wouldn't this severely brake backwards binary compatibility with dri
clients compiled with the old size of drm_sarea_t?
Are the locks generic enough that all hardware needs them?
The idea was that if such an implementation exists and works, It could
be
used by any driver that found a potential gain.
The generic part would be just a number of locks sitting there if
somebody wanted
to use them. Each driver would have to assign a certain meaning to each
lock used.
For each lock there would be a way to resolve contention and to clear
the lock if the holder dies.
Still I'd have to make a working trial implementation for the VIA
driver. The important thing at this stage is to get the basic thoughts
right.
/Thomas
You can extend VIASAREAPriv (drm_via_sarea_t) without messing up the
above check. drm_via_sarea_t is much smaller than SAREA_MAX.
You will still need to negotiate an interface version since some
servers will know about the extended locks and others won't. You'll
have to revert to the big lock if all of the clients don't know about
the new lock scheme.
/Thomas
Re: Multiple hardware locks
On Sun, 31 Oct 2004 22:54:25 +0100, Thomas Hellström [EMAIL PROTECTED] wrote: Wouldn't this severely break backwards binary compatibility with dri clients compiled with the old size of drm_sarea_t? You can't put them in drm_sarea_t. There is definitely code that will break if you do. I don't see anyway to extend drm_sarea_t without causing binary incompatibility. drm_sarea_t was just not designed with binary extension in mind. I haven't located any code that will break if you put them in the card specific sareas. Also you only have to check the driver for the card if you do it this way. -- Jon Smirl [EMAIL PROTECTED] --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
Jon Smirl wrote: On Sun, 31 Oct 2004 22:54:25 +0100, Thomas Hellstrm [EMAIL PROTECTED] wrote: Wouldn't this severely break backwards binary compatibility with dri clients compiled with the old size of drm_sarea_t? You can't put them in drm_sarea_t. There is definitely code that will break if you do. I don't see anyway to extend drm_sarea_t without causing binary incompatibility. drm_sarea_t was just not designed with binary extension in mind. I haven't located any code that will break if you put them in the card specific sareas. Also you only have to check the driver for the card if you do it this way. The thing is that if I do that, and at some time in the future want to extend the number of locks, and at the same time have added other stuff after the locks in the private part of the sarea, I have a problem. Using the private part of the sarea also makes producing generic code somewhat harder. That's really why I wanted to allocate a separate sarea. /Thomas
[Bug 1746] New: Freelist issues in MGA DRM
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://freedesktop.org/bugzilla/show_bug.cgi?id=1746 Summary: Freelist issues in MGA DRM Product: DRI Version: DRI CVS Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DRM modules AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I found these two issues while reading the MGA DRM source as a basis for the new Savage drm: 1. When a DRI client crashes or is killed then it looks like DMA buffers held by it are not returned to the freelist. I think the reclaim_buffer callback should be overridden to return buffers held by the killed process to the freelist and then call drm_core_reclaim_buffers. 2. The size of the buf_priv data structure must be set in the dev_priv_size-field of the drm_driver data structure in mga_drv.c. This is used in drm_bufs.c for dynamic memory allocation. -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
On Sun, 2004-10-31 at 13:18, Thomas Hellström wrote: Keith Whitwell wrote: Thomas Hellström wrote: Hi, list! With display cards that have more and more hardware on them, (TV-capture, mpeg decoders) etc. that can work independently of oneanother, but share the same DMA engine I've find the need for more than one hardware lock. The first question is - have you found that lock contention is actually a problem? I've done a simple implementation for the mpeg decoder of the via driver, but that one doesn't cover the DMA case. The question arises Why should I need to wait for DMA quiescent to check whether the decoder is done with a frame, if there is no decoder data in any of the pending DMA buffers? But this question isn't really answered by having multiple locks - it sounds more like you want some sort of IRQ notification or timestamping mechanism. Under normal circumstances grabbing the lock doesn't mean waiting for DMA quiescence. The typical case here: I want a DRI client to flip a video frame to screen, using a hardware entity called the HQV. This is a rather time critical operation. To do this I have to take the hardware lock. While this is happening, another thread is waiting for the mpeg decoder to complete a frame. To to that, this thread needs to take the hardware lock, wait for quiescent DMA, and then wait for the mpeg decoder to signal idle. It might be that the DMA command queue does not even contain mpeg data. This waiting delays the frame flip enough to create a visible jump in the video. With multiple locks: The first thread checks the HQV lock, it is available and frame flipping is done immediately. The other thread meanwhile takes the MPEG engine lock, waits until the DMA engine has processed all MPEG commands in the command queue and then waits for the MPEG engine to be idle. DMA might still be processing 3D commands. Do you not have interrupts that either signal MPEG engine idle, or just sw interrupts you can drop in the command stream? That would let you sleep waiting for them (rather than spinning, a win in itself) and you wouldn't have to hold the hardware lock. -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
--- Thomas Hellström [EMAIL PROTECTED] wrote: Keith Whitwell wrote: The typical case here: I want a DRI client to flip a video frame to screen, using a hardware entity called the HQV. This is a rather time critical operation. To do this I have to take the hardware lock. While this is happening, another thread is waiting for the mpeg decoder to complete a frame. To to that, this thread needs to take the hardware lock, wait for quiescent DMA, and then wait for the mpeg decoder to signal idle. It might be that the DMA command queue does not even contain mpeg data. This waiting delays the frame flip enough to create a visible jump in the video. With multiple locks: The first thread checks the HQV lock, it is available and frame flipping is done immediately. The other thread meanwhile takes the MPEG engine lock, waits until the DMA engine has processed all MPEG commands in the command queue and then waits for the MPEG engine to be idle. DMA might still be processing 3D commands. Only while submitting command buffer data. This will hopefully be a very fast operation. The IOCTL copying this data to the ringbuffer will check that all locks are held for the hardware entities that the submitted command batch touches. The user will have to tell the IOCTL which entities these are, or possibly the command verifier checks this but I consider that an overkill since that is more of a bug-check than a security check. Part of security is making sure authorised users can't make changes to other users tasks. In this case killing all the tasks, by causing a hardware fault, is a good example. It's a fackt that any user with rights to the DRM device can use any other code or program to play with the card or send junk into the cmd streem. The DRM should detect and prevent this, even if it means a slight proformance loss. Can I get an AMEN? __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
--- Thomas Hellström [EMAIL PROTECTED] wrote: Keith Whitwell wrote: The typical case here: I want a DRI client to flip a video frame to screen, using a hardware entity called the HQV. This is a rather time critical operation. To do this I have to take the hardware lock. While this is happening, another thread is waiting for the mpeg decoder to complete a frame. To to that, this thread needs to take the hardware lock, wait for quiescent DMA, and then wait for the mpeg decoder to signal idle. It might be that the DMA command queue does not even contain mpeg data. This waiting delays the frame flip enough to create a visible jump in the video. With multiple locks: The first thread checks the HQV lock, it is available and frame flipping is done immediately. The other thread meanwhile takes the MPEG engine lock, waits until the DMA engine has processed all MPEG commands in the command queue and then waits for the MPEG engine to be idle. DMA might still be processing 3D commands. Only while submitting command buffer data. This will hopefully be a very fast operation. The IOCTL copying this data to the ringbuffer will check that all locks are held for the hardware entities that the submitted command batch touches. The user will have to tell the IOCTL which entities these are, or possibly the command verifier checks this but I consider that an overkill since that is more of a bug-check than a security check. Part of security is making sure authorised users can't make changes to other users tasks. In this case killing all the tasks, by causing a hardware fault, is a good example. It's a fackt that any user with rights to the DRM device can use any other code or program to play with the card or send junk into the cmd streem. The DRM should detect and prevent this, even if it means a slight proformance loss. Can I get an AMEN? You are probably right, and it would be quite easy to implement such checks in the via command verifier as long as each lock is associated with a certain hardware address range. However, I don't quite see the point in plugging such a security hole when there are a similar ways to accomplish DOS, hardware crashes and even complete lockups using DRI. On via, for example, writing random data to the framebuffer, writing random data to the sarea, taking the hardware lock and sleeping for an indefinite amount of time. Writing certain data sequences to the HQV locks the north bridge etc. Seems like DRI allow authorized clients to do these things by design? /Thomas __ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Multiple hardware locks
On Sun, 2004-10-31 at 13:18, Thomas Hellström wrote: Keith Whitwell wrote: Thomas Hellström wrote: Hi, list! With display cards that have more and more hardware on them, (TV-capture, mpeg decoders) etc. that can work independently of oneanother, but share the same DMA engine I've find the need for more than one hardware lock. The first question is - have you found that lock contention is actually a problem? I've done a simple implementation for the mpeg decoder of the via driver, but that one doesn't cover the DMA case. The question arises Why should I need to wait for DMA quiescent to check whether the decoder is done with a frame, if there is no decoder data in any of the pending DMA buffers? But this question isn't really answered by having multiple locks - it sounds more like you want some sort of IRQ notification or timestamping mechanism. Under normal circumstances grabbing the lock doesn't mean waiting for DMA quiescence. The typical case here: I want a DRI client to flip a video frame to screen, using a hardware entity called the HQV. This is a rather time critical operation. To do this I have to take the hardware lock. While this is happening, another thread is waiting for the mpeg decoder to complete a frame. To to that, this thread needs to take the hardware lock, wait for quiescent DMA, and then wait for the mpeg decoder to signal idle. It might be that the DMA command queue does not even contain mpeg data. This waiting delays the frame flip enough to create a visible jump in the video. With multiple locks: The first thread checks the HQV lock, it is available and frame flipping is done immediately. The other thread meanwhile takes the MPEG engine lock, waits until the DMA engine has processed all MPEG commands in the command queue and then waits for the MPEG engine to be idle. DMA might still be processing 3D commands. Do you not have interrupts that either signal MPEG engine idle, or just sw interrupts you can drop in the command stream? That would let you sleep waiting for them (rather than spinning, a win in itself) and you wouldn't have to hold the hardware lock. You're right. Unfortunately the MPEG interrupt is not functioning on the CLE266 (HW bug according to VIA). Also there doesn't seem to be a SW command stream interrupt either. Not even a command stream completion interrupt. /Thomas -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 1735] SAVAGEDRIMoveBuffers not implemented
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://freedesktop.org/bugzilla/show_bug.cgi?id=1735 --- Additional Comments From [EMAIL PROTECTED] 2004-10-31 20:51 --- Owen, the savage DRI is still very much a work in progress. it works for the most part, but a lot of it still needs work, as you can see :) There's a reason it's disabled by default. Feel free to submit patches. -- Configure bugmail: https://freedesktop.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
