Sottek, Matthew J writes:
I agree. I think we are on the same page. A minimal set of features
is
all that would be part of the defined mode setting API. It is just a question of if some of the multi-head concepts are generic enough to be part of that defined set.
That's exactly the problem. My experience is that many things in mode setting are just too interrelated. You can easily design a very tiny API to set up a mode to get something drawn to the screen, however if you want to make use of all the nice features your hardware offers you will find out that this tiny API is more in your way than it is useful and you'll end up duplicating everything.
You have a valid point, making a small mode API will guarantee that the most advanced drivers are going to have a duplicate API to reach their most advanced features. I don't see this as a problem.
We must have a Device independent API such that software _can_ be written that will set modes and/or do some minimal drawing. Maybe the "oops displayer" or an OS installer etc.
We also must not make the API so advanced that it is hopelessly mangled with one-off features of rare hardware. Those one-off features will have to be reached only by applications with device dependent knowledge.
So I see the small duplication of API features as the solution, not the problem.
Boy, I haven't really been following this too closely, but surely this sort of thing can be resolved with an extension mechanism or api versioning?
Keith
-------------------------------------------------------
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
