Luc Calls For A Dead Linux Desktop If Keith Gets His Way

[plonoma]

*rant* *rant* Can somebody of phonorix please change the title from 'Luc Calls For' to 'Luc Warns For'. Please don't put up such nonsense titles again phonorix.

[89c51]

noob question (you have been warned )

does moving the drivers in X affects projects like wayland??

[bridgman]

What I don't understand is why everything gets pushed into the mainline kernel. This leaves you having to update the kernel to update the graphics bits. Wouldn't it be easier just to build everything as Kernel Modules?

Thats one of the things I like about using the nVidia blob, I don't have to worry that if i upgrade my kernel im going to have to rebuild half my x server to keep the userspace bites in lockstep with the kernel stuff.

Does KMS *need* to be in the kernel, would it not work if it was a loadable module? Eg, you could have a package called KMS that had the bits needed for KMS built into a loadable module. Or do i really not understand the problem?

You understand fine; the distinction is between "what is possible" and "what most people do these days". The kernel graphics driver can still be built as a separate module... it's just that since the source code was merged into the kernel tree relatively more people pick up an entire new kernel.

That behaviour is arguably part of the whole discussion here - the X developers are hoping that relatively more people will pick up the entire X+drivers stack and thereby test all the bits rather than just the one they wanted (that's the upside) but the downside is the risk that fewer people will pick up the newer drivers until the entire X+driver set is released (and it becomes too late to fix bugs in that release), which would arguably be worse from a testing perspective than the current situation.

I guess there are really three options, and I'm not sure what is currently being proposed :

- current state (drivers and X in separate projects, changed separately and built separately)
- intermediate state (drivers and X in one tree, can be changed together, retain ability to build & use separately)
- full integration (drivers and X in one tree, can be changed together, can only be built together)

My recollection is that the proposed change is actually the intermediate state where individual drivers can be built independently, and so can be updated independently as long as API/ABI changes don't render the new driver incompatible with the current X. The "definite" downside of the intermediate state relative to today is that you need to download source for the entire X+driver stack even if you only want to build one driver; the "feared" downside is that developers will make so many API/ABI changes that the ability to build and use a single driver will practically disappear because the new driver would only rarely be compatible with the current X.

[nanonyme]

Does KMS *need* to be in the kernel, would it not work if it was a loadable module?

This isn't about that. I had to read this quite a few times to figure out what this is about exactly. I'm still not quite sure.
If I'm right, there's two things here
1) Moving DRM development out of DRM branch into kernel tree. Luc opposed this but it's more of a historical thing, doing anything about it anymore would be painful even if anyone would want to. It has arguments for it and against it anyhow.
2) Moving modular X.org video drivers (in KMS world we're talking about dumb drivers that just rely on DRM for modesetting and acceleration) into the actual X server. As far as I can see, this would mean that
X-server<->ddx<->libdrm<->DRM would be simplified into X-server<->libdrm<->DRM. This would mean one less place where API/ABI can break, however, it would also mean X-server and libdrm would be tightly bound into each other. Personally I'd prefer concentrating work on getting the generic ddx in Gallium to work and moving thus moving into
X-server<->Gallium<->libdrm<->DRM for everything. I think it might lead to significant wins in terms of removed duplicate code as well. This would also allow nVidia and fglrx to use whatever interface there is between X-server and Gallium for the generic ddx (note, I'm not saying they should use Gallium) so we wouldn't lose functionality. Of course, Intel wouldn't agree because they don't want to use Gallium.

[nanonyme]

In a nutshell, my alternative approach would simplify things for those who want to play this together and allow everyone else to keep doing things just like they've been doing them before.

[Xanbreon]

You understand fine; the distinction is between "what is possible" and "what most people do these days". The kernel graphics driver can still be built as a separate module... it's just that since the source code was merged into the kernel tree relatively more people pick up an entire new kernel.

That behaviour is arguably part of the whole discussion here - the X developers are hoping that relatively more people will pick up the entire X+drivers stack and thereby test all the bits rather than just the one they wanted (that's the upside) but the downside is the risk that fewer people will pick up the newer drivers until the entire X+driver set is released (and it becomes too late to fix bugs in that release), which would arguably be worse from a testing perspective than the current situation.

I guess there are really three options, and I'm not sure what is currently being proposed :

- current state (drivers and X in separate projects, changed separately and built separately)
- intermediate state (drivers and X in one tree, can be changed together, retain ability to build & use separately)
- full integration (drivers and X in one tree, can be changed together, can only be built together)

My recollection is that the proposed change is actually the intermediate state where individual drivers can be built independently, and so can be updated independently as long as API/ABI changes don't render the new driver incompatible with the current X. The "definite" downside of the intermediate state relative to today is that you need to download source for the entire X+driver stack even if you only want to build one driver; the "feared" downside is that developers will make so many API/ABI changes that the ability to build and use a single driver will practically disappear because the new driver would only rarely be compatible with the current X.

Thanks for that! If and when I can use the OSS drivers (I need high performance OpenGL for many reasons) I dont think I would want to have to rebuild the whole graphics stack just to pick up an updated driver.

I suppose xorg is the part of linux I am most afraid of breaking, if the worst comes to the worst and i build a new kernel that doesnt boot, no harm no foul, I reboot with one of the other i have installed, with xorg I might have to spend god knows how long purging configs and removing/reinstalling bits.

If the drivers where they own, upgrading one wouldn't be as scary, you just remove/reinstall one part without to much fuss.

Wouldn't it be more sain to have a stable API, where only new API calls where added, and only ones where depreciated after being marked as such for a long time.

Im not a dev, but out of all things linux, the graphics stack seems to be the part in most need of some love (if you ignore PA, but thats a rant for another time).

[RealNC]

You understand fine; the distinction is between "what is possible" and "what most people do these days". The kernel graphics driver can still be built as a separate module... it's just that since the source code was merged into the kernel tree relatively more people pick up an entire new kernel.

Nope. The kernel graphics driver can not be built as a separate out-of-tree module anymore. It could in the past, but after moving in-kernel, the out-of-tree version was dropped.

[pingufunkybeat]

AFAIK, it does not replace large parts of X (or any parts of anything.)

It replaces all of Mesa (much of which is shared now), all of kernel drm (much of it is shared now) and the bottom half of the X stack, and everything related to direct rendering, all of which is shared now. Also it replaces all of Gallium3d, which also has lots of shared code.

A binary blob is a drop-in replacement for Kernel DRM, bottom part of X, DRI, Mesa, Gallium3d and DDX. All of it closed source and working only on one certain manufacturer's hardware.

The Nvidia binary blob, for example, has more source code than the Linux kernel, and is several times larger when compiled.

[pingufunkybeat]

EDIT: Obviously, the open-source way, and the goal of all open source developers is to share code where possible, and not reinvent the wheel.

The only question is whether it's easier to do bundled with X or not.

[pingufunkybeat]

Nope. The kernel graphics driver can not be built as a separate out-of-tree module anymore. It could in the past, but after moving in-kernel, the out-of-tree version was dropped.

I believe that it's still possible to check out the drm part of the kernel and compile it as a module to run with your kernel.

The problem is that the binary compatibility breaks more often nowadays, so there's not guarantee that it will work.