User: Password:
|
|
Subscribe / Log in / New account

X.Org releases: present and future

X.Org releases: present and future

Posted Oct 8, 2009 4:32 UTC (Thu) by bronson (subscriber, #4806)
In reply to: X.Org releases: present and future by daniels
Parent article: X.Org releases: present and future

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!


(Log in to post comments)

X.Org releases: present and future

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

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 michaeljt (subscriber, #39183) [Link]

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]

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


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds