Can we wrap this up the discussion and try to get to a consensus on
design requirements? I think most of the opinions are starting to
solidify enough to start hashing out the requirements and actual
design.
Also, we probably want to drop the communication down to just one
list? I think dri-devel seems to have the widest group of subscribers.
To start the ball rolling here is a few requirements that I have. We
can build up the list and veto as needed to try and get to a working
set.
1: Design must provide a mechanism for basic mode setting in a
device independent manner from an application with user level
permissions. ("Basic" to be defined)
2: Design must provide a mechanism for any number of driver dependent
extensions.
3: Design must provide a mechanism to allow the kernel to draw oops
or console messages to the screen in any mode.
4: Design must insure that user applications may not set the hardware
into an unstable state that could lead to lockup or damage display
devices.
5: Design must incorporate a bi-direction API versioning system. The
application must indicate the API version it is expecting first,
followed by the driver's reply.
And some that may require some discussion:
6: Design must provide a mechnism by which the driver can inform a
user application of acceptable modes that may later be applied to
hardware.
7: Design must provide a mechnism for user level applications to
use rendering features of hardware in a secure manner.
8: Design must provide a mechanism for multi-framebuffer and
multi-display per framebuffer devices to be controlled.
-------------------------------------------------------
This SF.Net email is sponsored by Sleepycat Software
Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to
deliver higher performing products faster, at low TCO.
http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
