Kevin Lawton 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.
Okay, I agree ! :)
> 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.
Sounds decent.
-- Ramon
