Maybe they did, couldn't say. my use case probably won't be a popular one but i'll run it through it anyway. My setup might not even be optimal so I am happy to consider advice.
This was a finding while I was investigating why Zoom started crashing after the whiteboard update (only if the whiteboard was open, and it was only for me). I've been using Zoom within x2go XFCE sessions since 2020 without issue, (recommended or not) it works fine for daily use imo. I could rollback Zoom to 5.9.x series and it was/is fine. Unfortunately due to a vuln in the xmpp chat protocol implementation of Zoom min versions needed to be enforced at 5.10.x series which has the new whiteboard implementation.
Additional to updating Zoom I'd inplace upgraded the x2go endpoint OS from 20.04 (x2go glx working, mesa 21) to 22.04 (x2go glx broken, mesa 22) while on Zoom 5.9.x series client and only noticed some slight performance degradation in general session use but hadn't bothered to investigate it, I expect (now) it is related to the lack of glx.
Zoom will not start without the glx extension, and using LIBGL_INDIRECT_ALWAYS is problematic (slow) as were some other envars I was testing which broke a lot of additional stuff. I don't have my notes with me now though.
sai
On Sat, Jun 4, 2022 at 7:08 PM Ulrich Sibiller <uli42@gmx.de> wrote:
Maybe glxinfo simply dropped support for old versions of glx.
Running gl applications over NX is not recommend es because it will be slow. So I am wondering what you need it for.
If it is for some program that just requires glxinfo to not return an error you can test what happens when the glx extension is disabled in NX. You can configure that in /etc/x2go/x2goagent.conf ( not sure about the exact name, but it is similar)
Uli
Norman Gaywood <ngaywood@une.edu.au> schrieb am Sa., 4. Juni 2022, 07:13:
Thanks Sai,
Glad someone else is seeing this :-) I've reported a bug in the Fedora bugzilla. Hopefully this gets to the right developers.
https://bugzilla.redhat.com/show_bug.cgi?id=2093528
On Sat, 4 Jun 2022 at 14:50, sairuk <sairuk@gmail.com> wrote:
Hi Norman,
I've run into similar issues after an upgrade to Ubuntu 22.04 on one of my machines which is now Mesa 22, i've been trying to investigate further this morning to no avail, thanks for the workaround on Fedora, good to at least understand a potential cause.
I setup a separate vm today with a fresh 22.04+x2go and the issue is repeatable, so I had a test space
I'll have to look at downgrading, although I don't know offhand how reasonable that is in debian land, time to go have a play
(meant to reply to all, sorry for the dupe email Norman)
sai
On Sat, Jun 4, 2022 at 2:25 PM Norman Gaywood <ngaywood@une.edu.au> wrote:
OK, further downgrades gets glxinfo to work again.
On my test F36 system I downloaded F35 mesa* and libglvnd* packages and did: dnf downgrade ./mesa*rpm ./libglv*.rpm
Which resulted in the packages listed below to be downgraded. After that, glxinfo and glxgears work again.
So, a bug in mesa 22?
libglvnd-1:1.3.4-2.fc35.i686 libglvnd-1:1.3.4-2.fc35.x86_64 libglvnd-core-devel-1:1.3.4-2.fc35.x86_64 libglvnd-devel-1:1.3.4-2.fc35.x86_64 libglvnd-egl-1:1.3.4-2.fc35.x86_64 libglvnd-gles-1:1.3.4-2.fc35.x86_64 libglvnd-glx-1:1.3.4-2.fc35.i686 libglvnd-glx-1:1.3.4-2.fc35.x86_64 libglvnd-opengl-1:1.3.4-2.fc35.x86_64 mesa-dri-drivers-21.3.8-2.fc35.i686 mesa-dri-drivers-21.3.8-2.fc35.x86_64 mesa-filesystem-21.3.8-2.fc35.i686 mesa-filesystem-21.3.8-2.fc35.x86_64 mesa-libEGL-21.3.8-2.fc35.x86_64 mesa-libEGL-devel-21.3.8-2.fc35.x86_64 mesa-libgbm-21.3.8-2.fc35.i686 mesa-libgbm-21.3.8-2.fc35.x86_64 mesa-libGL-21.3.8-2.fc35.i686 mesa-libGL-21.3.8-2.fc35.x86_64 mesa-libglapi-21.3.8-2.fc35.i686 mesa-libglapi-21.3.8-2.fc35.x86_64 mesa-libGL-devel-21.3.8-2.fc35.x86_64 mesa-libGLU-9.0.1-5.fc35.i686 mesa-libGLU-9.0.1-5.fc35.x86_64 mesa-libOpenCL-21.3.8-2.fc35.i686 mesa-libOpenCL-21.3.8-2.fc35.x86_64 mesa-libOSMesa-21.3.8-2.fc35.x86_64 mesa-libxatracker-21.3.8-2.fc35.x86_64 mesa-vulkan-drivers-21.3.8-2.fc35.i686 mesa-vulkan-drivers-21.3.8-2.fc35.x86_64
On Sat, 4 Jun 2022 at 11:15, Norman Gaywood <ngaywood@une.edu.au> wrote:
On Fedora 36 we have: libglvnd-1.4.0-2.fc36.x86_64 libglvnd-glx-1.4.0-2.fc36.x86_64
On Fedora 35: libglvnd-1.3.4-2.fc35.x86_64 libglvnd-glx-1.3.4-2.fc35.x86_64
I managed to download the libglvnd* packages for F35, and on an F36 system, I downgraded: dnf downgrade ./libglvnd* ./glx-utils* and rebooted.
So now on my F36 system I have: libglvnd-1.3.4-2.fc35.x86_64 libglvnd-glx-1.3.4-2.fc35.x86_64
(I've trimmed the package lists in the above, there are more libglvnd* installed/downgraded).
And the same behaviour occurs: $ glxinfo name of display: :50.0 X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 17 (X_GLXVendorPrivateWithReply) Serial number of failed request: 27 Current serial number in output stream: 27
So this suggests it's not the upgrade from 1.3 to 1.4 of libglvnd-glx ???
glxinfo is part of the glx-utils package, which I also downgraded. But they have the same version number: glx-utils-8.4.0-12.20210504git0f9e7d9.fc35.x86_64 glx-utils-8.4.0-13.20210504git0f9e7d9.fc36.x86_64
So, I'm not sure what to look at next.
On Fri, 3 Jun 2022 at 17:26, Ulrich Sibiller <uli42@gmx.de> wrote:
The version of x2goserver and x2goclient is irrelevant here. The GLX code is in nx-libs (nxagent/x2goagent). However, nothing has changed there in years, so I suggest to downgrade glxinfo and retry. Let me know the result.
Uli
On Fri, Jun 3, 2022 at 1:51 AM Norman Gaywood <ngaywood@une.edu.au> wrote: > > In Fedora 35 glxinfo (and glxgears) worked fine with x2goserver-4.1.0.3-17.fc35.x86_64 > > After updating to Fedora 36, x2goserver-4.1.0.3-17.fc36.x86_64, glxinfo no longer works. > $ glxinfo > name of display: :50.0 > X Error of failed request: GLXUnsupportedPrivateRequest > Major opcode of failed request: 143 (GLX) > Minor opcode of failed request: 17 (X_GLXVendorPrivateWithReply) > Serial number of failed request: 27 > Current serial number in output stream: 27 > > Linux x2goclient X2Go Client v. 4.1.2.2 (Qt - 5.15.3) > > Is there any way to make this work? Not sure what programs actually use it. > Thankfully matlab still seems to work. > -- > Norman Gaywood, Computer Systems Officer > School of Science and Technology > University of New England > Armidale NSW 2351, Australia > > ngaywood@une.edu.au http://turing.une.edu.au/~ngaywood > Phone: +61 (0)2 6773 2412 Mobile: +61 (0)4 7862 0062 > > Please avoid sending me Word or Power Point attachments. > See http://www.gnu.org/philosophy/no-word-attachments.html > _______________________________________________ > x2go-user mailing list > x2go-user@lists.x2go.org > https://lists.x2go.org/listinfo/x2go-user
-- Norman Gaywood, Computer Systems Officer School of Science and Technology University of New England Armidale NSW 2351, Australia
ngaywood@une.edu.au http://turing.une.edu.au/~ngaywood Phone: +61 (0)2 6773 2412 Mobile: +61 (0)4 7862 0062
Please avoid sending me Word or Power Point attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
-- Norman Gaywood, Computer Systems Officer School of Science and Technology University of New England Armidale NSW 2351, Australia
ngaywood@une.edu.au http://turing.une.edu.au/~ngaywood Phone: +61 (0)2 6773 2412 Mobile: +61 (0)4 7862 0062
Please avoid sending me Word or Power Point attachments. See http://www.gnu.org/philosophy/no-word-attachments.html
x2go-user mailing list x2go-user@lists.x2go.org https://lists.x2go.org/listinfo/x2go-user
-- Norman Gaywood, Computer Systems Officer School of Science and Technology University of New England Armidale NSW 2351, Australia
ngaywood@une.edu.au http://turing.une.edu.au/~ngaywood Phone: +61 (0)2 6773 2412 Mobile: +61 (0)4 7862 0062
Please avoid sending me Word or Power Point attachments. See http://www.gnu.org/philosophy/no-word-attachments.html