Difference between revisions of "Talk:HiDPI"

From ArchWiki
Jump to: navigation, search
(Xrandr: re)
Line 140: Line 140:
:This obviously lowers the effective resolution of the screen from 2560x1440 to 1664x936 so it's not enough compared to the methods described on the [[HiDPI]] page which preserve the high resolution. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:01, 11 February 2018 (UTC)
:This obviously lowers the effective resolution of the screen from 2560x1440 to 1664x936 so it's not enough compared to the methods described on the [[HiDPI]] page which preserve the high resolution. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:01, 11 February 2018 (UTC)
::Agreed, but if your goal is to scale up the size of all windows to make them usable and don't care about the lower dpi, this works and might be what a lot of people need.  [[User:Djraymondnm|Djraymondnm]] ([[User talk:Djraymondnm|talk]]) 16:36, 11 February 2018 (UTC)

Revision as of 16:37, 11 February 2018


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)

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)

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: https://github.com/GNOME/gnome-tweak-tool/blob/master/gtweak/tweaks/tweak_group_windows.py#L64

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 ~~~~!

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)

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)
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)
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)
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)

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)

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)

GNOME ignores X settings

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

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)

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)

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)


I have found that using xrandr alone at the start of a session solves most problems with hidpi displays. For instance,

xrandr --output eDP-1 --scale 0.65x0.65

on a Lenovo X1 Gen 4 laptop with a 2560x1440 pixel display scales all application sizes, fonts, and icons by the same amount, resulting in the following output from "xdpyinfo | grep -B 2 resolution"

screen #0:
 dimensions:    1664x936 pixels (440x247 millimeters)
 resolution:    96x96 dots per inch

There is no obvious problem with fuzzy fonts, etc.

The advantage of this solution is that it works for all applications, even legacy code using the TK tool kit and older.

Most desktop environments have a way of executing programs at the start of a session. I have successfully used xrandr this way on Openbox, LXDE, and Mate. (I haven't tried Gnome, but from other comments it appears that this would work on Gnome as well.)

The only real problem I have encountered is that this technique does nothing for the desktop manager, though LXDM doesn't reset the screen dimensions between sessions, so it only displays with tiny fonts after reboot.

Djraymondnm (talk) 13:41, 11 February 2018 (UTC)

This obviously lowers the effective resolution of the screen from 2560x1440 to 1664x936 so it's not enough compared to the methods described on the HiDPI page which preserve the high resolution. -- Lahwaacz (talk) 14:01, 11 February 2018 (UTC)
Agreed, but if your goal is to scale up the size of all windows to make them usable and don't care about the lower dpi, this works and might be what a lot of people need. Djraymondnm (talk) 16:36, 11 February 2018 (UTC)