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

101–110 of 192 posts

Re: A few HiDPI tricks for Linux

#101

Post by chao- »

chao- wrote: post #30
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.

This is the recommended default, and I assume it is for good reason, but I would caution against adopting this on faith. If you feel pain, try different positions out. I had the setup you recommend for many years. At first I started getting shoulder pain, and realized that I was stopping over to accommodate when looking down. I forced myself (at regular intervals, and modest cost to productivity) to have better postu…

(slight followup correction: "stooping over" not "stopping over" but I cannot edit my post anymore)

Re: A few HiDPI tricks for Linux

#102

Post by vzaliva »

HPDI support on Linux is terrible. After stuggling to make it work consistently accross various applications on my Dell XPS 13 with HDPI screen, I conciously choose my next laptop to have just HD screen. I am so happy as everything is finally working normally.

Re: A few HiDPI tricks for Linux

#103

Post by derefr »

canofbars wrote: post #71
nxc18 wrote: post #36

Earlier quoted context omitted.

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

> Basically every problem falls back on nvidia

So... get an AMD GPU instead?

Re: A few HiDPI tricks for Linux

#104

Post by derefr »

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…

> If anybody knows how to forcibly override the "pixels per mm" reported by a monitor, you will be my hero forever.

The brute-force way to alter everything your monitor reports, is to dump its EDID data, patch it (there are programs for this, or you can resort to a hex editor and the EDID spec), and then tell your kernel to load that patched EDID in place of the real EDID when it recognizes your monitor.

On Linux, that's apparently accomplished by plopping the patched EDID file into /lib/firmware: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

(I've never actually done this with Linux, but I've done it in macOS on a Hackintosh, because macOS frequently thinks televisions connected over HDMI should be fed YUV instead of sRGB. You can patch the EDID to force macOS to treat the TV as a monitor.)

Re: A few HiDPI tricks for Linux

#105

Post by canofbars »

derefr wrote: post #103
canofbars wrote: post #71

Earlier quoted context omitted.

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

> Basically every problem falls back on nvidia So... get an AMD GPU instead?

Yes, either that or put up with the many problems of X

Re: A few HiDPI tricks for Linux

#106

Post by FunnyLookinHat »

My experience with 4k has essentially been that it's too small for the display sizes I want to have on my desk - and the fractional scaling support is always quite a bit of work to get right (as evidenced by this post).

I've found that 2k (2560x) displays at 27" give me great real estate without any need to scale.

Re: A few HiDPI tricks for Linux

#107

Post by cycloptic »

pedrocr wrote: post #93
cycloptic wrote: post #90

Earlier quoted context omitted.

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…

The solution in that email is essentially how it works, the only difference is that the scaling factor is forced to be an integer.

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

Then question I was getting at is: how do you write a renderer that does the right thing and works properly when given a box of 133.333333 x 133.333333 pixels? If you say "round in some direction" this is now a policy that must propagate to every bit in the stack that touches input and rendering.

>It's no worse than the current solution for that screen and better for the one that matches.

It actually is much worse for the one that doesn't match, because now you have lost the ability to do pixel-perfect scaling.

Re: A few HiDPI tricks for Linux

#108

Post by cycloptic »

ironmagma wrote: post #79
vetinari wrote: post #76

Earlier quoted context omitted.

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

I think "there is only one person working full-time on maintaining Linux input libraries and he's overworked" is probably a decent excuse. I don't know what you plan to do, but I would advise against forking unless you can hire a team to accumulate testing hardware and work on this for multiple years. What we have seen too often is these forks just fizzle and get forgotten, especially if they are only focused on getting one feature to work on one very specific device.

Re: A few HiDPI tricks for Linux

#109

Post by hollerith »

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…

>To illustrate, I usually use a simple example: How do you render a 20px tall font at scale 1 2/3?

You replace it with a 33px tall font.

This is what Gnome 3.38 actually does in my experience: on the computer on which I am writing this, I have a scale factor of 1.50 set in the Displays pane of Gnome Settings. Google Chrome and vscode show up in the output of xlsclients, which I am told means that they are talking to XWayland (and there are web pages promising that in a few months those 2 apps will be adapted to talk directly to wayland), and those 2 apps are blurry whereas Gnome Terminal and Evince (my PDF reader) do not show up in the output of xlsclients and those 2 apps are not blurry, but their default text size and the size of their UI elements are consistent with everything being scaled by 1.5.

Re: A few HiDPI tricks for Linux

#110

Post by hollerith »

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…

If you restrict yourself to Google Chrome, Chromium-based Edge, apps using Electron and apps recently written by Microsoft (Settings, Timer, image viewer, video player, etc), then display scaling is very slick on Windows 10. (I didn't try with multiple monitors, but I did use the Settings app to change the scaling factor frequently.)

On OSX in contrast, if you change the display resolution in System Preferences, most apps do not automatically adapt, with the result that you have to close their windows, then re-open them before your system is usable. And at non-integral scaling factors, everything is blurry at least on the non-retina displays I tried. In constrast, there is zero blurriness in the apps I just listed in Windows 10 regardless of which scale factor is chosen in the Settings app. On a 1080p monitor, the choices are 100%, 125%, 150% and 175%.

Gnome also lets you choose the scale factor in increments of 25% and in a few months after more apps have been adapted to work "directly" with Wayland (without the intervention of XWayland) promises to be as slick as Windows 10 currently is. (In fact, I personally prefer Gnome because on Windows changing the scale factor by 25% can result the stems and lines of the letters becoming abruptly twice as thick, but I vastly prefer either to MacOS's blurriness when the display is not being run at its native resolution, but again I had the luxury of being very choosy about which apps I used on Windows, relying mainly on a web browser and vscode.)

Post reply on HN