From ArchWiki


Is there already a workaround for java-based apps? They look really ugly on hidpi :/ —This unsigned comment is by Avarty (talk) 16:28, 25 June 2014‎. Please sign your posts with ~~~~!

Instant messengers

I think it would be worthwhile to change section 5 from 'Skype' to 'Instant Messengers / Chat' and add others as well. Telegram Messenger supports HiDPI perfectly, it has an option for 200% scaling in the settings. It is also supported on almost every major platform. —This unsigned comment is by Veazer (talk) 05:26, 8 January 2015‎. Please sign your posts with ~~~~!


Could you potentially temporarily change the console frame buffer resolution (i.e. during installation?) —This unsigned comment is by Georgewhite5 (talk) 18:50, 9 October 2015‎. Please sign your posts with ~~~~!

I found with the i915 driver I needed to add i915 to the MODULES section of /etc/mkinitcpio.conf for me to be able to set a large font (anything bigger than 16) for the vconsoles. systemd-vconsole-setup.service failed to start otherwise with with the following error: "/usr/bin/setfont failed with error code 71" Raoulmillais (talk) 18:29, 6 December 2015 (UTC)Reply[reply]

The archlinux iso doesn't come with lot of fonts. the best I got is sun12x22. This will make your life easy. Try running following command on prompt

setfont sun12x22

—This unsigned comment is by Mohit310 (talk) 16:24, 17 December 2015‎. Please sign your posts with ~~~~!

As of July 2016, the latarcyrheb-sub32 is also included after a fresh Arch Linux install. Unlike sun12x22 it looks much more similar to cp437 but it has just been scaled up. Its much larger size makes the console much more easier to read on a HiDPI screen. —This unsigned comment is by Makhlaghi (talk) 14:38, 22 July 2016‎. Please sign your posts with ~~~~!


I tried font settings in KDE Plasma but it doesn't change the DPI. Is there any other way to work around this.

—This unsigned comment is by Mohit310 (talk) 16:26, 17 December 2015‎. Please sign your posts with ~~~~!

Is adding a file under /usr/share really the best place to do this? Would it be better to do it in /etc, for example?

There is no option to sign this edit. The usual buttons used to do this are missing altogether.

—This unsigned comment is by Margali (talk) 20:30, 26 October 2017‎. Please sign your posts with ~~~~!

As the many unsigned templates on this page say, you just write ~~~~ at the end of your post. Use the preview button to see that the replacement is working. And I don't think there have ever been buttons for this... -- Lahwaacz (talk) 21:06, 26 October 2017 (UTC)Reply[reply]

Gnome Instructions are incomplete

When you use GNOME by default on a HiDPI system, it autodetects the settings to use. In fact, it doesn't even set the environment variable that this article references. In reality, it stays at zero and it's autodetected. But another setting that is part of a gsettings propertybag is also changed.

This is confirmed by looking at the source code for gnome-tweak-tool and seeing that it also changes XSettingsOverrides:

I think it's worth mentioning that this value probably doesn't need to be adjusted. GNOME has autodetected it for a few releases now. Certainly with 3.20 if the mixed-hidpi work lands.

—This unsigned comment is by Colemickens (talk) 02:35, 27 December 2015‎. Please sign your posts with ~~~~!

And also:

$ gsettings set org.gnome.settings-daemon.plugins.xsettings overrides "[{'Gdk/WindowScalingFactor', <2>}]" 

will overwrite any existing settings you do have there, not append to it.

—This unsigned comment is by Elijah Lynn (talk) 01:45, 1 August 2020‎. Please sign your posts with ~~~~!

Gnome Scaling for Different Devices

Recent changes asked the question:

The scaling factor is obviously different for every device. What is the advantage of using xrandr over gsettings (i.e. gsettings set org.gnome.desktop.interface scaling-factor 1.5), let alone combining them?


gsettings set org.gnome.desktop.interface scaling-factor 1.5

...generates an error. 1.5 is not allowed. The "period" is an illegal charater. You can only set 1 (100%), 2 (200%), 3 (300%), etc. As mentioned in the recent edit, this is not enough resolution for several devices which require 1.5, 2.5, 2.25 1.75 and so on.

Therefore, a tip/trick/hack/note was added that describes using the combination of xrandr and gsettings to achieve a scale of 1.5 (150%) without fonts becoming 'fuzzy'.

