Pixel-perfect (integer) scaling via HDMI 1.x
Below is a portion of specific-enough data I collected during testing so far, probably worth posting already. (Updated 2021-07-12.)
Integer scaling works, but at some rarely-used resolutions scaling is not performed at all; and 640×480 is effectively not available under Windows at least with nVidia GPUs, though is available under Linux.
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.
The resolutions integer scaling is functional at with the firmware 100 rev.849 / 101 rev.858:
- 1920×1080 (Full HD, 2x);
- [NEW 2021-07-01] 1920×1080i (Full HD interlaced; 2x) (HDMI-only) (not under Linux);
- 1680×1050 (WSXGA+, 2x);
- 1280×1024 (SXGA, 2x);
- 1280×720 (HD, 3x);
- 1024×768 (XGA, 2x);
- 800×600 (SVGA, 3x);
- 640×480 (VGA, 4x) (problematic via HDMI 1.x under Windows).
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.
No scaling at some resolutions
At some resolutions, scaling in “Pixel perfect” mode is not performed, the image is just centered:
- 1920×1078 (interlaced 1080i as displayed in the monitor menu under Linux — Ubuntu 18.10) (HDMI-only);
1440×900 (fixed in firmware 102 Rev.867);
1280×960 (fixed in firmware 102 Rev.867);
720×576 (fixed in firmware 102 Rev.867);
720×480 (fixed in firmware 102 Rev.867).
This looks like a bug in the firmware.
UPDATE (2021-07-01): In the regular blurry scaling mode — “Maintain aspect ratio” — scaling is performed fine. 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, and such hard-coded scales are just wrongly set to the same 1.0 for those resolutions that pixel-perfect scaling results in centering without scaling at.
UPDATE (2021-07-12): The firmware version 102 Rev.867 added support for pixel-perfect scaling at 1440×900, 1280×960, 720×576, 720×480. Didn’t retest 1920×1078 (interlaced 1080i) with the new firmware under Linux yet.
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, so we unreasonably lose a significant amount of screen space/height: the height loss is 33% instead of 11%.
UPDATE: 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 now displayed 640×480 as 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 466.77) 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.
Windows 7 is almost not affected by this, because 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 disabled at many resolutions
The “Picture” → “Aspect Ratio” monitor option is disabled at non-native resolutions of 800×600 and higher. This looks like a bug in the monitor firmware.
Fortunately, once the “Pixel perfect” value chosen, pixel-perfect scaling works (except for the issues listed above) regardless of whether the “Aspect Ratio” option is available for changing.
UPDATE (2021-07-21): Looks like the “Aspect Ratio” option gets disabled when “Low-latency mode” is enabled which also gets disabled automatically when “Adaptive-Sync” is enabled. Thanks Grant (@Lore_Wonder) for clarification.
[NEW 2021-07-01] 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:
- first, the original image is upscaled to an intermediate resolution;
- then 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.