Concerns Over Merging Drivers Back Into The X Server
With X.Org came the modularization of drivers compared to XFree86, which allow drivers to be built independently of the X Server. However, it was proposed a few months back that with X Server 1.10 that the drivers get pulled back into the X Server. This would result in X.Org becoming a more monolithic package, but would allow driver developers to more easily break the API/ABI and other invasive changes.
To users, moving the drivers back into the X Server means that you must build the entire server + drivers whenever you want to update your lone DDX driver. Building the X Server takes longer and requires more dependencies than building a single driver like xf86-video-ati or xf86-video-intel. This cause even fewer people to test Git snapshots, which is a problem for a project that already could use more Linux desktop users testing out the latest code -- not less people.
Moving the drivers back in would also mean that the driver developers could no longer release updates independent of the X Server, but that the X Server would need to be released more frequently to provide support for new graphics cards and features. Intel's Keith Packard has already said this would mean a three to four month release schedule for the X Server, where as in the past the X Server has been released every six months, but with delays it's often months longer.
As a step towards moving at least the video drivers back into the X Server, Keith Packard has made a single protocol headers package for X Server 1.9 and that's what has set off this most recent discussion about where X.Org video drivers belong.
Some driver developers like Alex Deucher (AMD) have voiced concerns on moving the graphics drivers back into the X Server in that it will hamper inexperienced end-users in testing out the new code even more. As Daniel Stone has also pointed out, it's harder to test out new drivers if the state of the X Server Git code is in a poor state where one looking to just test out new graphics driver code could be stopped by bugs in say the input driver. It's been mostly Intel's developers like Keith Packard and Jesse Barnes voicing support for this structural move.
Also having been discussed is whether support for new graphics cards could be introduced in an X Server point release or whether it would wait until the next major X.Org release. Well, it could go either way, but providing it as a point release would mean that the few X.Org driver developers are taxed even further by now needing to back-port the code to an older X Server code-base.
Stephane Marchesin has also asked what gains this would really be when the APIs for EXA, RandR, and others have already been worked through mostly. Jesse Barnes agrees with this partially, but merging them back in would allow Intel to drop some conditional code from their driver that is targeted at older X Server releases and also to share more code amongst DDX drivers by placing common code within the X Server.
Alan Coopersmith of Sun/Oracle is also concerned about back-porting driver fixes under this proposed X Server model particularly with the enterprise operating systems / distributions. Pulling an entirely new X Server into an already released and supported distribution could cause troubles.
Another issue touched on by Keith is that in some cases building a new X Server would require updating to new libdrm code that's released quite frequently. However, in the end Keith says, "Let's see what we think in a few months when we're starting to do planning for 1.10; we'll have had some experience with the merged protocol headers by that point (I hope), perhaps that's all we need to do?"
Right now the views are pretty mixed but we will have to wait until August after X Server 1.9 is released to see what the final verdict is on moving the X.Org drivers back into the server area. If this change does go into X Server 1.10, it will likely impact users of Ubuntu 11.04, Fedora 15, and other H1'2011 Linux distributions.
67 Comments
