Description of problem: When I trying to input chinese text with ibus-libpinyin in QT apps (tested texworks, okular, kwrite, konsole, fedora mediawriter, seemingly all QT apps), the candidate character panel shows up not below the cursor but at a wrong position, sometimes outside the window. This happens in both Wayland and Xorg sessions, although the position is different for the two environments. Version-Release number of selected component (if applicable): Fedora-Workstation-Live-x86_64-36-20220307.n.0.iso image running on bare metal. ibus-1.5.25-13.fc36 ibus-libpinyin-1.12.1-2.fc36 qt5-qtbase-5.15.2-33.fc36 How reproducible: Always Steps to Reproduce: 1. Boot from the live image 2. Add Intelligent Pinyin IME from Settings-Keyboard-Input Sources 3. Install some QT apps (e.g. kwrite) 4. Open kwrite, click the text field, use Super-Space to switch to Pinyin input, and try to input some text Actual results: The candidate character panel shows up at a wrong position, sometimes outside the window. Expected results: The candidate character panel should show up just below the text cursor. Additional info: Bug 2060988 for Wayland seems to be related. But this is happening in Xorg session too.
Created attachment 1864526 [details] KWrite in Wayland session
Created attachment 1864527 [details] KWrite in Xorg session
Created attachment 1864528 [details] TeXworks in Wayland session
Created attachment 1864529 [details] TeXworks in Xorg session
The X11 case works fine in a VM. It turns out to be happening only when the DPI scaling factor is not 1. With bare metal install on my machine GNOME selects 200% scaling automatically. I found that this was already reported at https://github.com/ibus/ibus/issues/2221 and a patch was proposed there but not merged. That patch indeed fixes this issue in my testing. According to the suggestion by the maintainer there, I reported the bug to Qt at https://bugreports.qt.io/browse/QTBUG-103393. The Wayland case, however, is still not working regardless of scaling factor, with F36 final release and updates. Is there any more information needed to identify the issue?
I think you should not mention Xorg and Wayland issues are same. I cannot reproduce your DPI issue in Xorg but since you have the patch, why don't you report your patch? Built qtbase from git: https://wiki.qt.io/Building_Qt_5_from_Git Push your patch to Gerrit: https://wiki.qt.io/Setting_up_Gerrit https://wiki.qt.io/Gerrit_Introduction You can describe QTBUG-103393 in your patch. Since we already have the Wayland issue in rhbz #2060988, this bug can be closed after you report your patch to upstream.
Thank you for your response. Since you cannot reproduce the issue, I wonder if it is just configuration issues on my side before trying to report the patch. Here are the complete detailed steps to reproduce the problem: 1. Boot Fedora-Workstation-Live-x86_64-36-1.5.iso or Fedora-Workstation-Live-x86_64-Rawhide-20220806.n.0.iso in GNOME Boxes. (VMware also works.) 2. Open GNOME Settings, in the Users panel add a password to "Live System User". (This step is only needed such that Xorg session can be chosen from GDM.) 3. Log out to go back to GDM, click "Live System User", click the cogwheel button and choose "GNOME on Xorg", and log in again. 4. Open GNOME Settings, Displays panel, select 3840x2160 (16:9) for Resolution, and then select 200% for Scale, click "Apply" and then "Keep Changes". 5. In GNOME Settings, go to Keyboard panel, click the + button under "Input Sources" and add "Chinese (China)" -- "Chinese (Intelligent Pinyin)". 6. Install some Qt application: open Terminal and run "sudo dnf install kwrite". 7. Log out and log in again. 8. Open KWrite, click the blank input area, switch IME to "Chinese (Intelligent Pinyin)" by pressing Super+Space. 9. Type anything on the keyboard, for example "a", and find that the IBus window appears at a wrong position. Is there any step you would do differently so that the IBus window would be positioned correctly? This issue currently occurs for Fedora 36 Live ISO, up-to-date Fedora 36 install, and also Rawhide. The package versions on rawhide is: ibus-1.5.26-15.fc37.x86_64 ibus-libpinyin-1.12.91-2.fc37.x86_64 qt5-qtbase-common-5.15.5-3.fc37.noarch
Created attachment 1904243 [details] kwrite in 3840x2160 200% GNOME Xorg (In reply to vtq from comment #7) > Thank you for your response. Since you cannot reproduce the issue, I wonder > if it is just configuration issues on my side before trying to report the > patch. > > Here are the complete detailed steps to reproduce the problem: > > Is there any step you would do differently so that the IBus window would be > positioned correctly? I cannot reproduce your problem in GNOME Xorg. I tried your patch and the inputWindow->devicePixelRatio() == 1. Are you able to find any problems in my screenshot? > > This issue currently occurs for Fedora 36 Live ISO, up-to-date Fedora 36 > install, and also Rawhide. The package versions on rawhide is: > ibus-1.5.26-15.fc37.x86_64 > ibus-libpinyin-1.12.91-2.fc37.x86_64 > qt5-qtbase-common-5.15.5-3.fc37.noarch I have a dependency problem and cannot update qt5-qtbase-5.15.3-2.fc36.x86_64 to qt5-qtbase-5.15.5-3.fc37 but I assume it would not effect this issue.
Created attachment 1904412 [details] comparison of kwrite window at 200% scaling > Are you able to find any problems in my screenshot? I tried to create a screenshot and put it side-by-side with yours. From what I can tell, the KWrite window in your screenshot (on the left) is not actually scaled to 200%. For example, if you look at the text in the KWrite window or its titlebar, it's much smaller than text in the GNOME Shell top bar or the IBus window. In my screenshot (on the right), text in the KWrite UI is correctly at 200%, and the text is about the same size as in GNOME Shell and IBus. It seems something is preventing the KWrite window from scaling on your side but I'm not sure what it could have been. On my Fedora 36 install and also VM running Live ISO, it automatically respects the scale in GNOME Settings, which I think is the expected behavior. > I have a dependency problem and cannot update qt5-qtbase-5.15.3-2.fc36.x86_64 to qt5-qtbase-5.15.5-3.fc37 but I assume it would not effect this issue. Doesn't look like it matters. I tried to downgrade my Fedora 36 install to qt5-qtbase-5.15.3-2.fc36.x86_64 and it's not different.
Upstream Qt developer made patches for this issue: https://codereview.qt-project.org/c/qt/qtbase/+/445920 https://codereview.qt-project.org/c/qt/qtbase/+/447069 I tested the patches over Qt 6.4 branch (there's 5.15 cherry-pick too but it seems to be private right now). They actually fixed both Xorg and Wayland, and now the window shows up at the correct position in both cases. When Qt versions 5.15.3 and 6.4.3 are released and arrive in Fedora this issue would be fixed. And I think this bug report can be closed, perhaps #2060988 too.
(In reply to vtq from comment #10) > Upstream Qt developer made patches for this issue: > https://codereview.qt-project.org/c/qt/qtbase/+/445920 > https://codereview.qt-project.org/c/qt/qtbase/+/447069 > > I tested the patches over Qt 6.4 branch (there's 5.15 cherry-pick too but it > seems to be private right now). They actually fixed both Xorg and Wayland, > and now the window shows up at the correct position in both cases. > > When Qt versions 5.15.3 and 6.4.3 are released and arrive in Fedora this > issue would be fixed. And I think this bug report can be closed, perhaps > #2060988 too. LGTM.
This message is a reminder that Fedora Linux 36 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '36'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 36 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
(In reply to vtq from comment #10) > When Qt versions 5.15.3 and 6.4.3 are released and arrive in Fedora this > issue would be fixed. And I think this bug report can be closed, perhaps > #2060988 too. Regarding to this comment, marking the fix is available. qt5-qtbase-5.15.9-1.fc37 is available. https://bodhi.fedoraproject.org/updates/FEDORA-2023-e78d433635
Sorry, I actually meant to say 5.15.13 and that was a typo. 5.15.13 will likely be open-sourced next March, in time for Fedora 40, unless someone wants to backport this https://invent.kde.org/qt/backports-tracker/-/issues/2231. I don't mind this bug report being closed though.
(In reply to vtq from comment #14) > Sorry, I actually meant to say 5.15.13 and that was a typo. 5.15.13 will > likely be open-sourced next March, in time for Fedora 40, unless someone > wants to backport this > https://invent.kde.org/qt/backports-tracker/-/issues/2231. I don't mind this > bug report being closed though. it was backported and included in rawhide