Wrong DPI scale since Enpass 5.2

[Tamaskan]

Hello community,

after updating to 5.2, the main window and all dialogs were really large, everything was scaled up. I assumed that somehow HiDPI scaling was enabled, but my laptop monitor is 1920x1080 with 96 DPI. So I added

export QT_AUTO_SCREEN_SCALE_FACTOR=0

to runenpass.sh to force Qt to disable HiDPI support, and the problem was resolved. I don't have this problem with other Qt 5 applications and on another computer with the same screen resolution Enpass 5.2 is running fine without the workaround. Both computers are running Fedora 23 with GNOME 3.18.

Did you guys changed something regarding HiDPI in the latest release? I'm really confused why this bug doesn't occur on my other computer. The only differences are that the affected machine is a laptop, while the other one is a desktop computer using an DVI-connected external monitor. The laptop has Intel graphics, the desktop AMD graphics with the free drivers.

[Valorin]

Same problem for me on a laptop with the 5.2 update - I'm running Ubuntu 16.06 x64 on a Thinkpad T440s.

I think it has to do with how laptops report DPI or something... I've seen it happen in other applications, and the devs have always found a fix for it... so fingers crossed Enpass can fix it too? :-)

Edited April 25, 2016 by Valorin
Adding more detail.

[iSCSI]

Same Problem with 5.2 on Windows 10 64bit / 4k Display

[Vinod Kumar]

Hi all,

Enpass now uses latest version of Qt (5.6) for drawing its user interface. It is supposed to handle scaling on hidpi or scaled desktops by default. If you are facing problems on your pc, you need to override default auto scaling behaviour of Qt using the method suggested by @Tamaskan.

Linux ->Add following line to runenpass.sh or set this environment variable

export QT_AUTO_SCREEN_SCALE_FACTOR=0

Windows -> Add the follow environment variable in Computer -> Properties -> Advance System Settings -> Environment variables->System variables->New.. with variable name  QT_AUTO_SCREEN_SCALE_FACTOR with value 0.

 

Also please share

1. Display resolution 

2. Percentage scaling OS is using for that display

[PierreP566]

I face the same issue on a Dell XPS13 with Intel chip.

My normal display resolution is 1080 x 1920, and for the Enpass screen I cannot say for sure but it seems to be 600x800... it's really huge.

The workaround found by @Tamaskan work good. Thanks

[iSCSI]

Hi Vinod Kumar,

the workaround for Windows works.

Display 3840 x 2160

OS Scaling 150%

 

[Tamaskan]

@Vinod Kumar: Fedora 23 also comes with Qt 5.6. When I delete the bundled Qt libraries from lib/, Enpass uses Fedora's Qt, but the bug is still present. Other Qt apps I use are not affected. Did you have written any specific code in Enpass handling HiDPI support? I'm very curious if this is an Qt bug, which should be reported to the Qt devs and fixed upstream, as other users here seem to have had the same problem with other applications.

[Vinod Kumar]

@Tamaskan Qt Hidpi support for Windows and X11 need to be enabled explicitly by app as per qt docs: http://blog.qt.io/blog/2016/01/26/high-dpi-support-in-qt-5-6/

Quote

Case II: Qt supports the scaling and computes a scale factor.

Supported platforms: X11, Windows, Android, Eglfs

Qt can enable devicePixelRatio scaling on platforms that do not support it natively. This can be done via an environment variable or an application attribute in the application source code:

QT_AUTO_SCREEN_SCALE_FACTOR=1 ./myApp
QGuiApplication::setAttribute(Qt::AA_EnableHighDpiScaling);

Qt will then query the the operating system for display metrics using native API, or in the eglfs case fall back on QT_QPA_EGLFS_PHYSICAL_WIDTH, QT_QPA_EGLFS_PHYSICAL_HEIGHT and the display pixel size.

So, It is enabled in Enpass explicitly. Qt doc also says it might not behave well for some users, so provides an environment variable override:

Quote

Enabling can also be vetoed, either by environment variable or by the application:

QT_AUTO_SCREEN_SCALE_FACTOR=0 ./myApp
QGuiApplication::setAttribute(Qt::AA_DisableHighDpiScaling)

The use-cases for vetoing are “I’m not getting correct DPI values from my displays” and “my application really needs to work in display pixels”. Note that this vetoing only disables “Case II” scaling: Qt can of course not change how the OS works, and manual set scale factors (below) are also kept as as a separate case.

Hidpi support is still far from perfect in Qt and still a work in progress (specially for non integer scale factors ie. 1.5[150%] ,1.75[175%] etc) : https://bugreports.qt.io/browse/QTBUG-50991

We are still gathering inputs from our customers whether to enable Hidpi support explicitly or not.

[Tamaskan]

1 hour ago, Vinod Kumar said:

We are still gathering inputs from our customers whether to enable Hidpi support explicitly or not.

I would suggest adding a checkbox in the settings to enable/disable HiDPI support. This could also be asked in the first setup dialog. Or add this workaround to the FAQ.

