Hacker News new | ask | show | jobs
by aumerle 984 days ago
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.
3 comments

>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.
> One needs a way for users to configure the per monitor DPI.

xrandr --setmonitor has entered the chat