Concerns Over Merging Drivers Back Into The X Server

[brent]

Merging protocol headers etc. is a good idea, merging drivers into Xorg is a VERY BAD idea.

[dfx.]

yeh.
if it's Intel developers who propose to move entire "drivers" in xorg-server and they would continue to push this "idea" that way then someone, please, knock them out, kidnap, pump up them with vitamins and healthy food, saunter them under some sun light and, maybe, stuff in their brains will begin flowing again...

if it's not then do it with the ones who came up with this shit but replace vitamins with punches.

[marek]

Count it up, a very full featured graphics driver stack has:
1) kernel drm part
2) microcode
3) lib drm part
4) mesa/dri part
5) mesa/gallium part
6) xserver part
7) xvmc part
8) vdpau/va-api part.

As far as radeon goes, the kernel drm part is stable from the userspace point of view. No need to ever replace that except for bug fixes. libdrm part doesn't change much and you can always bypass it and talk to kernel directly (I think r600g does that). You can mix and match the rest as you want, no need to update everything in lockstep.

The long-term plan seems to be moving all drivers into Mesa/Gallium (exa, xvmc, video accel, 3D, compute, other drawing APIs ...). Then you would compile just one driver to replace the whole driver stack (except the kernel part, which is stable anyway). Pulling DDXs back into the X server now doesn't seem to be that significant move, does it?

-Marek

[den64]

Would not like to see this idea go through, but seems some minds have already been made.No point in arguing.

[d4ddi0]

I was "for" Merging the drivers back in before I was against it.

I think I'm with those who would like to see a coordinated release schedule.

I think that would achieve most of what is desired (the ability to release features/changes along with drivers that use those features)

Being able to build the newest drivers against older X servers seems like at best red herring, and at worst, a real impediment. New wine in old bottles etc etc.

[bridgman]

Would not like to see this idea go through, but seems some minds have already been made.No point in arguing.

Have to disagree here. I don't think any decisions have been made yet other than merging protocol headers, "making X easier to build", and trying to follow a 3 month release cycle where possible.

Whenever you get a bunch of engineers discussing change, what they propose is their view of the final solution, and there will usually be all kinds of disagreement. After a while discussion shifts from "solution" to "objectives"... and it's usually easier to get agreement on those. Once agreement on objectives is reached, it's a lot easier to agree on a solution...

... and I think that is what's happening here.

The open issue is the anticipated amount of core-to-driver API changes vs the anticipated amount of inter-driver-component changes over the next couple of years.

If most of the changes are expected to be between components in the same driver (ddx, libdrm, drm, mesa hw driver) then Luc's proposal is probably the best direction. If, on the other hand, the inter-component interfaces have mostly stabilized and we are entering a period where core-to-driver API changes are more likely, then tighter integration between X server and drivers is probably correct.

The last couple of years have seen big changes between the components in each driver, as a result of moving to KMS, DRI2, GEM/TTM etc, and IMO Luc's proposal would have simplified some of that work. Today most of the wrenching changes have been completed, however, and the "scary work" is moving to other parts of the stack.

What makes the whole thing complicated is that the amount of anticipated core-to-driver API change seems to be different for each component. It seems likely that Mesa will see a lot of core-to-driver changes as a result of the move to higher levels of GL support and the evolution of Gallium3D, but since Mesa core and drivers are already integrated and are built together (whenever you build a Mesa HW driver you also build a million lines of Mesa core) the current structure seems fine.

In a way the initial proposal for moving the X drivers back into the X server tree would just make X work the same way as Mesa, although the code size is larger for X. The catch is that distros are sometimes willing to accept a new core+driver set for Mesa between releases, but have not been willing to do the same for X (or for the kernel).

If new X releases can be regarded as sufficiently safe that distros will accept them as updates between major releases (rolling releases already kinda do this)then moving to a fully integrated release model seems doable. The good news is that there seems to be consensus that making X easier & safer to build, making new X releases "smaller and more frequent" (which makes them safer as well) are the right first steps.

[bridgman]

Being able to build the newest drivers against older X servers seems like at best red herring, and at worst, a real impediment. New wine in old bottles etc etc.

Your distro makes a release. You buy a new graphics card. The distro isn't going to update the X server for 6-9 months. Do you want to have to update your X server by hand in order to get driver support for your new card ?

[KAMiKAZOW]

IMO Xorg's biggest problem is the lack of coordinated work. History showed us that updated drivers are usually not compatible with older Xorg releases anyway, so why not simply update everything at once?
Sun/Oracle is just too lazy to do proper testing, it seems. And if they really want, they can still backport individual drivers.

Just merge everything into one package and move all drivers to Gallium3D. Then we'll finally have a coherent package.

[Michael]

&^%#$^*%$*&$%!!!!

Maybe when the server is really slow the edit window could automatically extend to 2 minutes ? He says hopefully...

Still working on bringing edit time back to no limit for "verified" users while new users would still have the one minute limit until they have a number of non-spam posts.

[libv]

Merging protocol headers etc. is a good idea, merging drivers into Xorg is a VERY BAD idea.

Merging protocols is a first step to merging client libraries. What is good about that? It is de-modularizing from the other side of X. What would then stop them from de-modularizing the driver side from X?