Open adespoton opened 2 years ago
For context, some of this is a known issue with CUDA in the base qemu-system-ppc source.
From Mark Cave-Ayland: "It looks like adding the extra USB arguments to the command line is adding additional input devices and also a USB hub. My guess is that QEMU/OpenBIOS end up choosing the wrong input device in these cases so the chosen device doesn't match the one that gets connected to QEMU's host keyboard/mouse handlers."
We've been having more of a discussion over at emaculation about what might be causing this, since the behaviour is not the same on the default qemu-system-ppc builds we provide there: https://www.emaculation.com/forum/viewtopic.php?p=73106#p73106
So far, that thread has eliminated possible reasons for the behaviour, but hasn't identified the culprit (although it's likely something to do with the USB configuration, as 9.0, 10.0 and 10.1 are CUDA only, which doesn't technically support USB devices).
Does UTM have a way of triggering QEMU's monitor? I could walk through the device tree and identify what virtual devices the real mouse and keyboard are binding to if I could get to the monitor.
Here's something more useful: I changed display to "console only" and it provided the following info:
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)
>> =============================================================
>> OpenBIOS 1.1 [Aug 13 2020 19:36]
>> Configuration device id QEMU version 1 machine id 1
>> CPUs: 1
>> Memory: 256M
>> UUID: 4d6efe89-3ff4-4110-8e05-7fe7a930fe6d
>> CPU type PowerPC,G4
milliseconds isn't unique.
Welcome to OpenBIOS v1.1 built on Aug 13 2020 19:36
Trying /pci@f2000000/mac-io@c/ata-3@20000/disk:,\\:tbxi...
>> switching to new context:
So it appears that QEMU itself is rejecting the USB devices and thus going with defaults... and the keyboard isn't connected to any default. Mouse seems to bind to the ADB bus anyway.
On vanilla QEMU (with screamer), I use the following config (with defaults enabled) and have mouse and keyboard:
-L pc-bios \
-boot c \
-drive file="/dev/disk$DEVNUM",format=raw,media=disk \
-M mac99 \
-m 256 \
-cpu G3 \
-netdev user,id=vlan0 \
-device sungem,netdev=vlan0 \
-device VGA,edid=on \
-g 1280x720x32 \
Here's a more thorough debug log showing what's happening:
`/Applications/UTM.app/Contents/MacOS/UTM >debug.txt
2022-01-23 21:02:10.230 UTM[11407:3398832] -[CSConnection finishInit]:271
2022-01-23 21:02:10.230 UTM[11407:3398832] -[CSInput initWithSession:]:293
2022-01-23 21:02:10.230 UTM[11407:3398832] -[CSSession initWithSession:]:294
2022-01-23 21:02:10.232 UTM[11407:3398832] Running: -L /Applications/UTM.app/Contents/Resources/qemu -S -qmp tcp:127.0.0.1:4000,server,nowait -nodefaults -vga none -spice "unix=on,addr=/Users/
(
(
(
(
(
(
(
(
This appears to be fixed in 3.1.0; with the mouse in Legacy mode and CPU set to G4 in CUDA mode, the ADB mouse and keyboard are eventually found and presented as the primary devices. Takes a few seconds of the mouse being swept to the right side of the screen, but eventually it happens. This enables booting of Mac OS X 10.0.x, Mac OS X Server 10.0.x, Mac OS X 10.1.x and Mac OS X Server 10.1.x.
Unfortunately, Mac OS 9.0.4 now fails to boot at all, but that's a different issue.
Well... turns out it isn't a different issue. I found the problem. Machine Mac99 appears to be hard-coded with property via=pmu. If you enter property via=cuda, the actual output is -machine mac99,via=cuda,via=pmu -- which overrides the CUDA value with the PMU one.
This is an odd choice, considering the only PPC configuration that requires via=pmu is OS X 10.5. All other OSes (OS X, Mac OS and other Mac99 PPC OSes) perform significantly better with this disabled, and 9.0.4 cannot function, as the PMU VIA uses USB 2.0, and Mac OS 9.0.4 only supports USB 1.1. This means all input is broken for 9.0.4, OS X Server 1.2v3 and Rhapsody DR, and likely a few Linux and BSD variants too -- any Mac99 OS from 2000 and earlier.
This bug appears to have been added with feature https://github.com/utmapp/UTM/issues/313
One possible solution would be to have two mac99 machine options: one with via=pmu, and one without. Or even better, add via=pmu at the front so via=cuda can override it. Or, leave it off or make it a checkbox or selection item (blank, via=pmu, via=pmu-adb, via=cuda).
Machine Mac99 appears to be hard-coded with property via=pmu. If you enter property via=cuda, the actual output is -machine mac99,via=cuda,via=pmu -- which overrides the CUDA value with the PMU one.
That would be a bug. The intended behaviour is if you have “via=“ then it should override any “default” value.
https://github.com/utmapp/UTM/blob/main/Configuration/UTMQemuConfiguration%2BArguments.swift#L789
There should not be quotes around name.
Thanks for the quick find! After that's fixed I should finally be able to get back to testing USB 2.0 vs 1.1 issues and sort out CUDA.
I'm having this issue. On UTM, Mac OS 10.0 will not recognize the keyboard although it recognizes the mouse. I have the machine set to via=cuda. The keyboard works fine in stock QEMU.
Host OS: Ventura 13.3.1a Architecture: x86_64 UTM version: 4.2.5
Describe the issue When attempting to launch PPC containers with mac99,via=cuda (the default mac99 state if via=pmu or via=pmu-adb isn't specified), the keyboard is not properly passed through as an ADB keyboard. If I use the same general configuration and the same disk image on vanilla qemu-system-ppc 6.1 with screamer support compiled in, I can get keyboard support with one of -usbdevice keyboard, -device usb-kbd or -dev usb-kbd.
I've tried this with my fully functional qemu-system-ppc-screamer boot images for Mac OS 9.0.4, Mac OS X 10.0.4, Mac OS X Server 10.0.4, Mac OS X 10.1.5 and Mac OS X Server 10.1.5 (the configurations that need to use CUDA because they don't support PMU). In all cases, ADB keyboard mapping fails, and USB keyboard flags don't appear to be recognized. This is also reflected in the verbose boot data in OS X 10.x (keyboard not found error) and in the fact that Mac OS 9.0.4 pauses during boot until the mouse is clicked, just like it does on my real headless 9.0.4 G4 if I don't have a keyboard connected.
Maybe something in the stricter USB chain you've set up, or with the mandatory SPICE flags has blocked the basic usbdevice shim from working correctly?
Configuration
Debug log debug.log