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