Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A few HiDPI tricks for Linux

blog.yossarian.net

Post reply on HN
Print view View original

81–90 of 192 posts

Re: A few HiDPI tricks for Linux

#81

Post by leephillips »

woodruffw wrote: post #51
leephillips wrote: post #29

Earlier quoted context omitted.

If DPI means “dots per inch”, then how can the size of the screen come into it? And what is “not true”?

As the phrase "dots per inch" implies, it's a ratio. Specifically, it's the ratio between your resolution (say, 4K) and the size of your screen. What is "not true" is that every screen's pixel density is the same. Different screens have different sizes and resolutions, which means they have different pixel densities.

Who said that every screen’s pixel density is the same? What kind of bizarre claim would that be?

DPI is a resolution. It is not the ratio between resolution and size. It already has the units of resolution: 1/length.

Re: A few HiDPI tricks for Linux

#82

Post by KirillPanov »

cycloptic wrote: post #80
KirillPanov wrote: post #74

Earlier quoted context omitted.

> In X11, you can do it with xrandr --fbmm Yeah, that's basically what I want, but for sway. > Wayland applications should not be using that information to decide scaling. They should be using the wl_output.scale. Maybe so, but the physical size is definitely exposed to the clients via the wayland protocol (see below). I'm pretty sure that the QT toolkit and Chromium both use the reported values. The geometry event d…

Is there some reason you cannot just set the output scale? This almost certainly already does what you want. If you're talking about X11 applications running on XWayland, I think you can still change the properties there with xrandr.

I've definitely tried that and it has the wrong effect in a lot of cases. The worst is Chromium (via QtWebEngine, via qutebrowser), which seems to ignore things.

No, I'm not using XWayland.

I edited my comment above after you posted -- the Wayland protocol unfortunately does expose the screen size in millimeters to the client. I'm pretty sure Chromium and QT use this, which is why I need to lie to them.

Another question: is there any sort of "Wayland socket proxy"? Like a stupid simple program that offers up a $WAYLAND_DISPLAY socket to a client, opens its own to a server, and then passes all results through unmodified? It would be really easy to hack a change like this into a proxy like that, but I can't seem to find one. Sort of surprising; the simplicity of the Wayland protocol makes it seem like such a thing should exist. Sort of like waypipe, but without the cross-network magic.

Re: A few HiDPI tricks for Linux

#83

Post by gnull »

canofbars wrote: post #67
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.

> unless you use 2 monitors at different scales and load an X application

Agree 100%, this is the only issue I ran into using Wayland (Sway) with different DPI monitors.

I only want to stress that the impact of this issue is very limited—at least for me. Most of the apps that I use run natively on Wayland and scale perfectly: Firefox (with some extra setup), Telegram Desktop, Alacritty, all GTK and KDE apps.

The apps that do get blurry are the ones that are made by big companies for which Linux experience is not the first priority (thus they don't care about native Wayland support). Zoom, Chromium, Google Earth, Discord, Steam, Skype. I don't use them much, and when I do I try to keep them on my big (non-scaled) monitor, and it works fine.

Re: A few HiDPI tricks for Linux

#84

Post by cycloptic »

KirillPanov wrote: post #82
cycloptic wrote: post #80

Earlier quoted context omitted.

Is there some reason you cannot just set the output scale? This almost certainly already does what you want. If you're talking about X11 applications running on XWayland, I think you can still change the properties there with xrandr.

I've definitely tried that and it has the wrong effect in a lot of cases. The worst is Chromium (via QtWebEngine, via qutebrowser), which seems to ignore things. No, I'm not using XWayland. I edited my comment above after you posted -- the Wayland protocol unfortunately does expose the screen size in millimeters to the client. I'm pretty sure Chromium and QT use this, which is why I need to lie to them. Another quest…

Qt applications are almost certainly using the output scale property, I've tried those recently. I haven't tested Chromium's wayland backend recently, but Chromium is ignoring those physical values: https://github.com/chromium/chromium/blob/99314be8152e688baf...

Maybe your chromium is not using the Wayland backend correctly? If a Wayland application is using the physical values to determine scaling, instead of the output scale, that's a bug and you probably should consider reporting it. It's probably a mistake that the physical size information is there, it's unreliable as you have seen.

Edit: Rather than messing around with proxies, if you want to do a quick test to confirm, you could simply hack wlroots here to send a constant value: https://github.com/swaywm/wlroots/blob/b3e76d667855c16e97a4d...

Re: A few HiDPI tricks for Linux

#85

Post by encom »

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…

Your positive experiences with this, do not mirror mine. I have one 4K main display at 200% scaling, and an old 19" off-screen I use for IRC and music playback at 100% scale. Every time I wake my machine, the windows from the off-screen are shuffled around to the main screen, and windows on the main screen are resized and moved around. It absolutely drives me up the wall, and it's clear that this configuration has never been tested by anyone at Microsoft.

Re: A few HiDPI tricks for Linux

#86

Post by pedrocr »

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 (…

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 the compositor. This is needlessly blurry and a performance penalty. Text can be drawn at arbitrary scale but is blurry because of this. Browsers can render at any resolution but have substantial performace penalties because of this (2x at common fractional scales). Anything that renders images also gets needless downscales because of this with both quality and performance penalties. It's a baffling decision to not do this client side and hopefully will be fixed with the evolution of the protocol.

Re: A few HiDPI tricks for Linux

#87

Post by MetaDark »

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…

Wayland has a proper protocol for fractional per-output scaling: https://wayland-book.com/surfaces-in-depth/hidpi.html. While there are many reasons why I prefer Wayland over X, this is the biggest.

X only allows setting a DPI per "display", but not per screen (multiple monitor setups where you can drag windows between screens use one X "display"). So you have to resort to these hacks.

Re: A few HiDPI tricks for Linux

#88

Post by cycloptic »

badsectoracula wrote: post #66
KirillPanov wrote: post #59

Earlier quoted context omitted.

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 s…

What you are describing is not enough, the X server or the X compositor would still need to scale windows up/down if they don't support scaling or if you want to have fractional scaling. It's not something a old-style window manager can do -- There is just no real "Xorg way" on how to do this right now.

Re: A few HiDPI tricks for Linux

#89

Post by mlindner »

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.

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.

Re: A few HiDPI tricks for Linux

#90

Post by cycloptic »

pedrocr wrote: post #86
KirillPanov wrote: post #59

Earlier quoted context omitted.

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 (…

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 without rounding errors? And if you wanted to avoid any additional scaling artifacts or rounding errors, how tall would you make the output buffer, in pixels? What happens when you try to stretch this window across multiple screens?

Post reply on HN