Apple support tortured me with all kinds of diagnostics, with WontFix few weeks later. Wrote email and it got fixed in Sonoma :)

https://egpu.io/forums/mac-setup/4k144hz-no-longer-available...

24 inch 1080p 24 inch 4k (2x scaling) 27 inch 1440p 27 inch 5k (2x scaling) 32 inch 6k (2x scaling)

Other sizes are going to either look bizarre or you’ll have to deal with fractional scaling.

Given that 4k is common in 27/32 inches and those are cheap displays these kinds of problems are expected. I have personally refused to accept in the past that 27 inch 4k isn’t as bad as people say and got one myself only to regret buying it. Get the correct size and scaling and your life will be peaceful.

I would recommend the same for Linux and Windows too tbh but people who game might be fine with other sizes and resolutions.

Assuming the article is correct and the hardware can do 7680x4320 @60, which requires 8GB/s memory bandwidth, in theory it should be able to do the same to read the same memory and interleave every other line for the down-sampling. However, it's possible that the new memory controller can't support 2 simultaneous burst streams (because the 2 lines are 30KB apart in memory), or if it's doing a single burst and buffering the first line until the second line is available, then maybe the cache is smaller than 30KB.

Another possibility is that previously the scale averaged pairs of pixel horizontally and cached them until the next line was available to average with that, and for some reason it was changed to average all 4 at the same time and so the cache isn't sufficient (although it'd be weird as 25.25KB is a fairly weird size to limit the cache to)

Alternatively, looking at clock rates needed for the sampler, 3360x1890 @60 is 381MHz, 3840x2160 @60 is 497MHz. It's quite possible that they've lowered the base clock on some hardware and not considered that it'd impact the maximum effect on the scaler.

But whatever IMHO, it's unlikely to be a software bug with an easy fix.

Anyway I will run the diagnostic commands and see what I get.

I feel like some remote desktop software is already doing that sort of thing.

> Caps the HiDPI backing store to approximately 1.75x the native resolution (6720x3780 for 3840x2160 native), rather than the 2.0x needed for full HiDPI (7680x4320)

So, that could be an off by one bug? That might be testable by tweaking the system to think the display supports an even higher resolution.

Also, instead of messing with the Display Override Plist, patching drivers, etc, did they try using the “Advanced…” button in the “Displays” UI? They don’t mention they did.

For me (with a 27 inch 4K monitor not on M4 or M5) that replaces the 5-way choice by one with a list of 11 choices. With the then appearing “Show all resolutions” toggle, that becomes 18.

They've got a good thing going, but they keep finding ways to alienate people.

The article doesn't mention it.

Just another case of Apple intentionally going against established open standards to price gouge their users.

I wouldn't mind it as much if I didn't have to hear said users constantly moaning in ecstasy about just how much better "Apple's way" is.

High quality desktop Linux has been made real by KDE, and the AI-fueled FOSS development boom is accelerating this eclipse of proprietary nonsense like this.

If you're a developer, you should be using a system that isn't maintained by a company that intentionally stabs developers in the back at every turn. (Unless you're into that. U do u.)

That one also wasn't a hardware limitation as it ran my displays just fine in bootcamp, but macOS would just produce fuzzy output all the way.

It's infuriating.

If the theory about framebuffer pre-allocation strategy is to hold any water, I would think that 5k and 6k devices would suffer too, maybe even more. Given that you can attach 2x 5k monitors, the pre-allocation strategy as described would need to account for that.

Tim Apple's Apple has been fu#$%& me again..