[Mesa3d-dev] Re: library for cursors and mode setting

[Egbert Eich]

Jon Smirl writes:
 > --- Egbert Eich <eich at pdx.freedesktop.org> wrote:
 > > Writing mode setting code is not easy. The stuff that is documented
 > > in the specs consumes about 10 percent of your time. What is not
 > > in documented provides the most grief. It would therefore be desirable
 > > having to do this only once (Today we do it at least twice already-
 > > in the Xserver and in the Linux kernel).
 > > I would therefore *strongly recommend* we come up with a solution
 > > that is usable everywhere: For everything that's interested in mode
 > > setting both on Linux and non-Linux OSes.
 > 
 > I'm all for this, I just attached Brian's file as a way to get started. I'm also
 > totally in favor of reusing every piece of code that we can.
 > 
 > Each of the existing solutions has it's flaws:
 > 
 > X drivers:
 >    X specific, not useful outside of X
 >    they do a lot more than mode setting and cursor support

Right. Experience has shown that the hardware is the fastest evolving
piece in the game. Making any assumptions about hardware capabilities
outside the driver will soon require kludging around to support features
that oone thought of when the code was designed.
Therefore the driver was put in charge to decide how to map upper level
functionalities onto what the chipset is capable of.
This doesn't mean that there may not be a (to some extent non-generic) 
API inside the driver which separeates the low level hardware programming 
from the application dependent 'functionality mapping'.

 >    they are implemented completely in user space

Right. There was good reason for this.

 >    they manipulate the hardware without telling the kernel

Also correct. At least at the time this was designed there were
no interfaces to tell the kernel.
 > 
 > Kernel drivers:
 >    They only know about a single head
 >    they don't do memory management, multi head support requires it
 >    DDC code in kernel is big, 100K, and relatively seldom used
 >    they are hard to debug
 >    hard to implement user space config files
 > 
 > My preference is for a blend of both worlds:
 >    Minimum code in kernel driver
 >    but all code that touches the hardware is in the driver

Which driver? Kernel? In general I don't see a huge benefit in touching
mode setting registers from inside the kernel although some hardware may
require this.
I case of 2D acceleration it may create a signifficant performance penalty.


 >    Multihead support that is coordinated with DRI memory management
 >    user space library with single API

Single API will work only if you allow for chipset specific extensions.

 >    user space library loads personality libs for each card family
 >    personality libs use private IOCTLs to their corresponding drivers
 >    mode computations done in user space with IOCTL to set result into HW
 >    DRM and FB are combined into single driver
 > 
 > Of course this blended system would be completely implemented by copying files
 > from the other projects.
 > 

Make code reusable for other OSes. Especially code that deals directly
with hardware and its quirks is not 'cheap'!

Egbert.