Slashdot Mirror
The State of Linux Graphics
jonsmirl writes "I've written a lengthy article covering what I learned during the last two years building the Xegl display server. Topics include the current X server, framebuffer, Xgl, graphics drivers, multiuser support, using the GPU, and a new display server design. Hopefully it will help you fill in the pieces and build an overall picture of the graphics landscape."
I just want an ATI driver that will work in full screen mode with my Dell Laptop. Too much to ask, maybe, but I'm making due just fine with what I've got. (Fedora FC4 w/ Enlightenment)
Generation Trance: What generation are you?
Im sure you guys remember the Looking Glass demo that Sun showed us a year or so back. This article mentions Project Looking Glass, but only explain what it does. Did Sun just throw this up for publicity? Are they ever going to opensource it or make it more widely avaliable?
Linuxgangster.org
Interesting read. I'm quite happy with my nvidia proprietary drivers as long as Cairo/glitz/whatever will use that to make my desktop more responsive.
I hato to see a lousy looking window-drag (ie. sloow update) when I know I have a professional video card. It really bugs me and this is the reason I also bought an iBook (well, besides the BSD inheritance).
here's a demo of a hacked version of KDE running on a XGL server
i .html
http://rapidshare.de/files/4553011/xgl_wanking.av
Demoed at aKademy 2005, KDE's developers conference.
According to the developer, this is on a 4-years-old notebook running ATi hardware. Quite impressive.
I think it's a crying shame Jon has stopped working on Xegl - we can only hope others will pick up from where he left off. It looks like Linux graphics is going to go through a series of half-way steps before arriving at fully OpenGL accelerated graphics: Exa based drivers first to speed up RENDER based graphics, then Xglx running on top of an existing X server to utilise its mode setting and input code, then finally Xegl which eliminates the existing X server entirely in favour of a new one that pipes all its drawing directly into the 3D pipeline.
Question is, how long will it take?
My conclusion is that most people don't really know what is going on with graphics in Linux. It's understandable that people don't see the whole picture. Graphics is a large and complex area with many software components and competing developer groups.
...now just lemme read that X server RFC...
But it really should be like.. at most 3 indirections:
the toolkit --> the X server --> and the driver/hw!!
When I saw this (App->gtk+->Cairo->XRender->Xgl ->GLX(X)->GL->hw) it blew my mind..
gtkaml.org
Even if a "perfect" X server is implemented, that's not the end of the battle to give the Linux desktop a facelift. It's the beginning.
Toolkits running on top of X are just as important to Desktop Goodness as the Xserver is, and they can only be updated AFTER the X situation is stable. GTK and QT are the obvious ones, and I'm sure work will proceed on them, but I suspect such changes would be significant enough that they would warrant a major release, and lots of work to fully integrate new X features as opposed to just bolting them in.
Frankly, I think the best way to proceed would be to take the useful parts of Gnome and assorted GTK apps and port them over to the Enlightenment Foundation Libraries, once they are stable. Enlightenment DR17 is probably the only environment available with the potential to pass itself off as a next generation desktop for Linux and make it stick. Can you imagine what Gimp would be like written on top of the EFLs? (drool). Of course, that's too much work to expect it to actually happen on a large scale, but it might be that Gnome's recent trend toward simplicity could make such a target easier to achieve.
QT I think is in good hands - trolltech has proven quite good at making good toolkits with increasing performance in each new release. I'm sure it's just my perception, but GTK widigets feel clunky to me and I really think a shift by the Gnome effort to the EFL base would rock the Linux desktop world. Of course, that's easy to say and hard to do, but major landscape changes are not made by minor efforts.
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
I recently tried reinstalling windows on a Dell, using the Dell 'recovery' CDs (OS and drivers) that came with the box. Everything worked except the video. Windows had to boot into 'safe' mode in order for the video to work, and then it was at reduced bit-depth. This was a factory shipped Dell, with factory shipped CDS - I added nothing to it. Of course the problem can be easily fixed, but my point was that it was a problem in the first place.
I booted the same box with Ubuntu live 5.04. X came up fine, no problems. I had to do nothing at all for it to work just fine.
Windows: 0
Linux: 1
This kind of thing happens way too often. What the hell is MS doing with its time - making TPS reports? I guess this is what you get when you spend your resources buying software instead of making software.
"We are all geniuses when we dream"
- E.M. Cioran
The X-Window system runs in a variety of O/Ses, including every flavor of Unix, Mac OS X and Microsoft Windows.
What I haven't understood all these years of 3d development is that why X-drawing calls are not converted to OpenGL drawing lists. An X-Window server could take the graphic calls and store them as OpenGL drawing commands, and each time some window is redrawn, the commands are sent to OpenGL and thus the graphics card. That would mean automatic antialiasing, full zooming etc.
A lot of this article is flamebait. Jon is pretty obviously bitter that the rest of the X developers didn't feel his sense of urgency in moving everything to Xegl right away.
The fundamental difficulty in getting specs to write and maintain open drivers for various video cards still exists, and any move to a fully OpenGL-based system will still have this barrier for a large number of people. If you've ever tried to run sw-based mesa, you know how slow it is, so on a fully OpenGL subsystem a large number of people will have to run it using the proprietary drivers. These work well for some people but for others they crash constantly and integrate poorly with the rest of their system. Ultimately, the X developers have their hands tied with these drivers because they can't fix them. Imagine a world where most everyone running all of X on these drivers, from 3D games to xterm, and you can see a serious problem.
Jon just brushes this off in his article ("believe it or not some people like the proprietary drivers"). Meanwhile, he calls the current effort to actually make the code work a "bandaid" even though it shows great promise to actually deliver useable drivers for a large number of people in a very short amount of time. He laments that X doesn't handle hotplugging well, but ignores the many efforts to implement this (check the X wiki for info) and the fact that no one has really figured out the best way to do it. He willfully ignores the fact that X needs to run on non-Linux systems, and as such it can't rely on many of the facilities he talks about.
Jon's definitely a smart guy, and he understands X incredibly well, but he's unwilling to accept that maybe he's not prioritizing things very well. He certaintly hasn't done a great job of selling Xegl to the rest of the X world, because if he had he might not have written this wonderfully elaborate troll.
"I may not have morals, but I have standards."
The state of Linux graphics is in my opinion, better than Windows. I've had long nights of reinstalling the OS (Windows) just because I had a bad video driver that corrupted the system. Not even restoring the system from a backup helped. But what I am certainly curious about is minimizing the compile time on systems with higher-end video cards. If GPUs can be utilized for sorting processes and some boards contain more than one processors, why aren't we utilizing these high-speed processors to aid in compiling a kernel for our computers? I don't see the problem since audio processing is already being done.
-- Game Developers: Stop porting badly-textured games from crappy console systems!