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.
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.
output when DPI is bad
output when DPI is good
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).
Please post:
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.
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.
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.
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.
From the server log:
init_all_server_settings() dpi=0, default_dpi=0
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.
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:
(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!
Feel free to re-open if you still have problems.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1545