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.
I also think the dma-buf should be opened up to closed-source drivers -- as I understand, the debate is mostly political than technical.
Not quite. It's not technical, in the sense that it would be difficult to expose those interfaces. But it's technical in the sense that supporting binary drivers is a pain in the ass. For the most part, that's the kernel developers main issue around binary modules - it's less about the politics and ethics of closed source, and more about an unwillingness to deal with invisible code.
But having it as GPL wont "force" anyone to mark their software as GPL (or other FOSS licence) ... I pretty much share the PoV in this article → http://www.theregister.co.uk/2011/05...rs_and_takers/
If that codepath is GPL, nVIDIA won't use it, and won't open up their drivers...end of the story : No Optimus Support
They support Linux because it's in their interests, not because "it's a good cause" ... and, unfortunately I don't see Optimus with any kind of application outside the consumer market.
Unfortunately nVIDIA is not the kind of company that likes to play "open"
So, that's when, as customers (of whatever GPUs) we have to be vocal about the importance of FOSS drivers for us.
I guess we could say that this would be nice+convenient for the short term, but most likely damaging for the long term. So thanks, but no thanks. We can live perfectly well with the blob as-is for a few more years until the OSS drivers will be able to handle this (assuming they will...).
I have to laugh at all the people here who feel like making comments without even reading the LKML thread. If they did, then they would know that the issue is not that the kernel should be enforcing the GPL on external modules, but the contrary; it should not. The current behavior is a bug. External APIs have to be flagged as such. That's Linux kernel policy and it has been there for ages. It's vital that Linux can be used by proprietary vendors and that you can run proprietary software. But the DMA-BUF API, even though it is a driver interface, has not been flagged as an external interface, even though it should have been.
But if you guys would even care to spend 3 minutes to read the LKML message, then you would have known this. Instead, you chose to make up an issue that doesn't even exist: Linux infecting all software that runs in it with its own license, trying to prohibit people who disagree with it from making their own choices. Linux clearly doesn't do that, never did and never intended to. That's Microsoft's business model, not Linux's.
Most of the "magic" in the AMD/NVIDIA proprietary drivers is nowhere to be seen in the Open ones, particularly their shader compilers, command queue schedulers, video decoding, and so on.
And what magic did they have in the register layouts of their ethernet chips, that prevented them from releasing an open driver even for those? They could at least release datasheets, even deprived of the video decoding interfaces in the case of graphics cards. Their competitors, if that's their concern, can already obtain that information by reverse engineering their Windows drivers.
Intel's drivers seem to work under Linux pretty much as well as they do under Windows, so they at least can manage to achieve acceptable results even without any special technique that supposedly they woudln't want to use in the open. I hope that in the future, either their upcoming hardware or AMD's open source drivers will raise the bar for open source graphics stacks, as Linux did for open source operating systems. Then Nvidia will feel it more "natural" to join the others.
If I were a kernel developer answering this question of whether NVIDIA should be allowed to link its driver to DMA-BUF, based in history and on legal grounds, I'd say:
OVER. MY. DEAD. CORPSE.
The fact that NVIDIA fought a pathetic fight to keep their nForce code closed and to support a binary blob for something as basic as a NIC (an already lost battle thanks to the guys behind forcedeth) doesn't help.
haha i like this answer: "OVER. MY. DEAD. CORPSE." *Trumps up*
Speaking from an end-user (ie, non-developer) POV, i'm quite conflicted about the possibility of such a move.
On one hand, it does bring Linux hardware support up an additional notch now since hybrid graphics switching will finally be supported on desktop / notebook Linux, and in this case, NVIDIA itself is offering to provide Optimus support for Linux as long as this little issue about DMA-BUF is resolved by removing the restriction to export GPL symbols only. At least, it is much better than NIVIDA's previous behavior of completly shutting the door on Linux over optimus when it was first introduced in Windows 7 notebooks. And considering how Linus Torvalds once said that he considers the choice for any user to use any tool he / she desires. regardless of it being open or proprietary, as almost sacred, we have no say about what drivers a user should use, and they should be free to adopt any driver that bests suits their needs.
Thing is, by doing so, are we sending a signal that it is 'ok' to use binary drivers? Im not going to argue about the pros and cons of both open and closed drivers, but binary drivers are known to break whenever a distro rolls out a kernel update (eg: 2.6.27-20 to 2.6.27-30). And when end users find themselves faced with a blank screen and no X upon doing such an update, what is the first thing they do? Scream about how Linux sucks with updates, remove it and go back to Windows, and Linux gets a bad name for no reason. Also, there is the real possibility that lesser hardware companies will be inclined to release open drivers now that one key restriction is removed.
I'd vote for an interim solution in which the 'GPL symbols only' on DMA-BUF is allowed to be removed for a period of time for NVIDIA and only NVIDIA, and whether this restriction stays removed or not will depend entirely on NVIDIA's wilingness to play nice with our needs. As one user has said earlier, we can barter the restriction in exchange for KMS support or co-operation for other technologies, failing which the restriction will be reimplemented.
And anyway, it would appear that the Bumblebee + Nouveau support is moving along at quite a reasonable pace; sure you don't get the full performance of what the card is capable of doing, but at least there is rudimentary support for switchable graphics.