Kevin P. Lawton wrote:
>
> Ramon van Handel wrote:
> >
> > >To have semi accurate delivery of video/sound/etc, you really need to
> > >know that user process will be notified (roughly) at a particular time,
> > >so using a timer is the only way I can think of to do this properly.
> >
> > I guess it depends on which way you look at it... IMO, as the real VGA works
> > synchronously, you don't want to deliver video "at a specific time" but rather
> > "as soon as it's written to the video memory". As soon as possible, anyway.
> > Sound is a different matter entirely.
>
> How the real VGA works is immaterial. How to display data correctly
> to the user, with reasonable performance is.
Well, of course, but as we're mimicking the VGA we probably
want to mimick its behavior (in the most general sense)
as well, not only its functionality.
> We certainly don't want to jam more data at X windows every time a byte
> is written to the framebuffer.
Of course not. Though ideal in principle, in practice the
performance hit would be huge. That's why I suggest
update (more or less) after every quantum the guest ran,
as a compromise between performance and realism.
> For certain components such as the video emulation, if they
> are offloaded into a thread of their own, then perhaps we
> won't need to use a signal() timer, since we could invoke a blocking
> call to X to receive the next keyboard/mouse event.
That's also an advantage.
> But for sound, you need to deliver packets on certain time boundaries.
Yes, but they're pretty large boundaries I think. Not that
that matters of course.
> Other devices may need this as well, so we need the infrastructure
> in there.
A timing infrastructure is a good thing, but I was
thinking of having that more in the terms of guest
timing... what point is there in having a host timing
infrastructure ?
> > >Just keep in mind, the way thing are currently done is a hack, since we
> > >don't support the IO mapped frame buffer yet.
> >
> > Uhhhhh... what are you referring to ???
>
> The memory range 0xA0000 .. 0xBFFFF is memory mapped IO.
Okay... you were talking about "IO-mapped memory", that got
me confused ;)
> With such
> memory, you can not expect that what you write into it, is what you will
> read out of it, because it could represent anything. It could represent
> IO ports, or in the case of the VGA in planar mode, weird latching
> takes place which operates on multiple bytes at a time.
Okay; I don't know anything about this latching so
I'll take your word for it.
> Thus we would need to virtualize IO memory mapped ranges, and redirect
> IO ins and outs to the VGA hardware emulation, to do this correctly.
Sounds awfully slow...
Ramon
