Wrong dpi setting / --dpi is ignored

[totaam]

Issue migrated from trac ticket # 2610

component: client | priority: minor | resolution: fixed

2020-02-23 19:09:56: mviereck created the issue

---

xpra v4.0-25252 on Debian testing/bullseye

The client window is displayed with too large fonts.
Looking at the xpra output, I found that xpra server is setting another dpi value than I set in the xpra command (141x141 dpi vs. 96x96 dpi). I set the same -dpi / --dpi value in xpra server, xpra client and Xvfb command.
There is no scaling involved.

I don't understand why xpra assumes 141x141 dpi.
Expected behaviour: xpra should regard the dpi value given by option --dpi.

Xpra server log:

2020-02-23 19:41:30,371 6.7GB of system memory
2020-02-23 19:41:30,426 xpra is ready.
2020-02-23 19:41:30,431 xpra GTK3 X11 version 4.0-25252 64-bit
2020-02-23 19:41:30,870  uid=1000 (lauscher), gid=1000 (lauscher)
2020-02-23 19:41:30,871  running with pid 449252 on Linux Debian testing bullseye
2020-02-23 19:41:30,872  connected to X11 display :115 with 24 bit colors
2020-02-23 19:41:31,980 New unix-domain connection received
2020-02-23 19:41:31,981  on '/home/lauscher/.cache/x11docker/wine-pcmanfm-83280626554/buster-115'
2020-02-23 19:41:31,989 Handshake complete; enabling connection
2020-02-23 19:41:32,018  mmap is enabled using 256MB area in /run/user/1000/xpra/xpra.m0dbgmug.mmap
2020-02-23 19:41:32,021 Python/GTK3 Linux Debian testing bullseye x11 client version 4.0-25252 64-bit
2020-02-23 19:41:32,021  OpenGL is disabled
2020-02-23 19:41:32,022  connected from 'buster' as 'lauscher' - 'Lauscher'
2020-02-23 19:41:32,031 setting key repeat rate from client: 500ms delay / 37ms interval
2020-02-23 19:41:32,034 setting keymap: 
2020-02-23 19:41:32,092 setting keyboard layout to 'de'
2020-02-23 19:41:32,285  client root window size is 1920x1080 with 1 display:
2020-02-23 19:41:32,286   :0.0 (508x285 mm - DPI: 96x96) workarea: 1870x1045 at 50x35
2020-02-23 19:41:32,286     BOE eDP (344x193 mm - DPI: 141x142)
2020-02-23 19:41:32,288 cannot find a temporary resolution for Xinerama workaround!
2020-02-23 19:41:32,295 server virtual display now set to 1920x1080
2020-02-23 19:41:32,302  automatic picture encoding enabled, also available:
2020-02-23 19:41:32,302   rgb24, rgb32
2020-02-23 19:41:32,313 client   1 @02.568 Xpra GTK3 X11 server version 4.0-25252 64-bit
2020-02-23 19:41:32,313 client   1 @02.569  running on Linux Debian testing bullseye
2020-02-23 19:41:32,315 DPI set to 192 x 192
2020-02-23 19:41:32,320 client   1 @02.573 Attached to socket:///home/lauscher/.cache/x11docker/wine-pcmanfm-83280626554/buster-115
2020-02-23 19:41:32,321 client   1 @02.573  (press Control-C to detach)
2020-02-23 19:41:32,422 client   1 @02.675 server does not support xi input devices
2020-02-23 19:41:32,422 client   1 @02.675  server uses: xtest
2020-02-23 19:41:32,664 New unix-domain connection received
2020-02-23 19:41:32,665  on '/home/lauscher/.cache/x11docker/wine-pcmanfm-83280626554/buster-115'
2020-02-23 19:41:33,256 client   1 @03.512 Xpra OpenGL Acceleration Failure
2020-02-23 19:41:33,257 client   1 @03.513  invalid literal for int() with base 10: '5 (Compatibility Profile) Mesa 19'

Xpra client log:

