one-key-hidpi
one-key-hidpi copied to clipboard
xzhih
Not working on m1 mac
Seems like its not working with m1. I used script on my old macbook (intel) and it worked fine. On m1 macbook after rebooting i do not see any results. Tried with and without EDID
+1 Confirmed it's not working on the M1 MacBook on a 2K monitor. macOS Big Sur 11.6
I found out that there is no solution for m1 macs because apple changed something with puprpose. So m1 basically not support hdpi on monitors less than 4k
If your monitor supports HDR mode, turn it on and M1 Macs will recognize it as a 4K panel for unknown reasons, then you can scale it like the built-in monitor. This is the only workaround I am aware of.
Nice. But I think you got it working because 4K displays should be by default supported for HiDPI by M1 macs and something was/is messed up somehow somewhere which prevented this in your config maybe even though you use a 4K display.
But if you found a reliable way to circumvent this current M1 limitation without a dummy on sub-4K displays, it would be great if you shared it with the community in a way that could be reproduced. The BetterDummy workaround is less than ideal honestly and it would be great if native support could be achieved. 🙂
This problem is too annoying!
https://github.com/waydabber/BetterDummy works fine for M1 Mac.
See this for a thorough info:
https://medium.com/@parttimeben/mac-it-just-works-horribly-c98fd9be4001
Yes, if you have any Retina compatible display already connected, you can use that to mirror its screen to your non-Retina display for HiDPI. SwitchResX will let you create native resolutions on M1 (but can't activate HiDPI) but if you create a native resolution on a display that already has HiDPI enabled (as it fits the requirements of Apple for this), you can match the aspect ratio of your external screen. The obvious disadvantage of this method is that you always need a separate display occupied only to allow mirroring. On Macs with multiple outputs you can use a physical dummy to circumvent this which mostly works (the drawbacks are sometimes flickering mouse and the possibility that the login screen will show on your physical dummy screen if mirroring fails which will require you to disconnect manually - but to be fair, BetterDummy has its headaches as well :)).
I tried both Switchresx and BetterDummy on M1 Macbook Pro.
Switchresx's: It creates a custom resolution like @waydabber mentioned, and then mirrors the external and internal displays. The disadvantage is that you must keep the internal display on (even if the brightness = 0), and it seems like a waste of system resources as the Mac renders two displays at once.
BetterDummy: It creates a dummy (virtual) display and mirrors it to the external monitor. The advnatage over Switchresx is that the internal display can be off (e.g., in clamshell mode). The disadvantage is that it is still heavy on resources and some people have mentioned a bit of mouse-lag when using BD.
Hey @ibehnam - I think neither SwitchResX nor BetterDummy should be that heavy on resources as in case of mirroring both approaches use an intra-GPU, hardware mirror which means that there should be a single common framebuffer (but even if the framebuffer is copied, everything happens on-chip for M1 machines and the framebuffers are not too large big actually, the desktop compositing - which might be the heavier thing - happens only once in both scenarios).
BetterDummy can do streaming instead of mirroring, that will actually have two desktops, but the actual process is also super-efficient (the source screen is applied to a window layer surface which is optimized at hardware/kernel level to work ultra fast on M1 machines).
On Intel you'll have some issues with BetterDummy especially with non-integrated GPUs as in that scenario a lot of data is being moved around but on Intel SwitchResX is unquestionably the best choice to create custom resolutions.
BetterDummy has some issues on some configs with mirroring which are related to various macOS bugs when mirroring a virtual display (this happens with Sidecar as well without BetterDummy) - there can be some sleep woes and sometimes flickering when there is some screen activity (for example mouse is moved around) due to some weird colorsync problems. This can be annoying and require disconnecting/reconnecting the dummy or turn off/on mirroring.
@waydabber thanks for the details. I followed this guide and this one to create *.plist files similar to what Switchresx does, but unfortunately, RDM doesn't pick them up. Given that /System/Library is read-only on latest macOS versions, I can only guess that Switchresx copies such files to /Library instead. But on my M1 MBP, this method no longer works.
So, if HiDPI resolution are disabled by Apple, I don't know how Switchresx manages to create them. Really curious!
I had a better experience with BetterDummy. But when using MonitorControl + BetterDummy, sometimes the external display starts flickering and the only way to fix it it to reconnect the HDMI cable.
Hi @ibehnam - yes, afaik SwitchResX can't create HiDPI resolutions on displays where this feature is disabled by Apple so in this regard there is no alternative currently to BetterDummy. SwitchResX can create custom scaled resolutions though on Apple Silicon. If HiDPI is already enabled for a display, then the relevant HiDPI versions of the created custom scaled resolutions should be accessible as well.
I know the mirror flickering issue is a pain. :(
@waydabber So the way I got Switchresx working was by creating the HiDPI resolution on the internal display, and then mirroring it to the external. Obviously, the downside is that two displays must be on and one can't close the lid in this case, which is why I prefer BetterDummy. To create a HiDPI resolution on Switchresx, I simply created a 3840x2160 (2x the 1920x1080 resolution). After restart, my custom resolution showed up as 1920x1080 HiDPI!
I hope the flickering issue goes away, but tbh I think it's more likely that Apple will break something in the next macOS :/
Yes, Apple breaking stuff is a possibility anytime - especially since all these solutions are using various undocumented features or stuff that was not envisioned originally to be used for such purposes. But I don't think Apple will intentionally cripple or remove stuff (macOS is literally littered with old stuff inside) - they usually break things only when they don't consider a current thing a documented feature and it gets in the way of something new/better. But messing with virtual screens in a bad way would cause a lot of issues (render DisplayLink not working for example which would restart the DisplayLink support saga that happened a few years ago after the driver model changes) so I don't think such a thing will happen. We'll see.