Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More troubleshooting for Xdummy #601

Closed
totaam opened this issue Jun 14, 2014 · 15 comments
Closed

More troubleshooting for Xdummy #601

totaam opened this issue Jun 14, 2014 · 15 comments

Comments

@totaam
Copy link
Collaborator

totaam commented Jun 14, 2014

Issue migrated from trac ticket # 601

component: server | priority: major | resolution: duplicate

2014-06-14 11:46:09: callegar created the issue


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.

@totaam
Copy link
Collaborator Author

totaam commented Jun 14, 2014

2014-06-14 11:53:40: totaam changed owner from antoine to callegar

@totaam
Copy link
Collaborator Author

totaam commented Jun 14, 2014

2014-06-14 11:53:40: totaam commented


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

disabling the ConstantDPI option.
[[BR]]
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?

[[BR]]

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

@totaam
Copy link
Collaborator Author

totaam commented Jun 14, 2014

2014-06-14 12:19:21: callegar commented


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?

@totaam
Copy link
Collaborator Author

totaam commented Jun 14, 2014

2014-06-14 12:31:19: callegar commented


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

  • For xdummy, xrandr shows things like
Screen 0: minimum 320 x 175, current 1680 x 1050, maximum 8192 x 4096
default connected 1680x1050+0+0 0mm x 0mm

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).

@totaam
Copy link
Collaborator Author

totaam commented Jun 14, 2014

2014-06-14 12:45:09: totaam changed status from new to closed

@totaam
Copy link
Collaborator Author

totaam commented Jun 14, 2014

2014-06-14 12:45:09: totaam changed resolution from ** to duplicate

@totaam
Copy link
Collaborator Author

totaam commented Jun 14, 2014

2014-06-14 12:45:09: totaam commented


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.

[[BR]]

So xrandr seems to be plain broken on Xdummy.
[[BR]]
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.

@totaam totaam closed this as completed Jun 14, 2014
@totaam
Copy link
Collaborator Author

totaam commented Jun 14, 2014

2014-06-14 13:55:48: callegar commented


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.

@totaam
Copy link
Collaborator Author

totaam commented Jun 14, 2014

2014-06-14 14:07:55: totaam commented


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 FakeXinerama to handle that. (RPM packages are available, nothing for Ubuntu / Debian yet)

@totaam
Copy link
Collaborator Author

totaam commented Jun 14, 2014

2014-06-14 14:35:57: callegar commented


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.

@totaam
Copy link
Collaborator Author

totaam commented Jun 14, 2014

2014-06-14 14:40:31: totaam commented


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!

@totaam
Copy link
Collaborator Author

totaam commented Jun 14, 2014

2014-06-14 14:56:34: callegar commented


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.

@totaam
Copy link
Collaborator Author

totaam commented Jun 16, 2014

2014-06-16 00:10:48: callegar commented


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.

@totaam
Copy link
Collaborator Author

totaam commented Jun 16, 2014

2014-06-16 06:01:16: totaam commented


This uses the v3 patch. Is it the most updated one?
[[BR]]
Yes.

[[BR]]

Can you please provide more detail at the "we set a root window property with the desired dpi
[[BR]]
The root window properties are:

  • dummy-constant-xdpi
  • dummy-constant-ydpi

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..

@totaam
Copy link
Collaborator Author

totaam commented Dec 9, 2015

2015-12-09 15:20:41: antoine commented


For dummy randr issues, see #56.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant