OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [PATCH qemu 3/6] virtio-input: core code & base class


> > It's not different from other input devices.  No buffer space -> drop
> > event.  What else do you think should happen?  We could signal "you lost
> > events" to the guest, but I suspect that buys us nothing.  Other input
> > devices don't have that capability, so guests are likely not prepared to
> > handle the situation.
> For assigned device input events, how about we don't read events off the
> input device file if there's nowhere to put them?

That'll just offload the problem to the kernel.

> For things like sync that qemu generates, I suspect it's a good idea
> to buffer them in QEMU otherwise guest will get out of sync, right?

Grouping things makes sense indeed.  Mouse movements for example are
reported as three events:  one for the x axis, one for the y axis, and
the sync.  We should report either all three or none of them to the
guest to avoid confusion.  I'll think about how to do that best.

> I'm also pretty sure whoever's running the hypervisor does not
> want to see the fprintf.

I'll drop it.  Or maybe better make it a tracepoint.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]