-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
PPC: Extra video resolutions missing #2567
Comments
@osy @conath I have been reading about the issue and I found some posts about on e-maculation forums. Apparently a file called qemu_vga.ndrv can be edited to include the missing/custom resolutions. I do not possess the knowledge to hex edit that file, and add the 1280x960x32 resolution, though I have tried a few times myself these days, without luck. This file and the correct command argument -L pc-bios (or wherever is the screamer openbios file) is apparently the solution for all the problems we have with screamer PPC (the missing resolution and sound on iOS). These two things apparently were pointed out as a solution for others users of qemu screamer on e-maculation forums. I think this is worth a shot to check out. |
As the person who wrote the post on emaculation detailing how to edit the qemu_vga.ndrv file (and who also has the toolchain set up to compile a new version of that file with new graphics configurations baked in), I can make changes if you still need them. UTM's PPC build and associated BIOS files appear to have this DISABLED by default, either due to the -nodefaults flag or using the wrong openbios-ppc. So the VGA override for qemu-system-ppc of ",edid=on" is missing. |
Yeah would be great if you know the exact changes required. |
I bet on the -nodefaults flag. Try to run a test using qemu vanilla to run macOS 9, you still need "-device VGA,edid=on" for the missing resolutions to come back. If the test fails, then it's the other thing @adespoton is saying. I was told before, by conath and osy, that edid is on by default. However, I have a feeling, that -nodefaults overrides this. Either way, it still needs "-device VGA,edid=on" because the -nodefaults flag will not be removed from UTM. Currently, UTM only adds "-device VGA" and therefore macOS 9 is missing certain resolutions that would be more appropriate for a full screen experience on a 13-inch macbook, like 1680x1050, 1440x900 and 1280x960. I currently have no way to prove that theory because there is no way to set edid=on in UTM, even tried editing the plist files. I had to choose another resolution back when I had a jailbroken iPad Pro 12.9" and UTM, because 1280x1024 is missing there and it was the perfect resolution for that device. If you don't want to hardcode this setting to set edid always on, maybe you could add a checkbox for the users to decide, when the VGA device is selected. |
With the new override config, I was hoping it was possible to add -device VGA,edid=on in the QEMU config fields. Unfortunately, as of 3.1.3 (51), this appears to add a new device instead of overriding the existing VGA device, which just prevents the guest VM from booting to OpenBIOS. |
Apparently, this is now left for a future release, but I think the fix is simple: let users decide if they want or not to use the no-defaults flag. This may fix the issue so -device VGA,edid=on which is one of the default arguments will work and provide the missing resolutions for PPC. |
I don't think the current set-up lends itself to making no-defaults an option: because of SPICE, UTM has a characteristically different configuration than the QEMU default. Of course, it might be useful to create a separate default for UTM that's hard-coded such that no-defaults isn't needed, that takes those changes into consideration. This would require modifying QEMU for each code release update though, essentially creating a fork of QEMU. First thing to do is for me to finish testing -prom-env 'vga-ndrv?=true' as a command-line option. This didn't work before because of the quote parsing bug in UTM, but now it should work. |
The VGA edid feature has been enabled for several releases by default now, so I don't think this is the issue. A quick test using a local upstream QEMU build of master (6.2, going on 7.0):
Compare this with
Here you can see that |
The |
It's possible SPICE front end isn't updating the edid? |
Thanks, Mark! Currently qemu_vga.ndrv is present in /Applications/UTM.app/Contents/Resources/qemu/ alongside the likes of openbios-ppc and QEMU,tcx.bin, and I've verified that the contents of qemu_vga.ndrv match what we have running correctly under your version of QEMU. So I guess the big question is: since QEMU itself is running sandboxed in /Applications/UTM.app/Contents/XPCServices/QEMUHelper.xpc/Contents/MacOS/QEMULauncher.app/Contents/MacOS/QEMULauncher , is it properly seeing the file? Using Activity Monitor, my snapshot isn't capturing QEMULauncher opening the file at any point, or any copy of it stored elsewhere. But then, my timing might just be off, as I'm sure it won't be holding that file open, just loading the contents and closing. |
We pass in the -L argument along with the proper permissions so it should see any files there unless it was hard coded to use the /usr/share/qemu path instead of what is passed in -L |
Hmm... I know that's not it, because my copies of qemu-system-ppc reside inside the app (at Contents/Resources/qemu), just like yours. |
The quickest way to check if
If you can see the massive If the property isn't there, then something is going wrong loading the NDRV during startup. The NDRV is passed to OpenBIOS using the
and:
should set the default resolution as specified when OpenBIOS configures the framebuffer. Finally if that works, there must be an issue loading the |
Well THAT was interesting. I added Using If I switch that to -g 1280x720x32, I get the OpenBIOS screen at 1280x720, followed by the Mac OS boot screen at 640x480, which switches to my pre-set 1280x768 during the boot process. |
In that case the easiest thing to do is drop the The NDRV has its own concept of default resolution separate from OpenBIOS so the above behaviour is expected: maybe not overly aesthetic, but otherwise you get into trying to sync MacOS with OF using a non-MacOS native interface... |
Hmm... UTM has the option of VGA or Console mode. Switching to Console mode gave me this: C>> annot manage 'EHCI USB controller' PCI device type 'usb':
Followed by nothing. Same result whether -nographic is used or not. |
Looks like you need to add |
It's already added. Seems like it's getting stripped? |
That's what I found interesting above. nographic was working but auto-boot was not. |
I have to leave this for tonight now, but I hope that it gives both you and @osy some pointers as to how to track down what the issue is. Alas I have no Apple hardware capable of running UTM so all I can do is provide hints based upon working with upstream. |
Thanks again Mark! I'll keep digging into it from my side, although I'm not that well versed in how @osy has set up the UTM/QEMU communication. I'll know when the ndrv file is getting loaded correctly though. |
Did anyone of you get any further regarding the resolution-issue. I have a similar problem with a Mac OS X 10.7 x64 emulation. I only ever get 1280×720. :( |
@adespoton had some luck? |
@brunocastello I’m not sure if this is equally applicable for an PPC vm, but on an x86-Emulation, running on an M1 machine I was able to get my machine to 1920×1080 by editing a file on the EFI-LEGACY partition:
There is a EDIT: Sorry, I guess this is no help for PPC, as its not using OpenCore? |
Correct, PPC does not need OpenCore to boot. The guys above already traced (to some extent) the origin of the issue. The problem now is how to fix. I just need a 1280x800 option for the macbook. Closest I can get is 1280x720 with minimal black bars on top and bottom. I do currently accept that. The current resolutions coming right now do work for the 32" screen I have on my Mac Studio. |
I just realized; you can probably use the solutions from emaculation for POC resolutions; the files that need to be changed will be embedded in the UTM resources folder.Essentially, the video driver needs to push the appropriate resolution to OpenFirmware and then the OS will read that on boot and set it as a resolution option in the Monitors CP/prefpane.-Em On Jul 25, 2023, at 2:35 PM, Bruno Castelló ***@***.***> wrote:
@brunocastello I’m not sure if this is equally applicable for an PPC vm, but on an x86-Emulation, running on an M1 machine I was able to get my machine to 1920×1080 by editing a file on the EFI-LEGACY partition:
EFI-LEGACY/EFI/OC/config.plist
There is a <key>Resolution</key>, and changing its <string> to 1920x1080 actually worked. But I would still love to have a set of possible resolutions. Apart from that I tried a few other resolutions that did not work.
EDIT: Sorry, I guess this is no help for PPC, as its not using OpenCore?
Correct, PPC does not need OpenCore to boot. The guys above already traced (to some extent) the origin of the issue.
I just need a 1280x800 option for the macbook. Closest I can get is 1280x720 with minimal black bars on top and bottom. I do currently accept that.
The current resolutions coming right now do work for the 32" screen I have on my Mac Studio.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Any updates on this? |
As per request from #2548, I filed another issue for the video.
Describe the issue
Starting with both iOS and macOS versions of UTM 2.1.0 Beta, the VGA device is no longer giving me the extra video resolutions for use. I was using 1280x960x32 with previous UTM versions, good enough for me, but now I am using a little lower resolution (1024x768x32) because of that.
According to e-maculation forums documentation, the QEMU argument should be
-device VGA,edid=on
to get the extra resolutions for PPC OS 9 and OS X. But according to @mcayland comments on #2407, edid is on by default in recent QEMU versions, so no need to declare it, but apparently it does not seem to be the case here. The QEMU command line in UTM shows-device VGA
only.Configuration
UTM Version: 2.1.0 Beta
OS Version: Both (iOS 14.4.2 and macOS Big Sur 11.3
Intel or Apple Silicon? Intel mac and iPad Pro 12.9" 2nd generation
The QEMU commands for the OS 9 VM are:
qemu-system-ppc -L /private/var/containers/Bundle/Application/825DB694-F3C5-49DF-B888-C838DE405E35/UTM.app/qemu -S -qmp tcp:127.0.0.1:4444,server,nowait -vga none -spice port=5930,addr=127.0.0.1,disable-ticketing,image-compression=off,playback-compression=off,streaming-video=off -device VGA -cpu g4 -smp cpus=1,sockets=1,cores=1,threads=1 -machine mac99,via=pmu -accel tcg,tb-size=128,split-wx=on -boot menu=on -m 512 -name "MacOS 9.2" -device ich9-usb-ehci1,id=usb-controller-0 -device ich9-usb-uhci1,masterbus=usb-controller-0.0,firstport=0,multifunction=on -device ich9-usb-uhci2,masterbus=usb-controller-0.0,firstport=2,multifunction=on -device ich9-usb-uhci3,masterbus=usb-controller-0.0,firstport=4,multifunction=on -chardev spicevmc,name=usbredir,id=usbredirchardev0 -device usb-redir,chardev=usbredirchardev0,id=usbredirdev0,bus=usb-controller-0.0 -chardev spicevmc,name=usbredir,id=usbredirchardev1 -device usb-redir,chardev=usbredirchardev1,id=usbredirdev1,bus=usb-controller-0.0 -chardev spicevmc,name=usbredir,id=usbredirchardev2 -device usb-redir,chardev=usbredirchardev2,id=usbredirdev2,bus=usb-controller-0.0 -device ide-hd,bus=ide.0,drive=drive0,bootindex=0 -drive "if=none,media=disk,id=drive0,file=/var/mobile/Containers/Data/Application/6CC128D1-352F-4987-AC75-88E6C4B97618/Documents/MacOS 9.2.utm/Images/macOS9.img,cache=writethrough" -device ide-cd,bus=ide.1,drive=drive1,bootindex=1 -drive if=none,media=cdrom,id=drive1 -device sungem,mac=66:C2:26:89:5A:A9,netdev=net0 -netdev user,id=net0,hostfwd=tcp::80-:80,hostfwd=tcp::22-:22 -uuid 1AFED0DA-6802-43D7-A81E-4659EC2FED6B -rtc base=localtime -g 1280x960x32 -device usb-tablet
While we're at it, can I suggest to include
,clock=host
to-rtc base=localtime
as a standard for a better time on guest OS? as in,-rtc base=localtime,clock=host
? I've been told to declare it this way when using vanilla QEMU before I went for UTM.The text was updated successfully, but these errors were encountered: