On 01/04/2011 07:43 AM, Gerd Hoffmann wrote:
Hi,
Windows guests needs some registry hackery and Linux guests some
udev rules
to enable remote wakeup permanently.
That commit inspired me to look at UHCI. If the solution requires
modifying the guest then it is not widely useful.
Well, long-term this shouldn't be a big issue. I expect guest agents
become commonplace soonish as some features require guest cooperation,
so the guest agents can also care about this kind of tweaks. Also for
linux we can try to send the changes to upstream udev to have it
spread into linux distros.
I think we're long overdue for a paravirtual mouse. Basically, a virtio
version of xenkbd-front.c. In fact, it's probably possible to reuse the
protocol.
Regards,
Anthony Liguori
When the guest writes to those memory pages again in order to issue a
new USB transaction, we catch the write. UHCI unprotects the guest
memory pages and turns the frame timer back on.
It isn't that simple. "idle" state depends on the usb devices too.
With a
usb tablet connected (and no remote-wakeup being used) uhci will
poll the
tablet in regular intervals and the usb tablet will either send the
next
event in the queue or NACK the transfer in case there is no event
available.
Is there something preventing USB tablet emulation from using a
non-polling approach? Devices need to be able to kick UHCI when data
becomes available.
remote wakeup is exactly that. Except that it doesn't kick the uhci
directly but the port it is connected to, which isn't the same in case
the device is connected using a usb hub. Which probably makes it
tricky to re-use the remote wakeup callback for the idle detection.
cheers,
Gerd
