Sstrhsrtj

I'm building a Qt application using QML technologie. QML use OpenGL.

The computer running the build is a CentOS 6.7, with intel GPU.
I'm using it only on SSH, and I use XMing (or VcxSrv sometimes) to open graphical applications.

I had multiple trouble to make it works but by googling my problems and playing with xauth I can now remotly open my QML application.

BUT

When running my application with a normal user I get :

KiTTY X11 proxy: Unsupported authorisation protocol
QXcbConnection: Could not connect to display localhost:10.0

I noticed that the error message say Unsupported (a lot of SO question are about Wrong protocol)

AND

I can only open it in root (sudo does't work here, I need to su), and I got multiple errors :

failed to get the current screen resources
WARNING: Application /home/user/QMLapp/app calling GLX 1.3 function "glXCreatePbuffer" when GLX 1.3 is not supported! This is an application bug!
QXcbConnection: XCB error: 170 (Unknown), sequence: 163, resource id: 90, major code: 146 (Unknown), minor code: 20

Note :
glxinfo seems fine and direct rendering is activated.
glxgeers works fine too and don't need to be root to work

First question : Can I easily upgrade my GLX ?
Second question : Why it only works in root ?

QXcbConnection: Could not connect to display localhost:10.0

The error above may contain some clues. It means that, for this user, the variable $DISPLAY is set to localhost:10.0

After you su to root, you can check the variable again with echo $DISPLAY. then change the value of the variable for the normal user accordingly.

Correct value is probably localhost:0.0

The DISPLAY value of localhost:10.0 indicates you're on a SSH-forwarded X11 connection, as you stated in the question. If you change the DISPLAY to :0.0, then you're saying you want the program to present its windows on the screen that is directly attached to the remote computer... and if you're not physically near it, that isn't going to be very useful.

Direct rendering would require that the GUI application have direct access to the actual GPU that draws to your screen... which is of course impossible when the screen and the application are not in the same host.

It looks like this application might be designed to be used only locally. If it cannot gracefully fall back to indirect rendering, it cannot be used over a remote X11 connection: direct rendering requires that the GPU that will actually do the drawing should be in the same computer as the application, and not separated from it by a network connection.

If you're using a remote X11 connection with Xming or VcXsrv, then your OpenGL support levels depends primarily on what OpenGL levels your Xming or VcXsrv will support. Of course the remote computer also needs the appropriate OpenGL libraries present, but usually the package manager or the application installer takes care of that.

When you're running it as a regular user, are you running as the user you logged in your X11-forwarding SSH connection, or have you switched to another user account on the remote host after logging in?

Switching user accounts while preserving X11 forwarding requires a bit of extra effort: not only must you ensure that the value of the DISPLAY variable is preserved, you must also make sure the target user has access to the contents of the ~/.Xauthority file of the source user. You can copy the ~/.Xauthority file to some other location (e.g. into /tmp) and then use the XAUTHORITY environment variable to point to it.

For example:

<logged in to remote host as user1, with X11 forwarding>

user1$ echo $DISPLAY

localhost:10.0

user1$ cp ~/.Xauthority /tmp/user1.Xauthority

user1$ chgrp user2 /tmp/user1.Xauthority

user1$ chmod 640 /tmp/user1.Xauthority

user1$ sudo -u user2 -i

user2$ export DISPLAY=localhost:10.0

user2$ export XAUTHORITY=/tmp/user1.Xauthority

<now running a X11 GUI application should be possible>

This can be often avoided when you're switching from regular user to root, since root can read everyone's files... including the ~/.Xauthority file. So when switching from user1 to root the only things that need to be done is to maintain the DISPLAY value and point XAUTHORITY to /home/user1/.Xauthority. Some Linux distributions include scripts or PAM modules that do this for you automatically when switching from a regular user to root.