-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Machine mac99,via=cuda can't find keyboard #3504
Comments
For context, some of this is a known issue with CUDA in the base qemu-system-ppc source. From Mark Cave-Ayland: |
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: 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:
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:
|
Here's a more thorough debug log showing what's happening: `/Applications/UTM.app/Contents/MacOS/UTM >debug.txt (:11407): GSpice-WARNING **: 21:02:11.348: main-1:0: could not set sockopt TCP_NODELAY: Operation not supported on socket (:11407): GSpice-WARNING **: 21:02:11.405: display-2:0: could not set sockopt TCP_NODELAY: Operation not supported on socket (:11407): GSpice-WARNING **: 21:02:11.405: usbredir-9:2: could not set sockopt TCP_NODELAY: Operation not supported on socket (:11407): GSpice-WARNING **: 21:02:11.405: usbredir-9:1: could not set sockopt TCP_NODELAY: Operation not supported on socket (:11407): GSpice-WARNING **: 21:02:11.405: usbredir-9:0: could not set sockopt TCP_NODELAY: Operation not supported on socket (:11407): GSpice-WARNING **: 21:02:11.405: inputs-3:0: could not set sockopt TCP_NODELAY: Operation not supported on socket (:11407): GSpice-WARNING **: 21:02:11.477: cursor-4:0: could not set sockopt TCP_NODELAY: Operation not supported on socket (:11407): GSpice-CRITICAL **: 21:03:40.657: Source ID 1 was not found when attempting to remove it |
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. 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 #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). |
That would be a bug. The intended behaviour is if you have “via=“ then it should override any “default” value. 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 |
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
The text was updated successfully, but these errors were encountered: