C>> annot manage 'EHCI USB controller' PCI device type 'usb':
>> 8086 293a (c 3 20)
>> Cannot manage 'UHCI USB controller' PCI device type 'usb':
>> 8086 2934 (c 3 0)
>> Cannot manage 'UHCI USB controller' PCI device type 'usb':
>> 8086 2935 (c 3 0)
>> Cannot manage 'UHCI USB controller' PCI device type 'usb':
>> 8086 2936 (c 3 0)
I believe this just means these devices are not in the openbios pci devices list.
To my knowledge, Mac OS 9.x to 10.2. 8 only supports an ohci controller with usb 1.1 speed. One is added with -usb.
(For usb pass-through to work you can add an ehci controller from 10.2.8 upwards. With ohci, usb pass-through works only for some devices with transfer methods that do not require multiple active endpoints.
This has been diagnosed, but not fixed)
Mark showed me the usb issue through a dump in the monitor with "info qtree"
-M mac99,via=pmu:
dev: pci-ohci, id ""
masterbus = ""
num-ports = 3 (0x3)
firstport = 0 (0x0)
addr = 0d.0
romfile = ""
romsize = 4294967295 (0xffffffff)
rombar = 1 (0x1)
multifunction = false
x-pcie-lnksta-dllla = true
x-pcie-extcap-init = true
failover_pair_id = ""
acpi-index = 0 (0x0)
class USB controller, addr 00:0d.0, pci id 106b:003f (sub 1af4:1100)
bar 0: mem at 0xffffffffffffffff [0xfe]
bus: usb-bus.0
type usb-bus
dev: usb-mouse, id ""
usb_version = 2 (0x2)
port = ""
serial = ""
msos-desc = true
pcap = ""
addr 0.0, port 2, speed 12, name QEMU USB Mouse, attached
dev: usb-kbd, id ""
usb_version = 2 (0x2)
display = ""
port = ""
serial = ""
msos-desc = true
pcap = ""
addr 0.0, port 1, speed 12, name QEMU USB Keyboard, attached
-M mac99,via=pmu -usb -device usb-kbd:
dev: pci-ohci, id ""
masterbus = ""
num-ports = 3 (0x3)
firstport = 0 (0x0)
addr = 0d.0
romfile = ""
romsize = 4294967295 (0xffffffff)
rombar = 1 (0x1)
multifunction = false
x-pcie-lnksta-dllla = true
x-pcie-extcap-init = true
failover_pair_id = ""
acpi-index = 0 (0x0)
class USB controller, addr 00:0d.0, pci id 106b:003f (sub 1af4:1100)
bar 0: mem at 0x80080000 [0x800800ff]
bus: usb-bus.0
type usb-bus
dev: usb-hub, id ""
ports = 8 (0x8)
port-power = false
port = ""
serial = ""
msos-desc = true
pcap = ""
addr 0.3, port 3, speed 12, name QEMU USB Hub, attached
dev: usb-kbd, id ""
usb_version = 2 (0x2)
display = ""
port = ""
serial = ""
msos-desc = true
pcap = ""
addr 0.0, port 3.1, speed 12, name QEMU USB Keyboard, attached
dev: usb-mouse, id ""
usb_version = 2 (0x2)
port = ""
serial = ""
msos-desc = true
pcap = ""
addr 0.2, port 2, speed 12, name QEMU USB Mouse, attached
dev: usb-kbd, id ""
usb_version = 2 (0x2)
display = ""
port = ""
serial = ""
msos-desc = true
pcap = ""
addr 0.1, port 1, speed 12, name QEMU USB Keyboard, attached
It's worse than just attempting to cater for all Mac OS PPC guests... the same config is also used for all UTM hosts: that is, it's set up the same for macOS x86, macOS M1, iOS and iPadOS.
I can imagine it becoming a nightmare to support various qemu versions separately, but part of the problem is in Qemu.
When using UTM, you can do manual mouse and keyboard capture by pressing a hot key combo -- by default, it's control-option. In order for capture to result in a movable mouse, sometimes you need to press that combination once to toggle on, once off, once on, once off, once on, in order to actually get a movable mouse in the guest.
Interestingly, the mouse works fine with no capture on 10.4 and above. On 10.3, the mouse vanishes until capture is cycled on and off, and then is captured incorrectly, resulting in two mouse pointers in very different locations at different ramping speeds; capturing again fixes this. On 10.2 and below, the mouse needs to be captured for mouse and keyboard to work at all. This is all the case no matter which via is selected.
Is this grab option the same as default Qemu Ctrl-Alt-G?