Ok, I'll check again and update the docs.
Uli
On Thu, Jan 23, 2020 at 3:24 PM Tristan Miller <psychonaut@nothingisreal.com> wrote:
Dear Uli,
On Thu, 23 Jan 2020 13:45:46 +0100, Ulrich Sibiller <ulrich.sibiller@gmail.com> wrote:
On Thu, Jan 23, 2020 at 1:07 PM Tristan Miller <psychonaut@nothingisreal.com> wrote:
Some tips: Konsole: set QT_GRAPHICSSYSTEM=native and switch to Xlib rendering in KDE. I am using it daily this way!
By "switch to Xlib rendering in KDE", do you mean configuring KDE on the remote host to use XRender instead of OpenGL? If so, this workaround does nothing for me.
Yes, there's a config option kde settings (Desktop effects/Advanced). You should set the compositign type to "Xrender" and the Qt graphics system to native. Sometimes KDE does not accept changing the values or changes them back at next start. In that case you have to set them manually in the config file (without kde running):
/.kde/share/config/kwinrc in dection [Compositing] add/adapt to Backend=XRender.
Well, that's what I had been doing (though I didn't need to manually edit the config file as KDE remembered the setting). Konsole rendering is as slow as ever.
emacs: I am not aware of any crashing issues althought I am using it daily. Can you provide any more details?
The problem and workaround are described in the "Emacs crashes on start" thread on the X2Go-User list. See for example here: <https://lists.x2go.org/pipermail/x2go-user/2017-September/004524.html>
What? I had the impression that this bug is long gone!
That's news to me; none of the myriad bug reports filed about this issue have ever been marked as resolved:
https://bugzilla.gnome.org/show_bug.cgi?id=85715 https://gitlab.gnome.org/GNOME/gtk/issues/221 https://bugzilla.redhat.com/show_bug.cgi?id=1349412 https://bugzilla.suse.com/show_bug.cgi?id=1007912
I tried running Emacs over X2Go just now, without the EMACS_TOOLKIT=x11 workaround, and so far it seems to work fine. So I guess you are right that the bug has since been fixed. If so, maybe you are the only one who ever noticed this and everyone else, like me, is continuing to use one of the workarounds. :)
GLX: are you aware of this workaround?: https://wiki.x2go.org/doku.php/wiki:development:glx-xlib-workaround
Yes. Those instructions are out of date (Mesa wants to be compiled with meson, not scons). I tried adapting them and was able to compile the libraries, but after adding their location to LD_LIBRARY_PATH, glxinfo still reports the version to be 1.2. However, quite possibly I've done something wrong with the build. I can provide further information here or on X2go-User if you're interested.
I have done it successfully ~1 year ago using this document: https://mesa3d.org/llvmpipe.html
Those instructions don't work for me. Specifically, they fail when meson is invoked to build the library:
$ meson -D glx=gallium-xlib -D gallium-drivers=swrast The Meson build system Version: 0.51.2 Source dir: /home/psy/src/mesa-19.3.2 Build dir: /home/psy/src/mesa-19.3.2/build Build type: native build Program python found: YES (/usr/bin/python) Project name: mesa Project version: 19.3.2 Appending CFLAGS from environment: '-march=native' Appending CPPFLAGS from environment: '-march=native' Appending CPPFLAGS from environment: '-march=native' Appending CFLAGS from environment: '-march=native' Appending CPPFLAGS from environment: '-march=native' C compiler for the host machine: ccache cc (gcc 9.2.1 "cc (SUSE Linux) 9.2.1 20200109 [gcc-9-branch revision 280039]") Appending CPPFLAGS from environment: '-march=native' C++ compiler for the host machine: ccache c++ (gcc 9.2.1 "c++ (SUSE Linux) 9.2.1 20200109 [gcc-9-branch revision 280039]") Build machine cpu family: x86_64 Build machine cpu: x86_64
meson.build:403:6: ERROR: Problem encountered: gallium-xlib conflicts with any dri driver
I tried forcing the build using scons instead, and the library gets built, but once again, putting the library directory in LD_LIBRARY_PATH still results in glxinfo reporting GLX version 1.2.
Regards, Tristan
--
Tristan MillerFree Software developer, ferret herder, logologist https://logological.org/
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev