*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.
Announcement
Collapse
No announcement yet.
Luc Calls For A Dead Linux Desktop If Keith Gets His Way
Collapse
X
-
Originally posted by Xanbreon View PostWhat 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?
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.Test signature
Comment
-
Originally posted by Xanbreon View PostDoes KMS *need* to be in the kernel, would it not work if it was a loadable module?
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.
Comment
-
Originally posted by bridgman View PostYou 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.
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).
Comment
-
Originally posted by bridgman View PostYou 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.
Comment
-
Originally posted by RealNC View PostAFAIK, it does not replace large parts of X (or any parts of anything.)
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.
Comment
-
Originally posted by RealNC View PostNope. 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.
The problem is that the binary compatibility breaks more often nowadays, so there's not guarantee that it will work.
Comment
Comment