Kernel support for graphics cards

[Bojan Smojver]

Quoting Carsten Haitzler <raster at rasterman.com>:

> i'd argue "why not" as well. but the kernel developers disagree. and i woudl
> say that doing a gfx driver in userspace definitely makes for easier
> development & debugging. :) also it means for better performance
> characteristics of an OS if the gfx subsystem is doing some heavy software
> fallbacks - the driver can be pre-empted trivially... like any process...
> because... it is a process! :) seriously though - all that is really 
> needed is
> enough support hooks in the kernel to allow userspace gfx drivers - 
> that's it.
> and thats mostly there already.

I think there is some confusion here, probably related to the way I 
asked the question (maybe even the subject line).

What I'm concerned about (and Keith's paper appears to be too) is the 
fact that both the X and the kernels do things directly with the 
graphics hardware. I sure wouldn't like my apps mucking around with 
registers on my network card or SCSI controller without kernel's 
approval first. So, the same should be true for graphics cards. And 
because various systems can manipulate the same hardware resources, 
many times in a completely uncoordinated fashion (IMHO, good 
coordination should not be an excuse to keep things the way they are), 
this then leads to "an application (X) rendered my system unusable" 
problems (like it did in DOS days).

So, let me try again: my questions relate to making sure that X doesn't 
drive the *hardware* directly (and I'm actually surprised modern 
kernels allow it to do that all). The question isn't about moving all 
of the "X drivers" into kernel, just about not poking around hardware 
directly, which I think everyone agrees is a really bad idea.

-- 
Bojan