search

mate-desktop / mate-settings-daemon

MATE settings daemon
https://mate-desktop.org
GNU General Public License v2.0
43 stars 48 forks source link

Disable HiDPI support on nested Xservers #215

Open sunweaver opened 6 years ago

sunweaver commented 6 years ago

Expected behaviour

With a nested Xserver like nxagent, you can launch the Xserver using a -dpi <int> option. When doing so, I expect that a MATE session launched inside that nested Xserver uses the provided DPI. If you, e.g., set DPI to 250, everything will look magnified / bigger.

Actual behaviour

Since MATE 1.20, the underlying Xserver's DPI is not taken into account anymore. I get some default of (presumably) 96 DPI.

Steps to reproduce the behaviour

terminal-1 $ nxagent -ac -dpi <int> :1
terminal-2 $ export DISPLAY=:1
terminal-2 $ STARTUP=mate-session dbus-run-session /etc/X11/Xsession

Tinker with the DPI value. The desktop with MATE always looks the same.

Then compare to LXDE:

terminal-2 $ export DISPLAY=:1
terminal-2 $ STARTUP=startlxde dbus-run-session /etc/X11/Xsession

With LXDE (or other D-E) the fonts get bigger with high DPI values and smaller with low DPI values.

MATE general version

1.20

Package version

1.20-1

Linux Distribution

Debian buster

Link to downstream report of your Distribution

not reported downstream

Further info

@vkareh: I discussed the above topic with @flexiondotorg on #debian-mate IRC. Here is our chat backlog:

08:42 < sunweaver> flexiondotorg: did you notice my woes about DPI in X2Go sessions when running MATE?
[...]
08:42 < flexiondotorg> I hadn't seen your X2Go issue. Did you discuss in IRC of or mention it in IRC?
08:43 < sunweaver> and I have a tiny scrap of upstream hat on, too.
08:43 < sunweaver> IRC.
08:43 < flexiondotorg> Did vkareh comment? 
08:43 < sunweaver> normally, you can launch nxagent like this...
08:43 < sunweaver> nxagent -ac -dpi 200 :1
08:43 < sunweaver> if you start an LXDE on DISPLAY=:1, you have DPI 200 set and everything looks a little bigger.
08:44 < sunweaver> if you start a MATE session on DISPLAY=:1, you have some default DPI (96 I presume)
08:44 < flexiondotorg> vkareh is your man. He can assist is something with the hidpi implementation is messing with X2Go
08:44 < sunweaver> ok
08:44 < sunweaver> is he on #mate-dev?
08:44 < flexiondotorg> Yes
08:44 < sunweaver> I presume on and off, as he is currently not there.
08:45 < flexiondotorg> I don't think he uses a bouncer. 
08:45 * sunweaver feels that HiDPI should be plainly disable when running in nested Xservers.
[...]
08:45 < flexiondotorg> And that should be trivial to support. 
[...]
08:46 < sunweaver> yep
08:47 < flexiondotorg> Raise and issue against mate-settings-daemon on GitHub, propose that idea. Tag vkareh (same nic on GH) and mention you've discussed this with me.
vkareh commented 6 years ago

@sunweaver - I'm definitely able to reproduce this. I'll take a look

vkareh commented 6 years ago

@sunweaver - okay, here's what I have so far: we do read the Xserver's DPI, but we allow the user to override it. It seems possible that your value is overridden.

This is done in Appearance > Font > Details... there's a spinner. The value of that spinner is, by default, populated with the value from Xserver. However, if the user changes that value, it gets overridden and stored in gsettings org.mate.font-rendering dpi (the default value is 0, which respects the value from Xserver).

The tricky part of this app is that there's no Save/Apply button. If the user changes this value it gets set (otherwise the user wouldn't know how the font looks until they hit Apply). In my case, re-setting this value to 0 in gsettings solves the problem, and MATE respects the Xserver DPI value. Let me know if this is not the case for you.

In addition to this, we have the HiDPI scaling, which is really the Gdk/Gtk+ window scale factor. By default it's 0 (i.e. auto-detect) in gsettings org.mate.interface window-scaling-factor. If this value is set to 2, or if the system detects that the screen is HiDPI capable (through checking that the monitor is at least 1500px height and that its density is at least 192dpi), it will auto-scale everything including the font dpi. This font DPI scaling happens whether it's the one reported by X or the one set by the user. The reason for doing this is so that users can still set their very specific DPI settings (instead of having just a high/low switch). Since X is not HiDPI aware (in the GTK sense), we need to scale this value, otherwise users will see 96 when the HiDPI screen really is showing 192 (gsettings still stores it as 96, and we scale it up in both the applet and the Gdk/Xft settings - otherwise they would get messed up values when switching between HiDPI and regular screens). I'd be curious to know what resolution you're using, and whether you have HiDPI enabled in your host environment (assuming you're running MATE as well). You mentioned that you're playing with expanding the window past 2000px, so I'm assuming yes to HiDPI.

So, with all that, there are two possible solutions. First, however, could you test this by forcing org.mate.interface window-scaling-factor to 1 and the org.mate.font-rendering dpi to 0 in your host environment? If this last test works for you, then we've almost solved the mystery and thus have a few possible paths forward:

  1. We could make the window HiDPI auto-detect a bit stricter, so that it's more likely to default to 1 (I'd rather not do this, though, as I feel it's a huge benefit for new users)
  2. We could update the Font DPI setting spinner. What I'm thinking is having the current field as is, but then have some sort of switch/toggle/checkbox that defaults it to whatever X reports. This avoids the issue when users manually update it, but then can't go back to the default. This is a feature I would probably want to add regardless, as I would benefit from it as well.
  3. We could add a way of determining whether we're running inside a nested Xserver and then start that session with the default values. I honestly don't know the implications of this, but I'd be interested in knowing more about it (I've never used nested Xservers before).

