Wrong candidate window position for Qt applications with HiDPI 200% scaling

[struq]

Please fill in the following items if you don't know the root cause.

Which distribution and version?:
(E.g. Fedora 27. Check /etc/fedora-release)
Fedora 32

Which desktop environment and version?:
(E.g. GNOME 3.24. Check $XDG_CURRENT_DESKTOP and your ISO image.)
KDE Plasma Version: 5.18.3
KDE Frameworks Version: 5.68.0
Qt Version: 5.13.2

Which session type?:
(X11 or Wayland. Check $XDG_SESSION_TYPE)
X11

Which application and version?:
(E.g. gedit 3.24, leafpad, kate, xterm)
Dolphin, KWrite, Konsole, VLC, etc.
It seems to be all Qt applications.

IBus version?:
(Run ibus version)
1.5.22

Issue description:
The candidate window appears at about half the distance from the top left of the screen to the cursor for Qt applications. The position is correct (under the cursor) for GTK applications.

Steps to reproduce:

1. Set display scaling to 200% in System Settings - Display and Monitor - Display Configuration - Global scale
   This seems to automatically set the following environment variables:

GDK_DPI_SCALE="0.5"
GDK_SCALE="2"
QT_AUTO_SCREEN_SCALE_FACTOR="0"
QT_SCREEN_SCALE_FACTORS="Virtual1=2;Virtual2=2;Virtual3=2;Virtual4=2;Virtual5=2;Virtual6=2;Virtual7=2;Virtual8=2;"

Also

$ xrdb -query | grep dpi
Xft.dpi:        192

2. Enable IBus:
   imsettings-switch IBus
   Log out & log in
   The following environment variables are correctly set:

GTK_IM_MODULE="ibus"
QT_IM_MODULE="ibus"
XMODIFIERS="@im=ibus"

3. Switch to Intelligent Pinyin input method (libpinyin) and type in a Qt application, e.g. KWrite

Can you reproduce your problem when you restart ibus-daemon? (yes / no):
(Run ibus exit and ibus-daemon --xim &)
Sort of, the candidate window position for Qt applications is fixed, but now it breaks GTK applications. The candidate window appears at twice the distance from the top left of the screen to the cursor.

I also notice that in the Pinyin Preferences window, before restarting ibus-daemon, only text is scaled, but not widgets and icons. After restarting ibus-daemon, everything is scaled properly.

Do you see any errors when you run ibus-daemon with the verbose option?:
(Run ibus-daemon --xim --verbose & and look at the output when you encounter your problem.)
Errors that seem irrelevant to this issue:

cannot open ../lua/base.lua: No such file or directory
lua script loaded.
cannot open /home/user/.config/ibus/libpinyin/user.lua: No such file or directory
open /home/user/.cache/ibus/libpinyin/user.conf failed.portal is not running: Timeout was reached

Can you reproduce your problem with a new user account instead of the current your account? (yes / no):
Yes

Screenshots:
Qt, before restart

GTK, before restart

Qt, after restart

GTK, after restart

Preferences window, before restart

Preferences window, after restart

[CliffHan]

I met similar issue, the only difference is that the application is "Microsoft Teams Preview". I guess same problem happens on all electron apps.

Issue description:
The candidate window appears at right bottom direction, some distance away from the input control. When the input is at the bottom of the screen, the candidate window will not display, I think it's position is wrongly calculated to be outside the screen. Looks just like the 4th pic above.

I've already confirmed it happens on Ubuntu 20.04 when I set scale as 125%. If I set scale to 100% and restart, the problem is gone. And it happens too on Ubuntu 18.04 with scale set to 200%.

Ubuntu 18.04 environment:
Desktop: Gnome 3.28.2
Session: x11
Application: Microsoft Teams Preview (Guess to be all electron apps)
IBus version: 1.5.17
Input Method: Intelligent Pinyin for Chinese

[linwaytin]

I have the same issue on Arch linux.
Desktop: I3
Session: x11
Application: All applications I tested have the same issue
IBus version: 1.5.22+8+gf591381e
Input Method: Chewing

[AlynxZhou]

I met similar issue, the only difference is that the application is "Microsoft Teams Preview". I guess same problem happens on all electron apps.

