GGI might be the way...

Since you're all considering how to take the next step with X/Xfree, I
think you should consider absorbing and adopting GGI. Even if you have
some political beef with GGI or it's implementation choices -- please
consider the motivations below carefully. 

HEALTH WARNING: I make several references to how Microsoft has handled
things because we all know that they have (a) great driver support,
and (b) rippin fast graphics performance. If you have some mental
block which makes you mad when reading about someone saying Microsoft
has done something right, for your own health, please do not read any
futher.

1) Third party driver distribution needs to be the norm, not an
   afterthought. GGI _is_ a video driver model which is not
   limited to use inside X.

   There is alot of anti-third party anything sentiment in the open
   source community. Often this seems to revolve around the "presumed
   evil nature" of distributing binary software. If you ask any
   systems architect (in any field), they will tell you that
   centralized systems do not work, and "software development" is no
   exception to thus rule. It does not matter if you have 250
   volunteer developers, or 15,000 employed developers in Redmond, if
   you want to support third-party hardware (or software), you HAVE to
   let the third parties do it themselves.

   Here is an example of the perspective shift necessary. Recently,
   Keith explained that users with newly supported Radeon chips had to
   wait for the Feb 2003 release of Xfree under the heading "slow
   release schedules". This entire mindset is flawed. There is *NO*
   release schedule for Xfree which would be fast enough. XFree is
   packaged with RedHat at a specific time and RedHat is not about to
   go cut a new master every time Xfree does a release. Furthermore,
   users simple do not upgrade their Xfree... EVER. They get a new
   Xfree on a new machine when a new Linux distribution comes out. The
   only way to get them support for newer hardware is to stop
   expecting it to be provided by in an XFree release. Even better
   would be to stop expecting it to be provided by the XFree team.

   The open source community needs to stop throwing away all the
   valuable lessons learned over years of software industry growth. If
   we want to have the quickest and best driver support, we need to
   EMPOWER the hardware manufacturers to provide their own drivers by
   giving them a standards based development model which is (a) not a
   moving target, and (b) has forward compatibility with new core
   releases, whether that is XFree, the kernel, etc. That forward
   compatibility should work for at LEAST 2 years.

   GGI has all of these goals in mind, and has done a reasonable job
   so far given that very few people are using it.

2) Moving to a direct rendering model WILL increase performance. GGI
   provides this model, and also lets us run X today!

   I have read much argument about whether or not the architecture of
   X is responsible for some of the video performance delta between
   Windows and *nix. Some blame the drivers, some blame the wire
   protocol, others blame the *nix kernel schedulers. The fact is that
   improvement in any of these area can improvement performance. The
   fact is that direct rendering IS faster than networked
   rendering. Period. Can networked rendering be "fast enough"?
   Probably, but why settle for "fast enough"?

   The beauty of the X/GGI model is that it allows us to mix and match
   direct-rendering with the X wire-protocol. It's a simple migration
   path forward, providing a model which is not dissimilar from
   Microsoft's GDI/DirectX split. Although neither of those has a wire
   protocol, DirectX was gradually made available to improve
   performance of applications which need direct rendering. Now
   DirectX is the core of the entire rendering model on Windows.

   GGI could help facilitate the same type of change here. 

3) GGI provides modern features today.

   For example, it allows support for multiheaded displays running
   different video hardware with drag across. It already runs on small
   mobile devices. It supports 3d rendering (ala Direct3d) . It
   supports video overlay with hardware colorspace conversion (ala
   DirectDraw surfaces). It supports color blending (alpha). It
   supports direct hardware blitter access (ala DirectDraw). It
   supports an input handling driver model (ala DirectInput).

   It also supports features that Windows can't touch, such as
   virtualization of the drawing interface. Plus, GGI also runs on
   Windows under DirectX!

4) Xf86Config files must die

   *nix is at a cusp point where it could soon gain widespread
   adoption. However, it isn't going to happen if users have to hand
   edit configuration files to get basic things to work.

   Recently I was told a story about how ironically silly one new
   "graphical mouse chooser" dialog is. Apparently you can do almost
   everything with the dialog via Keyboard except expand nodes in the
   tree. The result, this user had to once again drop to command line
   and edit the config file by hand to set this source for his mouse.

   The real problem here is NOT the broken mouse config program. The
   problem is that someone thinks there should be a mouse chooser
   dialog! There is no mouse "chooser" dialog on Windows or
   MacOS. They just figure out where my mouse is. If I also plug in a
   USB mouse, guess what? I just have two working mice. Clearly there
   is no need for the user to have to poke around to make a mouse
   work. These other systems merely let me set the mouse speed, double
   click speed, etc. None of these are required for the mouse to move
   the pointer happily across the screen.

   We also don't need a configuration file to say what the valid
   switchable resolutions or color depths are, X should just show the
   user all the available resolutions in a display config panel and
   let him switch on the fly like every other modern operating
   system. Xfree has been getting closer to this. GGI can help go all
   the way. 

   Xfree needs to start with the goal of getting rid of the
   configuration files and to "just make things work".

I could go on, but I think I've expressed enough of my sentiment. The
XFree project has the attention and mindshare of the free *nix
community. In order to take *nix graphics to the next level, Xfree
needs to change it's entire mindset. It's more important to shed this
mindset allowing the end-user complexity of UNIX/X11 than it is to
shed the wire protocol. However, by welcoming and adopting GGI, Xfree
can take *nix graphics to the next level, meeting and surpassing
Windows graphics in many ways.

Food for thought... have at it.

-- 
David Jeske (N9LCA) + http://www.chat.net/~jeske/ + [email protected]