A few HiDPI tricks for Linux • Hacker News Board

Re: A few HiDPI tricks for Linux

#91

Post by podiki » Sun, Jan 31, 2021, 1:03 AM UTC

vbernat wrote: post #37

podiki wrote: post #35

Some other resources that may be helpful for anyone looking is (of course) the Arch wiki [0]. I also found it helpful to set somethings like DPI based on the machine (I share my dot files across my computers) which can be done pretty easily using e.g. the hostname [1]. (Note that GitHub doesn't perfectly render the org file, you'd want to see the raw file for details if interested in literal dotfiles.) [0] https://wi…

Also, it is possible for most settings to be dynamic, which is useful on a laptop where you can plug screens, with XSETTINGS. That's what Gnome and XFCE are using. With Awesome WM, I am using a script [1] to update XSETTINGS (through xsettingsd configuration file). I explain more on my blog [2]. [1] https://github.com/vincentbernat/awesome-configuration/blob/... [2] https://vincent.bernat.ch/en/blog/2018-4k-hidpi-dua…

Nice, thanks for sharing! At most I've also hooked up a projector to my computer, but never needed to deal with any setting changes really (just for gaming or rarely for a presentation).

A little off topic, but I've run into some weird issues with Display Port/Nvidia/Dell monitor where the monitor is not recognized on unplug/replug. In the past I know there were some issues with older Nvidia drivers and this particular monitor (P2715Q), though this seems like a weird problem that I've seen others have with different configurations online. It led to me needing a weird set of steps (I wrote about this in my Valve Index impressions [0]), using xrandr to add the display mode and switching to a virtual console too. I'm guessing this is mostly due to the older Dell monitor which has always been a bit wonky with Display Port. I assume things are better these days more broadly.

Relevant part of [0]:

  xrandr --newmode "4K" 533.250 3840 3888 3920 4000 2160 2163 2168 2222 +hsync -vsync
  xrandr --addmode DP-0 4K
  xrandr --output DP-0 --mode 4K
  # switch to virtual terminal, i.e. Ctrl-Alt-F2
  # switch to DisplayPort input on monitor which should display the terminal
  env DISPLAY=:0 xset dpms force off; sleep 5; env DISPLAY=:0 xset dpms force on
  # switch back to X, i.e. Ctrl-Alt-F7

The modeline to add can be found ahead of time with xrandr --verbose or using a tool like cvt or gtf (see the Arch wiki). Sometimes, though, I just need to power cycle the monitor or unplug and replug some cables. I hope this is just this older hardware, and probably solved, like everything else here, with a new GPU that has more DisplayPort outputs.

[0] https://boilingsteam.com/the-valve-index-on-linux-on-a-min-s...

Re: A few HiDPI tricks for Linux

#92

Post by podiki » Sun, Jan 31, 2021, 1:11 AM UTC

podiki wrote: post #35

Some other resources that may be helpful for anyone looking is (of course) the Arch wiki [0]. I also found it helpful to set somethings like DPI based on the machine (I share my dot files across my computers) which can be done pretty easily using e.g. the hostname [1]. (Note that GitHub doesn't perfectly render the org file, you'd want to see the raw file for details if interested in literal dotfiles.) [0] https://wi…

To add to hardware that's being mentioned in this discussion, for reference, I use a 27" 4k monitor (Dell P2715Q) at 1.5x scaling and a laptop with 15" 4k screen (Dell XPS 15 9550) at 2x scaling. Both on Arch, X11, and just a window manager (currently Xmonad, but just before that StumpWM and i3, too). One of the reasons being I prefer to have direct control over Xresources, xinitrc, etc. to set up dpi, color management, etc.

Re: A few HiDPI tricks for Linux

#93

Post by pedrocr » Sun, Jan 31, 2021, 1:22 AM UTC

cycloptic wrote: post #90

pedrocr wrote: post #86

Earlier quoted context omitted.

