X.Org Server & XWayland Hit By Four More Security Issues

[oiaohm]

Well that's obviously bullshit.
Because all the webGL modules of all the chromium and mozilla derivitives use ANGLE, and ANGLE definitely does, it's in the source

https://chromium.googlesource.com/angle/angle/+/chromium/2498/src/libANGLE/renderer/gl/glx/DisplayGLX.cpp

Posting over. This point has already been disproved not repeating self get lost now mSparks.

[mSparks]

Posting over. This point has already been disproved not repeating self get lost now mSparks.

you didn't disprove anything, you said webgl is limited to gles2, but since gles2 is a subset of opengl/glx - by definition glx supports all of gles2.

you might as well claim you disproved nvidia doesnt support/run opengl2 any more because all their cards are "only" opengl 4.6

[oiaohm]

you didn't disprove anything, you said webgl is limited to gles2, but since gles2 is a subset of opengl/glx - by definition glx supports all of gles2.

But when you are on a Android device you are not using GLX.

https://source.android.com/docs/core/graphics/arch-egl-opengl

Android device is EGL. Angle has a EGL backend as well. Yes on Wayland Angle is EGL. Angle on X11 can be EGL or GLX. Firefox default backend on X11 is EGL not GLX.

https://mozillagfx.wordpress.com/2021/10/30/switching-the-linux-graphics-stack-from-glx-to-egl/

Yes matter of time until chrome on Linux is EGL not GLX even for X11.

By khronos GLX and EGL are Platform Interface options. Here is the really fun part is gles2 is not a subset of GLX. gles2 is a optional part to be used with GLX/EGL/WGL... just like opengl is.

Back in the day you had GLX + opengl under Linux with no gles2 and then you also had GLX with gles2 and no opengl. There is a reason why Xwayland now provides option to chose between opengl and gles2 this allows coping some of the application expected behaviors better.

By khronos definition GLX only support GLX. GLX is a Platform Interface, Opengl and gles2 both sit on top of this platform interface and are not the platform interface.

https://en.wikipedia.org/wiki/GLX

GLX is not part of gles2 standard. gles2 is not a subset of GLX. GLX is a interface between opengl items and X11 nothing more. Just like EGL is another form of interface between opengl items and native platform.

mSparks you define of GLX is totally wrong. The standards that define EGL, GLX, WGL and so on don't include opengl or gles2.

Basically you example used Android since you used android there is no GLX there at all because that EGL. Even a demo on X11 Linux desktop if the browser is firefox or you have started chrome with EGL flag the webgl will not be on GLX at all but instead on EGL.

GLX is falling out of use very quickly coming a legacy only thing.

Basically stop posting obviously bullshit to anyone who knows how khronos set this out. Just because angle has GLX in it source code does not mean chrome always uses that bit.

mSparks I guess you missed that current day X11 has two platform support layers. EGL and GLX. EGL contains no network transparency at all.

[oiaohm]

The fact that GLX and EGL are not part of opengl gles standards but are their own standards is how mesa and nvidia drivers get to share the same code for opengl/glex implementations between the GLX and EGL when under X11.

[mSparks]

The fact that GLX and EGL are not part of opengl gles standards but are their own standards is how mesa and nvidia drivers get to share the same code for opengl/glex implementations between the GLX and EGL when under X11.

GLX is a file format (an extension of X11 specifically for openGL function calls) for serialising openGL function calls over a network.

GLES is a subset of GLES2, GLES2 is a subset of openGL, openGL is a list of function calls GLX can serialise, therefore GLES is a subset of a list of function calls GLX can serialise.

Do you actually know what serialisation and Remote Procedure Calls (RPC) are?

[oiaohm]

GLX is a file format (an extension of X11 specifically for openGL function calls) for serialising openGL function calls over a network.

https://community.khronos.org/t/opengl-3-and-later-glx-opcodes/65611

Except there is a problem. GLX does not process Opengl functions 3.0 and newer.

GLES is a subset of GLES2, GLES2 is a subset of openGL, openGL is a list of function calls GLX can serialise, therefore GLES is a subset of a list of function calls GLX can serialise

From khronos group Senior Member

For what it is worth, there is no GLX protocol for OpenGL ES1 or ES2 and much of GL3 (indeed even much of GL2) has no official GLX protocol… VBO’s I think have some experimental protocol in MESA… but it has been experimental for a very, very long time now.

You cannot encode into GLX most of GLES. GLES is not a subset of GLX. GLES like new opengl functions starting in opengl 2.0 are design to go direct to local card completely bypassing GLX.

There is nothing added in GL3 or for GLES that got a GLX code to be encoded into.

