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

51–60 of 192 posts

Re: A few HiDPI tricks for Linux

#51

Post by woodruffw »

leephillips wrote: post #29
woodruffw wrote: post #28

Earlier quoted context omitted.

This is not true. Your pixel density is a function of your resolution and dimensions. “HiDPI” is a nebulous term that refers to high resolution screens that are also relatively small.

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.

Re: A few HiDPI tricks for Linux

#52

Post by paulie_a »

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.

The xps 13 with 4k is gorgeous. Pair it with an external 4k and everything is seemless. If you go 1080 or whatever for the external monitor it becomes a pain to switch resolutions and scaling. I briefly had to do that and had a script to adjust things but pycharm for instance needed to be restarted

Once I upgraded to a 4k it's a great setup. I actually have dual 4k monitors now and that xps can handle it easily. No software issues either. The most I've had to do was adjust the zoo launcher to be hidpi

Re: A few HiDPI tricks for Linux

#53

Post by glandium »

BearOso wrote: post #48
glandium wrote: post #44

Earlier quoted context omitted.

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

There's only integral buffer scales, so it's entirely up to the compositor or client to do fractional scaling. https://wayland-client-d.dpldocs.info/wayland.client.protoco...

I don't know anything about the wayland API. Does this imply that windows can't have a different scaling on each screen they may overlap on? Or can a window be split across different surfaces?

Re: A few HiDPI tricks for Linux

#54

Post by arendtio »

Setting the DisplaySize in a /etc/X11/xorg.conf.d/90-monitor.conf is the way I like solving the DPI issue. The advantage is, that even the display manager (in my case SDDM) runs with the correct DPI.

If you want to find the correct dimensions for you monitor, this page might help you:

https://www.displayspecifications.com

Re: A few HiDPI tricks for Linux

#55

Post by arendtio »

Tepix wrote: post #16

Not related to HiDPI, but looking at the picture of his monitor setup: From an ergonomics standpoint (i.e. the health of your neck), the upper edge of your monitor shouldn't be higher than your eye level. Looking straight or looking down is fine. Thus the monitor on the left is probably not very ergonomic.

Actually, I prefer looking up and down over looking left and right. So for me it is normal to have the upper monitor way above my eye level.

Re: A few HiDPI tricks for Linux

#56

Post by woodruffw »

Stratoscope wrote: post #31
woodruffw wrote: post #18

Earlier quoted context omitted.

Author here: you’re absolutely right. My previous vertical monitor was a lot shorter; this one has definitely not been great for my neck. I’ll probably switch it back to horizontal at some point.

What size monitors are those? I use a pair of 24" 4K monitors in roughly the same configuration as yours. 27" would definitely be too tall. I find having a vertical 24" monitor to be super useful, especially for reading typical PDF files as an entire page fits nicely on the screen. My vertical monitor is a bit closer to the desk, and the horizontal monitor is much higher than yours, about 7.5" above the desk. The bot…

> What size monitors are those? I use a pair of 24" 4K monitors in roughly the same configuration as yours. 27" would definitely be too tall.

They're 24", like yours. It sounds like our setups are actually nearly identical: the top of my horizontal monitor is also just below my eye height, and I spend most of my time looking at the middle of the vertical one. I should probably move them around a bit so I can actually look at the vertical one without turning my head, though.

> With your horizontal monitor sitting so close to the desk, I have to wonder if your seating position may be too low? Are your forearms horizontal when typing? (Forgive me if I'm being nosy or presumptuous, just curious.)

I appreciate it! I think my seating is right, at least based on what I was taught about ergonomics -- my forearms are horizontal and I don't have to pivot my wrists up or down while typing or moving my mouse.

Re: A few HiDPI tricks for Linux

#57

Post by KirillPanov »

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. qutebrowser, who say the problem is a QtWebEngine bug that they can't fix).

I'm using sway, but almost all the Wayland compositors lack this override-the-monitor-reported-DPI functionality, because (for good reason) their philosophy is to securely multiplex the hardware, not abstract it away. They just pass through whatever values the monitor reports, to the client.

IMHO this does not make sense for physical pixel size, because it disregards the physical distance between the user's face and the pixels. What you really want to size your fonts based on is the number of arc-radians (or arc-degrees) per pixel, measured at the user's eyeball. In order to compute that you need to know both the physical pixel size (which can be queried from the device) and the physical eyeball-screen distance (which will need to be user-configurable).

Re: A few HiDPI tricks for Linux

#58

Post by vetinari »

glandium wrote: post #53
BearOso wrote: post #48

Earlier quoted context omitted.

There's only integral buffer scales, so it's entirely up to the compositor or client to do fractional scaling. https://wayland-client-d.dpldocs.info/wayland.client.protoco...

I don't know anything about the wayland API. Does this imply that windows can't have a different scaling on each screen they may overlap on? Or can a window be split across different surfaces?

Wayland surfaces (windows) have integer property, that says at what scale they are rendered. Compositor then suitably scales them for target displays. If a surface is at two different displays at two different resolutions, it will be scaled correctly on both (up or down; depending on the application; in practice downscaled on the lower resolution one).

Re: A few HiDPI tricks for Linux

#59

Post by KirillPanov »

wmf wrote: post #40
ironmagma wrote: post #33

Earlier quoted context omitted.

The question is, how do we fix this? Is there a best setting to use, and if not, who will join the working group to define one?

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 (cough cough chromium) that is so complicated that it cannot use a toolkit.

Some compositors like sway will let you do in-compositor scaling, but this is admittedly a kludge: it produces blurry scaled-up output instead of rendering at the right resolution in the first place. The sway authors acknowledge this; the feature is only there as a "better than nothing" workaround.

[1] https://news.ycombinator.com/item?id=25973875

Re: A few HiDPI tricks for Linux

#60

Post by viraptor »

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…

It still fails in many situations. For example switching between RDP session on standard and hidpi display will randomly get the desktop stuck in wrong mode, until you change resolution and or do one of actions that seem to trigger a refresh or that setting. I'm also having random switching when starting a Lenovo laptop. Occasionally it will think it's not hidpi at startup. At best I'd give windows "least broken" mark.
Post reply on HN