>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. ------------------------------------------------------- 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
