A few HiDPI tricks for Linux • Hacker News Board

Re: A few HiDPI tricks for Linux

#61

Post by vetinari » Sat, Jan 30, 2021, 11:06 PM UTC

azinman2 wrote: post #20

libcg wrote: post #19

This article makes it seem like these steps are necessary for most Linux setups, when in reality you can do per monitor fractional scaling from a GUI as long as you're using GNOME on Wayland. No need to fiddle with per app settings, it works transparently.

Except the author is using X11 as many people will. And what this shows is how many different environments / toolkits / settings there are out there. It would be nice if distributions would do a better job of handling this for you. I’ve run into the same issues myself, and it’s kind of hard to believe that I even had to figure out these configuration dpi settings in 2021.

The point is, you don't have to figure out configuration dpi settings in 2021, if you use distributions as they are supposed to be used.

If you insist on your favorite x11 window manager, the integration is on you. No point in complaining then, it is self-inflicted pain.

Re: A few HiDPI tricks for Linux

#62

Post by vetinari » Sat, Jan 30, 2021, 11:12 PM UTC

robertoandred wrote: post #9

gurkendoktor wrote: post #5

Earlier quoted context omitted.

To provide some counter-anecdata, if you are in the lucky position to have screens that work at exactly 200% (4K at 24", 5K at 27"), then Ubuntu and its derivatives will Just Work out of the box. At least that was my experience around 2017-2019. Fractional scaling factors like 150% are tricky, but macOS does not properly support them either. The only app that didn't pick up my DPI settings on Linux was Spotify, but a…

macOS supports fractional scaling just fine, by rounding up and then downscaling. Sure it's not pixel-perfect to the display, but at such high ppi it's not really noticeable, and certainly much better than trying to get actual fractional resolutions working. Apple tried true resolution independence in the early 2000s and it didn't work out. 2x and 3x scaling proved to be a much better solution.

macOS does very similar thing that Gnome/Wayland is using; except in Linux land, due to misc reasons[1], it works only for Wayland apps.

Yet, there are cries from the Internets, that it is not pixel perfect and other solution (Windows/Qt/Android-like) should be used.

[1] Mostly that you can't update client side libs like you can in Mac and Windows land and be done; there will be always some legacy X11 client that will connect directly to display server and ignore your modifications. On mac and windows, apps cannot talk directly to display server, the protocol is not public.

Re: A few HiDPI tricks for Linux

#63

Post by canofbars » Sat, Jan 30, 2021, 11:14 PM UTC

kevincox wrote: post #49

alwaysanon wrote: post #41

