Hello all I have a FreeBSD VM that I've installed as 'Other' for the OS choice. It's working fine for my needs but annoyingly I can't get a resolution other than 1024x768. In the FreeBSD boot prompt you can type `gop list` to list the resolutions that I am guessing UEFI is telling BSD what resolutions are available. I there any way of expanding this list to include other resolutions, or is this a restruiction of using the 'other' OS option?
Thanks for the info zoyaa1, I was guessing that was what was happening. This is happening in a VM so there is no settings in UEFI I can do to alter the resolution, unless it's hidden away somewhere.
Did you ever find a fix? I did achieve 1900x1280 on my iMac Pro, but something is different now, and I am unable to use regular BIOS (pretty sure you need that and vbe/vesa instead of gop/scfb). I put 'vm.bios.efi=0' in the boot flags, but still get UEFI. Working on it...
Hello Ryan Afraid I never found a fix. I never tried the non-UEFI boot (mainly as I didn't know about it!), but UEFI is stuck at 1024x768. I barely use the BSD VM to be honest, but keep it around just in case someone comes up with a fix or things ever change. Cheers.
I am extremely stubborn, and spent many, many hours on this. Here's the TL;DR: Only x86/x64 platforms can use legacy BIOS. arm/arm64 require UEFI, so this is why vesa/vbe are unavailable and we are stuck at 1024x768. `pciconf -lv` does not even list any devices in the 'display' category using Parallels' EFI support for BSD, and `xrandr` sees a 0x0mm display that refreshes at 0Hz Until Parallels realizes that plenty of people use BSD distributions, and create ports for the clipboard, file sharing, and video driver support, the BSD experience in Parallels is just going to be second-rate If you import your Parallels VM into VMWare Fusion, install `open-vm-tools`, and enable a couple vmware-related things in rc.conf, you can achieve fantastic resolutions. However, VMWare made it so that the driver itself can tell whether the VM is running in VMWare or a competitor, and it will disable itself and refuse to work properly (I tried in Parallels and UTM) So, the prognosis is not good, seeing as it appears that Parallels has zero interest in BSD distributions, even though their customers are plenty interested. Maybe we need to make more noise. I am quite sure that they can afford to throw a couple engineers at this problem for a few months.