The real question should be: "Then why not use xrandr to change the scale the other way, say 1920 / 1.5?"

Answer: Then you'll have fuzzy fonts and lines.

Hopefully this answers the factual accuracy request.

Eduncan911 (talk) 22:41, 7 January 2016 (UTC)Reply[reply]

One also has the option to scale up to 2 with scaling-factor and scale it back down with the text-scaling-factor. It's easier and looks better in my experiences. And yes, the text-scaling-factor affects the physical size of other UI elements besides just text. Colemickens (talk) 22:47, 7 January 2016 (UTC)Reply[reply]
Excellent idea! How about adding it as an alternative method? Though, in my opinion, that takes up too much space. To each his own i suppose! Adding it as an alternative to mine allows customization.
EDIT: I just tried this and the title bars are all wacky, along with the topbar. I wouldn't recommend it at all.
Now, I must state that I just tested this on a fresh new install on a system with no other changes to DPI or scale (no GTK, no scaling tricks, nothing). As a matter of fact, i even booted off of an Arch Live CD (made by Antergos) and tested it again to make sure it wasn't my bare-metal + Gnome install I just finished. If you are stating that it looks good on your system, then perhaps you've done other scaling that resolves this issues. Which, IMO again, is overkill if you can solve everything with 1 or 2 combinations. Eduncan911 (talk) 23:19, 7 January 2016 (UTC)Reply[reply]
Probably these "fuzzy" fonts were something I have missed when I did my edit today - please feel free to edit the way you think is appropriate. BTW how could I look at these fuzzy fonts? I checked Microsoft Word Online - looks good with "scale" approach, identical to "scale-from". F3flight (talk) 22:54, 3 February 2016 (UTC)Reply[reply]
Actually please re-check my last edit because it looks like it is not the same that has been proposed here - I do not do text-scale-factor nor do I do scale down by lowering the current res, like "1920/1.5". I feel like my approach keeps everything crisp while providing easier granularity then trying different pre-calculated values. Please re-check and let me know. F3flight (talk) 23:01, 3 February 2016 (UTC)Reply[reply]

Rephrase X Resources

The wording is not so obvious in the section, HiDPI#X_Resources as Lahwaacz suggested here [1]. Rather than desktop environments which DO NOT use `~/.Xresources` file, I recommend list few environments or window managers which DO use X resources. In a page with dedicated sections for all kinds of applications, it is a shame not to mention a window manager. Speaking from personal experience on trying to configure i3 for a HiDPI screen. Jadelord (talk) 22:58, 6 July 2016 (UTC)Reply[reply]

Since nothing is listed on the opposite side, it means basically "everything else". Adding one example is not going to make it any more obvious for people that don't use i3 and as I pointed out in the edit summary, we can't list every window manager here. -- Lahwaacz (talk) 07:06, 7 July 2016 (UTC)Reply[reply]

GNOME ignores X settings

[Moved from User talk:Kynikos#Hidpi — Kynikos (talk) 11:54, 20 April 2017 (UTC)]Reply[reply]

The blog entry I mentioned is still valid and works perfectly. Unfortunately compiling / make install does not work for me under Ubuntu (sorry no Arch user ;-) ) but even without Patching, so its a general compile problem.

The alternative I mentioned seems not to work as good as patching the scaling factor, even if its proposed to do nearly the same. Actually I have not enough time to dig into source.

Actually Gnome scaling, the patch or Gnome Settings Daemon itself does nothing then manipulate XServer DPI Setting. In particular gnome also prevents self-change XServer dpi settings.

So it's a bit running round in the circle when discussing where to put it. Feel free to put it where you think it makes the most sense.

—This unsigned comment is by Exloermond (talk) 20 April 2017‎. Please sign your posts with ~~~~!

Thanks for the explanation, I've moved your post here and linked it from the Accuracy flag so that it can be useful to other users, since I neither use GNOME nor a HiDPI monitor. Also, I've moved the content that you added under HiDPI#GNOME, where I think it will be more visible to interested users. — Kynikos (talk) 12:05, 20 April 2017 (UTC)Reply[reply]

Java - Is sun.java2d.uiScale really effective?

Is sun.java2d.uiScale really effective? I've tested it with VisualVM (which is based on AWT) to no avail. Hexchain (talk) 16:58, 14 September 2017 (UTC)Reply[reply]

