Description of problem:
It is not possible to use Kate over ssh X forwarding. Other apps like emacs and gedit work fine.
Version-Release number of selected component (if applicable):
Every single time.
Steps to Reproduce:
1. Ssh into a remote fedora 23 install using ssh -Y username@machinename
2. Run kate
3. No error messages shown, no application comes up
Kate does not come up, no error messages are shown, kate command keeps running in shell until you interrupt it with Ctrl-c. Running kate under a debugger and then hitting Ctrl-C reveals the following backtrace
0 0x00007ffff21e4fdd in poll () at /lib64/libc.so.6
#1 0x00007fffef6a3272 in _xcb_conn_wait () at /lib64/libxcb.so.1
#2 0x00007fffef6a4c27 in wait_for_reply () at /lib64/libxcb.so.1
#3 0x00007fffef6a4d31 in xcb_wait_for_reply () at /lib64/libxcb.so.1
#4 0x00007fffee8b02c5 in loader_dri3_open () at /lib64/libGL.so.1
#5 0x00007fffee8ab0b8 in dri3_create_screen () at /lib64/libGL.so.1
#6 0x00007fffee87f9b1 in __glXInitialize () at /lib64/libGL.so.1
#7 0x00007fffee87b7d7 in glXGetFBConfigs () at /lib64/libGL.so.1
#8 0x00007fffee87ca92 in glXChooseFBConfigSGIX () at /lib64/libGL.so.1
#9 0x00007fffdd3c3115 in qglx_findConfig(_XDisplay*, int, QSurfaceFormat const&, int) ()
#10 0x00007fffdd3c334d in qglx_findVisualInfo(_XDisplay*, int, QSurfaceFormat*) () at /usr/lib64/qt5/plugins/xcbglintegrations/libqxcb-glx-integration.so
Kate running normally
Just wrote a small standalone qt5 example as a repro and that fails to run over SSH forwarding as well. I then compiled a local version of qt 5.6 and compiled it with opengl disabled. Hello world example linked against the version of qt with opengl disabled works fine over X11 forwarding.
Is there some way to select the "backend" that qt in fedora will be using at runtime? If possible I would like to run Kate without the opengl backend in play to see if that works unmodified over X11 forwarding.
This is an xorg/server issue when dri3 is enabled, lemme see if I can dig up the existing open bug (with workarounds)...
can't find it right now, will dig more later today
ah, it's currently assigned against mesa, see bug #1174257
*** This bug has been marked as a duplicate of bug 1174257 ***
See also workarounds at:
Thanks for the pointers to the workaround.