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."

Comments

ATI Drivers

[GecKo213]

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)

lkml discussion

[slavemowgli]

There's also a discussion about this on the linux-kernel mailing list (lkml) currently - certainly worth reading:

http://marc.theaimsgroup.com/?t=112541793700006&r= 1&w=2

A little OT, but...

[Anonymous Coward]

here's a demo of a hacked version of KDE running on a XGL server

http://rapidshare.de/files/4553011/xgl_wanking.avi .html

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.

Thanks Jon!

[IamTheRealMike]

I'd just like to say thanks to Jon Smirl for writing this. I've been following X development for some time on the various mailing lists and so on, but for an outsider looking in it's nearly impossible to get an accurate picture of what's happening and which bits do what let alone what peoples plans are.

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?

Re:Thanks Jon!

[Anonymous Coward]

I'm posting anonymously because I don't want to seem like a suck-up - rest assured, though, that I am not Jon :)

I think it's a crying shame Jon has stopped working on Xegl

I think it's a crying shame that no one (i.e. Red Hat, Novell, IBM, etc) stepped up to sponsor such an intelligent and capable guy, even with just a living wage (although I'm glad that Novell hired Reveman, at least) - and the same goes for drobbins. IBM in particular has damn-near bottomless pockets for R&D, and I bet they hire legions of lesser skilled workers doing more menial jobs. Could they not have spared the budget equivalent to one extra support-monkey for such an exceptional talent? It boggles the mind, quite frankly.

Ungrounded Optimism?

[minginqunt]

Two years ago at FOSDEM, the Xorg fork had just occurred, and there was much excitement. Maybe this time, free from the shackles of the X consortium and XFree86, X would actually improve to the point where we can be proud, and snicker at our Mac OS X using chums and say "Why can't Quartz do this then, eh?"

Unfortunately, the way I read this article is:

1) Linux Graphics is a bloody mess.

2) X is still an embarassment, five years behind (at least) what Quartz and Avalon are capable of.

3) Nobody has the time, manpower or inclination to fix it.

Ah tits.

Ten years ago, we were having the discussion about X being b0rken. In ten years time will we still be having this discussion?

Plus ca change...?

Actually I am still excited about X's future. Yes, X development stagnated pretty badly under XFree86. But things are moving along nicely now that X development is being conducted at X.org.

The state of Linux Graphics isn't a mess. The controversy this article caused on LKML shows that many people are talking and working together and feel that things are improving. It may not be close to what Quartz is capable of yet. But it is still moving the right way.

The Big Iron vendors let X stagnate because they never ever seemed understand the desktop space. Stupidly, they let Bill and his minions stroll in and take it over before they really had any chance to grasp what a mistake they'd made.

Then XFree86 let X stagnate further, thinking of itself as some exclusive Gentleman's Club.

Fortunately, the foundations of X are right. Simple, modular, highly extensible. If there's one thing the Unix Way gets right, it's simple, modular and extensible.

Now, perhaps, X has finally space to really thrive and grow.

I reckon the Slashdot will still be having "X Suxx0rs!!!" flamewars in 10 years. I hope also that those trolls will be even more wrong than they are now.

Perhaps my terminal optimism is sweetly naive, but I sincerely hope and expect X to go from being "just-about-ok" now to leaving Mac OX smoking dead in the dust in the next few years.

X is hard to code for!

[Anonymous Coward]

There are lots of issues that need to get resolved reguarding X and Unix/Linux. The biggest one I've seen is that the developers are super focused on everything being GPL all the way down to the driver level. Here's an example I have a SiS 650 it uses the SiS 315 chipset. Currently there is no 3D driver available in X.

But, When I started to dig further into why the SiS 315 wasn't supported. I found out that the SiS 315 was the basis for all of SiS/XGI's new chipsets and included all kinds of new IP, register informtion/locations, and therefor datasheets could not be released to create an open driver. Ok, that is reasonable. So I asked if I could view the datasheets. After sighing an NDA I receievd all chipset datasheets within 2 weeks and an internal chip development contact. SiS/XGI was more than happy to work with me to get things to run under Linux/Unix but, their hands were just tied about releasing the specs as open. Also they don't have the technical resources to create a X driver.

Why can't a binary driver be accepted? I understand the implications. But seriously there are times when you need to look at the bigger picture.

My rant is done...

Re:_Eight_ redirections?

[IamTheRealMike]

Well, it's not as bad as it looks.

App to GTK+ is just some function calls and data structure manipulation. Like on any OS widget toolkit.

GTK+ to Cairo is the same: Cairo and GTK+ are both shared libraries. Cairo takes drawing instructions from GTK+ and translates it into low level primitives that map directly to the XRENDER protocol.

XRENDER is just a wire format - a way to tell the X server what to do.

Xgl is an X server. You need a single entity controlling video hardware, otherwise things get complicated very fast. Existing GL drivers don't like being used by lots of apps at once as they were built primarily for games. By centralising control of the hardware you can optimise things and deal with existing hardware/drivers.

GLX->GL->hw - this is only temporary until enough infrastructure has been integrated into the kernel to obsolete the existing X server.

Re:_Eight_ redirections?

[serialdogma]

>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..
Well it is really more like this

App->toolset->Cairo->XRender->Xgl->GLX(X)->GL->hw
|___App______||__Xserver_______________||OpenGLdri vers/hardware
(might not be lined up)

It is in fact the 3 part system that you think it should be, however it (for many diffent reasons) spilt up into subparts.

Like if I where to show you the way a file system works i might draw:
App->API->driver->hardware
when it is more like:
App->API->filesystem driver->device diver framework->PCI bus driver->PCI to IDE controller driver->Disk driver
It is still in the same 4 parts as it was shown in the first but this( 2nd one) is more detailed.
And as this is "News for nerds" surly we should crave the more detailed account.