If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
No announcement yet.
Luc Calls For A Dead Linux Desktop If Keith Gets His Way
This is not what is proposed here, this is not why the nvidia driver is mentioned.
The nvidia driver was mentioned, because it is the most popular, and the one we hear the least people complain about. The reason for that is: it just works for more of the time than any of the other drivers out there.
One major part of that is: people can just grab it and install it, and be pretty secure in that nothing else in their system, except the nvidia graphics driver stack itself, will change.
This is what we can learn from nvidia (and unichrome, and to some lesser extent sis and radeonhd)
Ya. I haven't personally complained about the nvdia blob for quite some time. You want to know why? Because I don't use it and I won't use it. I haven't had the blob installed since core 10 and I ran core 7 before that. So if you are expecting people to complain about the blob then it's not going to happen because they are all off in stable code land not caring about nouveau or ati project.
Another thing you can learn from nvidia. I think I'm running 196.30 driver under windows. I ran 182.something driver before that everything in between failed in some way or another. But it's a who cares situation. If you got a driver that works then who cares. When I want to run something new or different I go through the searching for a driver that will work phase.
Same thing with catalyst. Some people are stuck on the 10.4 drivers, some people are stuck on the 10.7 drivers. I figured you guys would do all this codeing and get it worked out in modular fashion and then suck the code into the kernel.
If you all are wanting to get this sucked into Xorg you still got to leave it modularized for a good year to a year and half to get it working well enough to suck it back into Xorg. But that just logically seems like an entirely different transformation for an entirely different time period. Through this ENTIRE process. I have been forced to downgrade X ONCE!!! I'm talking about installing every single version of X from 1.7.1 to 1.8.2-4 and it's only messed up ONCE. So at least screw things up badly before you allow someone to facilitate change. And watch out for group dynamics. These things can get sharky.
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.
don't move the drivers back into x server.
Will somebody please tell Keith that there is no such thing possible as to force api-keep up. That will not work with this approach. If your api's keep being broken, isn't it time to consider the way you handle api's? That's the problem with x server. All the api's are constantly changing. They should modularize old api's in libraries that can be optionally installed. And that will not exist with tying everything together. In the contrary he makes it worse. This will cause a lot of grief for graphic developers. Cause a lot of overhead.
This is a really suffocating kind of feeling you get from this situation. About the complete opposite of what free software wants to stand for.