PPC: Extra video resolutions missing

[brunocastello]

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.

[brunocastello]

@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.

[adespoton]

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.

[osy]

Yeah would be great if you know the exact changes required.

[brunocastello]

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.

[adespoton]

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.

[brunocastello]

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.

[adespoton]

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.

[mcayland]

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):

$ ./qemu-system-ppc -S -monitor stdio
QEMU 6.2.50 monitor - type 'help' for more information
bus: main-system-bus
  type System
  ...
  ...
  dev: grackle-pcihost, id ""
    ...
    ...
    bus: pci.0
      type PCI
      ...
      ...
      dev: VGA, id ""
        vgamem_mb = 16 (0x10)
        mmio = true
        qemu-extended-regs = true
        edid = true
        xres = 1280 (0x500)
        yres = 800 (0x320)
        xmax = 0 (0x0)
        ymax = 0 (0x0)
        refresh_rate = 0 (0x0)
        global-vmstate = false
        addr = 01.0
        romfile = "vgabios-stdvga.bin"
        romsize = 65536 (0x10000)
        rombar = 1 (0x1)
        multifunction = false
        x-pcie-lnksta-dllla = true
        x-pcie-extcap-init = true
        failover_pair_id = ""
        acpi-index = 0 (0x0)
        class VGA controller, addr 00:01.0, pci id 1234:1111 (sub 1af4:1100)
        bar 0: mem at 0xffffffffffffffff [0xfffffe]
        bar 2: mem at 0xffffffffffffffff [0xffe]
        bar 6: mem at 0xffffffffffffffff [0xfffe]
        ...
        ...

Compare this with -nodefaults -vga none -device VGA and you see something similar:

$ ./qemu-system-ppc -S -monitor stdio -nodefaults -vga none -device VGA
QEMU 6.2.50 monitor - type 'help' for more information
(qemu) info qtree
bus: main-system-bus
  type System
  ...
  ...
  dev: grackle-pcihost, id ""
    ...
    ...
    bus: pci.0
      type PCI
      dev: VGA, id ""
        vgamem_mb = 16 (0x10)
        mmio = true
        qemu-extended-regs = true
        edid = true
        xres = 1280 (0x500)
        yres = 800 (0x320)
        xmax = 0 (0x0)
        ymax = 0 (0x0)
        refresh_rate = 0 (0x0)
        global-vmstate = false
        addr = 01.0
        romfile = "vgabios-stdvga.bin"
        romsize = 65536 (0x10000)
        rombar = 1 (0x1)
        multifunction = false
        x-pcie-lnksta-dllla = true
        x-pcie-extcap-init = true
        failover_pair_id = ""
        acpi-index = 0 (0x0)
        class VGA controller, addr 00:01.0, pci id 1234:1111 (sub 1af4:1100)
        bar 0: mem at 0xffffffffffffffff [0xfffffe]
        bar 2: mem at 0xffffffffffffffff [0xffe]
        bar 6: mem at 0xffffffffffffffff [0xfffe]
        ...
        ...

Here you can see that edid = true in both cases, so presumably something else is the problem here. First thing to check is the obvious one i.e. that qemu_vga.ndrv is actually present in the same directory as the openbios-ppc binary.

[mcayland]

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-ndrv? option defaults to true in OpenBIOS so I don't think this would make any difference here.

[osy]

It's possible SPICE front end isn't updating the edid?

[adespoton]

Here you can see that edid = true in both cases, so presumably something else is the problem here. First thing to check is the obvious one i.e. that qemu_vga.ndrv is actually present in the same directory as the openbios-ppc binary.

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.

[osy]

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?

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

[adespoton]

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?

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.

[mcayland]

The quickest way to check if qemu_vga.ndrv is being loaded is from OpenBIOS:

$ ./qemu-system-ppc -nographic -prom-env 'auto-boot?=false'

