Jon Smirl has written,
> I've written an article that surveys the current State of Linux
> graphics and proposes a possible path forward. This is a long article
> containing a lot of detailed technical information as a guide to
> future developers. Skip over the detailed parts if they aren't
>
Jon Smirl has written,
I've written an article that surveys the current State of Linux
graphics and proposes a possible path forward. This is a long article
containing a lot of detailed technical information as a guide to
future developers. Skip over the detailed parts if they aren't
svgalib is spelled "svgalib"
I have started writing a windowing program which
uses svgalib. The source code is available at,
http://sourceforge.net/projects/svgalib-windows
select "browse cvs". SourceForge is rebuilding their
site, so some things don't work.
On Thu, September 1, 2005 4:38 pm, Jon Smirl said:
> We're not putting all of our eggs in one basket, you keep forgetting
> that we already have a server that supports all of the currently
> existing hardware. The question is where do we want to put our future
> eggs.
Amen! All these arguments
On 9/1/05, Jim Gettys <[EMAIL PROTECTED]> wrote:
> Not at all.
>
> We're pursuing two courses of action right now, that are not mutually
> exclusive.
>
> Jon Smirl's argument is that we can satisfy both needs simultaneously
> with a GL only strategy, and that doing two is counter productive,
>
On Wed, Aug 31, 2005 at 08:59:23PM -0700, Keith Packard wrote:
|
| Yeah, two systems, but (I hope) only one used for each card. So far, I'm
| not sure of the value of attempting to provide a mostly-software GL
| implementation in place of existing X drivers.
For the short term it's valuable for
Not at all.
We're pursuing two courses of action right now, that are not mutually
exclusive.
Jon Smirl's argument is that we can satisfy both needs simultaneously
with a GL only strategy, and that doing two is counter productive,
primarily on available resource grounds.
My point is that I don't
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
It's other (non-orientation) texture state I had in mind:
- the texel format (OpenGL has over 30 possible texture formats).
- texture size and borders
- the filtering mode (linear, nearest, etc)
- coordinate
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
> It's other (non-orientation) texture state I had in mind:
>
> - the texel format (OpenGL has over 30 possible texture formats).
> - texture size and borders
> - the filtering mode (linear, nearest, etc)
> - coordinate wrap mode
jg wrote @ Thu, 01 Sep 2005 11:59:33 -0400:
> Legacy hardware and that being proposed/built for the developing world
> is tougher; we have code in hand for existing chips, and the price point
> is even well below cell phones on those devices. They don't have
> anything beyond basic blit and,
Alan Cox wrote:
On Iau, 2005-09-01 at 09:24 -0600, Brian Paul wrote:
If the blending is for screen-aligned rects, glDrawPixels would be a
far easier path to optimize than texturing. The number of state
combinations related to texturing is pretty overwhelming.
As doom showed however once
On Thu, 2005-09-01 at 09:24 -0600, Brian Paul wrote:
>
> If the blending is for screen-aligned rects, glDrawPixels would be a
> far easier path to optimize than texturing. The number of state
> combinations related to texturing is pretty overwhelming.
>
>
> Anyway, I think we're all in
On Iau, 2005-09-01 at 09:24 -0600, Brian Paul wrote:
> If the blending is for screen-aligned rects, glDrawPixels would be a
> far easier path to optimize than texturing. The number of state
> combinations related to texturing is pretty overwhelming.
As doom showed however once you can cut down
Just a few comments...
Keith Packard wrote:
Again, the question is whether a mostly-software OpenGL implementation
can effectively compete against the simple X+Render graphics model for
basic 2D application operations, and whether there are people interested
in even trying to make this happen.
On 9/1/05, Alan Cox <[EMAIL PROTECTED]> wrote:
> On Iau, 2005-09-01 at 08:00 +0200, Antonio Vargas wrote:
> > 2. whole screen z-buffer, for depth comparison between the pixels
> > generated from each window.
>
> That one I question in part - if the rectangles are (as is typically the
> case)
On Iau, 2005-09-01 at 08:00 +0200, Antonio Vargas wrote:
> 2. whole screen z-buffer, for depth comparison between the pixels
> generated from each window.
That one I question in part - if the rectangles are (as is typically the
case) large then the Z buffer just ups the memory accesses. I guess
On Wed, Aug 31, 2005 at 08:11:12PM -0700, Ian Romanick wrote:
| Allen Akin wrote:
| > Jon's right about this: If you can accelerate a given simple function
| > (blending, say) for a 2D driver, you can accelerate that same function
| > in a Mesa driver for a comparable amount of effort, and
On 9/1/05, Ian Romanick <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Allen Akin wrote:
> > On Wed, Aug 31, 2005 at 02:06:54PM -0700, Keith Packard wrote:
> > |
> > | ...So far, 3D driver work has proceeded almost entirely on the
> > | newest documented
On 9/1/05, Ian Romanick [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Allen Akin wrote:
On Wed, Aug 31, 2005 at 02:06:54PM -0700, Keith Packard wrote:
|
| ...So far, 3D driver work has proceeded almost entirely on the
| newest documented hardware that
On Wed, Aug 31, 2005 at 08:11:12PM -0700, Ian Romanick wrote:
| Allen Akin wrote:
| Jon's right about this: If you can accelerate a given simple function
| (blending, say) for a 2D driver, you can accelerate that same function
| in a Mesa driver for a comparable amount of effort, and deliver a
On Iau, 2005-09-01 at 08:00 +0200, Antonio Vargas wrote:
2. whole screen z-buffer, for depth comparison between the pixels
generated from each window.
That one I question in part - if the rectangles are (as is typically the
case) large then the Z buffer just ups the memory accesses. I guess for
On 9/1/05, Alan Cox [EMAIL PROTECTED] wrote:
On Iau, 2005-09-01 at 08:00 +0200, Antonio Vargas wrote:
2. whole screen z-buffer, for depth comparison between the pixels
generated from each window.
That one I question in part - if the rectangles are (as is typically the
case) large then the
Just a few comments...
Keith Packard wrote:
Again, the question is whether a mostly-software OpenGL implementation
can effectively compete against the simple X+Render graphics model for
basic 2D application operations, and whether there are people interested
in even trying to make this happen.
On Iau, 2005-09-01 at 09:24 -0600, Brian Paul wrote:
If the blending is for screen-aligned rects, glDrawPixels would be a
far easier path to optimize than texturing. The number of state
combinations related to texturing is pretty overwhelming.
As doom showed however once you can cut down
On Thu, 2005-09-01 at 09:24 -0600, Brian Paul wrote:
If the blending is for screen-aligned rects, glDrawPixels would be a
far easier path to optimize than texturing. The number of state
combinations related to texturing is pretty overwhelming.
Anyway, I think we're all in agreement
Alan Cox wrote:
On Iau, 2005-09-01 at 09:24 -0600, Brian Paul wrote:
If the blending is for screen-aligned rects, glDrawPixels would be a
far easier path to optimize than texturing. The number of state
combinations related to texturing is pretty overwhelming.
As doom showed however once
jg wrote @ Thu, 01 Sep 2005 11:59:33 -0400:
Legacy hardware and that being proposed/built for the developing world
is tougher; we have code in hand for existing chips, and the price point
is even well below cell phones on those devices. They don't have
anything beyond basic blit and, miracles
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
It's other (non-orientation) texture state I had in mind:
- the texel format (OpenGL has over 30 possible texture formats).
- texture size and borders
- the filtering mode (linear, nearest, etc)
- coordinate wrap mode (clamp,
Ian Romanick wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Brian Paul wrote:
It's other (non-orientation) texture state I had in mind:
- the texel format (OpenGL has over 30 possible texture formats).
- texture size and borders
- the filtering mode (linear, nearest, etc)
- coordinate
Not at all.
We're pursuing two courses of action right now, that are not mutually
exclusive.
Jon Smirl's argument is that we can satisfy both needs simultaneously
with a GL only strategy, and that doing two is counter productive,
primarily on available resource grounds.
My point is that I don't
On Wed, Aug 31, 2005 at 08:59:23PM -0700, Keith Packard wrote:
|
| Yeah, two systems, but (I hope) only one used for each card. So far, I'm
| not sure of the value of attempting to provide a mostly-software GL
| implementation in place of existing X drivers.
For the short term it's valuable for
On 9/1/05, Jim Gettys [EMAIL PROTECTED] wrote:
Not at all.
We're pursuing two courses of action right now, that are not mutually
exclusive.
Jon Smirl's argument is that we can satisfy both needs simultaneously
with a GL only strategy, and that doing two is counter productive,
primarily
On Thu, September 1, 2005 4:38 pm, Jon Smirl said:
We're not putting all of our eggs in one basket, you keep forgetting
that we already have a server that supports all of the currently
existing hardware. The question is where do we want to put our future
eggs.
Amen! All these arguments
svgalib is spelled svgalib
I have started writing a windowing program which
uses svgalib. The source code is available at,
http://sourceforge.net/projects/svgalib-windows
select browse cvs. SourceForge is rebuilding their
site, so some things don't work.
On Wed, 2005-08-31 at 18:58 -0700, Allen Akin wrote:
> On Wed, Aug 31, 2005 at 02:06:54PM -0700, Keith Packard wrote:
> | On Wed, 2005-08-31 at 13:06 -0700, Allen Akin wrote:
> | > ...
> |
> | Right, the goal is to have only one driver for the hardware, whether an
> | X server for simple 2D only
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Allen Akin wrote:
> On Wed, Aug 31, 2005 at 02:06:54PM -0700, Keith Packard wrote:
> |
> | ...So far, 3D driver work has proceeded almost entirely on the
> | newest documented hardware that people could get. Going back and
> | spending months
On Wed, Aug 31, 2005 at 02:06:54PM -0700, Keith Packard wrote:
| On Wed, 2005-08-31 at 13:06 -0700, Allen Akin wrote:
| > ...
|
| Right, the goal is to have only one driver for the hardware, whether an
| X server for simple 2D only environments or a GL driver for 2D/3D
| environments. ...
I
> "Ian" == Ian Romanick <[EMAIL PROTECTED]> writes:
Ian> I'd really like to see a list of areas where OpenGL
Ian> isn't up to snuff for 2D operations.
Is that OpenVR spec from Khronos a reasonable baseline
for such a list?
-JimC
--
James H. Cloos, Jr. <[EMAIL PROTECTED]>
-
To unsubscribe
On Wed, 2005-08-31 at 13:06 -0700, Allen Akin wrote:
> On Wed, Aug 31, 2005 at 11:29:30AM -0700, Keith Packard wrote:
> | The real goal is to provide a good programming environment for 2D
> | applications, not to push some particular low-level graphics library.
>
> I think that's a reasonable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Allen Akin wrote:
> I believe we're doing well with layered implementation strategies like
> Xgl and Glitz. Where we might do better is in (1) extending OpenGL to
> provide missing functionality, rather than creating peer low-level APIs;
> (2)
On Wed, Aug 31, 2005 at 11:29:30AM -0700, Keith Packard wrote:
| The real goal is to provide a good programming environment for 2D
| applications, not to push some particular low-level graphics library.
I think that's a reasonable goal.
My red flag goes up at the point where the 2D programming
Well, I'm sure you'll keep us honest... ;-).
- Jim
On Wed, 2005-08-31 at 12:06 -0700, Allen Akin wrote:
> On Wed, Aug 31, 2005 at 01:48:11PM -0400, Jim Gettys wrote:
> | Certainly replicating OpenGL 2.0's programmability through Render makes
> | no sense at all to me (or most
On Wed, Aug 31, 2005 at 01:48:11PM -0400, Jim Gettys wrote:
| Certainly replicating OpenGL 2.0's programmability through Render makes
| no sense at all to me (or most others, I believe/hope). If you want to
| use full use of the GPU, I'm happy to say you should be using OpenGL.
When expressed
On Tue, 2005-08-30 at 23:33 -0700, Allen Akin wrote:
> On Tue, Aug 30, 2005 at 01:26:53PM -0400, David Reveman wrote:
> | On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> | > In general, the whole concept of programmable graphics hardware is
> | > not addressed in APIs like xlib and Cairo.
On 8/31/05, Jim Gettys <[EMAIL PROTECTED]> wrote:
> Certainly replicating OpenGL 2.0's programmability through Render makes
> no sense at all to me (or most others, I believe/hope). If you want to
> use full use of the GPU, I'm happy to say you should be using OpenGL.
>
Certainly replicating OpenGL 2.0's programmability through Render makes
no sense at all to me (or most others, I believe/hope). If you want to
use full use of the GPU, I'm happy to say you should be using OpenGL.
- Jim
On Tue, 2005-08-30 at 23:33 -0700, Allen
On Tue, 2005-08-30 at 23:33 -0700, Allen Akin wrote:
> On Tue, Aug 30, 2005 at 01:26:53PM -0400, David Reveman wrote:
> | On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> | > In general, the whole concept of programmable graphics hardware is
> | > not addressed in APIs like xlib and Cairo.
On 8/31/05, Eric Anholt <[EMAIL PROTECTED]> wrote:
> the X Render extension." No, EXA is a different acceleration
> architecture making different basic design decisions related to memory
> management and driver API.
I did start the EXA section off with this: "EXA replaces the existing
2D XAA
i have no freaking idea of coding. but going throught this "Discuss
issues related to the xorg tree" talk, made me feel and say "mommy
(coder), daddy (admin), please dont fight you tearing
us(users) apart."
glad its worked out.. all i hope is we(users) , now , get some nice
fast xorg :D.
On Tue, Aug 30, 2005 at 01:26:53PM -0400, David Reveman wrote:
| On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
| > In general, the whole concept of programmable graphics hardware is
| > not addressed in APIs like xlib and Cairo. This is a very important
| > point. A major new GPU feature,
On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> I've written an article that surveys the current State of Linux
> graphics and proposes a possible path forward. This is a long article
> containing a lot of detailed technical information as a guide to
> future developers. Skip over the
On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
I've written an article that surveys the current State of Linux
graphics and proposes a possible path forward. This is a long article
containing a lot of detailed technical information as a guide to
future developers. Skip over the detailed
On Tue, Aug 30, 2005 at 01:26:53PM -0400, David Reveman wrote:
| On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
| In general, the whole concept of programmable graphics hardware is
| not addressed in APIs like xlib and Cairo. This is a very important
| point. A major new GPU feature,
i have no freaking idea of coding. but going throught this Discuss
issues related to the xorg tree talk, made me feel and say mommy
(coder), daddy (admin), please dont fight you tearing
us(users) apart.
glad its worked out.. all i hope is we(users) , now , get some nice
fast xorg :D.
On 8/31/05, Eric Anholt [EMAIL PROTECTED] wrote:
the X Render extension. No, EXA is a different acceleration
architecture making different basic design decisions related to memory
management and driver API.
I did start the EXA section off with this: EXA replaces the existing
2D XAA drivers
On Tue, 2005-08-30 at 23:33 -0700, Allen Akin wrote:
On Tue, Aug 30, 2005 at 01:26:53PM -0400, David Reveman wrote:
| On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
| In general, the whole concept of programmable graphics hardware is
| not addressed in APIs like xlib and Cairo. This is
Certainly replicating OpenGL 2.0's programmability through Render makes
no sense at all to me (or most others, I believe/hope). If you want to
use full use of the GPU, I'm happy to say you should be using OpenGL.
- Jim
On Tue, 2005-08-30 at 23:33 -0700, Allen
On 8/31/05, Jim Gettys [EMAIL PROTECTED] wrote:
Certainly replicating OpenGL 2.0's programmability through Render makes
no sense at all to me (or most others, I believe/hope). If you want to
use full use of the GPU, I'm happy to say you should be using OpenGL.
On Tue, 2005-08-30 at 23:33 -0700, Allen Akin wrote:
On Tue, Aug 30, 2005 at 01:26:53PM -0400, David Reveman wrote:
| On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
| In general, the whole concept of programmable graphics hardware is
| not addressed in APIs like xlib and Cairo. This is
On Wed, Aug 31, 2005 at 01:48:11PM -0400, Jim Gettys wrote:
| Certainly replicating OpenGL 2.0's programmability through Render makes
| no sense at all to me (or most others, I believe/hope). If you want to
| use full use of the GPU, I'm happy to say you should be using OpenGL.
When expressed
Well, I'm sure you'll keep us honest... ;-).
- Jim
On Wed, 2005-08-31 at 12:06 -0700, Allen Akin wrote:
On Wed, Aug 31, 2005 at 01:48:11PM -0400, Jim Gettys wrote:
| Certainly replicating OpenGL 2.0's programmability through Render makes
| no sense at all to me (or most
On Wed, Aug 31, 2005 at 11:29:30AM -0700, Keith Packard wrote:
| The real goal is to provide a good programming environment for 2D
| applications, not to push some particular low-level graphics library.
I think that's a reasonable goal.
My red flag goes up at the point where the 2D programming
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Allen Akin wrote:
I believe we're doing well with layered implementation strategies like
Xgl and Glitz. Where we might do better is in (1) extending OpenGL to
provide missing functionality, rather than creating peer low-level APIs;
(2)
On Wed, 2005-08-31 at 13:06 -0700, Allen Akin wrote:
On Wed, Aug 31, 2005 at 11:29:30AM -0700, Keith Packard wrote:
| The real goal is to provide a good programming environment for 2D
| applications, not to push some particular low-level graphics library.
I think that's a reasonable goal.
Ian == Ian Romanick [EMAIL PROTECTED] writes:
Ian I'd really like to see a list of areas where OpenGL
Ian isn't up to snuff for 2D operations.
Is that OpenVR spec from Khronos a reasonable baseline
for such a list?
-JimC
--
James H. Cloos, Jr. [EMAIL PROTECTED]
-
To unsubscribe from this
On Wed, Aug 31, 2005 at 02:06:54PM -0700, Keith Packard wrote:
| On Wed, 2005-08-31 at 13:06 -0700, Allen Akin wrote:
| ...
|
| Right, the goal is to have only one driver for the hardware, whether an
| X server for simple 2D only environments or a GL driver for 2D/3D
| environments. ...
I count
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Allen Akin wrote:
On Wed, Aug 31, 2005 at 02:06:54PM -0700, Keith Packard wrote:
|
| ...So far, 3D driver work has proceeded almost entirely on the
| newest documented hardware that people could get. Going back and
| spending months
On Wed, 2005-08-31 at 18:58 -0700, Allen Akin wrote:
On Wed, Aug 31, 2005 at 02:06:54PM -0700, Keith Packard wrote:
| On Wed, 2005-08-31 at 13:06 -0700, Allen Akin wrote:
| ...
|
| Right, the goal is to have only one driver for the hardware, whether an
| X server for simple 2D only
Access has been restored. The URL is good again.
http://www.freedesktop.org/~jonsmirl/graphics.html
--
Jon Smirl
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Before you shut my account off I made you this offer:
On 8/31/05, Jon Smirl <[EMAIL PROTECTED]> wrote:
> Quit being a pain and write a response to the article if you don't
> like it. Censorship is not the answer. Open debate in a public format
> is the correct response. If you want me to I'll add
On 8/31/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-31 at 00:50 -0400, Jon Smirl wrote:
> > On 8/30/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
> > > 'As a whole, the X.org community barely has enough resources to build a
> > > single server. Splitting these resources over many
On 8/30/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> > The article has been reviewed but if it still contains technical
> > errors please let me know. Opinions on the content are also
> > appreciated.
>
> 'As a whole, the X.org community
On 8/30/05, Daniel Stone <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> > The article has been reviewed but if it still contains technical
> > errors please let me know. Opinions on the content are also
> > appreciated.
>
> 'As a whole, the X.org community
On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> The article has been reviewed but if it still contains technical
> errors please let me know. Opinions on the content are also
> appreciated.
'As a whole, the X.org community barely has enough resources to build a
single server. Splitting
>
> As the author of Xgl and glitz I'd like to comment on a few things.
>
> >From the article:
>
> > Xgl was designed as a near term transition solution. The Xgl model
> > was to transparently replace the drawing system of the existing
> > X server with a compatible one based on using OpenGL as
On 8/30/05, David Reveman <[EMAIL PROTECTED]> wrote:
> > Xgl was designed as a near term transition solution. The Xgl model
> > was to transparently replace the drawing system of the existing
> > X server with a compatible one based on using OpenGL as a device
> > driver. Xgl maintained all of the
On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
> I've written an article that surveys the current State of Linux
> graphics and proposes a possible path forward. This is a long article
> containing a lot of detailed technical information as a guide to
> future developers. Skip over the
On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
I've written an article that surveys the current State of Linux
graphics and proposes a possible path forward. This is a long article
containing a lot of detailed technical information as a guide to
future developers. Skip over the detailed
On 8/30/05, David Reveman [EMAIL PROTECTED] wrote:
Xgl was designed as a near term transition solution. The Xgl model
was to transparently replace the drawing system of the existing
X server with a compatible one based on using OpenGL as a device
driver. Xgl maintained all of the existing
As the author of Xgl and glitz I'd like to comment on a few things.
From the article:
Xgl was designed as a near term transition solution. The Xgl model
was to transparently replace the drawing system of the existing
X server with a compatible one based on using OpenGL as a device
On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
The article has been reviewed but if it still contains technical
errors please let me know. Opinions on the content are also
appreciated.
'As a whole, the X.org community barely has enough resources to build a
single server. Splitting these
On 8/30/05, Daniel Stone [EMAIL PROTECTED] wrote:
On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
The article has been reviewed but if it still contains technical
errors please let me know. Opinions on the content are also
appreciated.
'As a whole, the X.org community barely has
On 8/30/05, Daniel Stone [EMAIL PROTECTED] wrote:
On Tue, 2005-08-30 at 12:03 -0400, Jon Smirl wrote:
The article has been reviewed but if it still contains technical
errors please let me know. Opinions on the content are also
appreciated.
'As a whole, the X.org community barely has
On 8/31/05, Daniel Stone [EMAIL PROTECTED] wrote:
On Wed, 2005-08-31 at 00:50 -0400, Jon Smirl wrote:
On 8/30/05, Daniel Stone [EMAIL PROTECTED] wrote:
'As a whole, the X.org community barely has enough resources to build a
single server. Splitting these resources over many paths only
Before you shut my account off I made you this offer:
On 8/31/05, Jon Smirl [EMAIL PROTECTED] wrote:
Quit being a pain and write a response to the article if you don't
like it. Censorship is not the answer. Open debate in a public format
is the correct response. If you want me to I'll add your
Access has been restored. The URL is good again.
http://www.freedesktop.org/~jonsmirl/graphics.html
--
Jon Smirl
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
86 matches
Mail list logo