If the previous test doesn't work for you, then let me know as I'll need to dig deeper into what's causing it... Hope this helps for now, let me know more details and testing results when you have a chance :)

sunweaver commented 6 years ago

I will look into this the coming week. Thanks for the thorough investigation.

Mike

On Friday, March 2, 2018, Victor Kareh wrote:

@sunweaver - okay, here's what I have so far: we do read the Xserver's DPI, but we allow the user to override it. It seems possible that your value is overridden. This is done in Appearance > Font > Details... there's a spinner. The value of that spinner is, by default, populated with the value from Xserver. However, if the user changes that value, it gets overridden and stored in gsettings org.mate.font-rendering dpi (the default value is 0, which respects the value from Xserver). The tricky part of this app is that there's no Save/Apply button. If the user changes this value it gets set (otherwise the user wouldn't know how the font looks until they hit Apply). In my case, re-setting this value to 0 in gsettings solves the problem, and MATE respects the Xserver DPI value. Let me know if this is not the case for you. In addition to this, we have the HiDPI scaling, which is really the Gdk/Gtk+ window scale factor. By default it's 0 (i.e. auto-detect) in gsettings org.mate.interface window-scaling-factor. If this value is set to 2, or if the system detects that the screen is HiDPI capable (through checking that the monitor is at least 1500px height and that its density is at least 192dpi), it will auto-scale everything including the font dpi. This font DPI scaling happens whether it's the one reported by X or the one set by the user. The reason for doing this is so that users can still set their very specific DPI settings (instead of having just a high/low switch). Since X is not HiDPI aware (in the GTK sense), we need to scale this value, otherwise users will see 96 when the HiDPI screen really is showing 192 (gsettings still stores it as 96, and we scale it up in both the applet and the Gdk/Xft settings - otherwise they would get messed up values when switching between HiDPI and regular screens). I'd be curious to know what resolution you're using, and whether you have HiDPI enabled in your host environment (assuming you're running MATE as well). You mentioned that you're playing with expanding the window past 2000px, so I'm assuming yes to HiDPI. So, with all that, there are two possible solutions. First, however, could you test this by forcing org.mate.interface window-scaling-factor to 1 and the org.mate.font-rendering dpi to 0 in your host environment? If this last test works for you, then we've almost solved the mystery and thus have a few possible paths forward: We could make the window HiDPI auto-detect a bit stricter, so that it's more likely to default to 1 (I'd rather not do this, though, as I feel it's a huge benefit for new users) We could update the Font DPI setting spinner. What I'm thinking is having the current field as is, but then have some sort of switch/toggle/checkbox that defaults it to whatever X reports. This avoids the issue when users manually update it, but then can't go back to the default. This is a feature I would probably want to add regardless, as I would benefit from it as well. We could add a way of determining whether we're running inside a nested Xserver and then start that session with the default values. I honestly don't know the implications of this, but I'd be interested in knowing more about it (I've never used nested Xservers before). If the previous test doesn't work for you, then let me know as I'll need to dig deeper into what's causing it... Hope this helps for now, let me know more details and testing results when you have a chance :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

-- Sent from my Fairphone 2 (running Sailfish OS)

sunweaver commented 6 years ago

@vkareh: So... I played a little bit with the above...

Indeed, the DPI in MATE was set via gsettings org.mate.font-rendering dpi. I unset it (to zero via dconf-editor) and then Xserver DPI was properly propagated to the MATE session.

From the remote desktop perspective, this should always work when MATE is run remotely. For X2Go (using nxagent), this is easy. Run xprop -root and check if NX_AGENT_VERSION atom exists: 

NX_AGENT_VERSION(STRING) = "3.5.99.14"

IMHO, the DPI should be settable from the remote desktop client and override the MATE setting. This is tricky to negotiate, though. Maybe it even needs an extra switch in the font DPI configuration dialog:

My further testing revealed, that the HiDPI code is not triggered at all with latest nxagent (3.5.99.14). This might be related to the fact that we don't have a size for the display in xrandr:

 [mike@minobo ~]$ xrandr
Screen 0: minimum 320 x 240, current 3648 x 965, maximum 4480 x 1800
NX1 connected 3648x965+0+0 0mm x 0mm
   nx_3648x965   60.00* 
NX2 connected 3648x754+222+0 0mm x 0mm
   nx_3648x754   60.00*

(Note, that the the size is 0mm x 0mm, so no display DPI calculatable).