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
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
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
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
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
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
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
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
sairuk wrote:
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.
If you just want to use zoom then use their web app instead of the native zoom app. I always do this with zoom, teams, etc. because the options for sharing are better in chrome than the native apps.
Thanks Neal, this is what I ended up doing as well for Zoom.
The Zoom issue led me to note the difference in behaviour after it started crashing, I want to be careful not to detract from the actual glx issue even if it turns out to be mesa related.
Unfortunately no movement on the bug Norman raised yet
sai
On Sun, Jun 12, 2022 at 12:28 AM Neal Becker <ndbecker2@gmail.com> wrote:
sairuk wrote:
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.
If you just want to use zoom then use their web app instead of the native zoom app. I always do this with zoom, teams, etc. because the options for sharing are better in chrome than the native apps.
x2go-user mailing list x2go-user@lists.x2go.org https://lists.x2go.org/listinfo/x2go-user
If I get that right GLX offers the X_GLXVendorPrivateWithReply request. This request knows 4 subcommands in NX:
__GLXdispatchVendorPrivProcPtr __glXVendorPrivTable_EXT[__GLX_MAX_VENDPRIV_OPCODE_EXT - __GLX_MIN_VENDPRIV_OPCODE_EXT + 1] = { __glXDisp_AreTexturesResidentEXT, /* 11 */ __glXDisp_DeleteTextures, /* 12 */ __glXDisp_GenTexturesEXT, /* 13 */ __glXDisp_IsTextureEXT, /* 14 */
So chances are that glxinfo is using another one. So probably our Mesa version 6.4.2 does not come with this/those additional subcommands.
I am wondering if we can tweak glxinfo to work nevertheless. Can you please try if LIBL_DEBUG=verbose glxinfo shows more information? Can you check the environment variables mentioned here: https://dri.freedesktop.org/wiki/TestingAndDebugging/? Does it make a difference if you call glxinfo with -i?
Uli
On Sun, Jun 12, 2022 at 1:01 AM sairuk <sairuk@gmail.com> wrote:
Thanks Neal, this is what I ended up doing as well for Zoom.
The Zoom issue led me to note the difference in behaviour after it started crashing, I want to be careful not to detract from the actual glx issue even if it turns out to be mesa related.
Unfortunately no movement on the bug Norman raised yet
sai
On Sun, Jun 12, 2022 at 12:28 AM Neal Becker <ndbecker2@gmail.com> wrote:
sairuk wrote:
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.
If you just want to use zoom then use their web app instead of the native zoom app. I always do this with zoom, teams, etc. because the options for sharing are better in chrome than the native apps.
x2go-user mailing list x2go-user@lists.x2go.org https://lists.x2go.org/listinfo/x2go-user
x2go-user mailing list x2go-user@lists.x2go.org https://lists.x2go.org/listinfo/x2go-user
I played with these a bit beforehand, both glxinfo -i and LIBGL_ALWAYS_INDIRECT=1 will product the same results for a glxinfo run
glxinfo -i results: https://termbin.com/hwu2
LIBGL_DEBUG=verbose output with or without -i it is the same additional output
name of display: :50.0 libGL: MESA-LOADER: dlopen(/usr/lib/x86_64-linux-gnu/dri/swrast_dri.so) libGL: Can't open configuration file /etc/drirc: No such file or directory. libGL: Can't open configuration file /home/user/.drirc: No such file or directory. libGL: Can't open configuration file /etc/drirc: No such file or directory. libGL: Can't open configuration file /home/user/.drirc: No such file or directory. 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
I also tried a few of the mesa envvars but I can't find my notes, so I'll have to go through them again although I do recall MESA_DEBUG not adding anything additional to this output and a couple of the others broke the output in weird and wonderful ways.
https://docs.mesa3d.org/envvars.html
sai
On Sun, Jun 12, 2022 at 11:00 PM Ulrich Sibiller <uli42@gmx.de> wrote:
If I get that right GLX offers the X_GLXVendorPrivateWithReply request. This request knows 4 subcommands in NX:
__GLXdispatchVendorPrivProcPtr __glXVendorPrivTable_EXT[__GLX_MAX_VENDPRIV_OPCODE_EXT - __GLX_MIN_VENDPRIV_OPCODE_EXT + 1] = { __glXDisp_AreTexturesResidentEXT, /* 11 */ __glXDisp_DeleteTextures, /* 12 */ __glXDisp_GenTexturesEXT, /* 13 */ __glXDisp_IsTextureEXT, /* 14 */
So chances are that glxinfo is using another one. So probably our Mesa version 6.4.2 does not come with this/those additional subcommands.
I am wondering if we can tweak glxinfo to work nevertheless. Can you please try if LIBL_DEBUG=verbose glxinfo shows more information? Can you check the environment variables mentioned here: https://dri.freedesktop.org/wiki/TestingAndDebugging/? Does it make a difference if you call glxinfo with -i?
Uli
On Sun, Jun 12, 2022 at 1:01 AM sairuk <sairuk@gmail.com> wrote:
Thanks Neal, this is what I ended up doing as well for Zoom.
The Zoom issue led me to note the difference in behaviour after it
started crashing, I want to be careful not to detract from the actual glx issue even if it turns out to be mesa related.
Unfortunately no movement on the bug Norman raised yet
sai
On Sun, Jun 12, 2022 at 12:28 AM Neal Becker <ndbecker2@gmail.com>
sairuk wrote:
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
wrote: 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.
If you just want to use zoom then use their web app instead of the native zoom app. I always do this with zoom, teams, etc. because the options for sharing are better in chrome than the native apps.
x2go-user mailing list x2go-user@lists.x2go.org https://lists.x2go.org/listinfo/x2go-user
x2go-user mailing list x2go-user@lists.x2go.org https://lists.x2go.org/listinfo/x2go-user
-
Neal Becker -
Norman Gaywood -
sairuk -
Ulrich Sibiller