x11docker [19:41:28,551]: Starting Xpra client
2020-02-23 19:41:29,741 Xpra GTK3 X11 client version 4.0-25252 64-bit
2020-02-23 19:41:30,054  running on Linux Debian testing bullseye
2020-02-23 19:41:30,055  window manager is 'Xfwm4'
2020-02-23 19:41:30,285 No OpenGL_accelerate module loaded: No module named 'OpenGL_accelerate'
2020-02-23 19:41:31,252 Error loading OpenGL support:
2020-02-23 19:41:31,253  invalid literal for int() with base 10: '5 (Compatibility Profile) Mesa 19'
2020-02-23 19:41:31,667  keyboard settings: rules=evdev, model=pc105, layout=de
2020-02-23 19:41:31,677  desktop size is 1920x1080 with 1 screen:
2020-02-23 19:41:31,678   :0.0 (508x285 mm - DPI: 96x96) workarea: 1870x1045 at 50x35
2020-02-23 19:41:31,678     BOE eDP (344x193 mm - DPI: 141x142)
2020-02-23 19:41:32,308 enabled fast mmap transfers using 256MB shared memory area
2020-02-23 19:41:32,309 enabled remote logging
2020-02-23 19:41:32,311 Xpra GTK3 X11 server version 4.0-25252 64-bit
2020-02-23 19:41:32,312  running on Linux Debian testing bullseye
2020-02-23 19:41:32,315 Attached to socket:///home/lauscher/.cache/x11docker/wine-pcmanfm-83280626554/buster-115
2020-02-23 19:41:32,316  (press Control-C to detach)

2020-02-23 19:41:32,417 server does not support xi input devices
2020-02-23 19:41:32,418  server uses: xtest
2020-02-23 19:41:33,255 Xpra OpenGL Acceleration Failure
2020-02-23 19:41:33,256  invalid literal for int() with base 10: '5 (Compatibility Profile) Mesa 19'

Xpra server command:

  xpra start :115 --use-display \
  --csc-modules=none \
  --clipboard-direction=both \
  --encodings=rgb \
  --microphone=no \
  --notifications=no \
  --pulseaudio=no \
  --socket-dirs='/home/lauscher/.cache/x11docker/wine-pcmanfm-83280626554' \
  --speaker=no \
  --start-via-proxy=no \
  --system-tray=yes \
  --video-decoders=none \
  --video-encoders=none \
  --webcam=no \
  --xsettings=no \
  --dpi='96' \
  --clipboard=yes \
  --dbus-proxy=no \
  --daemon=no \
  --fake-xinerama=no \
  --file-transfer=off \
  --html=off \
  --opengl=noprobe \
  --mdns=no \
  --printing=no \
  --session-name='wine-pcmanfm' \
  --start-new-commands=no \
  --systemd-run=no

Xpra client command:

  xpra attach :115 \
  --csc-modules=none \
  --clipboard-direction=both \
  --encodings=rgb \
  --microphone=no \
  --notifications=no \
  --pulseaudio=no \
  --socket-dirs='/home/lauscher/.cache/x11docker/wine-pcmanfm-83280626554' \
  --speaker=no \
  --start-via-proxy=no \
  --system-tray=yes \
  --video-decoders=none \
  --video-encoders=none \
  --webcam=no \
  --xsettings=no \
  --dpi='96' \
  --clipboard=no \
  --compress=0 \
  --modal-windows=no \
  --opengl=auto \
  --quality=100 \
  --dpi='96' \
  --title='@title@ [in container]'

X server command:

  /usr/bin/Xvfb :115  \
  -retro \
  +extension RANDR \
  +extension RENDER \
  +extension GLX \
  +extension XVideo \
  +extension DOUBLE-BUFFER \
  +extension SECURITY \
  +extension DAMAGE \
  +extension X-Resource \
  -extension XINERAMA -xinerama \
  -extension MIT-SHM \
  +extension Composite +extension COMPOSITE \
  +extension XTEST \
  -dpms \
  -s off \
  -auth /home/lauscher/.cache/x11docker/wine-pcmanfm-83280626554/Xauthority.server \
  -nolisten tcp \
  -dpi 96 \
  -screen 0 1920x1080x24

[totaam]

2020-02-24 04:38:50: antoine changed owner from antoine to mviereck

[totaam]

2020-02-24 04:38:50: antoine commented

---

I don't understand why xpra assumes 141x141 dpi.
I see nothing in your output to show that xpra is using this DPI value.
If you are referring to this line:
BOE eDP (344x193 mm - DPI: 141x142)
Then that's just xpra printing the geometry if your client display.