Issue description:
The candidate window appears at right bottom direction, some distance away from the input control. When the input is at the bottom of the screen, the candidate window will not display, I think it's position is wrongly calculated to be outside the screen. Looks just like the 4th pic above.

I've already confirmed it happens on Ubuntu 20.04 when I set scale as 125%. If I set scale to 100% and restart, the problem is gone. And it happens too on Ubuntu 18.04 with scale set to 200%.

Ubuntu 18.04 environment:
Desktop: Gnome 3.28.2
Session: x11
Application: Microsoft Teams Preview (Guess to be all electron apps)
IBus version: 1.5.17
Input Method: Intelligent Pinyin for Chinese

Check you electron version (and embedded chromium version), there is a bug before chromium 79 that report wrong location using scale larger than 100%.

[ropery]

The issue is certainly not Electron-specific. My HiDPI settings are,

# X11, i3 WM, no DE
GDK_SCALE=2
GDK_DPI_SCALE=0.5
QT_ENABLE_HIGHDPI_SCALING=1
QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough
Xft.dpi=192  # xrdb

Results: QT applications are fine, GTK applications = misplaced candidate panel/window (ie same as @struq "after restart" results)

[struq]

This issue is still present in Fedora 33, in both KDE and GNOME environments.

I tried to modify qibusplatforminputcontext.cpp after looking at fcitx which has the expected behavior. The following change seems to have fixed this issue, at least under X11:

--- qtbase-everywhere-src-5.15.1/src/plugins/platforminputcontexts/ibus/qibusplatforminputcontext.cpp.scale	2020-10-10 22:03:29.141848234 -0700
+++ qtbase-everywhere-src-5.15.1/src/plugins/platforminputcontexts/ibus/qibusplatforminputcontext.cpp	2020-10-10 22:06:34.211497965 -0700
@@ -257,7 +257,8 @@ void QIBusPlatformInputContext::cursorRe
     r.moveTopLeft(inputWindow->mapToGlobal(r.topLeft()));
     if (debug)
         qDebug() << "microFocus" << r;
-    d->context->SetCursorLocation(r.x(), r.y(), r.width(), r.height());
+    qreal scale = inputWindow->devicePixelRatio();
+    d->context->SetCursorLocation(r.x() * scale, r.y() * scale, r.width() * scale, r.height() * scale);
 }
 
 void QIBusPlatformInputContext::setFocusObject(QObject *object)

Under GNOME Wayland, the candidate window for Qt is always at the top left of the screen, with or without this change. And fcitx doesn't work correctly either. So I guess that's a different issue. (In Fedora 32, IBus didn't work at all for Qt under Wayland so I can't compare.)

[ropery]

This is a fix in QT? For me, QT is working fine; it's the GTK applications that are having misplacement issues.

[struq]

This is in the ibus-qt plugin, which is included in Qt since Qt5. It fixes my issue in both GNOME and KDE with auto-started ibus.

Looks like it will depend on how ibus is started too. That could be distribution or DE-specific. Here in GNOME restarting ibus-daemon doesn't make a difference. In KDE, restarting ibus-daemon seems to double the scaling. (In the original report I had @lolilolicon's issue only after restarting ibus-daemon.) But at least the behavior is consistent between Qt and GTK now. If I take a wild guess, it has to do with the scaling related environment variables ibus itself is started with.

[ropery]

So are you saying that, with your patch, under KDE after restarting ibus-daemon the candidate window in QT applications become misplaced? While in your original report (after restart), as is my case, QT applications are fine. If so, I'm afraid this patch would break QT applications for me...

What is the situation with GTK applications? Your patch does not affect those, correct?

I use startx + i3 WM, no DE.
I have inspected the output of env. The only relevant variables are those found in my second to last post.
Maybe you could investigate what KDE/Gnome does differently in this respect?

[struq]

I'm not going to spend more time on this but hopefully maintainers of IBus or Qt would follow up.

What if you try to start ibus with GDK_SCALE and GDK_DPI_SCALE unset? Anyway, if not using GNOME, I'd suspect other input frameworks like fcitx will work better.

[ropery]

Thanks for the hint.
I was excited (Wow!) to find the following fixes the window misplacement in GTK applications:

