Problem with HiDPI screen on Ubuntu 18.04

[osrf-migration]

Original report (archived issue) by Abdelhak Bougouffa (Bitbucket: abougouffa).

---

I tried Gazebo 9 (which comes with ROS Melodic), and also the latest stable version (Gazebo 10) from the official repo, in both cases I have a display problem in my Dell XPS HiDPI screen, the inner window (for 3D stuff) is always half size of the total area, the attached picture shows the problem.

‌

[osrf-migration]

Original comment by Abdelhak Bougouffa (Bitbucket: abougouffa).

---

• Edited issue description

[osrf-migration]

Original comment by Sven Niederberger (Bitbucket: EmbersArc).

---

Same here on a 2K display with KDE Plasma, the scaling difference is not as strong in that case. Seems to be the same issue as https://osrf-migration.github.io/gazebo-gh-pages/#!/osrf/gazebo/issues/2687/simulation-window-not-scaling-correctly-on (#2687)

[osrf-migration]

Original comment by Ian Chen (Bitbucket: Ian Chen, GitHub: iche033).

---

are you by any chance running gazebo in a virtual machine? I recall in the past there was a problem that the incorrect device pixel ratio (scaling factor) is returned on a VM.

[osrf-migration]

Original comment by Abdelhak Bougouffa (Bitbucket: abougouffa).

---

Nop, I’m using Ubuntu as main OS, and I compiled also Gazebo from source in Arch Linux; I have always the same problem

[osrf-migration]

Original comment by Chris Beggs (Bitbucket: Chris Beggs).

---

Fixed the issue on Ubuntu 18.04 XPS 15.

Edit the Exec= portion in the “/usr/share/applications/gazebo.desktop“ file to:

Exec=/usr/bin/env QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCALE_FACTOR=1.0 /usr/bin/gazebo

It fixed the issue on my machine. If that doesn’t work, check out run_scaled script on Github.

‌

‌

[bionade24]

What is the root of this problem? Ogre? Does anyone know more about it?

[LeroyR]

Having the same problem
QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCALE_FACTOR=1.0 do not fix this for me

What is the root of this problem? Ogre? Does anyone know more about it?

Pretty sure gazebo does something wrong as rviz is able to display correctly and is using the same Ogre version (1.9.0 for me)

[bionade24]

Having the same problem
QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCALE_FACTOR=1.0 do not fix this for me

This one is deprecated. Use QT_SCREEN_SCALE_FACTORS =[list] for every display.
https://doc.qt.io/qt-5/highdpi.html

[matthias-mayr]

The suggested solution does not work for me having Ubuntu 18.04 and an Nvidia driver.
I tried the following

/usr/bin/env QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCALE_FACTOR=1.0 /usr/bin/gazebo
/usr/bin/env QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCALE_FACTOR=[1.0,1.0] /usr/bin/gazebo

in Gazebo Answers I got told to use run_scaled as an alternative.
It turned out that the Ubuntu xpra package does not with the x-server hwe packages. There are is an issue in xpra about it. Eventually I followed the installation procedure of their own xpra repository and that packages is compatible with the hwe packages.
I can run Gazebo without the borders when starting it with

./run_scaled --scale=1.0 /usr/bin/gazebo

but it renders the fonts so big that e.g. the simulation time can not be read anymore.

[bionade24]

Yes, I know the issues with xpra. Under Qt 5.14/5.15 on Arch Linux it ran fine, but I guess Qt 5.9 is way too old. You may should consider to switch to 20.04. Or maybe just try to only scale the display gazebo appears on: [1.0, scale_factor]. For 5.9 you should look into the Qt documentation to get the correct setting.

[matthias-mayr]

I just noticed that I forgot to switch out the other environment variable for the one that @bionade24 suggested: QT_SCREEN_SCALE_FACTORS =[list]

And indeed running Gazebo with

/usr/bin/env QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCREEN_SCALE_FACTORS=[1.0,1.0] /usr/bin/gazebo

works fine. The fonts are scaled appropriately and it uses the whole screen. It turns out that

/usr/bin/env QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCREEN_SCALE_FACTORS=[1.0] /usr/bin/gazebo

works as well. Even though I have two 4k screens.

But now that there's a quite nice workaround some other questions pop up: How to make this persistent and work in all scenarios?
For me Gazebo is run by roslaunch files most of the time. I guess that I could replace /usr/bin/gazebo with a script that appends the environment variables. But I guess that would make the package management complain. Any other ideas?

[bionade24]

If you write your wrapper script to /usr/local/bin/gazebo it will prefer it and package managers won't complain.

[zoenglinghou]

I checked the gazebo binary used in roslaunch with ps aux | grep gazebo, and I believed it is gzclient. So I basically change gzclient to a shell script (it was a simlink to /usr/bin/gzclient-VERSION):

#!/usr/bin/sh

/usr/bin/env QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCREEN_SCALE_FACTORS=[1.0] /usr/bin/gzclient-* $@

and that fixed it for me

[trick2011]

/usr/bin/env QT_AUTO_SCREEN_SCALE_FACTOR=0 QT_SCALE_FACTOR=1.0 /usr/bin/gazebo

Works for me on Ubuntu Mate 18.04

[kmdalal]

Using Ubuntu 18.04 and Gazebo 9.19.0, I solved this issue by simply adding the following variables (thanks to the suggestions above) in my .bashrc:

export QT_AUTO_SCREEN_SCALE_FACTOR=0
export QT_SCREEN_SCALE_FACTORS=[1.0]

[yuan-su-1997]

Using Ubuntu 18.04 and Gazebo 9.19.0, I solved this issue by simply adding the following variables (thanks to the suggestions above) in my .bashrc:

export QT_AUTO_SCREEN_SCALE_FACTOR=0
export QT_SCREEN_SCALE_FACTORS=[1.0]

Thanks, I solve this problem using this method !

[lkn01]

Using Ubuntu 18.04 and Gazebo 9.19.0, I solved this issue by simply adding the following variables (thanks to the suggestions above) in my .bashrc:

export QT_AUTO_SCREEN_SCALE_FACTOR=0
export QT_SCREEN_SCALE_FACTORS=[1.0]

Thanks, I solve this problem using this method ! In ubuntu22.04