From: Sven LUTHER <luther@dpt-info.u-strasbg.fr>
To: Miles Lane <miles@megapathdsl.net>
Cc: "David S. Miller" <davem@redhat.com>,
James Simmons <jsimmons@linux-fbdev.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Fbdev development list
<linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: [Linux-fbdev-devel] Re: ANNOUNCE New Open Source X server
Date: Thu, 19 Apr 2001 10:05:15 +0200 [thread overview]
Message-ID: <20010419100515.A25514@lambda.u-strasbg.fr> (raw)
In-Reply-To: <Pine.LNX.4.10.10104181317440.1478-100000@www.transvirtual.com> <15070.4428.345455.994818@pizda.ninka.net> <3ADE2A06.7EE56438@megapathdsl.net>
In-Reply-To: <3ADE2A06.7EE56438@megapathdsl.net>; from miles@megapathdsl.net on Wed, Apr 18, 2001 at 04:57:58PM -0700
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: devel@xfree86.org.
> 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
prev parent reply other threads:[~2001-04-19 8:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-04-18 22:02 ANNOUNCE New Open Source X server James Simmons
2001-04-18 22:12 ` David S. Miller
2001-04-18 23:28 ` Scott Prader
2001-04-19 0:18 ` Miles Lane
2001-04-19 1:56 ` Scott Prader
2001-04-19 2:20 ` Larry McVoy
2001-04-19 3:53 ` Richard Gooch
2001-04-19 3:54 ` Alan Cox
2001-04-19 4:05 ` Scott Prader
2001-04-19 12:06 ` [WAAAY OT]Re: " Mark Salisbury
2001-04-18 23:57 ` Miles Lane
2001-04-19 8:05 ` Sven LUTHER [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010419100515.A25514@lambda.u-strasbg.fr \
--to=luther@dpt-info.u-strasbg.fr \
--cc=davem@redhat.com \
--cc=jsimmons@linux-fbdev.org \
--cc=linux-fbdev-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=miles@megapathdsl.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.