Xpra: Ticket #601: More troubleshooting for Xdummy

In my experience, Xdummy keeps working inconsistently with the screen resolution (DPI). This is likely due to the insane number of different mechanisms used in X to inform applications about the screen resolution.

-> xrandr reported dpi -> xdpyinfo reported dots per inch -> Xft.dpi resource -> and maybe even the Gnome/KDE setting

All rigorously inconsistent one with the other.

Now, Xdummy seems to have the following issue.

Even with the -dpi option passed to the server /and/ the ConstantDPI option activated, xdpyinfo always returns a resolution that is different from the -dpi one (e.g. I get 20x25 in my setup).

The big big issue is that there are still pieces of software that look at the xdpyinfo dots per inch rather than at the other means. (Java seems to be among them). Hence, the standard xpra setup makes it simply impossible to run certain applications (e.g. Matlab).

I think that this is worth mentioning on the Xdummy wiki, since X will never be fixed in this respect. So it is good to have workarounds.

In my experience, the only workaround is to avoid passing -dpi to Xdummy when starting it and passing a huge screen size in the xpra xorg.conf, also disabling the ConstantDPI option.

With this, at the first connection you get weird font sizes. However, if you open a console and then you launch the new applications from there, the new apps will get (incorrect but) reasonable dpi values from xdpyinfo and will be usable.

In my experience this is the only way to use Java stuff such as matlab with xpra and xdummy.



Sat, 14 Jun 2014 10:53:40 GMT - Antoine Martin: owner changed

I believe this should be closed as a duplicate of #163.

disabling the ConstantDPI option.


That's the only workable fix, why would you want to turn it off!? Are you certain that your dummy driver supports the new ConstantDPI option?


The only reliable solution to the DPI problem is a patched dummy driver with ConstantDPI, in particular see ticket:163#comment:25 where packages are available. I need to re-submit the patch upstream.


Sat, 14 Jun 2014 11:19:21 GMT - callegar:

OK... right! My xdummy is just silently ignoring the ConstantDPI option. Sorry for the noise. I saw the new option in the xpra Xorg.conf and I thought things were failing even with that.

My X dummy driver is marked as 0.3.7 and does not support the ConstantDPI.

Could it be an idea to ship also updated dummy as part of the xpra ppa on ubuntu?


Sat, 14 Jun 2014 11:31:19 GMT - callegar:

Still, I wonder if the lack of the constantDPI option is the only issue.

Why is the xrandr reported screen size 0mm x 0mm ?

Furthermore, if I issue some

xrandr --dpi 90 --verbose

I get

xrandr: Failed to get size of gamma for output default
screen 0: 1680x1050 474x296 mm  90.00dpi

So it looks like xdummy has understood that I want to set the screen size to 474x296. However, right after this, querying xrandr still gives

Screen 0: minimum 320 x 175, current 1680 x 1050, maximum 8192 x 4096
default connected 1680x1050+0+0 0mm x 0mm

So xrandr seems to be plain broken on Xdummy.

If xrandr worked correctly, I believe that it would be easy to change the resolution reported by xdpyinfo from there.

Furthermore, I cannot understand why the screen is reported as "Screen 0" in one case and as "screen 0" in the other (note the different capitalization).


Sat, 14 Jun 2014 11:45:08 GMT - Antoine Martin: status changed; resolution set

I simply do not have the time to package more things, we package too many already.. I think my time will be better spent working on getting the changes upstream.


So xrandr seems to be plain broken on Xdummy.


The dummy driver does not implement the full randr interface: you cannot add new modes, you cannot change the screen size, etc.. That's why the ConstantDPI patch exists. AFAIK, the alternative would be some much more intrusive changes to make the dummy driver randr 1.4 compatible.


Sat, 14 Jun 2014 12:55:48 GMT - callegar:

I understand (and thank you for the explanation!).

I have just had a look at the xdummy git and indeed the ConstantDPI patch does not seem to be there. In fact, the devel pace of xdummy does not seem to be very rapid (2 commits in 9 months, both related to the build infrastructure).

If I find time, I will try to see if I can package the patch into an ubuntu PPA. In fact, my concern is that even if the patch gets accepted, there will be no point release for it. And without a point release, distros are not likely to pick up the patch.

As a side note, I understand that the ConstantDPI flag may improve the situation... still I really think that having proper xrandr support for DPI would be much better, given the variety of screens that you get nowadays. So I wonder if it can be the case to open a bug for the dummy driver on freedesktop.


Sat, 14 Jun 2014 13:07:55 GMT - Antoine Martin:

I think you are likely to face some resistance against changing dummy too much: it is simple and does what it does. Adding randr is likely to be more intrusive, unless it can be done mostly in the DIX layer.

As for handling multiple screens, you should install wiki/FakeXinerama to handle that. (RPM packages are available, nothing for Ubuntu / Debian yet)


Sat, 14 Jun 2014 13:35:57 GMT - callegar:

I was not really mentioning the need to handle multiple screens at once.

Rather, my issue is that at times I connect to a server via xpra from a client that has a low res (90 dpi) screen, and at times from a laptop that has a much higher res (140 dpi). Hence the 96 dpi catchall is really not perfect. Being able to fix dpi dynamically would be very helpful. Unfortunately, I can do that for apps looking at the Xft.dpi resource, but I cannot for those looking at the xdpyinfo data...

My (uninformed) guess is that there is really no need to add the /full/ xrandr 1.4 support to xdummy, but that adding /any/ sort of support for dynamically changing the reported dpi (--dpi) or display size (--fbmm) would fill a practical need.


Sat, 14 Jun 2014 13:40:30 GMT - Antoine Martin:

Apps that look at xdpyinfo-like data are in fact querying DisplayWidthMM and DisplayHeightMM, and the updated constant-dpi patch in #163 will take care of this case too: we set a root window property with the desired dpi (in both width and height so those can be different) and this overrides the constant dpi. So when your new client connects at 140 dpi, the constant-dpi patched dummy driver should "resize" the dummy screen to the right value. Works-for-me!


Sat, 14 Jun 2014 13:56:33 GMT - callegar:

So it is really smart!

Since I haven't had the possibility of trying it, I was expecting it to be just 'constant'.

Now my desire to try the patch is even higher!

Thanks.


Sun, 15 Jun 2014 23:10:48 GMT - callegar:

Packages with patch at https://launchpad.net/~callegar/+archive/ppa/+packages

Note: this is my testing PPA, I may move the packages to a dedicated location once I am happy with them.

This uses the v3 patch. Is it the most updated one?

Can you please provide more detail at the "we set a root window property with the desired dpi (in both width and height so those can be different) and this overrides the constant dpi. So when your new client connects at 140 dpi, the constant-dpi patched dummy driver should "resize" the dummy screen to the right value." I seem to get always 96x96 out of the xdpyinfo.

Thanks for the patch.


Mon, 16 Jun 2014 05:01:15 GMT - Antoine Martin:

This uses the v3 patch. Is it the most updated one?


Yes.


Can you please provide more detail at the "we set a root window property with the desired dpi


The root window properties are:

You need to resize the screen with randr for those to take effect. xpra normally does this when your client connects. If your driver has the patch, it should also print a message to the X11 server log in the form: DPI found root window property "dummy-constant-xdpi" with value=96 etc..


Wed, 09 Dec 2015 15:20:40 GMT - Antoine Martin:

For dummy randr issues, see #56.


Sat, 23 Jan 2021 05:00:33 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/601