[Valorin]

The weird thing for me is... my screen doesn't support HiDPI, so I have no clue why QT would think it does and enable it?

1. Display resolution : 1980 x 1080

2. Percentage scaling OS is using for that display : no scaling enabled as far as I am aware...

I just tried the workaround, but it didn't work - Enpass is still scaled huge for me.

Any ideas @Vinod Kumar?

[Valorin]

5 hours ago, Tamaskan said:

I would suggest adding a checkbox in the settings to enable/disable HiDPI support.

Yep, this would be great to have. Default it to off, as it seems to do stupid stuff to those without HiDPI...

[vanaoff]

Hey everyone, since upgrade to enpass 5.2.0 I'm observing unnaturally large elements of window like icons, buttons, or checkboxes, within Enpass application windows. Font size is ok. Some of named are quite blurry. Any ideas? Thanks

Edited April 27, 2016 by vanaoff

[Valorin]

After a reboot Enpass went back to the right size...

[Tamaskan]

2 minutes ago, Valorin said:

After a reboot Enpass went back to the right size...

You need to log out/log in again (or reboot) before changes in global environment variables take effect. If you edit runenpass.sh, the changes take effect the next time you run Enpass.

[Valorin]

Just now, Tamaskan said:

If you edit runenpass.sh, the changes take effect the next time you run Enpass.

I did that, but it didn't seem to work for some reason.

[Matteo]

The system variable disables the "very large" experience but it doesn't solve the scaling issue.

On Surface Pro 3 with 150% scaling, text and margins are too small, it doesn't scale correctly...

[Vinod Kumar]

@Matteo Please try adding following environment variables  to force for 150% scale on your primary display.

QT_AUTO_SCREEN_SCALE_FACTOR=1
QT_SCREEN_SCALE_FACTORS=1.5   

 

[Matteo]

3 hours ago, Vinod Kumar said:

@Matteo Please try adding following environment variables  to force for 150% scale on your primary display.

QT_AUTO_SCREEN_SCALE_FACTOR=1
QT_SCREEN_SCALE_FACTORS=1.5   

 

That makes the issue even worse. Icons are extremely large, as well as margins...

[Vinod Kumar]

@Matteo Qt has allowed non integer scaling in latest version but it still has too many problems. We are actively tracking upstream developments on regarding hidpi issues https://bugreports.qt.io/browse/QTBUG-50991 and will provide necessary updates. 

[Philip Colmer]

As requested, sharing resolution and scaling ...

Surface Pro 4 screen is 2736 x 1824 and scaling is 200%. External monitors (two of them) are 2560 x 1440 and scaling is 100%. This is with Windows 10.

Without the environment variable fix, enpass looks best on the built-in Surface Pro 4 screen. On the external monitors, the menus suffer the worst as items get dropped off the bottom without any indication that this has happened.

With the environment variable fix, enpass sort of looks OK on the external monitors although perhaps too much spacing whilst on the SP4 screen, it is all bunched up.

I'll probably stick with not using the environment variable fix for now and hope that Qt fixes the issue properly.

 

 

[gspe]

I have made some experiment with some combination of variables and I get best result with the following:

export QT_AUTO_SCREEN_SCALE_FACTOR=0
export QT_SCREEN_SCALE_FACTORS=2.0

I'm running Ubuntu 16.04 Unity on Dell Precision M5510 screen resolution 3840x2160

[Bent]

Using:

export QT_AUTO_SCREEN_SCALE_FACTOR=0
export QT_SCREEN_SCALE_FACTORS=1.5

on Ubuntu Gnome 16.04.1 with Enpass Beta v 5.5.0 on 4k (3840x2160).

Seems to kind of hit-or-miss. It worked well until I rebooted, now I get:

Fonts are really tiny while the rest of the UI is pretty large. Also, some of the elements don't seem to be 4k (HDPI) ready yet and become really pixelated. I hope this will be addressed in future releases.

[Anshu kumar]

Hi @Bent,

I'm afraid to say that your environment variables are getting wiped on reboot. To set them automatically on every login, please add them to  $HOME/.profile

• export QT_AUTO_SCREEN_SCALE_FACTOR=0
• export QT_SCREEN_SCALE_FACTORS=1.5

Hope this helps!

[cimm]

I recently switched from 1Password to Enpass as Enpass supports Linux and I am in the process of switching from macOS to Ubuntu. My new laptop arrived and I am moving over my passwords... turns out Enpass does not (yet) support HDPI and it's pretty unusable without. Are there any plans to support HDPI (Retina, 4K, whatever you want to call it) Linux systems?

Thank you.

 

Edited February 20, 2017 by cimm
Smaller image

[Vinod Kumar]

Hi @cimm,

Enpass does have HDPI support. In most cases it works out of the box, but sometimes you might need to adjust a few environment variables to make it work. e.g.

Please try adding following environment variables  to force for 150% scale on your primary display.

QT_AUTO_SCREEN_SCALE_FACTOR=1
QT_SCREEN_SCALE_FACTORS=1.5