Page 2 of 5

Re: The UTM Thread

Posted: Sat Jan 22, 2022 10:07 pm
by Cat_7
Haha,
You've given me an idea for another possible solution for clipboard sharing and mouse integration though: UTM has the ability to run in "Console Mode" which just presents a TTY and no video. If this can actually boot, but just boots "headless", then I can run VNC or Remote Access, and use the mouse/keyboard/clipboard control from there :) I'll have to test this and see if it actually works.
I tried that today (as I have no Metal available), and Mac OS seems to run. Long time ago I tried with the vnc server in Qemu on WSL on Windows, and that worked.

BTW: I found that the screamer builds do run Mac OS 9.0 and 9.1 if -cpu G3 is used. 9.1 might also need via=pmu

Best,
Cat_7

Re: The UTM Thread

Posted: Sat Jan 22, 2022 10:50 pm
by adespoton
Cat_7 wrote: Sat Jan 22, 2022 10:07 pm Haha,
You've given me an idea for another possible solution for clipboard sharing and mouse integration though: UTM has the ability to run in "Console Mode" which just presents a TTY and no video. If this can actually boot, but just boots "headless", then I can run VNC or Remote Access, and use the mouse/keyboard/clipboard control from there :) I'll have to test this and see if it actually works.
I tried that today (as I have no Metal available), and Mac OS seems to run. Long time ago I tried with the vnc server in Qemu on WSL on Windows, and that worked.

BTW: I found that the screamer builds do run Mac OS 9.0 and 9.1 if -cpu G3 is used. 9.1 might also need via=pmu

Best,
Cat_7
I'm using UTM screamer on 9.1 with -cpu G4 and via=pmu. 10.1 (not 10.0) required -cpu G3 to boot, but also required CUDA. This could be due to my original install being a -cpu G3 install though; I just used the same image from my standalone qemu-ppc-screamer app in UTM.

Which Mac OS did you get to run with Console Mode?

Re: The UTM Thread

Posted: Sat Jan 22, 2022 11:01 pm
by Cat_7
9.2

Yeah, might be my initial installations of those version were different. Perhaps also additional software installed creates problems.
And sometimes the apple audio extension crashes.

Best,
Cat_7

Re: The UTM Thread

Posted: Sat Jan 22, 2022 11:11 pm
by adespoton
Cat_7 wrote: Sat Jan 22, 2022 11:01 pm 9.2

Yeah, might be my initial installations of those version were different. Perhaps also additional software installed creates problems.
And sometimes the apple audio extension crashes.

Best,
Cat_7
How did you get 9.2 to run? Using an existing VNCServer aliased to the Startup Items folder?

That audio extension crash is also something I've experienced, but only when using CUDA.

Re: The UTM Thread

Posted: Sun Jan 23, 2022 12:04 am
by Cat_7
No, by using Qemu built-in vnc server.

-vnc :0

Best,
Cat_7

Re: The UTM Thread

Posted: Sun Jan 23, 2022 3:39 am
by Bruninho
Cat_7 wrote: Sat Jan 22, 2022 9:38 pm You can install the Mac OS 9.x tablet driver and see what happens to those guests.

https://github.com/kanjitalk755/macos9-usb-tablet

As said above, a tablet driver coming with the OS was only available from 10.2.8 or even 10.3 upwards

Best,
Cat_7
I used USB Overdrive, works like a charm

Re: The UTM Thread

Posted: Sun Jan 23, 2022 3:43 am
by Bruninho
https://gist.github.com/brunocastello/6 ... -macos9-sh

This is what I used with the screamer fork before UTM.

In UTM, the latest versions, I run the G4 with 9.2.2 just fine. Zero issues.

Re: The UTM Thread

Posted: Sun Jan 23, 2022 8:39 am
by Cat_7
Hi,

The vnc option works when adding

-vnc :0 -k en-us
-device VGA

to the custom options in UTM. However, when connecting a vnc viewer to the running instance I see Mac OS starting up for a few seconds only to have UTM come crashing down on me.

Re: The UTM Thread

Posted: Mon Jan 24, 2022 4:18 am
by adespoton
Interesting; I've had a chance to get back on my UTM machine again, and any attempted use of -vnc (I was using -vnc :9,password=no) causes UTM to crash as soon as you try and connect.

This appears to be due to the fact that UTM is already doing communication with qemu via -qmp tcp:127.0.0.1:4444,server,nowait and so as soon as vnc connects, the QMP connection is lost, resulting in UTM terminating, resulting in QEMU terminating. I'll be raising a bug :)

My next challenge is to see if I can use -monitor to redirect the monitor to an already open tty (or something other than a serial or telnet session which will terminate after each command) to gain monitor access to QEMU, so I can gain full control over the sessions in UTM.

Re: The UTM Thread

