Important: Please read the Qt Code of Conduct -

Get Startup Error on multiple systems with SSH, QT5 and RHEL 8

  • Folks,

    I have seen multiple apps build with QT5 on RHEL 8 systems showing the sample warning errors at launch (but the apps all appear to work), when being launched from a remote terminal window.

    In my office, its a RHEL 8.2 system with QT 5.12.5, all installed from Redhat provided RPMS. There are 2 apps I will call out in particular. One was built on the system, and the other was one of the provided example apps (I expect all other example apps to behave the same way). Then they start I see the following :

    qt.qpa.xcb: failed to initialize XRandr
    qt.qpa.xcb: X server does not support XInput 2
    qt.qpa.xcb: QXcbConnection: XCB error: 1 (BadRequest), sequence 166, resource id: 87, major code: 131 (Unknown), minor code: 47

    I also have a version of QT 4.8.7 that I build from source on the same system. When I run the same example program, I do not get those errors. (The example in question is multimedia/audiooutput). I am accessing the RHEL 8 workstation via SSH from a RHEL 6.10 system. When I directly accessed the RHEL 8 workstation, I did not get the issue, but a different issue.

    In the other office I work in, we have a RHEL 8 system with QT 5.15 installed, again from Redhat RPMs. When I build one of the example programs over there, I saw a similar set of errors. In this case I accessed the system using MobaXTerm on a Windows platform.

    So it looks like some interaction between QT 5, RHEL 8, and using SSH access. I would like to figure out why and stop it, as if this was code going to a customer, it would look rather bad.

    Dale Pennington

  • The days of exporting X11 displays are pretty much over. Too many local server specific you've discovered. Trying to run a remote X program on your local display will be very hit-or-miss, based on the app and how your local X server is configured.

    I'm assuming you are trying to run remote X11 apps over ssh -X remoteHost connections so that the display ends up being DISPLAY=localhost:10.0

    Make sure the needed extensions listed above are installed and correctly configured on the local display X server.

Log in to reply