It would actually be great if Wayland would allow clients to handle HiDPI themselves but it doesn't which makes fractional scaling much worse than it needs to be. Wayland defines integer scaling only and then compositors scale 2x content down to 1.5x or whatever it is you want. This means that if you have an app that's capable of drawing at arbitrary scale you are still forced to draw at 2x and then be scaled down by…

This was discussed at length years ago and it was decided that passing a fractional scale value to the client is not what you want, makes the code much more complicated and doesn't really solve the blurriness. A bit of background here: https://lists.freedesktop.org/archives/wayland-devel/2013-Ma... To illustrate, I usually use a simple example: How do you render a 20px tall font at scale 1 2/3 without being blurry or…

> This was discussed at length years ago and it was decided that passing a fractional scale value to the client is not what you want, makes the code much more complicated and doesn't really solve the blurriness.

From your link:

"""

> While rendering at rational factor can't be of better quality, it can

> however be done at a much higher quality than downscaling, faster and with

> less memory usage.

Perhaps, but that benefit diminishes compared to the cons.

"""

Being blurry and losing performance was deemed acceptable for other benefits. Maybe I'm discounting those benefits but the penalties are very real. 2x performance penalties in performance sensitive code and blurry scalable content like fonts are real downsides.

Looking further down the thread what I think would be the ideal solution is what is being proposed and doesn't get any response:

https://lists.freedesktop.org/archives/wayland-devel/2013-Ma...

The current solution actually seems much more complex than this as the protocol needs to actually know about scaling instead of the scaling factor being just some metadata about how things should be and have been rendered and everything else would be within the client and compositor code.

> How do you render a 20px tall font at scale 1 2/3 without being blurry or without rounding errors?

Fonts are not sized in pixels for the most part. Modern fonts are resolution independent and the renderers try hard to fit it to however many pixels you have. By faking them out and telling them "here's a 200x200 box to do your work" and then later scaling down that box to 150x150 prevents that code from working properly.

> What happens when you try to stretch this window across multiple screens?

For this case your render at the maximum of the two fractional scales and scale down in the lowest one. It's no worse than the current solution for that screen and better for the one that matches.

Re: A few HiDPI tricks for Linux

#94

Post by josephg » Sun, Jan 31, 2021, 1:25 AM UTC

leokennis wrote: post #43

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…

Yep. Windows 10 is fantastic in this regard. MacOS on the other hand sucks. Basically the recommendation is to run a lower and blurry resolution if you want bigger buttons and text... At the same time, iOS has great scaling and text sizing options, and macOS’ interface is so abstract that it should be very easy to vectorize it, enabling seamless scaling to any size wanted. Really baffling.

Huh? I have a 4k TV I've been using connected to my gaming computer for awhile running windows 10. I've had no end of issues with various programs becoming horribly confused by display scaling. Some applications ignore the display scaling entirely and end up tiny, and other applications (particularly some games) end up with 4x size on UI elements - which looks utterly awful. Its pretty clear lots of game developers never test with HiDPI displays.

In comparison I've never had a problem on macos. All macos applications I run seem to render correctly no matter what resolution and dpi settings my various displays use. And I can move most applications between displays just fine - with no pop-in or strange behaviour as the resolution of the containing monitor changes. (Except for some web browsers - which detect the transition and re-render content at the new resolution).

Re: A few HiDPI tricks for Linux

#95

Post by josephg » Sun, Jan 31, 2021, 1:29 AM UTC

sammorrowdrums wrote: post #11

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.

My only issue is that my mid sized 4k screen is a but clunky at 2x UI scaling but otherwise I don't have an issue until I plug into a standard Monitor when 2x scaling is ridiculous. But I find 1x scaling to be too small to enjoy on the QHD screen. Multiple integer scale factors are possible but it is a bit complex and when I did it machine was prone to crash... That said I still love it.

I'm using linux mint with fractional scaling on just one of my displays. (The other display is just 1:1). Everything seems to just work fine.

Well, except for an outstanding bug where after I log in, I get a duplicate, stationary mouse cursor appearing somewhere on the screen that just hovers over any open windows. Its annoying and weird.

Re: A few HiDPI tricks for Linux

