to be honest, the situation isnt quite so bad as your post lays it out to be.
X11 needs a replacement for open desktops, as is today its too far behind current trends in technology and constantly playing catchup. The learning curve for new developers is steep preventing any sort of acceleration in the project. X is large/bloated/buggy and was never meant for use as it is today. A massive effort could be started to design and develop a replacement. Such a project could bring in new developers and new ideas, with consideration for technology of today/future in mind. Multi monitor configs, rootless operation, kernel control of the hardware, standardized window manager, and widget set, fully hardware accelerated, mulit card, mulit imput, mulit touch interface, are just a few ideas. X backward compatibility would be necessary at first. Maybe use something like SDL for input. Support for legacy hardware should be dropped, a set of minimum requirements could be implemented and development can focus on hardware like intel, amd, or nvidia and as they represent the majority of graphics powering today's open desktops. Any other ideas?
Jon Smirl, a former Xegl dev, wrote an interesting article a few back concerning the state of linux graphics. He points out some of the gournd work needed for a new server design, some of which is now starting to emerge.
Last edited by eric390d; 05-16-2008 at 08:13 PM.
to be honest, the situation isnt quite so bad as your post lays it out to be.
Multi-Monitor configs, ever heard of randr? (Please don't criticize it, it is being improved)
Rootless operation, lately, this is being worked on.
Kernel control of the hardware, there is a reason for drm/ddx/dri, it's so the kernel doesn't get bloated or fail simply because of graphics!
Standardized wm, this is useless, a spec is all that is needed, it would slow development
Widgets are apps, not part of the graphic management solution!
Multi card, its there
Multi touch/input, MPX is being merged
Instead of reinventing the wheel, improving what we have is better
You confusing stuff here.
X11 is a network protocol.
Complaining about X11 as being obsolete is like complaining about HTTP because Flash keeps crashing your browser and flash uses http to download it's data.
On the local system X11 uses fast sockets for communication, totally bypassing the TCP/IP network stack and other such things and is essentially as fast as anything in any other OS.
Because all of this you can replace your X Server without having to recode all your applications and getting rid of X11.
Currently X.org is not the only Xserver for Linux. Xfree86 is still making their X server. For Solaris you still have Xsun. For Linux a old alternative is http://www.xig.com/
Jon Smirl wrote about the driver model that Linux and X.org uses.
We can change (and they are, in fact, changing) the driver model to something more efficient.
Currently for Linux you have:
DDX -- device dependant portions of X11. They have the 'X.org' driver that provides acceleration through either the EXA or XAA interfaces.
Linux Framebuffer, Linux VGA drivers -- This is your console drivers. When you switch from X to the virtual console this is the driver that is being used for your command line.
DRI -- OpenGL driver for Linux. The OpenGL stack they use is Mesa. (effectively Mesa is a opengl software library and DRI drivers accelerate as much of it as they can. No driver accelerates ALL of OpenGL. Not even the most expensive workstation cards do. OpenGL is a generic 3D api that works irregardless of acceleration)
DRM -- Linux kernel's driver that allows DRI to access hardware.
Linux's video drivers are userspace. This is something that Microsoft just got around to switching to for Vista.
So you have all these drivers from different projects all fighting with each other to access your video card AT THE SAME TIME.
Jon Smirl's solution was for XGL to replace the current X Server and have everything run through OpenGL.
That is instead of having DDX/DRM/DRI/VGA drivers you just had DRM/DRI. This makes things dramatically simpler.
The problem with this approach is that 3D programming and 2D programming are very different.
Also OpenGL was never intended to be the basis for a windowing system. It's meant for coding applications and lacks a lot fo the functionality that a X Server needs. (this is why XGL ran as a full screen application on top of a existing X Server)
He got pissed because people were working on EXA rather then going full bore with OpenGL.
So right now with DRI2, Gallium3D, TTM, kernel-level modsetting, etc etc etc are transforming the X.org Xserver into something much more modern.
Eventually X.org will have no more hardware video drivers. Instead everything should be handled by Linux kernel and DRI/Gallium/Whatever-they-end-up-using stuff and your X will just be another application.
The better driver model will lead to better performance and stability.
Having X run as a user application should increase multi-user functionality, increase stability, increase security, with only a slight reduction in performance.
Also by getting open source drivers going this will create a lowest-common-denominator for Linux performance/compatibility.
Currently for Linux your ability to run and support OpenGL applications vary widely by your hardware. If your using Intel you get different results vs Nvidia open source vs Nvidia closed source vs ATI closed source vs Via etc etc. A game that can work perfectly for ATI's closed source can crash a Nvidia-using machine. A game that may work for Intel's open source drivers may not get any acceleration at all on a Via system.
This makes Linux virtually impossible to support for things like games. Or at least makes it very difficult.
One of the major reasons, I suspect, for game developers targeting DirectX so much on Windows is that it's so consistent between vendors. Microsoft enforces DirectX with a iron grip and forces the hardware vendors to conform to their will.
With Windows and OpenGL your depending on each vendor's own OpenGL stack. ATI's is different from Nvidia is different from Intel's. So it's just plain easier to target DirectX and avoid dealing with the support overhead.
Once the driver situation in Linux is improved to such a point were you get Mesa's brand of OpenGL accelerated across all common video cards then it will make OpenGL-on-Linux much more like DirectX-on-Windows in terms of the availability and usability.
You see the problems with Linux isn't due with X11. (at least not mostly) It's due to the particular version of X server AND driver model(s) that Linux uses.
These are fixable issues and are being addressed as rapidly as can be managed.
eric390d, I think you don't appreciate the distinction between the window system itself and the implementation in the X server. Most of the issues you're concerned about are implementation issues in the X.Org server and/or free kernels, and have little or nothing to do with the actual window system or protocol. Those that do need protocol support can be (and in some cases already are, as others have pointed out) handled with extensions.
Also, you say that an X replacement should have a standard WM and toolkit, but there would be no way to enforce that in an open-source system, and it's not even clear to me that this is desirable. The current model lets those developing actual operating systems decide on the standards for their respective systems. Xt, Athena, OpenLook, Motif, GTK, Qt, and the countless WMs out there were all developed to meet differing and changing needs. Isn't it reasonable to expect that different operating system vendors/developers could have different ideas about how a GUI should appear and operate, and to let them deal with the issue of providing a cohesive desktop rather than trying to dictate a single solution to the entire FOSS world?
Not just reasonable, but necessary. And don't forget the USERS amongst that bunch. Please, don't impose on me your full hardware accelerated rotating crap nor your standardised shiny widgets.Isn't it reasonable to expect that different operating system vendors/developers could have different ideas about how a GUI should appear and operate, and to let them deal with the issue of providing a cohesive desktop rather than trying to dictate a single solution to the entire FOSS world?
One size DOESN'T fit all.