Hacker News Reader

Comment by bitwize | Hacker News Reader

X can easily support per-display DPI -- clients just have to eschew the legacy global DPI setting. The Xrandr extension knows the dimensions of each display in both pixels and millimeters from its EDID. Clients interested in making adjustments based on per-display DPI could simply use those values obtained from Xrandr. These values can be wrong, of course -- monitors have been known to lie in their EDID reports -- but they'd be wrong in Wayland too.

Of course, no one actually wants to do this work because there is a deep-seated intent to salt the earth where X once stood.

View on HN

The way multihead works in modern XOrg is basically a hack to enable seamless dragging of windows across physical display boundaries.

Once upon a time you'd do multihead on X with discrete screens and your display environment variable would be something like DISPLAY=:0.0 vs. DISPLAY=:0.1 where the last digit after the dot was the screen number. But your X client would then be confined to that screen. In this old manner you could probably have per-screen DPI stuff work somewhat, but you wouldn't be moving windows across physical monitors like we take for granted today.

Having your X clients connect to DISPLAY=:0 and somewhere behind the scenes that X server is putting its windows across physical displays or moving from one to the other seamlessly is basically Magic (look up XINERAMA) that the protocol is largely ignorant of, so the DPI differences among those physical displays are pretty invisible to the random X client.

IDK if ability to drag a window between screens is something more important than properly supporting different DPIs; but that might be a decent level of ignorance on my part

Eh, I lived with the limitation back in the XFree86 4.0 / beta multihead support days on an array of Matrox Millenium PCI cards.

While it technically works, you quickly discover the importance of being able to organize windows to different physical displays after the programs are already running / the windows have been created.

Requiring exiting and relaunching things to migrate them to different physical screens gets old fast.

The best article I have found about mixed dpi on x11 is.

http://wok.oblomov.eu/tecnologia/mixed-dpi-x11/

That article is horrible. What it describes is yet another hack where clients attempt to guess the DPI and then rescale themselves, and the server and compositor know nothing about DPI. That method only exacerbates the problems where clients that don't support scaling are going to be scaled wrong on every screen. Compare this to Wayland where the compositor itself knows the scale of every window and does all the scaling.

Which is a fair assessment, And I think I agree with you. however there is a bit of irony around the whole situation.

The article reaches the conclusion that the best way to handle the situation is for the display server to provide the dpi primitives and let the client figure out how best to draw to that dpi. But acknowledges that there is a hack where you can make the server present a standard scaled dpi, but the drawing will then be bad. And there is this new-fangled thing called wayland where all it can do is the hack.

The irony is that wayland is infamous for usually making the clients do the work(I am thinking window managers) and X for providing a standard method. Nether of which is true, but it made me chuckle.

xrandr is not sufficient for this. One needs a way for users to configure the per monitor DPI. And have the configuration available to X clients. Currently the only cross DE mechanism for this is Xft.dpi and its global, not per monitor.

> One needs a way for users to configure the per monitor DPI.

xrandr --setmonitor has entered the chat

>Xft.dpi and its global, not per monitor.

It's per screen, though ; you can have different Xresources on different screens bound to different monitors, I'm running such configuration just fine. Actually, since most of the software I'm using is GTK-based, my per-monitor DPI configuration tool(s) are a pair of xsettingsd running with different DISPLAY variables, and having different Xft/DPI values (and a few other tweaks, like different font rendering options). I'm running two openbox instances , xfce4-panel and tint2 , and two picom instances to properly support client side decorations. And I'm trying to scrape some time to patch xfwm4 and xfce4-panel to support per-screen processes for both . This way I'm driving 24" 4K as my primary display, for coding/browsing/etc, and 24" 2K as a sidekick for monitoring/documentation/spotify/etc

