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

ubuntu 18.04 gnome scaling #2438

Closed
totaam opened this issue Oct 7, 2019 · 12 comments
Closed

ubuntu 18.04 gnome scaling #2438

totaam opened this issue Oct 7, 2019 · 12 comments
Labels

Comments

@totaam
Copy link
Collaborator

totaam commented Oct 7, 2019

Issue migrated from trac ticket # 2438

component: client | priority: critical | resolution: fixed

2019-10-07 21:21:12: bleszynski created the issue


Recently xpra stopped working with Ubuntu 18.04.3 LTS when a Gnome desktop scaling factor other than 100% is used.

The effect is that the interface fills the lower left quarter of the window instead of scaling to fit the entire window. Mouse interactions seem to be mapped to the correct positions, however.

This problem affects all programs, including xcalc and xeyes. I am able to reproduce the problem on multiple machines, under both wayland and xorg, and different display drivers.

$ sudo dpkg-query -l | grep xpra
ii  python2-xpra    3.0-24095-1  amd64  tool to detach/reattach running X programs
ii  python3-xpra    3.0-24095-1  amd64  tool to detach/reattach running X programs
ii  xpra            3.0-24095-1  amd64  tool to detach/reattach running X programs
ii  xpra-html5      3.0-24095-1  amd64  html5 xpra client
@totaam
Copy link
Collaborator Author

totaam commented Oct 8, 2019

2019-10-08 02:48:52: antoine changed status from new to assigned

@totaam
Copy link
Collaborator Author

totaam commented Oct 8, 2019

2019-10-08 02:48:52: antoine edited the issue description

@totaam
Copy link
Collaborator Author

totaam commented Oct 8, 2019

2019-10-08 02:48:52: antoine commented


How do you set the desktop scaling factor?
Does the problem go away if you turn opengl off?

@totaam
Copy link
Collaborator Author

totaam commented Oct 8, 2019

2019-10-08 06:01:11: bleszynski commented


In the case of HiDPI displays, I use the Gnome Settings widget to change scale from 100% to 200%.

In the case of non-HiDPI displays, the scale widget is not displayed but I can reproduce the problem by opening dconf-editor, navigating to org.gnome.desktop.interface, and setting the scaling factor to 2. I think this has the same effect as the widget.

Regarding opengl, I was able to reproduce the problem in a "Gnome Flashback (Compiz)" session which appears to not use hardware acceleration. This was on a non-HiDPI display. I will try other machines tomorrow. If there is a better way to disable opengl then please let me know.

@totaam
Copy link
Collaborator Author

totaam commented Oct 8, 2019

2019-10-08 09:45:15: antoine commented


Regarding opengl, I was able to reproduce the problem in a "Gnome Flashback (Compiz)" session which appears to not use hardware acceleration
I meant starting xpra with --opengl=no or using the system tray to disable opengl.

@totaam
Copy link
Collaborator Author

totaam commented Oct 9, 2019

2019-10-09 18:01:27: bleszynski commented


Starting xpra attach with --opengl=no scales the application (xcalc) to fit the window. The pointer sometimes disappears and is not mapped to the correct xy position.

We were using xpra to scale a Java gui application on a HiDPI display in Gnome 3. Recently the application started to respect the gnome desktop scaling factor under Wayland sessions. I don't understand how this works but it solves the main problem for us.

@totaam
Copy link
Collaborator Author

totaam commented Oct 14, 2019

2019-10-14 12:54:06: antoine changed priority from major to critical

@totaam
Copy link
Collaborator Author

totaam commented Oct 14, 2019

2019-10-14 12:54:06: antoine commented


Links:

Related changes:

  • r24125 if the desktop scaling value is set, honour it
  • r24128 keep scaling value with mmap
  • r24131 fix cursor scaling

Found an easy workaround: run the client with xsettings=no.
The problem is that we're synchronising the GTK property that makes it report adjusted coordinates on the server, then all the calls we make to GTK report values that aren't real.
This will need to be filtered out.

@totaam
Copy link
Collaborator Author

totaam commented Oct 14, 2019

2019-10-14 13:45:08: antoine changed status from assigned to closed

@totaam
Copy link
Collaborator Author

totaam commented Oct 14, 2019

2019-10-14 13:45:08: antoine set resolution to fixed

@totaam
Copy link
Collaborator Author

totaam commented Oct 14, 2019

2019-10-14 13:45:08: antoine commented


Fixed in r24133.

This will be included in the next stable update. Until then, the xsettings=no is a viable workaround - works for both client and server command lines.

@totaam totaam closed this as completed Oct 14, 2019
@totaam
Copy link
Collaborator Author

totaam commented Oct 27, 2019

2019-10-27 03:52:38: antoine commented


See also #2464 and #2500.

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

No branches or pull requests

1 participant