Credit where credit is due this is the one area where Windows is the best OS these days. It not only will do fractional scaling but it will do display independent fractional scaling - whack in the scaling percentage on each screen and in the recent versions of Windows 10 it works well and looks great and remembers your settings when you plug that monitor back in. It is perhaps THE thing along with WSL2 (now giving me…

This also works well on GNOME Wayland (and probably other Wayland compositors) since about 1.5 years ago (for me at least). In the display settings you can pick a scale per monitor and almost all apps will respect it. (It seems some apps with custom toolkits are lagging but I can't remember the last time I ran into one of these).

Electron is the biggest offender these days. I saw that they added support a few months ago but it seems the apps haven't turned it on yet

Re: A few HiDPI tricks for Linux

#64

Post by vetinari » Sat, Jan 30, 2021, 11:15 PM UTC

ironmagma wrote: post #34

sitzkrieg wrote: post #25

Earlier quoted context omitted.

i managed (well, to make sensitivity low enough it was usable even at 400dpi .. ) by recompiling libinput. yea really

Shouldn’t that be something that’s pulled into upstream? And if they refuse, fork libinput?

Since the libinput upstream is one guy and nobody stepped up to help him, good luck with long-term maintenance of your fork.

Re: A few HiDPI tricks for Linux

#65

Post by canofbars » Sat, Jan 30, 2021, 11:18 PM UTC

glandium wrote: post #44

wmf wrote: post #40

Earlier quoted context omitted.

It's fixed in Wayland.

Is it intrinsically fixed, or is it up to the compositor to do the right thing? (implying it may be broken in some compositors)

All I know is the gnome settings has a scaling section and everything respects that scale.

Re: A few HiDPI tricks for Linux

#66

Post by badsectoracula » Sat, Jan 30, 2021, 11:19 PM UTC

KirillPanov wrote: post #59

wmf wrote: post #40

Earlier quoted context omitted.

It's fixed in Wayland.

No, it's not, see my comment [1]. Wayland just punts on the issue by removing the compositor from any decision involving scaling. The "Wayland Way" is for the compoisitor to relay information (monitor-reported scale, etc) to the client, and have the client figure out how to scale itself correctly. Unfortunately this means that these HiDPI bugs have to be fixed over and over in myriad apps and toolkits, and software (…

> The "Wayland Way" is for the compoisitor to relay information (monitor-reported scale, etc) to the client, and have the client figure out how to scale itself correctly.

FWIW this is also the "Xorg Way" (RandR provides all the necessary information), it is just that clients do not bother.

Ideally the window manager would use the information provided by RandR to set up default scale levels for each monitor and then send notifications to the applications whenever the window changes monitor to alter their scale levels (this would also allow for custom per-window scale level that is applied on top of the per-monitor scale level in case someone wants to scale up/down a specific window - e.g. scaling up some notepad-like editor for a screencast).

This does require each client (and toolkit) to support arbitrary scaling... and window managers to agree on such a message, though i do remember an email about this topic being posted on Xorg mailing list some time ago. AFAIK Qt should already provide the necessary functionality for this.

Re: A few HiDPI tricks for Linux

#67

Post by canofbars » Sat, Jan 30, 2021, 11:19 PM UTC

SweetestRug wrote: post #4

I set up Linux on a Dell XPS 13 with the HiDPI screen. With both Ubuntu and Manjaro it was relatively painless, especially using GNOME via Wayland. i3 and sway also worked well too. I had heard a lot of issues with Linux and HiDPI, and was worried I would have to return/swap for a FHD screen, but everything has worked almost flawlessly.

>but everything has worked almost flawlessly.

Its because everyone having issues is using X and likely 2 monitors with different dpis. On wayland its pretty much flawless unless you use 2 monitors at different scales and load an X application.

Re: A few HiDPI tricks for Linux

#68

Post by canofbars » Sat, Jan 30, 2021, 11:20 PM UTC

azinman2 wrote: post #20

libcg wrote: post #19

This article makes it seem like these steps are necessary for most Linux setups, when in reality you can do per monitor fractional scaling from a GUI as long as you're using GNOME on Wayland. No need to fiddle with per app settings, it works transparently.

Except the author is using X11 as many people will. And what this shows is how many different environments / toolkits / settings there are out there. It would be nice if distributions would do a better job of handling this for you. I’ve run into the same issues myself, and it’s kind of hard to believe that I even had to figure out these configuration dpi settings in 2021.

>It would be nice if distributions would do a better job of handling this for you

They did, its called wayland. If you want to use a legacy tool you shouldn't expect it to work as nice as the current generation software.

Re: A few HiDPI tricks for Linux

#69

Post by cycloptic » Sat, Jan 30, 2021, 11:21 PM UTC

KirillPanov wrote: post #57

If anybody knows how to forcibly override the "pixels per mm" reported by a monitor, you will be my hero forever. Every solution I've found so far (including the QT/GTK environment variables for overriding DPI) ends up instead causing scaling during compositing, rather than getting the apps to rasterize their fonts at the correct size in the first place. The worst offenders are anything derived from Chromium (i.e. qu…

I don't know of any Wayland implementations that let you do that, it wouldn't be hard to hack in, but Wayland applications should not be using that information to decide scaling. They should be using the wl_output.scale.

In X11, you can do it with xrandr --fbmm. Technically you can also set this information per-monitor but I don't think a command line option was ever added for it.

Re: A few HiDPI tricks for Linux

#70

Post by ironmagma » Sat, Jan 30, 2021, 11:22 PM UTC

vetinari wrote: post #64

ironmagma wrote: post #34

Earlier quoted context omitted.

Shouldn’t that be something that’s pulled into upstream? And if they refuse, fork libinput?

Since the libinput upstream is one guy and nobody stepped up to help him, good luck with long-term maintenance of your fork.

It's this kind of defeatist, responsibility-shifting attitude that holds Linux back from becoming a widely used desktop platform. What's the worst case with a fork, it stagnates and remains mostly identical to the upstream?