Posted: Mon Jan 24, 2022 4:47 am
by adespoton
Also, as for the mouse issue: I found that if you run UTM from Terminal.app, you get all the debug logs :D

So here's clearly what's going on with the mouse:

Code: Select all

2022-01-23 20:34:28.941 UTM[10952:3385963] Debug JSON recieved <- {
    return =     (
                {
            absolute = 0;
            current = 0;
            index = 4;
            name = "QEMU HID Mouse";
        },
                {
            absolute = 1;
            current = 0;
            index = 3;
            name = "QEMU HID Tablet";
        },
                {
            absolute = 0;
            current = 1;
            index = 2;
            name = "QEMU ADB Mouse";
        }
    );
}
2022-01-23 20:34:28.941 UTM[10952:3385964] found index:3 absolute:1
2022-01-23 20:34:28.941 UTM[10952:3385964] Debug JSON send -> {
    arguments =     {
        "command-line" = "mouse_set 3";
    };
    execute = "human-monitor-command";
}
Now I just need to figure out what's going on with the keyboard.

Re: The UTM Thread

Posted: Sat Jan 29, 2022 10:19 pm
by Bruninho
Just updated to the latest 3.0.4 and I still miss two resolutions from macOS 9.2.2 VM:
- 1440x900
- 1680x1050

These are two of the supported full screen resolutions on M1 MacBook Air "13 and they don't show up.

I can run 1920x1080 when I am using a 40" external monitor but that's overkill.

Note that when I had a jailbroken 12.9" iPad Pro, I was able to run macOS 9.2.2 on UTM from there and had a full screen 1280x1024 resolution. That resolution is also missing.

If I knew how to add them back, I would. Although I think that 1280x960 will probably fit better for a M1 MacBook Air 13".

Re: The UTM Thread

Posted: Sun Jan 30, 2022 6:45 am
by Cat_7
Determining the available resolutions seems to be a two step process. Qemu creates the edid information which is then read by the qemu_vga.ndrv. edid=on is the default setting when using the VGA device. With edid=off only the resolutions in the qemu_vga.ndrv are used.
On the qemu user list Mark suggested the edid info might be based on info from the host. However, I see the same resolutions available in Mac Os 9.2 on my lowly nvidia 330m (with vga max resolution 2048x1536) on a laptop with 1366x768 screen and nvidia 1060 in my desktop with 3840x2160 display.

Setting the resolution with e.g. qemu -device VGA,edid=on,xres=1280,yres=800 does not work for ppc guests.

Best,
Cat_7

Re: The UTM Thread

Posted: Sun Jan 30, 2022 8:57 pm
by Bruninho
Yeah, I know. However, UTM apparently does not set edid to "on", arguing that this setting was on by default, so no need to set it up manually (again).

I can't check it on iOS again because I no longer own the iPad Pro. I checked it on my Mac with an external monitor and albeit it does support these resolutions, they aren't listed there.

So it probably needs a custom qemu_vga.ndrv to fix it. Previous versions of UTM had these resolutions (prior to some early 2.x versions).

Re: The UTM Thread

Posted: Mon Jan 31, 2022 1:06 am
by adespoton
Bruninho wrote: Sun Jan 30, 2022 8:57 pm Yeah, I know. However, UTM apparently does not set edid to "on", arguing that this setting was on by default, so no need to set it up manually (again).

I can't check it on iOS again because I no longer own the iPad Pro. I checked it on my Mac with an external monitor and albeit it does support these resolutions, they aren't listed there.

So it probably needs a custom qemu_vga.ndrv to fix it. Previous versions of UTM had these resolutions (prior to some early 2.x versions).
I forgot to mention, after trying to make them understand the issue in the bug you raised on the UTM bug tracker, I went into their copy of qemu_vga.ndrv. All the resolutions are there. This means there's something about SPICE that's interfering with edid, or the fact that they've got -nodefaults set has meant that edid is NOT actually enabled by default in their build. Because running UTM from terminal so I can trace their events properly shows no indication qemu_vga.ndrv is ever accessed.

Re: The UTM Thread

Posted: Mon Jan 31, 2022 3:13 am
by Bruninho
Eh? Then this is interesting. They need to make -nodefaults optional with a checkbox. But this doesn't fix the problem entirely, just creates new problems for others. I think I was having this issue even before that.

Cannot be SPICE, because there are no SPICE drivers for macOS 9. Only for Linux and Windows. SPICE requires SPICE Tools installed on guest machine to work. Kinda like VMware Tools.

So it has to be the -nodefaults flag.

He could make a checkbox to enable edid, somewhere in the display settings screen for the VM.

Re: The UTM Thread

Posted: Mon Jan 31, 2022 5:40 am
by adespoton
Bruninho wrote: Mon Jan 31, 2022 3:13 am Eh? Then this is interesting. They need to make -nodefaults optional with a checkbox. But this doesn't fix the problem entirely, just creates new problems for others. I think I was having this issue even before that.

