The Linux GFX project grew out the need for a higher performance X
server that has a much faster developement cycle. In the last few years
the graphics card and multimedia environments have grow at such a rate
the current X solutions can no longer keep pace nor do they focus on
producing high performance X servers specifically for linux. Also the
community has demanded for specific functionality which has never come to
light.
This project looks to start from scratch to develope a new X
enviroment that addresses these issues. I posted here because we will
addressing several issues about hardware management between the kernel
and the X window enevironment. Of course the X enrvironment is extremly
broad so this will require skills from several areas as well as many
programmers. So we welcome anyone how would like to see a alternative to
the current X implemenation. If you like to subscribe to our mailing
list just follow the link below. Thank you.
http://lists.sourceforge.net/lists/listinfo/linuxgfx-dev
James Simmons writes:
> The Linux GFX project grew out the need for a higher performance X
> server that has a much faster developement cycle. In the last few years
> the graphics card and multimedia environments have grow at such a rate
> the current X solutions can no longer keep pace nor do they focus on
> producing high performance X servers specifically for linux. Also the
> community has demanded for specific functionality which has never come to
> light.
And this specific functionality is?
I think this is not a worthwhile project at all. The X tree, it's
assosciated protocols and APIs, are complicated enough as it is, and
the xfree86 project has some of the most talented and capable people
in this area. It would be a step backwards to do things outside of
xfree86 development.
If the issue is that "things don't happen fast enough in the xfree86
tree", why not lend them a hand and submitting patches to them instead
of complaining?
Later,
David S. Miller
[email protected]
* David S. Miller ([email protected]) uttered:
>
> James Simmons writes:
> > The Linux GFX project grew out the need for a higher performance X
>
> And this specific functionality is?
>
> I think this is not a worthwhile project at all. The X tree, it's
> assosciated protocols and APIs, are complicated enough as it is, and
> the xfree86 project has some of the most talented and capable people
> in this area. It would be a step backwards to do things outside of
> xfree86 development.
>
> If the issue is that "things don't happen fast enough in the xfree86
> tree", why not lend them a hand and submitting patches to them instead
> of complaining?
You see, it's people like you that actually further along projects such
as that.. "oh, it'll never work! blahblahblah!" well gee, X _has_ been
around for years....... but so's microsoft........ so we've all gotten
into this paradigm that linux is THE end solution for microsoft users...
got news for ya bud, Linux is great, it's dope, but quite frankly, if u
put all yer eggs in one basket, you become blind to everything else....
and bill gates likes that......... but WAIT! someone ELSE comes along with an
open project.... and what do you do? u take a hateful stance to it... do
we see a pattern here? you'd have to be pretty blind not to.
.oO Gnea [gnea at rochester dot rr dot com] Oo.
.oO url: http://garson.org/~gnea Oo.
"If you don't have anything useful to say, eat a fish." -unknown
"David S. Miller" wrote:
>
> James Simmons writes:
> > The Linux GFX project grew out the need for a higher performance X
> > server that has a much faster developement cycle. In the last few years
> > the graphics card and multimedia environments have grow at such a rate
> > the current X solutions can no longer keep pace nor do they focus on
> > producing high performance X servers specifically for linux. Also the
> > community has demanded for specific functionality which has never come to
> > light.
>
> And this specific functionality is?
>
> I think this is not a worthwhile project at all. The X tree, it's
> assosciated protocols and APIs, are complicated enough as it is, and
> the xfree86 project has some of the most talented and capable people
> in this area. It would be a step backwards to do things outside of
> xfree86 development.
>
> If the issue is that "things don't happen fast enough in the xfree86
> tree", why not lend them a hand and submitting patches to them instead
> of complaining?
Yes, David, I concur.
James, please just pitch in and help XFree86 evolve faster.
There are drivers that need to be "Render" extension enabled.
There's more work to do on fleshing out the Render extension.
I am sure that Kieth Packard would be grateful for any
worthwhile contributions.
If you are thinking that you'll provide better accellerated
graphics rendering performance, I'd love to know how you plan
to accomplish this. AFAIK, the main impediment to XFree86
giving really good accelleration support for a broad array
of hardware is the lack of technical documentation from the
manufacturers. Unless you plan on trying to get hardware
manufactures to have you develop their closed-source drivers
for them, I don't see how you'll be able to do any better
than the XFree86 organization is already doing.
XFree86 evolves in a measured way as a result of many
competing needs. Backward compatibility is needed for the
huge installed base of legacy apps. For the various
development toolkits (KDE, Gnome, etc.) there is a rapid
move toward using the Render and "Resize and Rotate"
extensions. These extensions will make all sorts of cool
rendering functionality available to the applications that
use these toolkits (alpha blending, anti-aliased fonts and
so on).
I'd love to hear you enumerate all the shortcomings that you
believe need to be addressed. Also, please CC: [email protected].
At least give the competition an opportunity to win over the
support of the developers you'd like to pull away from
XFree86 work!
Miles
Scott Prader wrote:
>
> * David S. Miller ([email protected]) uttered:
> >
> > James Simmons writes:
> > > The Linux GFX project grew out the need for a higher performance X
> >
> > And this specific functionality is?
> >
> > I think this is not a worthwhile project at all. The X tree, it's
> > assosciated protocols and APIs, are complicated enough as it is, and
> > the xfree86 project has some of the most talented and capable people
> > in this area. It would be a step backwards to do things outside of
> > xfree86 development.
> >
> > If the issue is that "things don't happen fast enough in the xfree86
> > tree", why not lend them a hand and submitting patches to them instead
> > of complaining?
>
> You see, it's people like you that actually further along projects such
> as that.. "oh, it'll never work! blahblahblah!" well gee, X _has_ been
> around for years....... but so's microsoft........ so we've all gotten
> into this paradigm that linux is THE end solution for microsoft users...
> got news for ya bud, Linux is great, it's dope, but quite frankly, if u
> put all yer eggs in one basket, you become blind to everything else....
> and bill gates likes that......... but WAIT! someone ELSE comes along with an
> open project.... and what do you do? u take a hateful stance to it... do
> we see a pattern here? you'd have to be pretty blind not to.
Take a chill pill, dude.
Dave's questions are perfectly valid. Obviously, if a bunch of
kick-butt programmers want to go off a create a "from-scratch"
X11 implementation, please go right ahead! If it turns out to
be great (have rock-solid support for legacy apps, have screaming
fast accellerated graphics drivers for all major hardware, support
anti-aliased fonts, alpha-blending and so on in a way that is
compatible with XFree86 APIs) then, sure, I'll switch over to the
new X Server. Of course, in the seven years that this project
will take, XFree86 will have evolved quite a bit.
I suppose the new X Server could jettison support for legacy
apps and only support applications written with the latest RAD
toolkits. There might be some value there. This might also
allow the new server to stabilize sooner.
Miles
* Miles Lane ([email protected]) uttered:
> Take a chill pill, dude.
i am quite calm. :)
> Dave's questions are perfectly valid. Obviously, if a bunch of
> kick-butt programmers want to go off a create a "from-scratch"
> X11 implementation, please go right ahead! If it turns out to
> be great (have rock-solid support for legacy apps, have screaming
> fast accellerated graphics drivers for all major hardware, support
> anti-aliased fonts, alpha-blending and so on in a way that is
> compatible with XFree86 APIs) then, sure, I'll switch over to the
> new X Server. Of course, in the seven years that this project
> will take, XFree86 will have evolved quite a bit.
So you're saying, that unless it _already_ has screaming support from
commercial hardware vendors, then everyone should just support one and
ONLY one type of X server? There are a lot of other X server projects
out there and different people go about developing them in different
ways. This whole holier-than-thou attitude about XFree86 that I'm
getting from you and David (not the rest of the XFree86 community, I
know there are bigots out there, but not everyone's a bigot) in general
tends to say to me "hm, these guys really DO have their heads stuck up
their anal cavities! amazing! and now they're trying to say that WE'RE
wrong in our own ways??" it's quite a riot, and i've enjoyed a good
chuckle - but don't get me wrong, i'm not mad at your or David
personally, however the attitudes that you appear to employ seem to
denote a dull sensitivity level around the area of delusionment of
grandeur. While you may sit there and rebute such claims, your
rebutement would only be further proof of where I am coming from and
thus we understand each other quite perfectly... of course if that is
not the case and someone is holding a gun to your head, forcing you to
make such claims, then please, feel free to express your true feelings,
otherwise, what I have pointed out will be true.
> I suppose the new X Server could jettison support for legacy
> apps and only support applications written with the latest RAD
> toolkits. There might be some value there. This might also
> allow the new server to stabilize sooner.
the 'latest RAD toolkits' now THERE'S something decent worth quoting, I
hope you won't mind me doing so. :) So, going back to the above, and
again, let me know if i'm wrong here, you're saying that in order to
support a decent X server project, there NEEDS to be 'RAD toolkits',
they can't be mediocre, less memory hungry, etc.. they have to be "RAD",
which is quite a vague term. Perhaps you could elaborate on this,
perferably in private email seeing as how the scope of this topic is
really not fit for this mailing list.
But SERIOUSLY here folks, please take a good look at yourselves for a
second before bothering to take this thread any longer and consider what
I have stated here, is it really worth bashing someone who's just trying
to help out the community as a whole with new ideas that just don't fit
into your paradigm? Obviously anyone that's going out of their way to
design a new type of X server from the ground up has to have SOME sort
of understanding of various X servers out there, including (but not
limited to) Xfree86, actually KNOWS the design structure, KNOWS where
it's heading, and has decided that they'd like to do something
different, new, from scratch, to go in another direction. I think Linus
himself did this back in 1991, obviously not with X, but you get the
idea I think. If not, then don't bother answering cuz it'll just be a
waste of bandwidth (not to say that this particular email isn't, but
once in awhile, it needs to be done. and now it is.)
.oO Gnea [gnea at rochester dot rr dot com] Oo.
.oO url: http://garson.org/~gnea Oo.
"You can tune a filesystem, but you can't tuna fish." -unknown
On Wed, Apr 18, 2001 at 09:56:03PM -0400, Scott Prader wrote:
> [much stuff about X]
Scott, I think in part what people are reacting to is the "Hi, I'm going
to start a new project, it will be cool, you should come work on it".
Forgive me if I got it wrong, I'm paraphrasing, but wasn't it something
like that what you said?
Here's my two cents on why you got the reaction you got. Reality is
settling in. I think people ar becoming aware that there aren't really
18,000 projects with 145,000 developers all hacking away on SourceForge.
Think about it - Red Hat comes with about 900 rpms. So what's in
the other 17,100 projects? The point being that while those projects
numbers sound impressive, I think we all know that 95% of them aren't
going anywhere.
In other words, what the world does not need is another project. What
the world does need is people who roll up their sleeves and do real work.
You may well be one of them, that would be cool. But what would be even
cooler is if we join together on real, existing efforts and work on them
rather than just constantly make up a new project. Yeah, it's a lot harder,
you have to put at least part of your ego aside and accept someone else's
leadership, but more gets done that way.
If you are still reading, my advice is to have a beer, relax, and ask
yourself which is more cool - a new project with about 1/100 chance
of going somewhere or contributing much more than 1/100 to an existing
project with proven track record.
Besides, there are some sharp cookies over there in X land, you are more
likely to have fun working with them.
> "You can tune a filesystem, but you can't tuna fish." -unknown
I am 99.9% sure that Kirk McKusick put that in the BSD man page.
If it wasn't him I'll bet it was Bostic or Joy, but my bet is on Kirk,
he wrote UFS. Someone at Sun took it out, and I put it back in in SunOS
4.1.1 in the tunefs.8 man page with the following comment above it (yeah,
I really did spell daemon the wrong way, shame on me):
.\" Take this out and a Unix Demon will dog your steps from now until
.\" the time_t's wrap around.
.sp
You can tune a file system, but you can't tune a fish.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
> different, new, from scratch, to go in another direction. I think Linus
> himself did this back in 1991, obviously not with X, but you get the
> idea I think. If not, then don't bother answering cuz it'll just be a
Yeah and we spent most of those 10 years reinventing wheels in order to make
them free. There are people doing interesting things with X rendering and
the ideas behind it. Some of them have been at it since Linus was a small
child. The TinyX server framework also lets you hack arbitarily interesting
card drivers into a nice easy framework.
There are also folks like the directfb people who've implemented something
Rasterman ranted about ages ago - which is using the 3d hardware subsystem to
render windows as rectangular textures.
I've seen exactly _one_ X project that is justifiably seperate. Thats weirdX
and its separate because its in Java. If you like the idea of
http://localhost/
giving you an Xdm window you'll find it worth a play
Larry McVoy writes:
> In other words, what the world does not need is another project.
> What the world does need is people who roll up their sleeves and do
> real work. You may well be one of them, that would be cool. But
> what would be even cooler is if we join together on real, existing
> efforts and work on them rather than just constantly make up a new
> project. Yeah, it's a lot harder, you have to put at least part of
> your ego aside and accept someone else's leadership, but more gets
> done that way.
Fixing NFS corruption would be a good project to work on. Despite
years of banging away at this problem, the community has yet to fix
it.
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
* Alan Cox ([email protected]) uttered:
> the ideas behind it. Some of them have been at it since Linus was a small
> child. The TinyX server framework also lets you hack arbitarily interesting
> card drivers into a nice easy framework.
you will NOT see my complaining about any of that. :)
btw Alan, I have a problem with sending you email directly, it appears
that rr.com made it into ORBS :( ah well, we'll get there, sooner or
later.. it is.. inevitable. :)
.oO Gnea [gnea at rochester dot rr dot com] Oo.
.oO url: http://garson.org/~gnea Oo.
"You can tune a filesystem, but you can't tune a fish." -Kirk McKusick
On Wed, Apr 18, 2001 at 04:57:58PM -0700, Miles Lane wrote:
> "David S. Miller" wrote:
> >
> > James Simmons writes:
> > > The Linux GFX project grew out the need for a higher performance X
> > > server that has a much faster developement cycle. In the last few years
> > > the graphics card and multimedia environments have grow at such a rate
> > > the current X solutions can no longer keep pace nor do they focus on
> > > producing high performance X servers specifically for linux. Also the
> > > community has demanded for specific functionality which has never come to
> > > light.
> >
> > And this specific functionality is?
> >
> > I think this is not a worthwhile project at all. The X tree, it's
> > assosciated protocols and APIs, are complicated enough as it is, and
> > the xfree86 project has some of the most talented and capable people
> > in this area. It would be a step backwards to do things outside of
> > xfree86 development.
> >
> > If the issue is that "things don't happen fast enough in the xfree86
> > tree", why not lend them a hand and submitting patches to them instead
> > of complaining?
>
> Yes, David, I concur.
>
> James, please just pitch in and help XFree86 evolve faster.
> There are drivers that need to be "Render" extension enabled.
Sure, but if there was a Render documentation or something such, things would
be much easier.
> There's more work to do on fleshing out the Render extension.
> I am sure that Kieth Packard would be grateful for any
> worthwhile contributions.
>
> If you are thinking that you'll provide better accellerated
> graphics rendering performance, I'd love to know how you plan
> to accomplish this. AFAIK, the main impediment to XFree86
> giving really good accelleration support for a broad array
> of hardware is the lack of technical documentation from the
> manufacturers. Unless you plan on trying to get hardware
Well, in doing fbdev drivers you already solve this kind of problems.
> manufactures to have you develop their closed-source drivers
> for them, I don't see how you'll be able to do any better
closed source driver are evil anyway, so don't worry about those.
> than the XFree86 organization is already doing.
>
> XFree86 evolves in a measured way as a result of many
> competing needs. Backward compatibility is needed for the
> huge installed base of legacy apps. For the various
> development toolkits (KDE, Gnome, etc.) there is a rapid
> move toward using the Render and "Resize and Rotate"
> extensions. These extensions will make all sorts of cool
> rendering functionality available to the applications that
> use these toolkits (alpha blending, anti-aliased fonts and
> so on).
>
> I'd love to hear you enumerate all the shortcomings that you
> believe need to be addressed. Also, please CC: [email protected].
> At least give the competition an opportunity to win over the
> support of the developers you'd like to pull away from
> XFree86 work!
I think the main critic (guessing from his announcement) is the interaction
between the console system and xfree86, as well as the
multi-head/keyboard/whatever handling, but let's hear what james has to say
about it.
Friendly,
Sven Luther
On Wed, 18 Apr 2001, Scott Prader wrote:
> the 'latest RAD toolkits' now THERE'S something decent worth quoting, I
> hope you won't mind me doing so. :) So, going back to the above, and
> again, let me know if i'm wrong here, you're saying that in order to
> support a decent X server project, there NEEDS to be 'RAD toolkits',
> they can't be mediocre, less memory hungry, etc.. they have to be "RAD",
> which is quite a vague term. Perhaps you could elaborate on this,
> perferably in private email seeing as how the scope of this topic is
> really not fit for this mailing list.
funny, I could swear that RAD was an acronym for Rapid Application Development
as opposed to your farcical interpretation.
you complain about other people being hateful, but as I read it you threw the
first fireball.
--
/*------------------------------------------------**
** Mark Salisbury | Mercury Computer Systems **
** [email protected] | System OS - Kernel Team **
**------------------------------------------------**
** I will be riding in the Multiple Sclerosis **
** Great Mass Getaway, a 150 mile bike ride from **
** Boston to Provincetown. Last year I raised **
** over $1200. This year I would like to beat **
** that. If you would like to contribute, **
** please contact me. **
**------------------------------------------------*/
Thank you. It is true all I want to do is help the community. I feel as
alot of people do XFree86 can not meet the needs of the community. It is
very sad that people feel that no amount of people in the open source
community can make code of the same or better quality as XFree86 in a
shorter period of time. I don't feel this way. Now I'm off to work on code
and documentation for the project. Thank you.
----- Original Message -----
From: "James Simmons" <[email protected]>
To: "Scott Prader" <[email protected]>
Cc: "Linux Kernel Mailing List" <[email protected]>
Sent: Thursday, April 19, 2001 5:16 PM
Subject: Re: ANNOUNCE New Open Source X server
>
> Thank you. It is true all I want to do is help the community. I feel
as
> alot of people do XFree86 can not meet the needs of the community. It
is
> very sad that people feel that no amount of people in the open source
> community can make code of the same or better quality as XFree86 in a
> shorter period of time. I don't feel this way. Now I'm off to work on
code
> and documentation for the project. Thank you.
My idea were: why not integrate kind of Nano-X (yes I know what that is)
into the kernel, just the X server, configured by make menuconfig (or
which you like more), and just use XF86 or something different (or even
X clients running under a different machine on the net) on it.
It should then implement enough of, if not the full, X11R6 API, and have
either direct access to the gfx board or at least to the fb (might this
be speeded up?).
It doesn't need to be fullstly (?) integrated to the kernel, it may also
be a "server" (as in microkernel systems), loaded as module but on CPL3.
So a crash doesn't hang the full system: if it crashes, we have a SysRq
which kicks out the module and does either a videomode-switch to a sane
80x25 (BIOS 03), VGA (BIOS 12) or - if framebuffer-based - nothing
because
the X server and the fb are separated.
We might as well support EGA, HGC or CGA(??) cards for it; switching to
a sane mode isn't that difficult (as discussed earlier, and for HGC I
have some NASM sources), and IIRC there is a HGC framebuffer somewhere.
-mirabilos
--
))) LICENSE FOR ABOVE MESSAGE BODY: (((
YOU _MUST NOT_ READ ABOVE MESSAGE BODY IF YOU DO NOT AGREE TO THESE
TERMS. BY READING ABOVE MESSAGE BODY YOU _AUTOMATICALLY_ _DO AGREE_
TO THE FOLLOWING TERMS:
This mail/work is protected by copyright law. It _MUST NOT_ be used
otherwise than specified by the terms and conditions at:
http://members.tripod.de/mirabilos/license.mip
The mail is, if not _explicitly_ specified differently, ONLY licensed
by these terms. THIS _CANNOT_ BE OVERRIDDEN BY ANY "TERMS OF SERVICE"
OF ANY S.PROVIDER THE MAIL GOES THROUGH, EVEN _NOT_ IF I SIGNED THEM!
--
(Sorry for the bandwidth, but some ToS force me to.)
EA F0 FF 00 F0 #$@%CARRIER LOST