On Mon, 2013-03-04 at 11:28 -0500, Walter Dnes wrote: > On Sun, Mar 03, 2013 at 10:48:07PM -0500, Rick "Zero_Chaos" Farina wrote > > > I am sorry that this package has been such a headache for you, > > unfortunately binary drivers (especially) are often like that. Thanks > > for all your hard work keeping this usable. > > I'm not a C programmer, let alone a developer, so this may be a stupid > question, but here goes... has anyone ever tried doing a HAL (Hardware > Abstraction Layer) to present a reasonably stable interface to binary > video drivers? Think of it as a shim translating a "pseudo-API" into > "the real API" that the kernel exposes directly. Surely, we can do > better than VESA. Give drivers 2 options... > 1) direct kernel access like now > 2) access via the HAL/shim
For video drivers, there are only a few things that can be abstracted away, e.g. hardware access synchronization, DMA, power management, a memory manager for GPUs without dedicated video memory. And the kernel already does have an API for this, called DRM (direct rendering manager); see https://www.kernel.org/doc/htmldocs/drm.html However, nvidia-drivers does not use this API, probably because they want to share code between their Linux and Windows drivers, and the Linux kernel's DRM API is too different from what Windows does. In addition, there might be licensing issues: I once read an argument that if a proprietary kernel module is too closely integrated with features that exists only in the Linux kernel and that cannot be applicable to other operating systems, the module might legally become a derived work of the Linux kernel, and so would need to be open-sourced under the GPL.
