Re: OpenGL-based framebuffer concepts

["Jon Smirl" <jonsmirl@gmail.com>]

On 6/2/06, D. Hazelton <dhazelton@enter.net> wrote:
> Actually, Jon, Dave is thinking like I am in that the DRI drivers needs to be
> loaded for use. Rather than forcing applications to include all that code the
> userspace daemon can be configured to load the DRI driver and provides the
> userspace interface to the system. Using a daemon for a simple task, like
> modesetting, is idiotic - but using the daemon to provide userspace with full
> access to acceleration (the Kernel drivers only provide the backend for the
> acceleration. The userspace side actually provides the code that manages it
> all) without needing to have to worry about loading and initializing the dri
> drivers provides a method for anything from a scripting language to a full
> compiled application easy access to the acceleration.

You are confused about this. Nobody wants to change the way DRI and
DRM work, it would take years of effort to change it. These are shared
libraries, it doesn't matter how many people have them open, there is
only one copy in memory.

Applications don't 'include' all of the DRI/DRM code they dynamically
link to the OpenGL shared object library which in turns loads the
correct DRI shared library. The correct DRM module should be loaded by
the kernel at boot. You can write a 10 line OpenGL program that will
make use of all of this, it is not hard to do. User space has always
had access to hardware acceleration from these libraries.

We have not been discussing DIrect Rendering vs indirect (AIGLX). It
will be up to the windowing system to chose which (or both) of those
model to use. The lower layers are designed not to force that choice
one way ot the other.

Dave wants to load the existing X drivers into the daemon, not the DRI
libraries. Other than using them for mode setting there isn't much use
for them. I have asked him where he wants things like blanking, cmap,
cursor and he hasn't said yet. Those functions are tiny, ~100 lines of
code.

-- 
Jon Smirl
jonsmirl@gmail.com