said by me1212:
I would love to know that. Right now as it is people ether have to use crappy intel hd or use the dedicated gpu 24/7 and slice their battery life. Sure theres »bumblebee-project.org/ but its not the same nor as good(imho) is optimus is on windows boxes.
It just seems wierd nvidia amd and intel already have propriatery drivers for linux, I don't get it.
To use both drivers and accurately have them speak to each other, the kernel is used. API in the kernel allows this, without issue. Many of the API's in the kernel have either been patched, moved, or solely created since 2005 in the _GPL session instead of the EXPORT_SYMBOL. This requires the caller to have either a GPL, GPL v2, BSD, MIT, or MPL license ONLY in order to interface with the kernel. Optimus on Windows is allowed to use the OS API in the same space and buffers as Intel's driver; it is not permitted with the Linux kernel due to incorrect choice in licensing. The "oppressing" party is the kernel, here.
Intel's 2d and 3d driver is MIT licensed.
AMD's 3d driver is MIT licensed.
nVidia's shim is GPL licensed.
Intel and AMD can make direct kernel API calls, nVidia can not.
The political debate and pragmatic fallout regarding compatibility with hardware is nothing new. 2006: »lwn.net/Articles/205644/
DMA-BUF is such an API call. While Optimus would certainly take advantage of it, it is Tegra in most need of the call. Firmware graphics handling for ARM SoC's is where the money is (and this does have implications with ARM). Although!!!! take note of the timing, Valve is dumping thousands of man-hours into porting a game over to Linux with nVidia beside them... may be related as well.
Either way, this was foreseen in 2005 when export symbols were split based on developer's "choice" of license... or lack of assimilation, to be more accurate. As kernel API and modules were patched, rewritten, and added; attrition of available "EXPORT_SYMBOL" non GPL calls would force all to a certain choice of license.
said by Alan Cox :
The Linux kernel being GPLv2 isn't a problem we can see for the future. It is a distinct work to the applications that run on it, just as Windows kernel is to Windows applications. The more awkward corner cases will be LGPL and similar licenses where you want the benefits and flexibility. The FSF have indicated they understand that and will ensure it works out. The licenses are about having barriers to abuse, not barriers to use.
I agree, Alan, yet DMA-BUF API call is SPECIFICALLY not listed in "EXPORT_SYMBOLS" non _GPL to barrier use by license...
said by Alan Cox :
Also I'd note if you are trying to do this for the purpose of combining it with proprietary code then you are still in my view as a (and the view of many other) rights holder to the kernel likely to be in breach of the GPL requirements for a derivative work. You may consider that formal notification of my viewpoint. Your corporate legal team can explain to you why the fact you are now aware of my view is important to them.
Big man say big words... Using an API call in a GPL shim to return values to an unassociated application is not a "derivative work". Leave legal scare tactics to "the evil" corps like Microsoft, Google and Apple and open the barriers to use the current kernel has in place.--
Show off that hardware: join Team Discovery and Team Helix