My .xsession:

  xrdb -screen -display :0.0 -merge .Xresources-0.0
  xrdb -screen -display :0.1 -merge .Xresources-0.1
  nohup /usr/lib64/xfce4/xfconf/xfconfd &
  export FREETYPE_PROPERTIES="cff:no-stem-darkening=0 autofitter:no-stem-darkening=0 cff:darkening-parameters=500,500,2000,450,3300,450,4600,200" 
  export DISPLAY=:0.0
  export GDK_SCALE=2
  export GDK_DPI_SCALE=0.5
  export QT_AUTO_SCREEN_SCALE_FACTOR=0
  export QT_SCREEN_SCALE_FACTORS=2

  nohup xsettingsd -c ~/.xsettingsd-0.0 -s 0 &
  nohup openbox --config-file ~/.config/openbox/rc-0.0.xml &
  ~/Apps/Picom/picom --vsync  --use-ewmh-active-win  --no-frame-pacing --backend glx -b
  nohup xfce4-panel --display=:0.0 &
  nohup /usr/lib64/xfce4/notifyd/xfce4-notifyd &

  export FREETYPE_PROPERTIES="cff:no-stem-darkening=0 autofitter:no-stem-darkening=0" 
  export DISPLAY=:0.1
  unset GDK_SCALE
  unset GDK_DPI_SCALE
  unset QT_SCREEN_SCALE_FACTORS
  nohup xsettingsd -c ~/.xsettingsd-0.1 -s 1 &
  nohup openbox --config-file ~/.config/openbox/rc-0.1.xml &
  ~/Apps/Picom/picom --vsync  --use-ewmh-active-win  --no-frame-pacing --backend glx -b
  nohup tint2 &
  wait

If this works for you, cool. But this is... not good in any way, and it's still not going to work for clients that use a different toolkit or text renderer than the ones you've configured. I hope you can see how it's unacceptable for an average user to have to mess around with this many random commands and environment variables just to get scaling working.

xrandr is perfectly sufficient for this, although GTK for whatever reason chooses to break it (not just not implement it; proactively break it). Xcb picks it up just fine, as does Qt. I'm pretty sure Fltk does now too though I haven't tried it in a while.

No, xrandr isn't sufficient. It still doesn't have scaling information, only size information. Changing the reported physical size of the monitor is a bad idea as it can break other things.

OFFS this is the most ridiculous reaction ever.

Reporting the physical size of the monitor is the right answer. Wayland is simply wrong here.

No. Even the X.org developers disagree with you here. Messing with the DPI will cause lots of clients to break even further. See this merge request for more info on this: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...

X11 simply isn't built to do this. If you want this to work, then the last 35 years of clients don't do the right thing and still would need to be changed to use a new extension that behaves more like Wayland does it.

And yet, it works better than in Wayland.

No it actually doesn't, I've heard tons of complaints about X clients not scaling correctly. Sure it might work for the subset of clients that are reading the DPI value the way you intended, but in doing so you've silently broke a lot of other clients.

The "subset" of clients using Xcb or Qt? I'm fine with only counting them, personally...

This comment makes no sense, XCB isn't a toolkit. You might be thinking of something else with a similar acronym.

But anyway, any solution that tells users to only use a small subset of compatible clients is about as disruptive as just switching wholesale to Wayland. It's not the reason anyone is hanging on to the X server.

I didn't say it was a "toolkit", it's a library that largely replaces Xlib, and it uses xrandr correctly to allow multiple pitches

https://xcb.freedesktop.org

Yes, I know what it is. Here are some corrections.

1. XCB is a low level binding to the X11 protocol. It doesn't really replace Xlib. Originally that was the intention, but it's non-trivial to take an Xlib program and port it to XCB.

2. XCB doesn't know anything about scaling or even about XRandR, besides the wire protocol. Just because a client uses XCB is no guarantee that it even uses XRandR. It's definitely not a guarantee that it implements scaling.

3. There is no way to use XRandR correctly to allow multiple pitches, because XRandR doesn't have that functionality. All it does is report an estimated size of the monitor.

