When attaching to a remote Xpra session, 3.0.2 shows text consistent with client side DPI, whereas 4.0.x shows text that is incredibly small. This is reproduced on both Ubuntu 18.04/Fedora 31 running both the latest beta and 3.0.2 xpra servers.
Looks like an exact duplicate of #2480.
From your log:
Warning: invalid screen size 5719x6349mm using 339x212 mm
Maybe there's somewhere else we need to workaround the bogus values we get from GTK.
Can you please add the output of
xpra info from the server?
Sorry for bugging you again, but there are still things I can't figure out from the information you provided:
upscaled to 200%, virtual screen size: 640x400 mjlbach-macbook-pro-2.local (339x212 mm - DPI: 47x47) workarea: 640x355 at 0x12 monitor 2 (286x179 mm - DPI: 56x56)
Running the client with
-d display,screen,scaling should tell us.
display.dpi.default=0 display.dpi.value=36 display.dpi.x=36 display.dpi.y=36
Can you run the server with
-d display,screen,scaling and post the server log?
Updated to the latest beta on server/client. Here are the logs:
Thanks for the logs.
upscaled to 200%
This is caused by #2438:
This must be a HIDPI display because GTK is telling us that there is a scale factor of 2.
What is the actual resolution of your display? Is it really 1280x800? or maybe 2560x1600?
r24535 works and helps us find the correct value for the physical screen dimensions:
Warning: invalid screen size 5719x6349mm using 286x179 mm
Which is the monitor size:
mjlbach-macbook-pro-2.local (286x179 mm - DPI: 113x113) workarea: 1280x709 at 0x23
Did you specify the
--dpi=144 switch anywhere?
Maybe in your local config?
You can verify with:
$ xpra showconfig | grep dpi
Because this log output seems to imply that you did:
dpi: (-1, -1) -> (36, 36).
The value 36 makes more sense now, it was caused by a bug: that would be 144 upscaled by 200% (the value was wrongly divided by 200% twice, one for each axis - that's fixed in r24545).
Another important point worth mentioning is that many applications will only honour the DPI value when they start, changes in DPI settings will not be adjusted at runtime. So it is best to launch the applications used for testing after connecting from the client.
Not much to see on the server side:
client resolution is (640, 400), current server resolution is 8192x4096
set to 36 x 36 wanted: 36 x 36
I have uploaded a new macos beta build with r24545: https://xpra.org/beta/MacOS. This should help honour whatever DPI is set on the command line when
desktop-scaling=auto kicks in, as it does on hidpi displays.
Things you can try:
--dpi=overrides - should not be any different
--dpi=144on the command line, should now be double the size it was before with
I have verified that the
--dpi switch does do something by launching
gedit on the server after connecting and the window title and menus do adapt to DPI settings.
I will take another look at this for #1933 and #2410 eventually.
The display resolution is 2560×1600 (2014 MBP retina 13"), I'm running at native resolution. I didn't specify any flags (just xpra attach ssh/host/1).
$ xpra showconfig | grep dpi $ dpi = 0
I also started the program (firefox) only after starting the server and attaching to the display from the client. I'll give the new beta a try along with the suggested additional dpi/desktop scaling flags and report back!
The text-size problem now appears only if the application is started after client attaches. If the application is started before attaching, the text-size is correct. In either case, the client-side scaling is still initially 200%.
Starting with --dpi=144 doubles the font size, but also results in scaling initially being set to 200%.
Setting --desktop-scaling=no seems to fix the problem regardless if I attach to a running application session, or start the application after attaching. The scaling is (unsurprisingly) none.
Setting both desktop scaling and dpi seems to make the scaling and font size consistent regardless of the order in which I start the application/attach.
There's a new beta 4.0 build here: https://xpra.org/beta/MacOS/. @mjlbach: does that work OK for you?
Seems like it is fixed on the latest beta! Thank you
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2500