Description of problem: Qt-5 applications linked with EPEL-6/7 qt5-qtbase-5.5.1-2 running under Xvnc from tigervnc won't respond to non-US keyboard button presses. Pressing for instance a danish special character (æ, ø, å) while a QLine is focused doesn't result in any characters being displayed Version-Release number of selected component (if applicable): qt5-qtbase-gui-5.5.1-2.el6.x86_64 qt5-qtbase-gui-5.5.1-2.el7.x86_64 How reproducible: Always Steps to Reproduce: 1. Configure the local keyboard for danish and test that you can make e.g æ, ø or å in a local application 2. Start Xvnc server: Xvnc :5 -SecurityTypes None -ac & 3. Start window-manager (to make sure it's absence doesn't cause problems): DISPLAY=:5 metacity & 4. Connect to server with vncviewer: vncviewer localhost:5 & 5. Start qt-5 application under the Xvnc server, for example qdbusviewer-qt5: DISPLAY=:5 qdbusviewer-qt5 & 6. In the vncviewer window focus the search field (QLineEdit) in the qdbusviewer and press some US and non-US keys on the keyboard Actual results: 1. You can write danish characters with danish keyboard 2. Xvnc server starts in the background 3. metacity window manager starts in the background 4. vncviewer starts and shows an empty black window 5. qdbusviewer-qt5 appears inside the vncviewer window 6. only the US keyboard keys result in text appearing in the qdbusviewer-qt5 search field. Nothing happens for the non-US key strokes. Expected results: 6. Both US and non-US keystrokes should work Additional info: The vncserver starts with a basic US-keyboard layout. When it receives an RFB KeyEvent with a keysym that is not in the keyboard layout it adds that keysym to the keymap under a free keycode. When it does this it prints a message like this to the Xvnc log (stderr by default): Input: Added unknown keysym 0xe6 to keycode 255 When it does this it alerts the applications via X events. My guess is that qt5-qtbase-gui-5.5.1-2.el{6,7} fail to respond to these keymap updates and then later ignore events for those keypresses, because the keycodes in the X key events are not in the keymap it has. on RHEL7 I can make qt5-qtbase-gui-5.5.1-2.el7 work simply by rebuilding it from source. I am not sure why this is, but my guess is that the Qt configure script auto-detection makes different decisions based on the package set that I have installed compared to the package set that was installed when qt5-qtbase-gui-5.5.1-2.el7 was build for EPEL7. On RHEL6 I can not make it work, just by rebuilding qt5-qtbase-gui-5.5.1-2.el6 from source. On RHEL6 I notice the that during rpm-build the Qt configure script reports this: XCB .................. yes (system library) EGL on X ........... no GLX ................ yes MIT-SHM ............ yes Xcb-Xlib ........... yes Xcursor ............ yes (loaded at runtime) Xfixes ............. yes (loaded at runtime) Xi ................. no Xi2 ................ yes Xinerama ........... yes (loaded at runtime) Xrandr ............. yes (loaded at runtime) Xrender ............ yes XKB ................ no XShape ............. yes XSync .............. yes XVideo ............. yes So I tried to rebuild qt5-qtbase-gui-5.5.1-2 on RHEL6 with a small patch to use the Qt distributed version of XCB and xkbcommon, ie use the switches -qt-xcb and -qt-xkbcommon-x11. This fixes the problem.
Created attachment 1111842 [details] Patch to use -qt-xcb on RHEL 6 With this patch the keyboard works correctly under VNC on RHEL 6.
Thomas, i'm working on it.
The problem does not reproduce under Fedora 23.
thomas, could you please try this build and let me know if the issue is fixed? Thanks
http://koji.fedoraproject.org/koji/taskinfo?taskID=12563746
correct build http://koji.fedoraproject.org/koji/buildinfo?buildID=711539
The build linked in comment 6 works on RHEL7. I have also tested the following build on RHEL6: http://koji.fedoraproject.org/koji/buildinfo?buildID=711549 It also works, ie the issue as described in comment 0 no longer reproduces. Thanks a lot for fixing this so quickly. When can I expect to see this released?
thanks for your feedback. I will push it into epel7 update today
and epel6?
qt5-qtbase-5.5.1-11.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-62ce5a7b3f
qt5-qtbase-5.5.1-11.el6 has been submitted as an update to Fedora EPEL 6. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-958a02c40c
qt5-qtbase-5.5.1-11.el6 has been pushed to the Fedora EPEL 6 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-958a02c40c
qt5-qtbase-5.5.1-11.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-62ce5a7b3f
qt5-qtbase-5.5.1-11.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.
qt5-qtbase-5.5.1-11.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.