To get more information on DPI and screen settings, run your server with -d screen.
Apart from the virtual "physical" screen geometry set by the server, there is also this value which is honoured by most applications:

$ xrdb -q | grep -i dpi

More information here: DPI.

[totaam]

2020-02-24 12:05:18: mviereck commented

---

There is another DPI line in the log above, and the one below, too (I've missed it before):

2020-02-23 19:41:32,315 DPI set to 192 x 192

It is exactly twice the value I set with --dpi 96.

Then that's just xpra printing the geometry if your client display.

The client has 96x96 dpi:

$ xdpyinfo | grep dots
  resolution:    96x96 dots per inch

xrdb gives a wrong result:

$ xrdb -q | grep -i dpi
Xft.dpi:	120

Xpra server output with -d screen:

2020-02-24 12:36:09,608 X11 display is ready
2020-02-24 12:36:09,993 GDK can access the display
2020-02-24 12:36:09,998 created unix domain socket '/home/lauscher/.cache/x11docker/wine-pcmanfm-44158236876/buster-104'
2020-02-24 12:36:10,218 pointer device emulation using XTest
2020-02-24 12:36:10,240 Warning: no XShm support on display :104
2020-02-24 12:36:10,279 xvfb pid not found
2020-02-24 12:36:10,283 randr=True
2020-02-24 12:36:10,284 _XPRA_RANDR_EXACT_SIZE=None
2020-02-24 12:36:10,284 randr=True, exact size=True
2020-02-24 12:36:10,284 randr enabled: True
2020-02-24 12:36:10,285 query_opengl() skipped: noprobe
2020-02-24 12:36:10,400 _NET_WORKAREA=[0, 0, 1920, 1080]
2020-02-24 12:36:10,401 _NET_DESKTOP_GEOMETRY=[1920, 1080]

(Xpra:462966): Gtk-CRITICAL **: 12:36:10.650: gtk_widget_realize: assertion 'widget->priv->anchored || GTK_IS_INVISIBLE (widget)' failed
2020-02-24 12:36:10,668 6.7GB of system memory
2020-02-24 12:36:10,724 xpra is ready.
2020-02-24 12:36:10,735 xpra GTK3 X11 version 4.0-25252 64-bit
2020-02-24 12:36:11,134  uid=1000 (lauscher), gid=1000 (lauscher)
2020-02-24 12:36:11,135  running with pid 462966 on Linux Debian testing bullseye
2020-02-24 12:36:11,136  connected to X11 display :104 with 24 bit colors
2020-02-24 12:36:12,106 New unix-domain connection received
2020-02-24 12:36:12,107  on '/home/lauscher/.cache/x11docker/wine-pcmanfm-44158236876/buster-104'
2020-02-24 12:36:12,114 Handshake complete; enabling connection
2020-02-24 12:36:12,115 dpi=192, dpi.x=0, dpi.y=0, antialias={b'enabled': True, b'hinting': True, b'hintstyle': b'hintnone', b'contrast': 0, b'orientation': b'NONE'}, cursor_size=0
2020-02-24 12:36:12,146  mmap is enabled using 256MB area in /run/user/1000/xpra/xpra.n47wqmlp.mmap
2020-02-24 12:36:12,149 Python/GTK3 Linux Debian testing bullseye x11 client version 4.0-25252 64-bit
2020-02-24 12:36:12,149  OpenGL is disabled
2020-02-24 12:36:12,149  connected from 'buster' as 'lauscher' - 'Lauscher'
2020-02-24 12:36:12,157 setting key repeat rate from client: 500ms delay / 37ms interval
2020-02-24 12:36:12,159 setting keymap: 
2020-02-24 12:36:12,206 setting keyboard layout to 'de'
2020-02-24 12:36:12,365 do_parse_screen_info(ClientConnectionMuxer(1 : Protocol(unix-domain socket:/home/lauscher/.cache/x11docker/wine-pcmanfm-44158236876/buster-104)), (1920, 1080))
2020-02-24 12:36:12,365  client root window size is 1920x1080 with 1 display:
2020-02-24 12:36:12,366   :0.0 (508x285 mm - DPI: 96x96) workarea: 1870x1045 at 50x35
2020-02-24 12:36:12,366     BOE eDP (344x193 mm - DPI: 141x142)
2020-02-24 12:36:12,367 current server resolution is 1920x1080
2020-02-24 12:36:12,367 maximum client resolution is 1920x1080
2020-02-24 12:36:12,367 minimum client resolution is 1920x1080
2020-02-24 12:36:12,367 want: bigger, so using 1920x1080
2020-02-24 12:36:12,367 set_screen_size(1920, 1080, True)
2020-02-24 12:36:12,367 set_screen_size(1920, 1080, True) xdpi=192, ydpi=192
2020-02-24 12:36:12,368 set_dpi(192, 192)
2020-02-24 12:36:12,369 cannot find a temporary resolution for Xinerama workaround!
2020-02-24 12:36:12,370 using XRRSetScreenConfigAndRate with 1920x1080
2020-02-24 12:36:12,375 calling RandR.get_screen_size()
2020-02-24 12:36:12,376 RandR.get_screen_size()=1920,1080
2020-02-24 12:36:12,376 RandR.get_vrefresh()=0
2020-02-24 12:36:12,376 server virtual display now set to 1920x1080
2020-02-24 12:36:12,377 configure_best_screen_size()=(1920, 1080)
2020-02-24 12:36:12,377 get_max_screen_size()=(1920, 1080)
2020-02-24 12:36:12,377 calculate_workarea(1920, 1080)
2020-02-24 12:36:12,378 calculate_workarea() screen_sizes(ClientConnectionMuxer(1 : Protocol(unix-domain socket:/home/lauscher/.cache/x11docker/wine-pcmanfm-44158236876/buster-104)))=[(b':0.0', 1920, 1080, 508, 285, ((b'BOE eDP', 0, 0, 1920, 1080, 344, 193),), 50, 35, 1870, 1045)]
2020-02-24 12:36:12,378 calculate_workarea() found <Gdk.Rectangle object at 0x7f7bfdb91ad0 (GdkRectangle at 0x1f96aa0)> for display b':0.0'
2020-02-24 12:36:12,378 calculate_workarea(1920, 1080) workarea=<Gdk.Rectangle object at 0x7f7bfdb919f0 (GdkRectangle at 0x21dc7e0)>
2020-02-24 12:36:12,379 _NET_WORKAREA=[50, 35, 1870, 1045]
2020-02-24 12:36:12,379 _NET_DESKTOP_GEOMETRY=[1920, 1080]
2020-02-24 12:36:12,379 no icc data found in {}
2020-02-24 12:36:12,380 reset_icc_profile()
2020-02-24 12:36:12,383 client resolution is (1920, 1080), current server resolution is 1920x1080
2020-02-24 12:36:12,383 get_max_screen_size()=(1920, 1080)
2020-02-24 12:36:12,385  automatic picture encoding enabled, also available:
2020-02-24 12:36:12,386   rgb24, rgb32
2020-02-24 12:36:12,394 RandR.get_screen_size_mm=254,143
2020-02-24 12:36:12,394 client   1 @02.700 Xpra GTK3 X11 server version 4.0-25252 64-bit
2020-02-24 12:36:12,394 DPI set to 192 x 192
2020-02-24 12:36:12,395 wanted: 192 x 192
2020-02-24 12:36:12,395 client   1 @02.701  running on Linux Debian testing bullseye
2020-02-24 12:36:12,399 client   1 @02.703 Attached to socket:///home/lauscher/.cache/x11docker/wine-pcmanfm-44158236876/buster-104
2020-02-24 12:36:12,404 client   1 @02.704  (press Control-C to detach)
2020-02-24 12:36:12,414 get_max_screen_size()=(1920, 1080)
2020-02-24 12:36:12,521 client   1 @02.806 server does not support xi input devices
2020-02-24 12:36:12,530 client   1 @02.807  server uses: xtest
2020-02-24 12:36:13,031 New unix-domain connection received
2020-02-24 12:36:13,032  on '/home/lauscher/.cache/x11docker/wine-pcmanfm-44158236876/buster-104'
2020-02-24 12:36:13,490 client   1 @03.796 Xpra OpenGL Acceleration Failure
2020-02-24 12:36:13,490 client   1 @03.797  invalid literal for int() with base 10: '5 (Compatibility Profile) Mesa 19'

Additional infos:

$ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
eDP connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 193mm
   1920x1080     60.01*+  39.27  
   1680x1050     60.00  
   1400x1050     60.00  
   1280x1024     59.95  
   1440x900      59.99  
   1280x960      59.99  
   1280x854      59.95  
   1280x800      59.96  
   1280x720      59.97  
   1152x768      59.95  
   1024x768      59.95  
   800x600       59.96  
   848x480       59.94  
   720x480       59.94  
   640x480       59.94  
HDMI-0 disconnected (normal left inverted right x axis y axis)
VGA-0 disconnected (normal left inverted right x axis y axis)

[totaam]

2020-02-24 14:43:31: antoine changed status from new to assigned

[totaam]

2020-02-24 14:43:31: antoine changed owner from mviereck to antoine

[totaam]

2020-02-24 14:43:31: antoine commented

---

Wow, 2 different values can happen, but 3!?

[totaam]

2020-03-15 00:05:58: twyeld commented

---

Any progress on this? Makes using xpra html difficult until we can set the dpi.

In the mean time, is there a get-around to improve performance/res?

[totaam]

2020-03-15 07:50:27: antoine changed status from assigned to new

[totaam]

2020-03-15 07:50:27: antoine changed owner from antoine to mviereck

[totaam]

2020-03-15 07:50:27: antoine commented

---

First, about your command lines:

• --clipboard-direction=both this is the default, not needed
• --clipboard=no so why bother setting the direction?
• --system-tray=yes this is the default, not needed
• --fake-xinerama=no - this is now the default (was not before - slowing down startup on Debian), but if and when we do package fakexinerama for Debian then this will disable it unnecessarily - but I can't think of a better way
• --video-decoders=none doesn't do anything on the server
• --video-encoders=none doesn't do anything on the client
• --xsettings=no this will prevent the xpra server from setting xproperties, including DPI (Xft.dpi and friends) - if you want to prevent the client's xsettings from being propagated to the server, use this switch client-side only
• `--dpi='96' - you're setting this option on the xpra server and (twice!) on the xpra client command lines. What is it that you're trying to accomplish? leaving it alone should pickup the client's dpi automatically.
  Then you're also setting it for the vfb. Why? This won't look good on high-DPI displays.
• -extension MIT-SHM - I know I mentioned this to you before - hasn't this been fixed? Disabling mmap transfers to the host is one thing, but not having shared memory within-the-container-only will severely hamper the xpra-X11 performance and has no security benefits - surely there's a way to enable one without the other?

Now, this bug:

DPI set to 192 x 192
Is fixed in r25645 + r25646.
It only triggers if you use the dpi switch client-side, which is not recommended.

xrdb -q | grep -i dpi
Xft.dpi: 120
Since you are telling xpra to not touch the xresources, this value does not come from xpra, which explains why it is unrelated to the others.

Also, you're using Xvfb instead of Xdummy, which is not a default setup, some DPI attributes may not be honoured that way.

[totaam]

2020-03-15 17:20:50: mviereck commented

---

Thank you for your comments on several options! I've adjusted the xpra commands accordingly.

Is fixed in r25645 + r25646. It only triggers if you use the dpi switch client-side, which is not recommended.

Thank you! Yet I've detected that, too. I'm running an update now to check the fix.

What is it that you're trying to accomplish? leaving it alone should pickup the client's dpi automatically. Then you're also setting it for the vfb. Why? This won't look good on high-DPI displays.

x11docker sets up xpra server+client+Xvfb on the same computer. It sets --dpi in xpra and Xvfb accordingly to the host dpi (found with xdpyinfo) or defined by the user with an x11docker option --dpi.
Xvfb and the client applications are started before the xpra server, so it makes sense to set -dpi in Xvfb.

-extension MIT-SHM - I know I mentioned this to you before - hasn't this been fixed? Disabling mmap transfers to the host is one thing, but not having shared memory within-the-container-only will severely hamper the xpra-X11 performance and has no security benefits - surely there's a way to enable one without the other?

x11docker enables mmap because xpra server and xpra client run on the host. It cannot allow MIT-SHM because the container does not share the memory with the host.
I found no way to allow memory sharing for MIT-SHM only. Docker only allows to share the entire IPC namespace/shared memory for all applications (Docker option --ipc=host).

@twyeld The bug fixed here does not affect your custom xpra setup in container (mviereck/x11docker#229 (comment)). Maybe it helps if you also (or only) set x11docker option --dpi to have another Xvfb DPI setting.

[totaam]

2020-03-16 03:12:57: twyeld commented

---

thanks to both Antoine and mviereck , a short-term getaround is to set the screen size for x11docker - it seems 4:3 ratio gives the best result (~75x75dpi):

x11docker --xvfb --size 1024x768 --dbus-system -- "-p 15500:15500" chromium-x11docker-test

[totaam]

2020-03-16 05:06:30: antoine commented

---

It sets --dpi in xpra and Xvfb accordingly to the host dpi (found with xdpyinfo) or defined by the user with an x11docker option --dpi.
Just beware that xdpyinfo is unreliable and almost always set to 96, even when the actual dpi is not.
Then there's also Xft.dpi and friends, those are better because they reflect the user's preference, not the faked geometry you get from xdpyinfo.

Xvfb and the client applications are started before the xpra server, so it makes sense to set -dpi in Xvfb.
Sure. Just be aware that if the client's geometry is modified later (new monitor plugged in, change in resolution), things may get whacky.

I found no way to allow memory sharing for MIT-SHM only.
Docker only allows to share the entire IPC namespace/shared memory for all applications (Docker option --ipc=host).
That's a real shame!
As per Understanding the Linux Virtual Memory Manager: The filesystem comes in two variations called shm and tmpfs. They both share core functionality and mainly differ in what they are used for. shm is for use by the kernel for creating file backings for anonymous pages and for backing regions created by shmget().
We need shmget for xshm, so mounting a tmpfs may not be enough. I have not tried it.

x11docker --xvfb --size 1024x768 --dbus-system -- "-p 15500:15500" chromium-x11docker-test
FYI: Should be OK, but if 1024x768 is smaller than your client's screen size, you may hit other issues later on: #349, #1132. (not sure about Xvfb since xpra generally uses Xdummy instead)

@mviereck: please close if this works for you.

[totaam]

2020-03-16 07:51:06: twyeld commented

---

using Xdummy instead of xvfb provides similar results = 88 x 75 dpi

is there a chart showing pixel ratios/res and dpi for xdummy/xvfb?

[totaam]

2020-03-16 08:18:55: antoine commented

---

is there a chart showing pixel ratios/res and dpi for xdummy/xvfb?
How would that work?
There is no fixed ratio!

[totaam]

2020-03-16 08:30:31: twyeld commented

---

I agree - I was just trying to work out the magic numbers that would produce at least a balanced dpi

how is the dpi currently calculated?

[totaam]

2020-03-16 08:31:37: antoine commented

---

how is the dpi currently calculated?
First, you have to be clear about which DPI you are referring to. As I explained before, there are many.
Please also see DPI and the links in there.

[totaam]

2020-03-16 08:48:16: twyeld commented

---

Replying to [comment:12 Antoine Martin]:

Please also see DPI and the links in there.

I have read through much of this material - and it seems to offer some convoluted solutions - but I can't know what dpi my users will have on their machines and so it seems that there should be simple method for setting the dpi to either 72 or 96 for most standard formats on a 2K screen and higher dpi as a custom option...

but non of the dpi flags seem to work and using RANDR seems like a bit of kludge - unless I am missing something crucial..?

[totaam]

2020-03-16 08:59:27: antoine commented

---

unless I am missing something crucial..?
No, welcome to my world!

[totaam]

2020-03-16 09:06:15: mviereck commented

---

@mviereck: please close if this works for you.

The update gave me a lower xpra version so I could not check the fix. However, I'll just assume it works. For x11docker it is fixed setting --dpi in xpra server command only. So far, we can close the ticket as the origin issue is solved.

I have opened a new ticket at x11docker for @twyeld's issues: mviereck/x11docker#230
I'm not sure if we should discuss here or there.

About the MIT-SHM issue I've opened a new ticket: #2647

[totaam]

2020-03-16 09:27:59: antoine changed status from new to closed

[totaam]

2020-03-16 09:27:59: antoine set resolution to fixed

[totaam]

2020-03-16 09:27:59: antoine commented

---

(for Ubuntu 16.04 servers, see also #1935)