Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
Martin Spott wrote: "Matt Sealey" <[EMAIL PROTECTED]> wrote: I'm sure that MPlayer or Xine actually support an OpenGL output plugin already. Chances are it's Xine, but I haven't touched it in 6 months, maybe they removed it? I believe it's still there. Before propagating the use of 'new' API's in Xinre for example please remember that this software was designed to run on other platforms, too, that don't know anything of MESA (IRIX for example). Um.. IRIX doesn't have OpenGL now? That's not what I was claiming. People where talking about 'MESA_ycbcr_texture' which I was referring to (see my posting), Typically it's pretty easy to write GL programs to not rely on given extensions being present. The GL extension mechanism makes this fairly painless. And as the fallback paths are already in place, I can't see it being much of a problem. Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
Matt Sealey wrote: I'm sure that MPlayer or Xine actually support an OpenGL output plugin already. Chances are it's Xine, but I haven't touched it in 6 months, maybe they removed it? I believe it's still there. Before propagating the use of 'new' API's in Xinre for example please remember that this software was designed to run on other platforms, too, that don't know anything of MESA (IRIX for example). *Lots* of platforms support NV_texture_rectangle or EXT_texture_rectangle. Lots of platforms also support some form of YUV textures. You have SGI_ycrcb, APPLE_ycbcr, NVX_ycbcr, and MESA_ycbcr_texture from which to choose. Variety is the spice of life, afterall! :) Um.. IRIX doesn't have OpenGL now? That's certainly news to me, and probably to SGI too :) Of course it has OpenGL. What it doesn't have is any of the Mesa-specific extensions (such as MESA_ycbcr_texture). --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
"Matt Sealey" <[EMAIL PROTECTED]> wrote: >> > I'm sure that MPlayer or Xine actually support an OpenGL output >> > plugin already. Chances are it's Xine, but I haven't touched it in >> > 6 months, maybe they removed it? >> >> I believe it's still there. Before propagating the use of 'new' API's in >> Xinre for example please remember that this software was designed to run on >> other platforms, too, that don't know anything of MESA (IRIX for example). > Um.. > IRIX doesn't have OpenGL now? That's not what I was claiming. People where talking about 'MESA_ycbcr_texture' which I was referring to (see my posting), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
Alex Deucher wrote: Gabucino, Do you know if either plugin uses MESA_ycbcr_texture? this would avoid the need for you to convert YUV data to RGB in order to render it as a texture. Should speed things up of OGL. when I looked at the xine plugin source, it did not support this. For systems that do not support the extension, you could always fall back to RGB. As Ian mentioned, some of the other extensions coming down the pike will also help performance: APPLE_client_storage and such... http://mesa3d.sourceforge.net/MESA_ycbcr_texture.spec http://oss.sgi.com/projects/ogl-sample/registry/APPLE/client_storage.txt http://oss.sgi.com/projects/ogl-sample/registry/APPLE/fence.txt I've just been looking at the one in Xine, and it just uses plain RGB square textures. Keith --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
Gabucino, Do you know if either plugin uses MESA_ycbcr_texture? this would avoid the need for you to convert YUV data to RGB in order to render it as a texture. Should speed things up of OGL. when I looked at the xine plugin source, it did not support this. For systems that do not support the extension, you could always fall back to RGB. As Ian mentioned, some of the other extensions coming down the pike will also help performance: APPLE_client_storage and such... http://mesa3d.sourceforge.net/MESA_ycbcr_texture.spec http://oss.sgi.com/projects/ogl-sample/registry/APPLE/client_storage.txt http://oss.sgi.com/projects/ogl-sample/registry/APPLE/fence.txt Alex -- Matt Sealey wrote: > I'm sure that MPlayer or Xine actually support an OpenGL output > plugin already. Chances are it's Xine, but I haven't touched it in > 6 months, maybe they removed it? Both players have OpenGL output. MPlayer actually has two different ones, for each is faster than the other, on specific hardware. (-vo gl/gl2) > All I remember is that it was terribly slow to output to a YUV or > RGB texture and use OpenGL to display it. Whatever app was playing > the movie etc. did a lot better when it used plain ordinary writing > to pixmaps and blitting them to the window. Yes, it's unusable.. However it's good for SGI workstations with no xv, but fast 3D. --=20 Gabucino MPlayer Core Team __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Martin Spott > Sent: Thursday, June 05, 2003 10:21 AM > To: [EMAIL PROTECTED] > Subject: Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture > > > "Matt Sealey" <[EMAIL PROTECTED]> wrote: > > > I'm sure that MPlayer or Xine actually support an OpenGL output > > plugin already. Chances are it's Xine, but I haven't touched it in > > 6 months, maybe they removed it? > > I believe it's still there. Before propagating the use of 'new' API's in > Xinre for example please remember that this software was designed to run on > other platforms, too, that don't know anything of MESA (IRIX for example). Um.. IRIX doesn't have OpenGL now? That's certainly news to me, and probably to SGI too :) -- Matt Sealey <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
"Matt Sealey" <[EMAIL PROTECTED]> wrote: > I'm sure that MPlayer or Xine actually support an OpenGL output > plugin already. Chances are it's Xine, but I haven't touched it in > 6 months, maybe they removed it? I believe it's still there. Before propagating the use of 'new' API's in Xinre for example please remember that this software was designed to run on other platforms, too, that don't know anything of MESA (IRIX for example). Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
Matt Sealey wrote: > I'm sure that MPlayer or Xine actually support an OpenGL output > plugin already. Chances are it's Xine, but I haven't touched it in > 6 months, maybe they removed it? Both players have OpenGL output. MPlayer actually has two different ones, for each is faster than the other, on specific hardware. (-vo gl/gl2) > All I remember is that it was terribly slow to output to a YUV or > RGB texture and use OpenGL to display it. Whatever app was playing > the movie etc. did a lot better when it used plain ordinary writing > to pixmaps and blitting them to the window. Yes, it's unusable.. However it's good for SGI workstations with no xv, but fast 3D. -- Gabucino MPlayer Core Team pgp0.pgp Description: PGP signature
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
That's because, like a said earlier, the OGL output plugins convert the YUV to RGB in software and then displays it as an RGB texture. none of the plugins I've looked at use MESA_ycbcr_texture for YUV textures. Alex - > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Michel Dänzer > Sent: Tuesday, June 03, 2003 12:42 AM > To: Alex Deucher > Cc: Keith Whitwell; [EMAIL PROTECTED] > Subject: Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture > > > On Tue, 2003-06-03 at 00:09, Alex Deucher wrote: > > perhaps it would be better to just write opengl output plugins for > > video applications that used MESA_ycbcr_texture. > > I think so, e.g. you lose direct rendering by putting this into the > server. I'm sure that MPlayer or Xine actually support an OpenGL output plugin already. Chances are it's Xine, but I haven't touched it in 6 months, maybe they removed it? All I remember is that it was terribly slow to output to a YUV or RGB texture and use OpenGL to display it. Whatever app was playing the movie etc. did a lot better when it used plain ordinary writing to pixmaps and blitting them to the window. -- Matt Sealey <[EMAIL PROTECTED]> __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
Matt Sealey wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Michel Dänzer Sent: Tuesday, June 03, 2003 12:42 AM To: Alex Deucher Cc: Keith Whitwell; [EMAIL PROTECTED] Subject: Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture On Tue, 2003-06-03 at 00:09, Alex Deucher wrote: perhaps it would be better to just write opengl output plugins for video applications that used MESA_ycbcr_texture. I think so, e.g. you lose direct rendering by putting this into the server. I'm sure that MPlayer or Xine actually support an OpenGL output plugin already. Chances are it's Xine, but I haven't touched it in 6 months, maybe they removed it? All I remember is that it was terribly slow to output to a YUV or RGB texture and use OpenGL to display it. Whatever app was playing the movie etc. did a lot better when it used plain ordinary writing to pixmaps and blitting them to the window. That can probably be fixed with little effort. There have been a few people using DRI drivers with video in mind, so the paths to do this efficiently are looking a bit clearer these days. Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Michel Dänzer > Sent: Tuesday, June 03, 2003 12:42 AM > To: Alex Deucher > Cc: Keith Whitwell; [EMAIL PROTECTED] > Subject: Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture > > > On Tue, 2003-06-03 at 00:09, Alex Deucher wrote: > > perhaps it would be better to just write opengl output plugins for > > video applications that used MESA_ycbcr_texture. > > I think so, e.g. you lose direct rendering by putting this into the > server. I'm sure that MPlayer or Xine actually support an OpenGL output plugin already. Chances are it's Xine, but I haven't touched it in 6 months, maybe they removed it? All I remember is that it was terribly slow to output to a YUV or RGB texture and use OpenGL to display it. Whatever app was playing the movie etc. did a lot better when it used plain ordinary writing to pixmaps and blitting them to the window. -- Matt Sealey <[EMAIL PROTECTED]> --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
Alex Deucher wrote: I've been thinking of trying to implement an XV adapter using OpenGL and MESA_ycbcr_texture for YUV or regular RGB textures for RGB video. This would not only provide a default Xv adapter (in the event that the hw didn't have one) or it would provide hw accelerated video playback on hw that supports the appropriate OGL extensions. You would also not be limited to a single window like most hardware that only provides a single overlay. I mentioned this a while back, but I hadn't had much time to think about it. I'm new to openGL so I'm still trying to figure out what all would be involved. From what I've read traditional openGL textures have to be a power of 2 and be RGB. MESA_ycbcr_texture seems to handle the YUV colorspace, and it perhaps NV_texture_rectangle allows you to get around the power of 2 issue. Am I even on the right track here? As a side note, it's interesting that this comes up now in dri-devel while a similar discussion is happening in [EMAIL PROTECTED] (the subject is "RFC: OpenGL + XvMC"). You're totally on the right track. However, there's one GL extension you've forgotten about that makes your job almost a no-op: APPLE_client_storage. It isn't very well supported right now, but with some improvements to Mesa and a few of the DRI drivers, we could make it 1st class. The idea is the app captures a frame to memory "somewhere." The app then specifies a pixel packing of GL_UNPACK_CLIENT_STORAGE_APPLE. The Mesa part of the driver then keeps to pointer specified to glTexImage, glDrawPixels, etc. When the device specific part of the driver gets the pointer it does one of several things depending on where the data is. 1. If the data is in video memory (like on a VIVO card), it does a blit to copy the buffer. 2. If the data is in AGP memory, it does a normal texture upload to video memory or uses AGP texturing. 3. If the data isn't any video or AGP memory, it uploads it just like any other texture / pixel data. There are two problems. As near as I can tell, the support for APPLE_client_storage isn't complete enough to handle all this. The other problem is there isn't a synchronization mechanism available so that apps know when they can touch their memory (i.e., NV_fence or APPLE_fence). Technically speaking, there is no reason why any driver shouldn't expose this extension. Why force Mesa to have a copy of the image when the application already has one? There is some trickery involved. The application would have to supply the image data in *exactly* the right format that the driver could use, and there are probably one or two other corner cases. Somewhere around line 848 in texstore.c (current Mesa CVS, in _mesa_store_teximage2d), there should be a check to determine if and match the internal format set ChooseTextureFormat *exactly*. If it's a perfect match, it should keep the pointer and set texImage->IsClientData. Then most of r200ValidateClientStorage would go away (it would actually be moved to _mesa_store_teximage2d & co.), and the rest of it wouldn't happen until uploadSubImage time. There may also be some endianness issues, but I'd have to think about it more. Anyway, that's just my thought on the matter. :) http://oss.sgi.com/projects/ogl-sample/registry/APPLE/client_storage.txt http://oss.sgi.com/projects/ogl-sample/registry/APPLE/fence.txt http://oss.sgi.com/projects/ogl-sample/registry/NV/fence.txt --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
On Tue, 2003-06-03 at 00:09, Alex Deucher wrote: > perhaps it would be better to just write opengl output plugins for > video applications that used MESA_ycbcr_texture. I think so, e.g. you lose direct rendering by putting this into the server. > However, looking at the code for several video apps, most that have an > OGL output still use RGB textures with the the YUV->RGB conversion done > in software. Add support for this to SDL and support for SDL to apps that still don't have it? -- Earthling Michel Dänzer \ Debian (powerpc), XFree86 and DRI developer Software libre enthusiast \ http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
whoops... I meant to replay to all... --- Keith Whitwell <[EMAIL PROTECTED]> wrote: > > Not sure I quite understand you - but definitely changing those apps > to use > the Mesa extension (if available) would be a win. They convert the YUV frames to RGB in software and then display them as OGL textures. > > I'm not quite sure why you expressed a desire elsewhere to make the > video > stuff an xfree module - I'd have thought a library or plugin to > existing > library would make more sense. I just figured it would easier for end users since A LOT of applications support Xv already and since there is no software Xv implementation, it would provide that as well, but if the complications of doing it outweighs the value, then it might not be worth the effort. Plus I'm still pretty new to graphics programming so what seems like a good idea at first isn't always ;) Alex __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
Alex Deucher wrote: perhaps it would be better to just write opengl output plugins for video applications that used MESA_ycbcr_texture. However, looking at the code for several video apps, most that have an OGL output still use RGB textures with the the YUV->RGB conversion done in software. Not sure I quite understand you - but definitely changing those apps to use the Mesa extension (if available) would be a win. I'm not quite sure why you expressed a desire elsewhere to make the video stuff an xfree module - I'd have thought a library or plugin to existing library would make more sense. Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
perhaps it would be better to just write opengl output plugins for video applications that used MESA_ycbcr_texture. However, looking at the code for several video apps, most that have an OGL output still use RGB textures with the the YUV->RGB conversion done in software. Alex --- Keith Whitwell <[EMAIL PROTECTED]> wrote: > > Hmm - maybe... You'll probably run into some issues with the locking > > mechanism used by the DRI drivers - the X server currently holds the > lock all > the time it is active, so you'd have to release the lock before > calling into > any GL functions, which is loosing some of the cleanness you get by > using GL. > > > Unfortunately, i'm more familiar with the 2D aspects of xfree86. > I'm > > still learning about opengl programming and the 3D side of the > > hardware. > > I need to decide how to best map the Xv functions to their OGL > > implementation. An comments on the feasibility of this or how I > would > > best proceed are welcome. > > The GLX_NV_vertex_array_range allows GL clients to be allocated > actual AGP > memory, which will speed up texture uploads in the R200 driver if you > do > *everything* right. Note - this is only r200 at this stage. > > Keith > __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
Alex Deucher wrote: I've been thinking of trying to implement an XV adapter using OpenGL and MESA_ycbcr_texture for YUV or regular RGB textures for RGB video. This would not only provide a default Xv adapter (in the event that the hw didn't have one) or it would provide hw accelerated video playback on hw that supports the appropriate OGL extensions. You would also not be limited to a single window like most hardware that only provides a single overlay. I mentioned this a while back, but I hadn't had much time to think about it. I'm new to openGL so I'm still trying to figure out what all would be involved. From what I've read traditional openGL textures have to be a power of 2 and be RGB. MESA_ycbcr_texture seems to handle the YUV colorspace, and it perhaps NV_texture_rectangle allows you to get around the power of 2 issue. Am I even on the right track here? Absolutely. It would be written as an xfree86 modules like "v4l." The module would then accept data from Xv clients but rather than writing the data to the overlay hardware, it would act like an openGL client and write the data to the screen using an RGB or YUV texture. The question is, can an xfree86 module be an opengl/DRI client? Hmm - maybe... You'll probably run into some issues with the locking mechanism used by the DRI drivers - the X server currently holds the lock all the time it is active, so you'd have to release the lock before calling into any GL functions, which is loosing some of the cleanness you get by using GL. Unfortunately, i'm more familiar with the 2D aspects of xfree86. I'm still learning about opengl programming and the 3D side of the hardware. I need to decide how to best map the Xv functions to their OGL implementation. An comments on the feasibility of this or how I would best proceed are welcome. The GLX_NV_vertex_array_range allows GL clients to be allocated actual AGP memory, which will speed up texture uploads in the R200 driver if you do *everything* right. Note - this is only r200 at this stage. Keith --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [RFC] New Xv adapter using MESA_ycbcr_texture
I've been thinking of trying to implement an XV adapter using OpenGL and MESA_ycbcr_texture for YUV or regular RGB textures for RGB video. This would not only provide a default Xv adapter (in the event that the hw didn't have one) or it would provide hw accelerated video playback on hw that supports the appropriate OGL extensions. You would also not be limited to a single window like most hardware that only provides a single overlay. I mentioned this a while back, but I hadn't had much time to think about it. I'm new to openGL so I'm still trying to figure out what all would be involved. From what I've read traditional openGL textures have to be a power of 2 and be RGB. MESA_ycbcr_texture seems to handle the YUV colorspace, and it perhaps NV_texture_rectangle allows you to get around the power of 2 issue. Am I even on the right track here? It would be written as an xfree86 modules like "v4l." The module would then accept data from Xv clients but rather than writing the data to the overlay hardware, it would act like an openGL client and write the data to the screen using an RGB or YUV texture. The question is, can an xfree86 module be an opengl/DRI client? Unfortunately, i'm more familiar with the 2D aspects of xfree86. I'm still learning about opengl programming and the 3D side of the hardware. I need to decide how to best map the Xv functions to their OGL implementation. An comments on the feasibility of this or how I would best proceed are welcome. Thanks, Alex __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