4. The scaling you're talking about is happening in the client, not in XCB or XRandR, and if it's ever going to work at all it needs to be controlled by some other setting or environment variable. Someone else in the thread posted a big set of those environment variables. Ideally you wouldn't use XRandR at all, there would be another extension.

5. None of the above applies to Qt, because Qt is a toolkit that does (mostly) implement the scaling for you. That's why it was weird you grouped it with XCB.

That's a whole lot of "nothing" it has to do with randr:

https://xcb.freedesktop.org/manual/group__XCB__RandR__API.ht...

But, yes, software using Xcb does have to actually do it correctly for it to work, like nearly all aspects of software development.

Like everything else in XCB, those are just stubs autogenerated from the wire protocol definition. The client has to actually implement the protocol semantics including duplicating a lot of logic that's already present in Xlib. There's no performance benefit to this either. For that reason XRandR is probably one of the most useless and least beneficial things to use XCB for. Signed, someone who actually did try this at one point and ended up reverting back to Xlib.

>But, yes, software using Xcb does have to actually do it correctly for it to work,

There isn't a way to do this correctly, it's a hack. The difference is that Qt attempts to do it automatically, compared to XCB that intentionally does nothing for the programmer because it's a low-level binding.

> There isn't a way to do this correctly, it's a hack

Hacks are often the correct way to do things.

JFC this is annoying. I'm telling you "it works for my professional use case on X11 and doesn't on Wayland" and you keep trying to gaslight me about this by saying it's impossible.

This doesn't work on Wayland. It does work on X11. You can stomp your feet until you're blue in the face but that won't change this basic fact.

If (for whatever reason; I'm still mystified why you care about this) you really really think it's important to get me to switch display servers, make it work on Wayland. Otherwise just let me have my preferences which I largely maintain and package.

>Hacks are often the correct way to do things.

In this case, it's not the correct way.

>I'm telling you "it works for my professional use case on X11 and doesn't on Wayland" and you keep trying to gaslight me about this by saying it's impossible.

No it's actually the other way around. You keep gaslighting and insisting that it's a valid solution because it works for a small subset of clients that you've picked for yourself. I'm telling you this isn't a valid solution for any X11 maintainer to put in place. I've already showed you where an X11 maintainer actually said this, but for some reason you think you know better. Well I'm sorry, but it's not a solution. When you maintain something like that, you don't get to pick and choose the clients you support. You have to support all of them. And yes, it is impossible for X11 maintainers to go and find and fix bugs in every single client from the last 35 years or port them all to XCB and rewrite the drawing code or whatever it is you'd like them to do.

>This doesn't work on Wayland. It does work on X11.

No, it doesn't work on X11 either. Refer back to the merge request I posted earlier. This isn't something you can just hack in. Your solution will break down if you ever need to use a different type of client.

>If (for whatever reason; I'm still mystified why you care about this) you really really think it's important to get me to switch display servers, make it work on Wayland. Otherwise just let me have my preferences which I largely maintain and package.

Where is this coming from? I've never said you should switch display servers. I'm only observing that you probably will once the limitations in your approach become apparent. You realistically don't get to even have preferences here, maintaining all of this is too much work for one person. Maybe you won't switch to Wayland, maybe it'll be something else entirely. Who knows? The point is, X11 doesn't do it.

And this is really my problem with talking about open source on HN. The well has been poisoned, I can't point out broken stuff without someone accusing me of having some kind of agenda. As if anyone who's developed for X11 for the last 36 years hasn't run into all these problems, repeatedly. Nothing is going to get fixed if everyone gets defensive and starts playing the blame game when bugs are pointed out. But that's all that happens here. If you ask me, it's yet another sign that the project is finished.

Simpler you can just scale lower dpi clients down from a higher resolution. Applications think every screen has the same DPI and draw accordingly. X scales such displays to the correct physical size.

Reply on news.ycombinator.com