Pixel-perfect (integer) scaling via HDMI 1.x
Integer scaling works, but at unsupported resolutions scaling is not performed at all.
640×480 is effectively not available via HDMI under Windows at least with nVidia GPUs, though is available under Linux (Ubuntu 18.10/21.04), as well as under both Windows and Linux via DisplayPort.
Integer scaling does work in general in the Eve Spectrum 4K monitor (ES07D03). So it’s indeed the world’s first computer monitor with built-in integer scaling. Yay! This alone puts Eve Spectrum far ahead of all “similar” monitors, including those based on the same LCD panel.
With the firmware 102 rev. 875 (2021-07-12), integer scaling is functional at all the resolutions formally supported by the monitor:
- 1920×1080 (Full HD, 2x);
- 1920×1080i (Full HD interlaced; 2x) (HDMI-only) (not under Linux);
- 1680×1050 (WSXGA+, 2x);
- 1440×900 (WSXGA, 2x);
- 1280×1024 (SXGA, 2x);
- 1280×960 (SXGA−, 2x);
- 1280×720 (HD, 3x);
- 1024×768 (XGA, 2x);
- 800×600 (SVGA, 3x);
- 720×576 (PAL DVD, 3x);
- 720×480 (NTSC DVD, 4x);
- 640×480 (VGA, 4x) (problematic via HDMI 1.x under Windows).
Before the firmware version 102 rev. 867, pixel-perfect scaling did not work at 1440×900, 1280×960, 720×576, and 720×480.
There are some issues, some of them are caused by the monitor itself, while other ones are caused either by Windows or by nVidia graphics driver.
Centering instead of pixel-perfect scaling at unsupported resolutions
At 1080i (interlaced) under Linux (Ubuntu 18.10/21.04), scaling in “Pixel perfect” mode is not performed, the image is just centered. This does not happen under Windows.
The Linux-specific thing is that it sends 1080i as 1920×1078, while Windows sends 1920×1080. The monitor does not specifically support 1920×1078, though correctly displays the image and indicates the mode as the current video mode in the monitor menu/OSD.
Interlaced modes are only available via HDMI and not via DP.
In the regular blurry scaling mode — “Maintain aspect ratio” — scaling is/was performed fine even at resolution(s) that pixel-perfect scaling does/did not work at. So the possible reason may be that specific scales (scaling ratios) in the “Pixel perfect” monitor mode are not calculated dynamically in a universal resolution-agnostic way, but hard-coded for each resolution into firmware, such hard-coded scales are only available for the resolutions explicitly listed in the monitor EDID, and any other resolution combined with pixel-perfect scaling results in centering with no scaling at all.
640×480 can’t be used under Windows via HDMI
This is most likely not a monitor fault. The lowest resolution supported by the monitor is 640×480, but it’s effectively impossible to use it under Windows (both 10 and 7):
instead of outputting 640×480 directly to the monitor, it’s first upscaled to 800×600 using GPU scaling, and that fake 800×600 is then upscaled by the monitor itself.
Blur caused by scaling via GPU can be avoided by switching GPU-scaling method to “No scaling”. But because the resolution the monitor receives is 800×600, it is scaled instead of 640×480. So the resulting scale is 3.0 (300%) instead of the proper 4.0 (400%) expected at true 640×480, and we unreasonably lose a significant amount of screen space/height: the height loss is 33% instead of 11%.
This issue is specific to HDMI connection and does not reproduce with DisplayPort. Using DP instead of HDMI, I was able to run “POD Gold” (GOG version) and “C&C Red Alert II” (Origin version) with direct 640×480 output without forced implicit GPU prescaling to 800×600. Also, successfully switched Windows itself to 640×480@60Hz, and the monitor menu displayed 640×480 as the current resolution, not 800×600, in all the three cases.
Windows/nVidia bug: silently switching to GPU scaling
Under Windows 10, there is apparently an annoying bug in nVidia driver (including the latest 471.41, 2021-07-19) or even Windows itself:
the device to perform scaling on silently switches to GPU (instead of display) each time when changing resolution via Windows display settings, and this is not even reflected in the nVidia control panel.
So to use scaling via monitor, each time the desktop resolution is changed, the user is forced to go to nVidia control panel, choose “GPU” in the “Perform scaling on” dropdown (“Display” → “Adjust desktop size and position” → “Apply the following settings” → “Scaling”), press the “Apply” button, then immediately cancel the change, just to make the already displayed “Display” value match reality and allow the monitor to perform scaling.
Alternatively, silent switching to GPU scaling can be prevented by switching video modes via the classic (pre-Windows-10) “List All Modes” window available via a button in the window opened with the “Display adapter properties for Display 1” text button in the “Advanced display settings” window.
Windows 7 is almost not affected by this: it only switches to GPU scaling if the refresh rate is not available (typically too high) at the selected resolution (e.g. it sets 120 Hz at 1280×720, even though this rate is only available at FHD). Once the user manually switches the refresh rate to a lower one supported by the monitor at the selected resolution, monitor scaling is used automatically.
“Aspect Ratio” option is not available in low-latency and Adaptive-Sync modes
The “Picture” → “Aspect Ratio” monitor option gets grayed-out and not available to change, at resolutions of 800×600 and higher when “Performance” → “Low-latency mode” is turned on.
The “Low-latency mode” option gets grayed-out when “Performance” → “Adaptive-Sync” is turned on. “Adaptive-Sync” is turned on by default, so “Low-latency mode” is grayed-out by default, and so “Aspect Ratio” is grayed-out by default too.
“Aspect Ratio” is available at 4K@30Hz even with default settings (factory defaults), because Adaptive-Sync cannot be used at 30 Hz (as it’s below minimum 48 Hz) and the “Adaptive-Sync” option is grayed-out and implicitly set to “Off”.
Once “Aspect Ratio” is set to “Pixel perfect”, pixel-perfect scaling works regardless of whether the “Aspect Ratio” option is available for changing.
Thanks Grant (@Lore_Wonder) for clarification about the relationship between “Aspect Ratio”, “Low-latency mode” and “Adaptive-Sync” monitor options.
Two-stage blurry+integer scaling during non-UEFI boot, only visible via HDMI
During boot of a computer with a non-UEFI BIOS (“Award Modular BIOS v6.00PG” in my case) when using HDMI, scaling in “Pixel perfect” mode is apparently performed in two stages:
- the original image is upscaled to an intermediate resolution;
- that blurry image is upscaled pixel-perfectly with 2×2 square pixels.
The resolution displayed in the monitor menu during boot is 1280x1024@60Hz. So 1280×1024 is probably the intermediate resolution the original image is scaled to with blur before pixel-perfect scaling at the second stage.
This is probably due to that the video mode used by non-UEFI computers during boot (probably 720×400@70Hz, 640×400@70Hz, or 640×480@75Hz), is missing in the list of supported video modes specified in the monitor EDID — this is probably the same reason why boot process is invisible and black screen is displayed instead when the monitor is connected via DisplasPort (DP) (see below).
Monitor menu (OSD) is blurry
The monitor’s own menu (OSD) is blurry for some reason. Such blur decreases text legibility and makes reading text harder.
This is certainly not antialiasing, this is exactly blur, like if a lower-resolution graphics was upscaled using bilinear or bicubic interpolation instead of pixel-perfect upscaling with no blur.
World’s first pixel-perfect-capable monitor with blurry menu/OSD? Uh.
This should be fixable quite easily — either by creating new graphics for menu (if all the text is graphics), or by changing the menu upscaling algorithm (if such upscaling is done dynamically when opening the menu) from bilinear/bicubic to Nearest Neighbour, or by rendering text at full native monitor resolution with type hinting (snapping to physical pixels) enabled.
Going to provide some demonstrative photos later. Testing continues.
For what it’s worth, so far I have been testing using HDMI 1.x (my GPU is not capable of HDMI 2.0) that I was forced to temporarily use instead of DisplayPort due to not having DP-to-DP cable (my Dell P2415Q came with a DP-to-MiniDP cable, but Eve Spectrum does not have a MiniDP input, only full-size DP), so it’s possible that this could affect some of the testing results to some extent. I already bought a DP-to-DP cable and plan to use it instead of HDMI starting from tomorrow.