David Bronaugh wrote:
A device driver is not just a wrapper around the device which gives you access to the registers. Even the core components of your computer have a nice interface (your harddisk controller: open/read/write/close etc).
You're speaking of a generic interface to the hardware. The problem (from what I have seen) with doing this with 3D graphics hardware is that it really -is- all different. Different in design. You -could- put a whole OpenGL driver in the kernel, and that would abstract the hardware successfully, but there are a -LOT- of good arguments against this (bloating the kernel's image size by 2-3 megs would probably not be appreciated -- a LOT of bugs would get in, etc.)
You're right, I had the opengl interface in my mind, but I certainly don't want to put it into the kernel. It's good to separate userspace and kernelspace.
Another option would be to design a generic, more low-level wrapper for graphics hardware. In my opinion this is a huge undertaking (ever read chip docs? You try integrating 3000 pages of information (that would be around 5 different chips)). However, if you think this is a good idea, feel free to do it. Just take about 6 months off from life...
That's why I think there should be a more high-level interface.
My idea is that every card creates a device node in /dev which can be openend by anyone with appropriate rights. With each device is a userspace library associated which has implemented the interface
functions (gl*). The interface between userspace library and device node
is not defined, each driver/library pair can create's own interface.
So it is possible to
1) implement everything in userspace and use the device driver only to
access the framebuffer or
2) use hardware acceleration using the device driver.
So it's possible that every driver developer can decide for himself what
to put into the userspace library and what into the kernel driver.
The only interface that is defined is opengl.
(Actually, that's not just an idea, but my project. I've done quite a lot of work so far, now I'm looking for some opengl implementations I could use.)
[1]: even /dev/hda or /dev/sda is readable by world (at least on my box).
Which is fundamentally insecure. People can find your /etc/shadow file on /dev/hda or whatever and run John the Ripper or its ilk on it. Simple matter of using 'grep'.
Ahem.. sorry.. I mean readable by anyone who can log into the machine, not many people in my case. And I'm thinking of usual home computers, not servers. (High performance graphics cards on servers?)
[2]: X isn't easy and DirectFB.. it's a bit better to use but it's still a lot of unnecessary code around the actual driver.
Unneccesary in -your- opinion. How much have you studied it?
Just to render a nice picture using opengl (off-screen)?
David "I am not a DRI developer" Bronaugh
-- wereHamster a.k.a. Tom Carnecky Emmen, Switzerland
(GC 3.1) GIT d+ s+: a--- C++ UL++ P L++ E- W++ N++ !o !K w ?O ?M
?V PS PE ?Y PGP t ?5 X R- tv b+ ?DI D+ G++ e-- h! !r !y+-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
