sottek writes: > 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.
Well, I would think there are a lot more people who are interested in this subject than are subscribed on dri-devel. dri-devel really has a different scope. > 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. The 'driver' must do mode validation using data supplied by either the display itself or the application (you need the second as some display devices may not support sending this data or the data sent is bogus). Broken video modes usually result from: 1. broken drivers 2. bogus user level configuration/override Egbert. ------------------------------------------------------- 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
