X.Org releases: present and future [LWN.net]

X.Org releases: present and future

Posted Oct 8, 2009 2:23 UTC (Thu) by daniels (subscriber, #16193)
Parent article: X.Org releases: present and future

Two things that are worth noting is that MPX just works with applications today. While they're unable to take full advantage of it, even if you have multiple cursors, you'll be able to interact with multiple legacy apps at the same time. Getting this to work fine was most of the reason why MPX took so long to arrive: having this kind of thing work correctly with, say, Firefox, is next to impossible.

Also, 1.10 will be part of 7.8. Externally-built drivers will still be supported, and the plan is -- when we're ready, which may or may not be 1.10 -- to start merging in the more active drivers, such as Intel and Radeon. That these drivers also have KMS support is not coincidental; hopefully having the actual driver code in a separate project means that the drivers themselves will settle down, and thus make them vastly more suitable for merging into the main server tree.

The fear of merging them originally was that with an unstable master and an ever-changing driver base, the odds of getting the core server and the drivers working at the same time were indistinguishable from zero. Hopefully the combination of the new development process and KMS can allay these fears.

to post comments

X.Org releases: present and future

Posted Oct 8, 2009 4:32 UTC (Thu) by bronson (subscriber, #4806) [Link] (5 responses)

Wouldn't merging the core and drivers into the same repo be the single biggest help to getting them to work at the same time?

It works great for Linux... A break-the-world change can be contained in a single checkin, updating core and drivers all at the same time. You just need to not be too worried about maintaining backward compatibility!

X.Org releases: present and future

Posted Oct 8, 2009 4:50 UTC (Thu) by daniels (subscriber, #16193) [Link] (4 responses)

Sure, and indeed a large part of the motivation is so we can take a sledgehammer to the collection of header files and undocumented semantics we laughably call our driver API, but the problem with the previous development process was that all development essentially happened on master.

So the server code was often in a parlous state, and with the drivers having a huge body of fragile modesetting code, so were the drivers. Had we combined them previously, the odds of having a revision where, say, the input code and Intel modesetting were both working were fairly minimal. Now that master is slated to be infinitely more stable, adding more code is actually feasible.

X.Org releases: present and future

Posted Oct 8, 2009 8:12 UTC (Thu) by mjthayer (guest, #39183) [Link] (1 responses)

I hope that the API will stay stable withing a given server release branch. I agree that coding to the current "API" (in fact just working out what it is) is a bit of a nightmare, but I dread the thought of maintaining an out-of-tree driver against an API, even a somewhat cleaner one, that changes between point releases like 1.8.0 to 1.8.1.

X.Org releases: present and future

Posted Oct 8, 2009 8:23 UTC (Thu) by daniels (subscriber, #16193) [Link]

Yes, it will.

Ease of testing

Posted Oct 8, 2009 10:14 UTC (Thu) by alex (subscriber, #1355) [Link] (1 responses)

X.org still remains harder to test than the kernel and part of the problem is the scattered repos. There are scripts that will build you a local xorg from git (without killing your working system xorg) and I have actually managed to successfully complete a build that ran. Unfortunately the build would crash as soon as I pressed a key and I eventually had to give up after banging my head against the wall.

The best I've managed so far is testing development versions of the intel driver by creating custom ebuilds and testing on my X setup and reverting when I loose a working X.

The process has certainly improved over the last few releases but there is a way to go.

Ease of testing

Posted Oct 8, 2009 13:00 UTC (Thu) by nix (subscriber, #2304) [Link]

I'll admit that I've tended to start with stable drivers and cherry-pick specific bugfixes rather than even trying to get development versions working, unless they were slushy development versions in imminent pre-freeze mode. Everything else is just too fraught right now (though better than it used to be, I think).

X.Org releases: present and future

Posted Oct 8, 2009 12:56 UTC (Thu) by nix (subscriber, #2304) [Link] (3 responses)

Wouldn't you still have some churn post-KMS because modesetting support for non-Linux kernels would still have to sit in the driver?

(Or is the idea that new features implemented by the majority of devs who only really care about Linux will only get implemented in KMS, leaving users of other Unixes and older kernels out in the cold? I mean, sure, this isn't terribly important because the number of people upgrading X without upgrading the whole distro is measurable in hundreds and they can be assumed to know what they're doing, and the number of people running X on recent hardware on non-Linux systems is pretty low as well...)

X.Org releases: present and future

Posted Oct 8, 2009 14:11 UTC (Thu) by mjg59 (subscriber, #23239) [Link] (2 responses)

The only other OS other than Linux putting any real effort into X at all nowadays is Solaris, and they're implementing KMS.

X.Org releases: present and future

Posted Oct 8, 2009 21:47 UTC (Thu) by oak (guest, #2786) [Link] (1 responses)

So what BSD is going to use? Quartz? :-)

X.Org releases: present and future

Posted Oct 10, 2009 6:07 UTC (Sat) by roelofs (guest, #2599) [Link]

So what BSD is going to use? Quartz? :-)

Aren't at least a few of the BSDs still using XFree86?

Greg