Ramon van Handel wrote:
> Yes, I do understand this!! but it doesn't solve the problem, as
> I see it (though it does reduce it). Let me try to explain
> again.
> Of course this would be nice, but running old DOS software (for
> instance) would still require pretty accurate timing... and you'd
> like at least halfway decent performance even for guests that
> you did not write custom drivers for (yet).
OK then, it's agreed. We won't do any skewing for now. :^)
How about we get some basic stuff working and then deal with
this stuff later. Any way you slice it, timing has to
be in the monitor, otherwise performance will get beat to
death switching from user<-->monitor all the time. Any
extensions you want to make will have to enhance the
monitor timing framework. So I'll just code that.
With skewing, as long as you establish lower and higher
bounds of the skew factor you may apply to the timing,
you can keep the skew within reason.
-Kevin
