macOS: native display resolution reported incorrectly (when using a scaled resolution, very common on macOS)

[rxhfcy]

General description of bug:

• What happened:
  fastfetch doesn't report the native display resolution correctly on macOS

I tried multiple different (scaled) resolutions on 2 different computers on 2 different macOS versions (macOS 14 beta and macOS 13)

Looks like "Display:" is using "scaled as" x 2 instead of the native resolution (when using a scaled resolution which is the default behavior on macOS).

Some examples:
(M1 MacBook Air (2020), the native resolution of the built-in display is 2560x1600)

scaled to look like 1024x640 (in System Settings / Displays):

Display: 2048x1280 @ 60Hz (as 1024x640)

"as 1280x800"
(now "Display: 2560x1600" is reported correctly, probably because it happens to be scaled x 2):

Display: 2560x1600 @ 60Hz (as 1280x800)

"as 1440x900" (I believe this is the default setting for M1 MacBook Air laptops):

Display: 2880x1800 @ 60Hz (as 1440x900)

"as 1680x1050":

Display: 3360x2100 @ 60Hz (as 1680x1050)

From the other computer (as 1920x1080, as 2560x1440, as 3008x1692, as 3360x1890, as 3840x2160 (native)
Native resolution of the monitor: 3840x2160

Display: 3840x2160 @ 60Hz (as 1920x1080)
Display: 5120x2880 @ 60Hz (as 2560x1440)
Display: 6016x3384 @ 60Hz (as 3008x1692)
Display: 6720x3780 @ 60Hz (as 3360x1890)
Display: 3840x2160 @ 60Hz 

PS. I also tried on neofetch, which always (only) shows the scaled resolution, unless you "brew uninstall --ignore-dependencies screenresolution" (after that neofetch only shows the native resolution)

• What should happen:
  Should show the correct native resolution. I normally use "1440x900" so in my case it should be:

Display: 2560x1600 @ 60Hz (as 1440x900)

• Did it work in an older version: didn't test
• Where did you get the binary: homebrew ("brew install fastfetch")
• Does this issue still occurs in the latest dev build? didn't test

Often helpful information:

Output of fastfetch --version:

fastfetch 1.12.2 (aarch64)

(clip)If this isn't possible (or too much work) for you, post the output of env NO_CONFIG=1 fastfetch --show-errors --stat --multithreading false --disable-linewrap false --hide-cursor false.

                     c.'          x@x.local                                                       0ms
                 ,xNMM.           --------------                                                       0ms
               .OMMMMo            OS: macOS Sonoma 14.0 23A5301h arm64                                 0ms
               lMM"               Host: MacBook Air (M1, 2020)                                         0ms
     .;loddo:.  .olloddol;.       Kernel: 23.0.0                                                       0ms
   cKMMMMMMMMMMNWMMMMMMMMMM0:     Uptime: 4 days, 13 hours, 44 mins                                    0ms
 .KMMMMMMMMMMMMMMMMMMMMMMMWd.     Packages: 91 (brew), 6 (brew-cask)                                   0ms
 XMMMMMMMMMMMMMMMMMMMMMMMX.       Shell: bash 5.2.15                                                   7ms
;MMMMMMMMMMMMMMMMMMMMMMMM:        Display: 2880x1800 @ 60Hz (as 1440x900)                             69ms
:MMMMMMMMMMMMMMMMMMMMMMMM:        DE: Aqua                                                             0ms
.MMMMMMMMMMMMMMMMMMMMMMMMX.       WM: Quartz Compositor                                                0ms
 kMMMMMMMMMMMMMMMMMMMMMMMMWd.     WM Theme: Blue (Dark)                                                0ms
 'XMMMMMMMMMMMMMMMMMMMMMMMMMMk    Theme: Not supported on this platform                                0ms
  'XMMMMMMMMMMMMMMMMMMMMMMMMK.    Icons: Not supported on this platform                                0ms
    kMMMMMMMMMMMMMMMMMMMMMMd      Font: .AppleSystemUIFont [System], Helvetica [User]                  4ms
     ;KMMMMMMMWXXWMMMMMMMk.       Cursor: Fill - Black, Outline - White (42px)                         0ms
       "cooc*"    "*coo'"         Terminal: iTerm 3.5.20230805-nightly                                 0ms
                                  Terminal Font: JetBrainsMonoNF-Regular (14pt)                        1ms
                                  CPU: Apple M1 (8)                                                    0ms
                                  GPU: Apple M1 (7)                                                    2ms
                                  Memory: 7.62 GiB / 16.00 GiB (47%)                                   0ms
                                  Disk (/): 162 GiB / 210 GiB (77%)
                                  Disk (/Volumes/x): 1.85 GiB / 2.33 GiB (79%)                3ms
                                  Battery: 93%                                                         1ms
                                  Power Adapter: not connected                                         0ms
                                  Locale: en_US.UTF-8                                                  0ms
                                                                                                       0ms
                                  ████████████████████████
                                  ████████████████████████                                             0ms

Output of fastfetch --list-features:

threads
vulkan
imagemagick7
chafa
zlib
sqlite3

[CarterLi]

That's expected behavior.

There are 3 resolutions:

1. The native (highest) resolution supported by hardware monitor.
2. The output resolution ( the image resolution generated by GPU ). It will be scaled to the native resolution by monitor.
3. The scaled resolution. It will be scaled to the output resolution by software (if the app you are using supports HIDPI) or system (if the app you are using doesn't support HIDPI)

What fastfetch detected is output_resolution as (scaled_resolution)

2 here is scale factor, or devicePixelRadio. In macOS, it's always 2, which is called retina display, not customizable so far.

It is customizable in other platforms. For example, I'm using 1.5 in my Windows laptop, so it's detected as 2560x1440 (as 1707x960)

[rxhfcy]

OK I'm sure that's technically correct, but my guess is that what a normal non-technical user who doesn't care about obscure implementation details expects to see here is 1 and 3 (native highest resolution of the monitor + the scaled resolution). Just a hunch of course.

[CarterLi]

I don't think it's counterintuitive, as these resolutions are the resolutions customized by user in system / window manager settings. Is there really any *fetch programs detects native / highest resolutions?

And ot's 2023, all modern systems support HiDPI scaling. So there is no reason not to use the highest resolution as the output resolution. One can assume that output resolution is the native resolution in most cases.

[CarterLi]

Just tested neofetch in Linux. It uses output resolutions for X11, but uses native resolutions for Wayland.

X11:

Wayland:

Neofetch uses native resolution is not because neofetch creator decided to report native resolution for Wayland, but is because neofetch has better support for X11, and uses some X11 programs to detect the output resolutions (and refresh rates)

[rxhfcy]

I don't know what other people expect here and I don't expect to change your mind, but I personally expect *fetch to mainly report hardware specs.

To me the "output resolution" is a weird implementation detail about what the system is imagining under the hood, and reporting it is like saying my system has 18 GB of RAM (because 16 GB physical + 2 GB Swap is obviously 18 GB).

[CarterLi]

I personally expect *fetch to mainly report hardware specs.

That's a hardware spec. It's the resolution outputed by GPU as I said before. And you can choose a output resolution only if the hardware monitor supports it.

my system has 18 GB of RAM (because 16 GB physical + 2 GB Swap is obviously 18 GB).

Fastfetch never reports the full physical memory sizes, but always the usable memory sizes. There are usually a few memory reserved for system use ( eg for intergrated GPU ). However it's not the case for macOS, which seems to use a different strategy.

Fastfetch does support swap size detection by the way. Fastfetch decided to split them into 2 different modules because they are useful ( if your physical memory is full you can expect a major slow down ).

But it's not the case for native resolution, because a program can't make use of it without changing the output resolution. Note a program can make use of output resolution as long as it is HiDPI aware.

[CarterLi]

It is the output resolution that decides how many details the displayed image has, not the native resolution.

[CarterLi]

I suspect if neofetch can report the native resolution, but can only report the highest resolution available. The highest output resolution is not always the native resolution supported by monitors, because there are many things can limit the maximum output resolution can make use of.

For example, if you use a HDMI 1.2 connection cable to connect a 4K monitor, you can't choose 4K as the output resolution

https://en.wikipedia.org/wiki/HDMI#Refresh_frequency_limits_for_standard_video

Will verify it tomorrow

[CarterLi]

Tested. If screenresolution is not available, neofetch always reports the native ( the same as highest available ) resolution for builtin retina display, and reports the output resolution for external display

Because of the inconsistant between different monitors, I'm sure that it's a bug of neofetch. I will submit a PR to neofetch to fix this.

I have no plan to change behavior of fastfetch. Closing

[CarterLi]

PR submitted: dylanaraps/neofetch#2356

[CarterLi]

Added a new module Monitor

$ NO_CONFIG=1 ./fastfetch -s host:display:brightness:monitor -l none
Host: MacBook Pro (16-inch, 2021)
Display (Color LCD): 3456x2234 @ 120Hz (as 1728x1117) *
Display (U32J59x): 3840x2160 @ 60Hz (as 1920x1080)
Brightness (Color LCD): 87%
Monitor (Color LCD): 3456x2234 px - 344x223 mm (16.14 inches, 254.97 ppi)
Monitor (U32J59x): 3840x2160 px - 697x392 mm (31.48 inches, 139.94 ppi)