After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 768133 - Make HighDPI limit configurable
Make HighDPI limit configurable
Product: mutter
Classification: Core
Component: wayland
git master
Other Linux
: Normal enhancement
: ---
Assigned To: mutter-maint
Depends on:
Reported: 2016-06-28 10:54 UTC by Michael Vorburger
Modified: 2021-07-05 13:49 UTC
See Also:
GNOME target: ---
GNOME version: ---

local temp hack (2.25 KB, patch)
2017-01-16 21:02 UTC, Caolan McNamara
none Details | Review

Description Michael Vorburger 2016-06-28 10:54:19 UTC
[Opening this bug based on a chat on #wayland with jadahl, SardemFF7, pq, raster, heftig, zubzub]

I'm a Fedora 24 end-user, and have a laptop with an internal 1920x1080 LCD and bought an external 4k UHD 3840x2160 screen. I was hoping / expecting that with Wayland I could use both and have different scaling on them, but noticed it didn't work out of the box. has the weston-info (there is a 3rd monitor listed there; ignore that one).

On IRC jadahl & pq kindly explained in details (Thank You!) that this is because that ext. one is physically "too big", so it's DPI is too low for the hard-coded auto-magic HIDPI_LIMIT "minimum resolution at which we turn on a window-scale of 2" that's #defined in to kick in.

The purpose of this issue is to suggest that perhaps this HighDPI limit could be made end-user configurable, to make it easier to benefit from window-scale of 2 in such mixed resolution monitor settings?

I understand that the "fractional scaling" which bug 765011 will eventually bring would also address this, but if that's a little further off, then perhaps this in the interim would be valuable to some?
Comment 1 Michael Vorburger 2017-01-16 10:17:30 UTC
I've since move on to other shores, but if I remember correctly, the suggested next step on the IRC chat (6 months ago), for anyone interested in contributing to moving this forward, was to start trying to even locally just change that hard-code constant (HIDPI_LIMIT), and report back if that helps.  Then making it run-time configurable would be a next step..
Comment 2 Caolan McNamara 2017-01-16 21:02:12 UTC
Created attachment 343596 [details] [review]
local temp hack

Well, here's a hack to make 28" 4k screens double scale. There might be some argument towards calculating something like the "apparent dpi at the distance from the eyes required to fit the whole screen into a view X degrees l/r of your direct eyeline" or some such
Comment 3 Jonas Ådahl 2017-01-25 08:31:52 UTC
FYI, The API introduced in bug 777732 will allow overriding the calculated scale.
Comment 4 Lonnie Best 2018-05-03 13:18:25 UTC
You should not only be able to have different fractal scaling for each monitor, but you should also be able to have fractal scaling for each separate window you launch.

Back around 2008, Mandriva released a desktop called Metisse that allowed (seemingly infinite) fractional scaling for each window! (much less is per monitor granularity) Here's a video of that in action:

To accomplish this, using Metisse, you'd simply hold down shift (or was it ctrl) while resizing the window.

You could do almost anything to that window, and all your mouse actions on that window would still work accurately no matter how you scaled it. You could even do silly impractical things like turn the window up-side-down, pivot it, push the left side of the window deeper into the background than the right side, etc. And, all your interactions with that window would still work accurately. It was amazing (and done on Linux first -- 10 years ago).

When will the world catch up with what Metisse accomplished in 2008? It was way ahead of its time.

Here's an academic paper on Metisse:
Comment 5 GNOME Infrastructure Team 2021-07-05 13:49:29 UTC
GNOME is going to shut down in favor of
As part of that, we are mass-closing older open tickets in
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
and create a new ticket at

Thank you for your understanding and your help.