Cannot be SPICE, because there are no SPICE drivers for macOS 9. Only for Linux and Windows. SPICE requires SPICE Tools installed on guest machine to work. Kinda like VMware Tools.

So it has to be the -nodefaults flag.

He could make a checkbox to enable edid, somewhere in the display settings screen for the VM.
SPICE is trickier than that. None of the extensions are available in OS 9, but the display server is being used by UTM as is the hardware I/O. So the bits that allow you to integrate with the OS itself can’t be used, but everything else is still going through the SPICE client/server interface. This has resulted in some of my other tickets, like the one for fixing mouse/keyboard I/O when using CUDA (SPICE only works with USB) and providing access to the monitor (SPICE depends on the alternate JSON interface, so exposing the monitor is more complicated than with vanilla QEMU).

Re: The UTM Thread

Posted: Fri Feb 04, 2022 7:06 pm
by demonlemon
How can I format a disk image that can be written within the guest? I'm running Mac OS 9.2 on a host MacBook running Catalina

I've tried creating a .cdr file and renaming to .iso extension. The guest still sees the drive as read only, despite me unlocking the file within the get info dialog.

Am I formatting something wrong here? My goal is to export a folder to my host from the guest machine but it's proving really tricky...

Re: The UTM Thread

Posted: Fri Feb 04, 2022 7:45 pm
by Bruninho
demonlemon wrote: Fri Feb 04, 2022 7:06 pm How can I format a disk image that can be written within the guest? I'm running Mac OS 9.2 on a host MacBook running Catalina

I've tried creating a .cdr file and renaming to .iso extension. The guest still sees the drive as read only, despite me unlocking the file within the get info dialog.

Am I formatting something wrong here? My goal is to export a folder to my host from the guest machine but it's proving really tricky...
You can install DAVE on your macOS 9.2. I use DAVE to access my Apple Time Capsule from macOS 9.2. Don't know if it works with other computers on the network, but they probably don't unless you're sharing a drive or a folder from your host machine to the network. I think they need to be SMB v1 compatible.

However, I only managed to make DAVE run by trial and error so I can't instruct how exactly it works, but it did.

Re: The UTM Thread

Posted: Fri Feb 04, 2022 8:46 pm
by adespoton
demonlemon wrote: Fri Feb 04, 2022 7:06 pm How can I format a disk image that can be written within the guest? I'm running Mac OS 9.2 on a host MacBook running Catalina

I've tried creating a .cdr file and renaming to .iso extension. The guest still sees the drive as read only, despite me unlocking the file within the get info dialog.

Am I formatting something wrong here? My goal is to export a folder to my host from the guest machine but it's proving really tricky...
Create an HFS+ disk image using Disk Utility, then mount it raw in QEMU.

If the QEMU has issues with the image being a .dmg, just rename the extension to img instead -- QEMU is happy with raw image files named .img, and so is Disk Utility.

[edit] whoops; got my discussion threads mixed up. Fixed now.

Re: The UTM Thread

Posted: Tue Feb 15, 2022 4:38 am
by Bruninho
Fresh new UTM 3.1.0 Beta can now run VMs from an external storage. Yay!

I am still missing the above screen resolutions in MacOS 9.2 though.

Re: The UTM Thread

Posted: Tue Feb 15, 2022 3:56 pm
by adespoton
Yeah; that's one of the first things I checked, whether they'd applied the fix to actually use edid. Apparently they haven't.

Re: The UTM Thread

Posted: Tue Feb 15, 2022 5:31 pm
by Bruninho
He added it to the milestone goal: https://github.com/utmapp/UTM/milestone/21

Since 3.1.0 is still a beta, I wonder if he will include it for the final 3.1.0 release.

1680x1050 is definitely the best resolution for a 13" MacBook on MacOS 9.2. I can run 1920x1080 when using the 40" external screen.

Re: The UTM Thread

Posted: Tue Feb 15, 2022 6:53 pm
by adespoton
While you're testing things, try running a VM in the background for a while, both with "Do not save VM screenshot to disk" enabled and disabled. I'm getting crashes under 3.1 that appear to be screenshot related.

Re: The UTM Thread

Posted: Tue Feb 15, 2022 10:51 pm
by Bruninho
I haven’t seen any crashes yet, but I chose not to save screenshots since the start. However even with this option disabled, sometimes when I turn off my VMs they have a screenshot saved there. All VMs are stored in an external drive.

Re: The UTM Thread

Posted: Wed Feb 23, 2022 5:25 am
by adespoton
I've got https://github.com/adespoton/utmconfigs updated now; every OS from 9.1 through macOS 11 is working except 10.6. Still have to sort out the UEFI config for that, and get 9.0.4 working again. 3.1.1 seems to have fixed most of the stability issues I found in 3.1.0.