Side display - Nvidia scale 2.0x2.0 problem

Regarding note:

Note: Above solution with --scale 2x2 does not work on some Nvidia cards. No solution is currently available.[2]

Possible workaround that worked for me using nvidia-settings:

nvidia-settings --assign CurrentMetaMode="DVI-D-0 {ForceFullCompositionPipeline=On}" 

see also: [3] Sbeverts (talk) 21:24, 7 November 2017 (UTC)Reply[reply]

I think that using the scale factor on xrandr achieves the same effect as configuring the monitor with a lower resolution. Everything get scaled pixel-wise. It works but you totally lose the benefit of HIDPI. You can probably also do that with a Nvidia card (untested). Olive

Multiple external monitors?

The setup described in the "Multiple displays" session works for me when I have only one external display. However, when I have more than one external displays of lower dpi, it doesn't seem to work. For example, if I write `xrandr --output HDMI1 --right-of eDP1 --panning 3840x2400+2560+0 --scale 2x2 --output DP2 --left-of eDP1 --panning 3840x1920+2560+0 --scale 2x2` (not sure if this is the right thing to write), then both DP2 and HDMI1 become of the wrong scale. Could anybody provide an example of working multiple external monitors setup? Thanks.

EDIT: One way that I've now found is to downscale the laptop screen instead of trying to upscale the two external monitors, with --scale 0.5x0.5. The laptop screen gets a bit blurry, but actually I feel this kind of blurry to be more acceptable to the strange font rendering that happens when I upscale the external monitors. I guess before a better solution is found I'll try to stick with this.

SZJX (talk) 09:45, 28 February 2018 (UTC)Reply[reply]

Virtualbox and KDE

I found a workaround that does not require calculating anything:


Buovjaga (talk) 10:44, 17 May 2018 (UTC)Reply[reply]

Xft.dpi and GDK_SCALE

Xft.dpi scales fonts. This has the effect of making programs usable (including GDK applications) but doesn't actually scale UI (as touched upon in the article). The solution for GDK in the typical case is, first, to set GDK_SCALE=2. This doubles the UI and fonts. Since the fonts are already scaled by the DPI settings, they're now too big. So, second, you set GDK_DPI_SCALE=0.5 to scale the fonts back down to where they were.

The information is in the article but it doesn't really link the two concepts. The GDK section, for example, contains both commands but no explanation of why you'd want them. I'm not sure where the edits should go. I was thinking of putting a more detailed explanation in the GDK section and editing the Xft section to more clearly note that users should also read the section for their UI toolkit.

The explanation of these settings is at:

Webarnes (talk) 17:39, 14 February 2019 (UTC)Reply[reply]

KDE force font DPI: how to calculate DPI value

While, in my case, using Force font DPI scales fonts and UI elements correctly, and when I used display scaling the fonts and UI were blurry, I had trouble deciding on the correct DPI value to achieve a 1.2x display scale. The answer I found online was to multiply 1.2 (or your scale factor) with the default DPI value (96) and set the result as the value for Force font DPI.

I'd like to add the above info to the KDE section, but I'm new here and I'd like to read up on writing style, before I attempt that. Any feedback is appreciated.

—This unsigned comment is by Dmaroulidis (talk) 10:18, 25 July 2019‎. Please sign your posts with ~~~~!

AutoHiDPI extension

The mention of said extension should be removed because its too outdated. Even firefox-esr does not support it anymore because it is too old for this. The link to the extension is also dead.

NetSysFire (talk) 18:55, 13 February 2021 (UTC)Reply[reply]

False information in KDE Plasma - Tray icons with fixed size?

In HiDPI#Tray icons with fixed size (for KDE Plasma), it says:

The tray icons are not scaled with the rest of the desktop, since Plasma ignores the Qt scaling settings by default. To make Plasma respect the Qt settings, set PLASMA_USE_QT_SCALING=1.

First, the tray icons do scale correctly if I change "Panel height" for the panel. Second, I try to set PLASMA_USE_QT_SCALING=1 in ~/.bash_profile, then I am stuck in the login screen. I try to switch from X11 to Wayland, but the issue persists.

Is this section outdated, or is this my own problem? TripleCamera (talk) 03:56, 6 February 2024 (UTC)Reply[reply]

