Which is ridiculous, considering they cherry-picked RandR of all the technologies in the "Linux common infrastructure" to support with their latest driver release. I suppose I should be grateful that my projector can work without opening up NVIDIA Settings and tweaking about, but it certainly flies in the face of this statement and belies their true motivations: they'll implement the bare-minimum Linux-only feature support that will keep their business/edu customers from fleeing to AMD, and that's about it.
RandR is a Xorg extension, it's not a Linux kernel thing. To continue to provide graphics options for their customers that use OS's with recent Xorg installs (they make a FreeBSD driver available too) they had to support RandR.
This is right in line with 'we support our customers/users' not whatever the Linux kernel guys feel like doing today.
That's spun and unfair. Booting with a working framebuffer isn't something that tickles only the "kernel guys" interest. Running the GPU on your hybrid laptop likewise. You realize that, with just a handful of exceptions, the NVIDIA part on most Optimus laptops simply doesn't work under linux, right? And that NVIDIA hasn't so much as lifted a finger to fix this?
So sure, if "customers/users" includes the only handful of 3D content shops out there running linux toolchains, and not the millions of people buying NVIDIA-enabled laptops, I guess it makes sense. But for everyone else it kinda sucks.
Hardly. NVIDIA says they "made a decision to support Linux on our GPUs by leveraging NVIDIA common code, rather than the Linux common infrastructure." HN responder says that's bullshit since they finally support RandR. I point out RandR is not 'Linux common infrastructure' but a Xorg technology and supporting that is very literally "supporting Linux ... by leveraging NVIDIA common code" because the NVIDIA common code is targeting Xorg technologies and not Linux specific ones.
Then you move the point to something completely different.
NVIDIA is clearly not interested in providing any Linux only support. Don't expect them to support anything under Linux that isn't also common to other platforms they support.
You're just making things up, stop it. DRI2 and KMS are no more "linux kernel" things than "X" things; all you have to do is check the domain hosting the specs. These are well established, well-supported APIs that have been very well received in the Linux world. And yet NVIDIA wants nothing to do with either, for silly internal reasons with poor justification.
> You realize that, with just a handful of exceptions, the NVIDIA part on most Optimus laptops simply doesn't work under linux, right? And that NVIDIA hasn't so much as lifted a finger to fix this?
I have an Optimus laptop (Thinkpad W520) and that's not really true. The problem is that you can't run both the Intel and NVidia chips at the same time without it being a PITA. If I want to use my internal display while I'm on the road, I move my NVidia Xorg.conf out of the way and it's fine. I'm not saying it's optimal, but it definitely works.
There's not just one Optimus implementation, there are many ways to wire Optimus. My colleague bought an Optimus laptop (can't remember which one now) that absolutely doesn't have the nVidia part of Optimus working. See here for details: http://nouveau.freedesktop.org/wiki/Optimus
> Booting with a working framebuffer isn't something that tickles only the "kernel guys" interest
Is it? If my computer boots up directly to X anyway, why do I care about a framebuffer beyond the standard vesa stuff?
PS: If Linus would get off his high horse about closed source drivers, and commit to have at least a somewhat stable ABI, that would do more for hardware support on linux than 1000 years of ranting and moaning, which if anything, will only alienate the hardware makers even more.
"If Linus would get off his high horse about closed source drivers"
... then he would be Microsoft and Apple, and not an Open Source operating system developer, maintainer, producer, and evangelist. All his years of working openly and freely will be squandered and his life's work beholden to closed-source, closed spec device manufacturers.
But his stance actually makes us much MORE beholden to the 3rd parties. If every minor kernel version didn't require the vendors to recompiled drivers, and quite possible change code because Linus changed the ABI again, that would result in more hardware working better for more people.
Live the open source dream if it makes you feel good. I live in a world where if it doesn't work, I couldn't care less about it.
I don't think reality bears this out. Now that Broadcom has come to their senses, NVIDIA is pretty much the only major consumer device vendor in the PC space with binary blob drivers. Everyone else has, ultimately, folded in the face of pressure from the dogmatists. I think Linus is pretty much winning, and the fact that NVIDIA is feeling pressure here is a good thing.
Do you have any examples of situations where this is making us "MORE" beholden to third parties? I honestly don't see many (though in the SoC space, the PVR drivers are a very similar situation).
Didn't AMD release a ton of documentation for their GPUs specifically so that the open source radeon drivers could become a realistic option when using their GPUs?
Nobody I know with an AMD GPU uses the propriety fglrx drivers.
Open source 3D drivers will have a hard time EVER being useable for anything beyond glgears... everything in that space is going to be really patent encumbered.
Having an unstable, internal kernel interface has nothing to do with being opposed to closed source drivers. Linus' problem is when people bitch and moan when things change and it breaks closed source drivers. He's repeatedly said that anything internal is fair game to change. If your driver is in the kernel it will be fixed if the interface changes; if it's closed then you better keep up on your own.