#96

Post by girvo » Sun, Jan 31, 2021, 1:42 AM UTC

leokennis wrote: post #43

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…

Yep. Windows 10 is fantastic in this regard. MacOS on the other hand sucks. Basically the recommendation is to run a lower and blurry resolution if you want bigger buttons and text... At the same time, iOS has great scaling and text sizing options, and macOS’ interface is so abstract that it should be very easy to vectorize it, enabling seamless scaling to any size wanted. Really baffling.

My MacBook powering my 4K monitor doesn’t look blurry at all, and I have it set to “2560x1440” scaling in the display settings.

It does however run a tiny bit slower due to that non-integer retina scaling.

Re: A few HiDPI tricks for Linux

#97

Post by alwaysanon » Sun, Jan 31, 2021, 1:45 AM UTC

josephg wrote: post #94

leokennis wrote: post #43

Earlier quoted context omitted.

Yep. Windows 10 is fantastic in this regard. MacOS on the other hand sucks. Basically the recommendation is to run a lower and blurry resolution if you want bigger buttons and text... At the same time, iOS has great scaling and text sizing options, and macOS’ interface is so abstract that it should be very easy to vectorize it, enabling seamless scaling to any size wanted. Really baffling.

Huh? I have a 4k TV I've been using connected to my gaming computer for awhile running windows 10. I've had no end of issues with various programs becoming horribly confused by display scaling. Some applications ignore the display scaling entirely and end up tiny, and other applications (particularly some games) end up with 4x size on UI elements - which looks utterly awful. Its pretty clear lots of game developers n…

This is only true for 4k monitors with MacOS. Anything under that looks terrible these days as it won't offer the HiDPI modes on those.

Re: A few HiDPI tricks for Linux

#98

Post by alwaysanon » Sun, Jan 31, 2021, 1:46 AM UTC

mlindner wrote: post #89

leokennis wrote: post #43

Earlier quoted context omitted.

Yep. Windows 10 is fantastic in this regard. MacOS on the other hand sucks. Basically the recommendation is to run a lower and blurry resolution if you want bigger buttons and text... At the same time, iOS has great scaling and text sizing options, and macOS’ interface is so abstract that it should be very easy to vectorize it, enabling seamless scaling to any size wanted. Really baffling.

I'm sorry what? I've used Windows 10 scaling and it looks horrible compared to MacOS native 2x HiDPI scaling. The computers are made for HiDPI or not and it looks very natural compared to windows which doesn't scale all elements by the same amount.

This is only true for 4k monitors on MacOS - and I often run into non-4K monitors in my work hotdesking situation (though admittedly I mainly WFH at the moment). And Windows solved that not scaling elements by the same amount several years ago.

Re: A few HiDPI tricks for Linux

#99

Post by yjftsjthsd-h » Sun, Jan 31, 2021, 2:11 AM UTC

canofbars wrote: post #68

azinman2 wrote: post #20

Earlier quoted context omitted.

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.

> If you want to use a legacy tool you shouldn't expect it to work as nice as the current generation software.

I'm not using the "current generation" because it doesn't work as nice as the "legacy" software. Have y'all figured out how to do screen sharing without per-compositor hacks yet?

Re: A few HiDPI tricks for Linux

#100

Post by dTal » Sun, Jan 31, 2021, 2:23 AM UTC

vetinari wrote: post #72

kevincox wrote: post #49

Earlier quoted context omitted.

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

I've got 4K display for my Linux machine in 2017; Fedora+Gnome+Wayland worked fine at 200% scale back then. That's 4 years. After those 4 years, there are people still trying to make their X11 square peg fit into the HiDPI round hole. X11 is dead. Nobody is going to retrofit HiDPI into it as it is in Wayland. In another 4 years, it is still going to be as annoying as it is today to fix up X11 desktops and apps; maybe…

Works fine for me and always has, since my SXGA+ Thinkpad X61T. Currently running KDE Plasma on a WQHD screen and everything native (QT and GTK) is great; only WINE programs are too small.