GDK_SCALE= GDK_DPI_SCALE= ibus-daemon --xim --replace --daemonize

However, the window now becomes misplaced in QT applications, namely towards the top-left, at (x/2, y/2), as if halving the scaling, so to speak. (Which is still an improvement, for at least the panel won't go off-screen now!)
(i.e., the exact same situation as "before restart" in @struq's original post.)

鱼与熊掌，不可兼得。
GTK or QT, you can't have both.

Just a thought: Is it possibe for ibus to detect whether the input focus is in a GTK application or a QT application? If so, it appears it should ignore GDK_SCALE and GDK_DPI_SCALE only if it's a GTK application.
(It seems... ibus being a GTK application itself, seems to apply the 2x scale on top of the 2x scale of the "parent" GTK window.)

[s0nny7]

For me, I solved the problem by clearing "GDK_SCALE" and setting "GDK_DPI_SCALE=2".

[fujiwarat]

@struq Thank you for your investigation.
Would you report your issue to https://bugreports.qt.io ? and your patch to https://codereview.qt-project.org/ ?

If you won't, I can work on this issue on behalf of you.

Reagarding to Wayland, you no longer settle the lookup window position with the IM modules since Wayland gives the permission to the window manager only. E.g. gnome-shell in GNOME Wayland so you need to export GTK_IM_MODULE="wayland" instead of "ibus" and QT applications cannot settle the window position in GNOME Wayland.

[struq]

Hi @fujiwarat, I probably wouldn't have the time for that. Could you work on it instead? Thank you.

[escape0707]

Reagarding to Wayland, you no longer settle the lookup window position with the IM modules since Wayland gives the permission to the window manager only. E.g. gnome-shell in GNOME Wayland so you need to export GTK_IM_MODULE="wayland" instead of "ibus" and QT applications cannot settle the window position in GNOME Wayland.

Interesting, I set *IM_MODULE variable according to ArchWiki to both "ibus" and GTK apps work fine in GNOME Wayland.

I've migrated to Fcitx5 and these variable is set to "fcitx", and for both GTK and Qt apps it works fine. It even has a screen boundary sanity check or something to prevent any part of the panel to appear out of the screen.

[struq]

Reagarding to Wayland, you no longer settle the lookup window position with the IM modules since Wayland gives the permission to the window manager only. E.g. gnome-shell in GNOME Wayland so you need to export GTK_IM_MODULE="wayland" instead of "ibus" and QT applications cannot settle the window position in GNOME Wayland.

Interesting, I set *IM_MODULE variable according to ArchWiki to both "ibus" and GTK apps work fine in GNOME Wayland.

I've migrated to Fcitx5 and these variable is set to "fcitx", and for both GTK and Qt apps it works fine. It even has a screen boundary sanity check or something to prevent any part of the panel to appear out of the screen.

I've been using fcitx5 for a while too. Indeed it seems to handle all the environments perfectly: GTK or Qt, GNOME or KDE, X11 or native Wayland or XWayland, and even Flatpak apps.

[liangqi]

See also https://codereview.qt-project.org/c/qt/qtbase/+/445920 for x11.

For Wayland, it looks like we need to update those .xml files in src/plugins/platforminputcontexts/ibus/interfaces in qtbase, but I only found one at https://github.com/ibus/ibus/blob/main/portal/org.freedesktop.IBus.Portal.xml , could someone help to guide? Thanks a lot.

[fujiwarat]

qtbase's interface is maintained by itself. You could refer ibus/bus/bus/inputcontext.c .

[liangqi]

qtbase's interface is maintained by itself. You could refer ibus/bus/bus/inputcontext.c .

https://github.com/ibus/ibus/blob/main/bus/inputcontext.c ? Thanks.

[liangqi]

For https://bugreports.qt.io/browse/QTBUG-103393 IBus input method cannot set panel position correctly with DPI scaling, there are patches,

• https://codereview.qt-project.org/c/qt/qtbase/+/447069 ibus: add SetCursorLocationRelative in InputContext.xml
• https://codereview.qt-project.org/c/qt/qtbase/+/445920 ibus: support high dpi for cursor rectangle on both X11/xcb and Wayland.