Seemingly random DPI problem

[Thomas Esposito]

I am on RHEL 6.6 (using the Centos 6.6 RPMs). I am currently on the latest supported version: 1.0.6. I did not start experiencing this issue until 1.0.5 (I think).

Sometimes, when I reconnect to a running session, applications that use fontconfig fonts (e.g. gnome-terminal) render fonts MUCH smaller than they would normally, as if the DPI setting has been dramatically reduced. After disconnecting and reconnecting, sometimes multiple times, the issue is resolved.

FWIW, I'm using the latest client version 2.0.2 on Windows 7. I suppose the issue could be related to that.

I doesn't appear that 2.x is supported on Centos 6.6, otherwise I would be using it.

[Antoine Martin]

Please attach client and server logs with the "-d screen,xsettings" debug switch.

And try to capture some of the debug information as per wiki/DPI comparing when the problem occurs and when it does not.
ie:

xrdb -query -all | grep dpi

xdpyinfo | grep dots

xrandr

client output, etc.

[Thomas Esposito]

output when DPI is bad

[Thomas Esposito]

output when DPI is good

[Thomas Esposito]

It looks like the fontconfig DPI value is cut in half (from 96 to 48) when the bug manifests. Interestingly, even when fonts look correct (i.e. the "good" case), the horizontal DPI value reported by xdpyinfo is incorrect (i.e. 48 instead of 96).

[Antoine Martin]

Please post:

• the full client output
• "xpra info" from the server
• "GTK_info.exe" output
• "NativeGUI_info.exe" output
• the server log running with "-d xsettings,screen"

FWIW, I'm using the latest client version 2.0.2 on Windows 7. I suppose the issue could be related to that.
I doesn't appear that 2.x is supported on Centos 6.6, otherwise I would be using it.

2.x clients connecting to a 1.x server should work just fine, for more information, see wiki/Platforms and wiki/Versions.

[Thomas Esposito]

I attached files containing the information that you asked for. Ignore server.2.log which was added in error. I'm not sure how to remove attachments.

[Thomas Esposito]

I re-uploaded server.log with a new version with more interesting output. In this case, shortly before dumping the log, I returned to my PC after being locked for a while and discovered that my DPI had changed WITHOUT reconnecting. You can see evidence of this in the log.

[Antoine Martin]

I'm not sure how to remove attachments.

Just click on the attachment link and select "Delete Attachment" at the bottom of the attachment view page. (I've done it for you)

I will take a look at the data as soon as I can.

[Antoine Martin]

From the server log:

• initial dpi is unset (good): init_all_server_settings() dpi=0, default_dpi=0
• after the client handshake, we set the client's dpi: overrides: dpi=96, double click time=550, double click distance=(4, 4)
• Warning: xxhash python bindings not found - not sure how that is possible, "python2-xxhash" is a dependency of the xpra package which you are missing.
• at 14:20:03 the client sends an updated screen definition (with the same size), that happens sometimes (screensaver, etc) - we re-apply the xsettings and the DPI is still at 96
• 14:22:51 a new client connection
• 14:54:34 another spurious screen size change - this is the one where the DPI ends up at 48, and just before that we can see:

  14:54:34,145 client 2: failed to get xdpi: argument 2: <type 'exceptions.OverflowError'>: long int too long to convert
  

So we failed to get the xdpi... and that value must therefore be invalid. Then we take the average of 0 and 96... and we get 48. This bug is only occurring with the 2.x clients because of the move from pywin32 to ctypes (#678).

---

Fixes:

• r16361: the overflow fix
• r16362: don't take the average if one of the values is invalid!

(these updates will be applied to the 1.x and 2.x branches)
You can find beta 2.1 builds with these fixes (and more) here: http://xpra.org/beta. Please close if that works for you.

Many thanks for reporting this bug with the server log!