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

71–80 of 192 posts

Re: A few HiDPI tricks for Linux

#71

Post by canofbars »

nxc18 wrote: post #36
libcg wrote: post #24

Earlier quoted context omitted.

He's using "i3 with a heavily customized userspace" which isn't exactly what most people would use. Gnome on X11 lets you (integer) scale monitors through a GUI at the very least.

Yeah but there’s a very good chance that won’t work with various hardware configurations. I was able to get per-monitor scaling to work only after giving up use of half my GPUs, and still there were problems with several apps. This was on stock Ubuntu; I didn’t get too crazy customizing because I just wanted to find a Linux desktop that worked.

>I was able to get per-monitor scaling to work

X11 is not capable of doing this properly. Wayland is and as you probably know, nvidia refuses to support it which is out of the control of linux developers. You can get everything working if you use the open source nvidia drivers but then they run slow as shit because nvidia blocks them from setting the clock speed on the gpu.

Basically every problem falls back on nvidia and the linux desktop people have done everything in their power to make it work.

Re: A few HiDPI tricks for Linux

#72

Post by vetinari »

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

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 even more so.

Re: A few HiDPI tricks for Linux

#73

Post by canofbars »

sitzkrieg wrote: post #6

what an incredible waste of time. messing with dpi, crappy apps taking from here and there in 2021. linux desktop userspace is a dumpster fire

If you actually use a modern config like the defaults on Fedora it all just works. 100% of these problems come from people trying to use the proprietary nvidia drivers which is filled with issues.

Re: A few HiDPI tricks for Linux

#74

Post by KirillPanov »

cycloptic wrote: post #69
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.

> 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 describes geometric properties of the output.
    The event is sent when binding to the output object and whenever
    any of the properties change.
    
    The physical size can be set to zero if it doesn't make sense for this
    output (e.g. for projectors or virtual outputs).
I will probably end up hacking it into sway, like I've done with other things.

It's just that the swaywm/libwlroots codebase is so utterly illegible. "wlroots is largely documented through comments in the headers. Read 'em." Yeah, those headers with no comments anywhere, egregious amounts of boilerplate code (because C), and naming conventions that take weeks to learn. Argh. I've spent entire days trying to figure out "how to I get a sway_foo pointer from a wlr_foo pointer". It's madness. There's so much typecasting going (with totally undocumented rules for when said typecasts are safe) on that you can't even use the compiler-visible types as a guide for these kinds of questions.

Re: A few HiDPI tricks for Linux

#75

Post by vetinari »

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…

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

One of the differences is, that Wayland surfaces do have scale property. So compositor knows, when clients do not bother, and can do scaling for them. Under X11, some clients do bother, some don't, and the compositor doesn't know which are which.

Re: A few HiDPI tricks for Linux

#76

Post by vetinari »

ironmagma wrote: post #70
vetinari wrote: post #64

Earlier quoted context omitted.

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?

Is it defeatist to point out, that there is no need to fork, just communicate with the upstream?

Especially if you do not have resources for maintenance. If you had them, and spent some time and effort in the problem domain, maybe, just maybe, you could come to the same conclusions and the results as the original you forked from.

Re: A few HiDPI tricks for Linux

#77

Post by cycloptic »

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

>Unfortunately this means that these HiDPI bugs have to be fixed over and over in myriad apps and toolkits

There is nothing that can be done about this from the view of the display server. The application and toolkits have to be updated to support high DPI.

Re: A few HiDPI tricks for Linux

#78

Post by Zardoz84 »

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

You can do it on X11 using xrand (crapy but works)

Re: A few HiDPI tricks for Linux

#79

Post by ironmagma »

vetinari wrote: post #76
ironmagma wrote: post #70

Earlier quoted context omitted.

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?

Is it defeatist to point out, that there is no need to fork, just communicate with the upstream? Especially if you do not have resources for maintenance. If you had them, and spent some time and effort in the problem domain, maybe, just maybe, you could come to the same conclusions and the results as the original you forked from.

Like I said, it is something that should be pull requested to the upstream, and if that fails, then fork. The fork is a secondary path to cooperation.

If the conclusions are that the platform cannot support cursor acceleration the proper way (i.e. the way all commercial OSes do), the premise of the library is flawed. If not, then it must be the whole OS that's flawed, because that needs to be possible on a desktop system. Linux's cursor acceleration sucks, there is no excuse for the whole UI layer of the ecosystem being as bad as it is.

Re: A few HiDPI tricks for Linux

#80

Post by cycloptic »

KirillPanov wrote: post #74
cycloptic wrote: post #69

Earlier quoted context omitted.

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.

> 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.
Post reply on HN