Created attachment 585508 [details, diff] Workaround for broken input mask handling in qxcbconnection_xi2.cpp Qt5 uses libxcb to set up input masks for XInput2. However, it does not follow the correct format for an input mask. Because of this Qt will not get all the events it wants resulting in the mouse wheel not being handled. How to reproduce: 1) Run a Qt5 application on any big endian system supporting XInput 2) Try to use the mouse wheel Actual behaviour: * No mouse wheel events are sent to the application Expected behaviour: * Mouse wheel events are sent to the application Details: Input masks in XInput2 are arrays of bytes. Xlib provides convenience macros XISetMask(), XIClearMask() and XIMaskIsSet() for finding the correct byte in case the event number is 8 or larger. However, Qt does not set up an array of bytes but rather a single 32-bit integer, and assumes that as long as all events have numbers smaller than 32 it can just set the corresponding bit in the 32-bit integer. This happens to work on little endian since the byte order on LE matches the hard-coded byte order of the input masks in XInput2. However, it does not work on big endian where the byte order differs. In my proposed patch, I did not rewrite the code to use an array of bytes but simply added a conversion to little endian of the 32-bit integer, which solves the immediate issue.
Has this been reported upstream? I see no signs of that commit even in current upstream dev branch.
Created attachment 793985 [details, diff] Patch to fix non-working menu mouse grab on big endian With 5.15.5, there is an additional place where the swapping needs to happen. Without this, mouse events will not be handled during menu grabs unless the environment variable QT_XCB_NO_XI2_MOUSE is set. This makes it impossible to select entries in the menus using the mouse (keyboard selection still works).
Please submit your patches upstream: https://codereview.qt-project.org/q/status:open+-is:wip Once it has landed in dev branch, we can try and cherry-pick it back to kde/5.15 branch as part of Qt5PatchCollection: https://invent.kde.org/
(In reply to Andreas Sturmlechner from comment #3) > Please submit your patches upstream: > https://codereview.qt-project.org/q/status:open+-is:wip > > Once it has landed in dev branch, we can try and cherry-pick I wouldn't hold my breath for that happening - the last bug I reported, complete with patch, ( https://bugreports.qt.io/browse/QTBUG-82599 ) has just been sitting there for over two years...
But if it makes you happier I created an issue in the new upstreams tracker. https://bugreports.qt.io/browse/QTBUG-105157 (I may or may not have created an issue in their old tracker back in 2019, honestly don't remember anymore.) Pushing the patch directly to https://codereview.qt-project.org/ as you seem to suggest did not work, I got this error message: ---8<--- remote: error: branch refs/for/5.15: remote: You need 'Create Change' rights to upload code review requests. remote: Verify that you are pushing to the right branch. remote: User: marcus_c remote: Contact an administrator to fix the permissions ---8<---
You need to target dev branch, which is Qt6 for quite some time already. (In reply to Marcus Comstedt from comment #4) > I wouldn't hold my breath for that happening - the last bug I reported, > complete with patch, ( https://bugreports.qt.io/browse/QTBUG-82599 ) has > just been sitting there for over two years... In fact, codereview told you the same in May '20: "This repo has moved to cherry-pick mode. As such, this change will no longer be merged up to dev." Which means that your codereview will be ignored until it is rebased onto dev branch, which hopefully works without too many changes. The codereview then would hopefully get a Pick-To: 5.15 notice, but we can try to get it backported to kde/5.15 even without that.
(In reply to Andreas Sturmlechner from comment #6) > rebased onto dev branch, which hopefully works without too many changes. ...and if the code there looks basically the same, it would be reasonable to assume Qt6 is still affected, which should get upstream interested.
(In reply to Andreas Sturmlechner from comment #6) > You need to target dev branch, which is Qt6 for quite some time already. In Qt6 this file has been modified so that the patch no longer applies. And if I modify it so that it does apply, it's not going to apply to 5.15.5 anymore, so you can't cherry pick it. I think I'll leave it at this. I have informed all relevant parties what the bug is and how to fix it, and in case someone searches for a solution they will hopefully find this Gentoo issues so that they can drop the fix into their /etc/portage/patches/ and get on with their lives...
Actually, on closer inspection the bug _is fixed_ in Qt6 (in the more ambitious way of using actual byte arrays). So for that reason pushing the hotfix for 5.15.5 to dev is not practical.
Upstreams fix in Qt6: https://codereview.qt-project.org/c/qt/qtbase/+/349848
(In reply to Marcus Comstedt from comment #10) > Upstreams fix in Qt6: > > https://codereview.qt-project.org/c/qt/qtbase/+/349848 Excellent. Given there's a proper fix in Qt 6, we may be able to get your one backported to Qt 5.15, given the Qt 6 fix is far larger.
(In reply to Marcus Comstedt from comment #10) > Upstreams fix in Qt6: > > https://codereview.qt-project.org/c/qt/qtbase/+/349848 Does it apply (half-)cleanly against 5.15.5 and could you test it? I mean you would be the obvious person to check. Then I could suggest it to KDE. (In reply to Marcus Comstedt from comment #8) > And if I modify it so that it does apply, it's not going to apply to 5.15.5 > anymore, so you can't cherry pick it. Ah, but then we would have already had your working version attached here, right? ;) Yes, cherry-picking from dev branch sometimes means fixing conflicts.
(In reply to Andreas Sturmlechner from comment #12) > (In reply to Marcus Comstedt from comment #10) > > Upstreams fix in Qt6: > > > > https://codereview.qt-project.org/c/qt/qtbase/+/349848 > Does it apply (half-)cleanly against 5.15.5 and could you test it? I mean > you would be the obvious person to check. Then I could suggest it to KDE. Seems at least f6b149fffbe650cb37e8602f46a0b6a2db32fb60 would be a prerequisite.
(In reply to Andreas Sturmlechner from comment #13) > (In reply to Andreas Sturmlechner from comment #12) > > (In reply to Marcus Comstedt from comment #10) > > > Upstreams fix in Qt6: > > > > > > https://codereview.qt-project.org/c/qt/qtbase/+/349848 > > Does it apply (half-)cleanly against 5.15.5 and could you test it? I mean > > you would be the obvious person to check. Then I could suggest it to KDE. > Seems at least f6b149fffbe650cb37e8602f46a0b6a2db32fb60 would be a > prerequisite. Also, https://codereview.qt-project.org/gitweb?p=qt/qtbase.git;a=commit;h=4f99f87578a36d59448e4332a06cdb0c8556a37a removed a few calls to xcb_input_xi_select_events{,_checked} which therefore never got fixed.
(In reply to Marcus Comstedt from comment #4) > I wouldn't hold my breath for that happening - the last bug I reported, > complete with patch, ( https://bugreports.qt.io/browse/QTBUG-82599 ) has > just been sitting there for over two years... Same for this btw, if you rebase onto dev branch/Qt6 (path changed to src/opengl/qopengltextureblitter.cpp there) I promise to put it to KDE after upstream integration.
(In reply to Andreas Sturmlechner from comment #15) > (In reply to Marcus Comstedt from comment #4) > > I wouldn't hold my breath for that happening - the last bug I reported, > > complete with patch, ( https://bugreports.qt.io/browse/QTBUG-82599 ) has > > just been sitting there for over two years... > Same for this btw, if you rebase onto dev branch/Qt6 (path changed to > src/opengl/qopengltextureblitter.cpp there) I promise to put it to KDE after > upstream integration. Thanks, but Qt6 on dev branch does not use qopengltextureblitter.cpp anymore - 6.4 introduced a new thing called qbackingstoredefaultcompositor.cpp which is used instead. It had the same bug of course, so I have a new fix going here: https://codereview.qt-project.org/c/qt/qtbase/+/423499
If it is the same code just refactored, can still add "Pick-to: 5.15" and even make a comment about the proper fix for 5.15, makes it easier for us to argue for backporting to kde/5.15.
(In reply to Andreas Sturmlechner from comment #17) > If it is the same code just refactored, can still add "Pick-to: 5.15" and > even make a comment about the proper fix for 5.15, makes it easier for us to > argue for backporting to kde/5.15. * a comment inside git summary of course.
https://code.qt.io/cgit/qt/qtbase.git/commit/?id=d2fcccd3f1c5e3729c280a6f0a3e12dc9835477b landed upstream. Over to asturm, I think ;)
(In reply to Sam James from comment #19) > https://code.qt.io/cgit/qt/qtbase.git/commit/ > ?id=d2fcccd3f1c5e3729c280a6f0a3e12dc9835477b landed upstream. > > Over to asturm, I think ;) Oh, I'm not sure what the situation is for the original bug, actually. The swizzling is fixed now for 6.4 but I've no idea about the original mouse issue.