mSparks without question you cannot serialize majority of GLES into GLX opcodes for network transport because GLX opcode don't exist covering majority of GLES . This is why GLES and Opengl are not a subset of GLX. GLX only implements a subset of Opengl 2.1 and GLES need more than this. Yes subset most of Opengl 2.1 is not implemented and less than 75% of Opengl 2.0 is implemented in GLX.

EGL/WGL/GLX... as in the Platform Interface all only implement a subset of opengl functionality fairly much never exceeding Opengl 2.1 and never GLES v1 let alone later versions newer functions. Its the direct to GPU functionality that allows all the later Opengl and GLES functionality.. Yes 2006 opengl at best for this stuff. Opengl ES/Gles in 2003 being designed for embedded is use the bar min of GLX to setup direct to GPU.

mSparks the reality here is that GLES cannot be sent over network by GLX because GLES cannot be encoded into GLX opcodes.

Basically this has nothing todo with RPC this is all about what i possible. GLX protocol does not contain GLES all version or Opengl 3.0 and newer. Since GLX does not contain these things it cannot be used to transmit them over the network.

Yes GLES and modern Opengl bypasses GLX as soon as it can. Encoding to opcodes has a performance cost.

[mSparks]

Except there is a problem. GLX does not process Opengl functions 3.0 and newer.

Why is it a problem? X forwarding has the same limitation and it was never a problem

Yes GLES and modern Opengl bypasses GLX as soon as it can. Encoding to opcodes has a performance cost.

more BS from you. plus something of a pivot.
glx applications only output glx datastreams. gpu drivers generally interpret these directly - as does angle.

[oiaohm]

Why is it a problem? X forwarding has the same limitation and it was never a problem

https://registry.khronos.org/OpenGL/...xencode1.3.pdf
Version 1.3 - 2 June 1999

Fun fact X11 forwarding of opengl for newer versions also operated in 2d. Yes local indirect rendering then sending 2d of that over the wire.

GPU instructions have not been sent over the network link for quite some time. You have to have a opengl 2.1 or lower application for this to be happening.

glx applications only output glx datastreams. gpu drivers generally interpret these directly - as does angle.

Except this is not true. The simple reality there is no GLX opcodes to encode newer opengl and opengl es functions into a glx datastream.

Angle in fact used newer opengl functions.

https://chromium.googlesource.com/angle/angle/+/chromium/2498/src/libANGLE/renderer/gl/glx/FunctionsGLX.cpp#60

This is a complete list of GLX functions used.

The GLX function used that kills your argument dead.

https://registry.khronos.org/OpenGL/extensions/ARB/GLX_ARB_create_context.txt

If glXCreateContextAttribsARB succeeds, it initializes the context
to the initial state defined by the OpenGL specification, and
returns a handle to it. This handle can be used to render to any GLX
surface (window, pixmap, or pbuffer) compatible with <config>,
subject to constraints imposed by the OpenGL API version of the
context.

Once you have a modern context you don't have to talk glx opcode any more. Instead you switch over to talking what purely in the opengl API standard to the handle you have got. Same thing happens with WGL and EGL as well with their version of the same function.

Yes out of everything that is in GLX angle only uses 19 functions of GLX.

Older versions of GLX documentation makes out the only way to the screen is by GLX. The newer extensions to GLX provide these context handles that bipass

mSparks the simple reality it does not matter if it X11 forwarding. XPRA or RDP.... if the application you are using is Opengl 3.0 or newer you not sending GPU commands over the network. This is the change over to sending 2d data instead of 3d data. To be correct most cases with GLX you don't even get opengl 1.5 and 2.0 and 2.1 if you are using glx encoding instead you find yourself stuck with Opengl 1.4 this is not enough Opengl todo Angle.

https://blog.mecheye.net/2012/06/the-linux-graphics-stack/#comment-5505

These limitations are not a new thing mSparks. You have been purely deceived by 2d trickery that remote opengl works with newer applications. GLX opcodes transporting a current version at the time of opengl commands over network has not worked for decades.

All form of modern desktop graphical transport over network are 2d operations.

[mSparks]

These limitations are not a new thing mSparks.

In case you missed it, google recently tried to commercialise a serialised full modern graphics stack. maybe you didnt hear about it? they called it stadia.

The key limitation for anything more advanced than early opengl is latency, similar to gles because of gpu limitations.

Could we have better than GLX? sure, but key developers were too busy wasting their time with wayland on ideas that turned out to be hyperbole.

[ReaperX7]

Technically GLX doesn't "need" to be improved. It's mainly for networked X displays to draw with OpenGL post process. You technically, on your own desktop, never use GLX. That's why if you see the subset of function calls GLX has, it's VERY limited. If you run X through a terminal from a server via network login and then use a program running OpenGL over a network, then you will be using GLX.

It's mainly meant for small form factor units with severely limited GPUs in Terminals that mainly just draw a 2D display, and receive OS data in streaming format from a Terminal Server.