...the BIOS offers Panorama only resolutions it thinks the 'monitor in conjunction with the current connection' (DP, DVI, HDMI, ...) is capable. Then Panorama tries to select the predefined BIOS mode (resolution) which matches best OR tries to patch on of the BIOS modes to a better resolution...
@Andi's description above is spot-on: it is the combination of all of the above components that all come together to negotiate the best display configuration.
@Martin,
Do you have the option to try your config using it's native BIOS as opposed to the UEFI mode?
The other thing to investigate is the memory allocation (framebuffer I believe) needed to support a specific resolution. I can only assume that the UEFI VESA Emulator, once the actual display mode is negotiated, attempts to do so, which is why perhaps the following shows up in the LOG:
Product Name: UEFI VESA Emulator v1.0
VBE VRAM size 1000000 (16 MiB) (rounded) 1000000 (16 MiB)
In my experience with SNAP in trying to minimize the amount of memory it tried to allocate/address, and which would typically run up against what OS/2 could possibly access on my machine (ATI 256M video card, but my 1920x1200x2 really doesn't NEED all that space so why should SNAP set-aside that much ram for video card purposes?), I took to setting SNAP to use a much smaller framebuffer with 'gaoption vidmem 32', which sets that to 32M total.
By my calculation your 3840x2160 in 32-bit colour needs about 32M, so the current size shown in the LOG is too small, although it is perfectly fine for the resolution that Panorama is picking up for it's use at that time.
In comparison my 1920x1200 in 32-bit colour only needs 9M, and even with dual-head display that's only 18M.
