Do you not know how dangers are exploited?
Crafty hacker takes over the nvidia blob (which has unknown number of severe dangers waiting to be exploited), and USES IT to interface with the kernel through DMA-BUF.
Being fanatic about GPL won't make your laptops run faster. Be reasonable. Nvidia is not a single person you can blame with bad attitude towards OSS community. Besides engineers it is hoard of lawyers and salesmen who simply count their money. If kernel devs say no-way you get those symbols to Nvidia, then we — end users — won't see Optimus working in any near future, because GPLing the blob is absolutely unreal. One option for Nvidia is to implement Optimus in their driver but leave patching the kernel to distribution. Another solution for security sick ones would be digital signature mechanism so only trusted vendors would be able to use this kernel interface, but devs won't go this way for sure.
Stop spreading that nonsense, droidhacker! It won't be a license violation and Nvidia blob already has a kernel module. Go and hack it !Quote:
Originally Posted by droidhacker
Nvidia's goal here is to keep people from switching their chip off from the BIOS in laptops where having it switched on will have a severe negative effect on battery life --- basically, they don't want people to do what I did with my dual GPU AMD system (both AMD GPUs). I switched off the high performance chip because all it does is suck on the battery. Of course in a dual-AMD system, there is no issue with GPL-only restrictions on the interfaces.
Nvidia GPUs on laptops are pretty much always combined with INTEL primary low power GPUs. Switch off the nvidia and it might as well not be there. Without being able to interface with the intel chip, all it will do is eat battery. It would really suck for them if people REALIZED that the nvidia chip is just a waste.
I can't think of even ONE task that can't be handled by open source drivers.
Performance is MORE than adequate -- high enough in fact, that I disabled my discrete GPU from the BIOS.
Power consumption... is lower (for my laptop) on Linux than it is on winsuckers. No, I don't dual boot, I erased that crap. Spec says 2.5 hours battery, reality is about 4.
To what amount of time are you referring? My chip is an AMD NI. That makes it about 1.5 years out the gate NOW (less than 1 year out when I purchased it). NOT TEN.
And you are so thoroughly blinded by your misconceptions that you can't accept that your arguments only apply to a VERY small subset of "zealots", not even a significant portion of the open source development community.Quote:
Reality doesn't match the fantasy world you have created in your head. Linux devs seem to only care about being able to run X11 with an xterm on it and do coding in Emacs and vi. They're stuck in the 1990's. Also, they behave like children. They constantly repeat the same thing, "I want the code", like a child in a candy store repeatedly shouting "I want candy." They should grow up and learn to cooperate with proprietary vendors. Even the hardcore "Free Software or Death" guys at FSF gave the world tools to create proprietary software if they so wish (like GCC and glibc). That was a sane decision. It's funny how the kernel devs distance themselves from the "Free Software zealots" and the likes of RMS, but then play the "proprietary drivers are evil" card. What a bunch of hypocrites. The only explanation that makes sense is the conspiracy theory; AMD and Intel trying to damage NVidia. It simply doesn't make any sense otherwise.
Renaming symbols to "EXPORT_SYMBOL" does not change anything. You still can't link a binary blob to the linux kernel because the linux kernel is GPL v2 only and the only license that covers any of this is the one in the COPYING file. According to many developers, including Mauro and Alan Cox, this "patch" wouldn't make blobs using DMA_BUF any more legal than now. to use DMA_BUF, you need to interact with the kernel differently than the Nvidia blob does now, and there's no way to do this without making parts of your driver a derivative work of the kernel.
This is not a decision that the kernel devs are making NOW, it is a decision Linus made back in 1991 when he first released Linux. That is the license, and it cannot be retroactively changed, without every single contributor agreeing to it, so Linux is GPL v2 and will remain so forever. If this interferes with Nvidia's business model 20 years later (because they introduced Optimus technology well knowing that it't not compatible and will not be compatible with Linux), then it's unfortunate, but there is NOTHING anybody can do about it.
Renaming the symbols would not change squat, binary blobs using DMA_BUF are illegal and there is nothing anybody can do to change that now, 20 years later. Either join the bandwagon with the companies providing in-tree graphics drivers (Intel and AMD), or give up on the technology you designed not to be compatible with Linux.
The alternative would be to ONLY have KMS drivers and run llvmpipe for everything else. That would be very slow. So yes, absolutely, GPL makes my laptop FAST.
What's your point?Quote:
Be reasonable. Nvidia is not a single person you can blame with bad attitude towards OSS community. Besides engineers it is hoard of lawyers and salesmen who simply count their money.
Maybe it will teach people NOT TO BUY NVIDIA.Quote:
If kernel devs say no-way you get those symbols to Nvidia, then we — end users — won't see Optimus working in any near future, because GPLing the blob is absolutely unreal.
And just WHO would be a "trusted vendor"??? I sure don't trust nvidia. I'm sure I'm not the only one.Quote:
One option for Nvidia is to implement Optimus in their driver but leave patching the kernel to distribution. Another solution for security sick ones would be digital signature mechanism so only trusted vendors would be able to use this kernel interface, but devs won't go this way for sure.
Meanwhile past the world of gaming Linux has long enjoyed a strong position in 3D/SFX where it entered the pipelines as render clusters but has now progressed to support the entire pipeline which is why 3d content software like Mudbox, Maya etc have Linux versions. If graphic performance was 'bad' as you try to paint it, this would never have happened as these programs really rely on gpu performance.
But of course the BIG thing is that discrete GPU's are becoming obsolete for the end user desktop in favour of GPGPU solutions like Intel's which is fully open source and thus can tap right into the kernel driver infrastructure and take advantage of what it offers. This means that your -'graphics evolve past their ability to catch up' statement is just bull.
As I see it Linux has never been in a better position in terms of graphics, there's a new display server coming in the form of Wayland, Valve is working with hardware graphics vendors to increase Linux performance for gaming, discrete GPU's which has been a sore point in terms of open drivers are being obsoleted on the desktop in favour of open source GPGPU solutions, and for those who are using discrete graphics there are both official proprietary offerings AND open source offerings.
As it is now, the kernel developers offers the following incentive for open sourcing your drivers, once in the tree they will maintain it against changes in the internal interfaces thus making use of new functionality and even fix bugs as we find them. The price is to open source so that it can be shipped as part of the kernel.
NVidia refuses and so they maintain their proprietary out-of-tree driver which re-implements functionality they would have gotten for free if they would open source the driver. That is their choice and noone says they can't do so, however now they want to make use of existing kernel solutions rather than writing their own as they've done sofar, of course without open sourcing their driver. Obviously the kernel devs will disagree as the whole point is that proprietary blobs is a nuisance at best, and a raging security/stability hole at worst from the perspective of the kernel devs, and as such they sure don't want to make it more comfortable to maintain binary blobs against the kernel.