On Mon, 4 Oct 2021, Howard Spoelstra wrote:
Hi all,
One more observation: When running Mac OS guests with -mac99,via=pmu, the
guest is presented with a usb-mouse and usb-kbd, while -mac99 provides cuda
mouse/kbd.
If I run with via=pmu, the mouse/kbd will not work when passing through the
usb headset.
Only when I keep interrupting by pressing a volume button on the headset,
the mouse moves. So it seems Qemu does not iterate getting interrupts over
multiple devices.
It the MacOS HID driver works by always keeping a request pending to
receive any events that become an async packet waiting on your usb headset
ep 4, this currently blocks all of OHCI and no other packets go through
until this async packet completes (when you press a button on the HID
device). So the comment in code not only means that different endpoints
block each other but one endpoint blocks the whole controller which is
clearly wrong. I think this confirms the theory that we'd need to fix
this.
I've tried removing the async_id from OHCIState but I'm lost between all
these callbacks. Maybe somebody who knows more about QEMU USB and OHCI
could take a look or are there some docs about what callbacks are called
when in QEMU when something happens? I'm interested in the child detach,
detach and async complete callbacks (which handle pending packets in
hcd-ohci) and if they can be called while ohci_service_td is running
(which submits packets and also called for handling completed async
packets). Maybe ohci_service_td should be split into two parts: submitting
and handling returns, so only the completion part is called from
ohci_async_complete_packet callback but that needs to find the OHCI struct
for the packet to put results in so now it just triggers a complete
processing of all requests and handles completion if it finds the packet.
I'm lost in the possible interactions between these callbacks so some info
on that might help.
Regards,
BALATON Zoltan