>> =============================================================
>> OpenBIOS 1.1 [Jan 15 2022 14:23]
>> Configuration device id QEMU version 1 machine id 2
>> CPUs: 1
>> Memory: 128M
>> UUID: 00000000-0000-0000-0000-000000000000
>> CPU type PowerPC,750
milliseconds isn't unique.
Welcome to OpenBIOS v1.1 built on Jan 15 2022 14:23
Trying hd:,\\:tbxi...
Trying hd:,\ppc\bootinfo.txt...
Trying hd:,%BOOT...
No valid state has been set by load or init-program

0 > cd /pci/QEMU,VGA  ok
0 > .properties 
name                      "QEMU,VGA"
vendor-id                 1234 
device-id                 1111 
revision-id               2 
class-code                30000 
min-grant                 0 
max-latency               0 
devsel-speed              0 
subsystem-vendor-id       1af4 
subsystem-id              1100 
cache-line-size           0 
device_type               "display"
model                     "QEMU VGA"
compatible                "VGA"
assigned-addresses        42000810 00000000 80000000   00000000 01000000
                          02000818 00000000 81000000   00000000 00001000
AAPL,address              -- 8 : 80 00 00 00 81 00 00 00 
reg                       00000800 00000000 00000000   00000000 00000000
                          42000810 00000000 00000000   00000000 01000000
                          02000818 00000000 00000000   00000000 00001000
width                     320 
height                    258 
depth                     20 
linebytes                 c80 
driver,AAPL,MacOS,PowerPC -- 4941 : 4a 6f 79 21 70 65 66 66 ... ....

If you can see the massive driver,AAPL,MacOS,PowerPC property then all is working since that's the binary representation of the qemu_vga.ndrv file.

If the property isn't there, then something is going wrong loading the NDRV during startup. The NDRV is passed to OpenBIOS using the fw_cfg interface which is the same mechanism used to pass the default resolution. Next check would be to confirm that this works as expected i.e.

$ ./qemu-system-ppc -g 800x600x16 -prom-env 'auto-boot?=false'

and:

$ ./qemu-system-ppc -g 1024x768x16 -prom-env 'auto-boot?=false'

should set the default resolution as specified when OpenBIOS configures the framebuffer. Finally if that works, there must be an issue loading the qemu_vga.ndrv file over the fw_cfg interface so grab a debugger and look at https://gitlab.com/qemu-project/qemu/-/blob/master/hw/ppc/mac_newworld.c#L521 to make sure the file is being located correctly.

[adespoton]

Well THAT was interesting. I added -nographic -prom-env 'auto-boot?=false' to the parameters, and I got the same behaviour as usual except that the OpenBIOS screen was black with no visible text instead of yellow. Still booted to 9.2.2 desktop just fine, using my regular 1280x768 resolution.

Using -g 1024x768x16 -prom-env 'auto-boot?=false' I get the OpenBIOS screen at 1024x768, followed by the Mac OS boot screen at 1024x768, which switches to my pre-set 1280x768 during the boot process.

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.

[mcayland]

In that case the easiest thing to do is drop the -nographic option so that the output is routed to the VGA framebuffer rather than the serial port, but of course you'll have to type the above commands manually to see if the driver,AAPL,MacOS,PowerPC property exists rather than being able to use cut/paste.

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...

[adespoton]

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':

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) set_property: NULL phandle

============================================================= 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,750 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: call-method get-key-map: exception -21 call-method get-key-map failed with error ffffffdf MacOS: unable to find a usable NVRAM partition - using offset 0x1400. call-method get-key-map: exception -21 call-method get-key-map failed with error ffffffdf

Followed by nothing. Same result whether -nographic is used or not.

[mcayland]

Looks like you need to add -prom-env 'auto-boot?=false' to your command line to stop MacOS from booting automatically.

[adespoton]

It's already added. Seems like it's getting stripped?

[adespoton]

That's what I found interesting above. nographic was working but auto-boot was not.

[mcayland]

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.

[adespoton]

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.

[animaux]

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. :(

[brunocastello]

@adespoton had some luck?

[animaux]

@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?

[brunocastello]

@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. 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.

[adespoton]

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 Resolution, and changing its 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: @.***>

[sentient06]

Any updates on this?