> > Hi, > > > > Completely separate question: Have you figured what the root cause for > > > the bug is? > > > > > While wading through the code I've figured the queue size > > > isn't (directly) exposed to the guest. > > > The process correspond with the above linux kernel code, i8042_flush(void). > > So linux tries to flush the buffer, then is confused in case it can read > more than 16 bytes (which is the buffer size of real hardware) without > seeing the status register signaling that the buffer is empty. So the > qemu internal buffer size is indirectly visible to the guest. > Agreed.
> Hmm. > > We could try sending the data to the guest in chunks, i.e. signal > "buffer empty", then set up a (short) timer when we'll go make it appear > to the guest as if new data arrived (which in reality just comes from > out large buffer). > > Not that easy to do, as we should better avoid splitting messages in the > middle. > > > > but for mouse events we > > > probably want keep some more space to buffer events ... > > > > > Maybe you are right, and I worry about it too. At present, > > but I haven't feel uncomfortable by VNC client then before. > > Do you have a usb-tablet attached, for more comfortable absolute > coordinates? If so, then the ps/2 mouse will not be used to deliver > events to the guest. > I have tested the two situation, both using usb-tablet and not using usb-tablet . > And as this is a pretty common setup we maybe should not worry too much > about the ps/2 mouse queue depth ... > > cheers, > Gerd > Best regards, -Gonglei