Yeah, that info is kinda wrong. It is not about tray icons. It is about Plasma panels, which do not scale in X11 unless PLASMA_USE_QT_SCALING=1 is set.
Idk why it makes you not being able to log in though. Try to reset the panel settings I guess, by deleting plasmashellrc and plasma-org.kde.plasma.desktop-appletsrc from ~/.config/.
Also try to clear ~/.cache, it makes troubles sometimes with graphical environments.
Hanabishi (talk) 10:15, 6 February 2024 (UTC)Reply[reply]
Oh, I forgot to mention that. Panels don't follow the "global scale" option in X11. (PS. Although they do follow in Wayland, I gave up Wayland because everything in the windows looks fuzzy.)
To solve the problem of not being able to login, I opened another tty (Ctrl+Alt+F3, I forgot where I learned this) and deleted the variable. TripleCamera (talk) 11:48, 7 February 2024 (UTC)Reply[reply]

Panels don't follow the "global scale" option in X11.

That's exactly what PLASMA_USE_QT_SCALING=1 solves.

I gave up Wayland because everything in the windows looks fuzzy.

Wayland is perfectly fine, it is only matter of proper configuration.
For KDE, Display Configuration > Legacy Applications (X11) > Apply scaling themselves. It fixes blurriness for XWayland apps.
Also setting QT_QPA_PLATFORM=wayland and GDK_BACKEND=wayland helps by running most apps natively (see Wayland#GUI libraries for details).
Just remember that some setting require session restart to be applied.
Hanabishi (talk) 12:00, 7 February 2024 (UTC)Reply[reply]
First, I tried to delete ~/.config/plasmashellrc, ~/.config/plasma-org.kde.plasma.desktop-appletsrc and ~/.cache, but I still couldn't login (probably because KDE crashed when logging in). However, after removing set PLASMA_USE_QT_SCALING=1 and successfully logging in, I found that the config files I deleted were regenerated, and the panel height was set to an adequate value (much higher than before). :D
Second, I found that blurriness was my fault. After setting "global scale" (which was reset when I switched to Wayland), I had to restart the applications to fix blurriness. To fix blurriness for the panel, I had to logout and login again. TripleCamera (talk) 07:52, 8 February 2024 (UTC) (edited)Reply[reply]
I was so stupid. I read Environment variables again and found that I should use export PLASMA_USE_QT_SCALING=1 instead of set PLASMA_USE_QT_SCALING=1. I changed the config and then panels could follow the "global scale" option in X11. The wiki was correct, it was my mistake again. TripleCamera (talk) 14:47, 8 February 2024 (UTC)Reply[reply]
Corrected the section anyway. Special:Diff/800012
Hanabishi (talk) 15:11, 8 February 2024 (UTC)Reply[reply]
Thank you for your edit! I just amended it and added more information from my own experience. However, I changed the title back because I couldn't see any other changes apart from the panel height. Special:Diff/800052 TripleCamera (talk) 10:12, 9 February 2024 (UTC)Reply[reply]
It also affects widget sizes on the desktop and some popouts (like a calendar size from the digital clock). So your observations are lacking.
Hanabishi (talk) 16:20, 9 February 2024 (UTC)Reply[reply]
Indeed, I just tried it out. The calendar popup became enormous when PLASMA_USE_QT_SCALING is set. However, since this variable affects many desktop elements, maybe it's better to move this section to the bottom of HiDPI#KDE Plasma. TripleCamera (talk) 12:41, 11 February 2024 (UTC)Reply[reply]
I don't get the point of moving the section.
Btw, wrong popouts sizes (like the calendar) is kinda a bug. They became normal if you remove and add the widgets again, iirc. Or after plasma-org.kde.plasma.desktop-appletsrc reset. Hanabishi (talk) 12:53, 11 February 2024 (UTC)Reply[reply]
I can confirm that PLASMA_USE_QT_SCALING affects other desktop elements. Apart from the calendar popout from the digital clock, I found a reddit post linking to a bug report, stating that PLASMA_USE_QT_SCALING affected checkboxes in the system tray settings dialog. It can be reproduced on my computer.
Since this variable affects more than just panels, I just moved it to the bottom of HiDPI#KDE Plasma, and placed the way to adjust only panel scaling under "Panel Scaling". (Special:Diff/800267) If this is not adequate, please feel free to revert. TripleCamera (talk) 02:42, 12 February 2024 (UTC)Reply[reply]