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

[mSparks]

Using XPRA is absolute not. Because you really did not send 2000fps.

what you send is the bytes for these gl functions ("you" being the application developer that linked libX11)

https://github.com/JoakimSoderberg/mesademos/blob/6eef979a5488dab01088412f88374b2ea9d615cd/src/xdemos/glxgears.c#L323

Which is mostly lots of

byte 16 rendering command length
byte 70 rendering command opcode (Vertex3fv)
+ 3x 4 byte floats for X Y and Z

As defined in

https://registry.khronos.org/OpenGL/specs/gl/glxencode1.3.pdf

with a complete draw finishing on the android device 2000 times a second. (the application is synchronized on the return of glXSwapBuffers)

XPRA client simply maps those byte sequences to calls to GL functions, webGL in the case of its HTML5 client.

Wayland has no such definitions, which is why there is no wayland for XPRA. Also why there are no serious wayland developers (the other reason being no one uses wayland, but that is much less of an issue than a complete lack of any functionality required by developers)

[mrg666]

This idiot is here again talking glxgears and showing glxgears source code as if he understands something. Although Michael has showed that Wayland is not slower than X11 in frame rates. See below.

https://www.phoronix.com/review/ubuntu-2304-wayland-xorg-gaming

He is spewing nonsense.

[access]

Right… well, in that case

http://static.stellarea.net/img/ios-rdp-wayland-es2gears.png

OMG, Wayland + RDP + iOS == over 5000 fps

BTW, could you show us in the xpra-html5 source where this command mapping is. The webgl stuff I find in their repo is starting at html5/js/lib/jsmpeg.js:3656 where there is some logic to set up a webgl shader to update a canvas/texture with decoded image data; like what you'd expect in a system where the content is sent as (compressed) pixelbuffers.

[oiaohm]

XPRA client simply maps those byte sequences to calls to GL functions, webGL in the case of its HTML5 client.

Little problem mSparks XPRA clients including the HTML ones do not process GLX Extensions For OpenGL at all. . XPRA is a screen scrapper that sends 2d content over the wire.

https://github.com/Xpra-org/xpra-htm...aster/html5/js there is no GLX processing in the xpra-html5 client source code. GLX is resolved in Xvfb, Xwayland or virtualgl when dealing with XPRA. GLX does not leave the machine where the application is running with XPRA.

mSparks the android device never received the GLX commands if you are using XPRA.

XPRA network protocol is not X11 when it comes to graphical.

You have had it pointed out by 3 different people that what you are writing is made up garbage.

Here is something horrible yes access pointed out that Wayland RDP is faster than XPRA. There is reason. XPRA is using opengl functions to screen scrap this slows the x11 server down due to locking conflits between the opengl application and the XPRA screen scrap code.

XPRA issues with Wayland have nothing todo with GLX because XPRA has never sent GLX over the network.

https://www.virtualgl.org/pmwiki/uploads/About/vglperf21.pdf

mSparks page 31. GLX code over network is indirect Opengl due to Opengl being implicit sync this tanks performance so bad you would be luck to see 100 frames per second. Yes indirect Opengl is basically divide you local opengl performance by 20 and that what you get at the best. This is why XPRA was designed from day 1 to render local to the application and not send GLX across network.

[mSparks]

BTW, could you show us in the xpra-html5 source where this command mapping is.

I doubt it is, WebGL/GLX is in the browser source.
e.g.

https://wiki.mozilla.org/Platform/GFX/WebGL/Backends

Why would it need to be in the XPRA-HTML5 source when WebGL/canvas speaks GLX natively?

[oiaohm]

Why would it need to be in the XPRA-HTML5 source when WebGL/canvas speaks GLX natively?

Webgl design is not based on GLX.
GLES2 and GLES3 is what Webgl is. This opengl subset that is GLES2/3 does not include GLX extensions including GLX encoding to transmit over network. WebGL can be implement on top of GLX because it subset without a lot of extra code but the reverse is not true.

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

Like OpenGL ES 2.0, WebGL lacks the fixed-function APIs introduced in OpenGL 1.0 and deprecated in OpenGL 3.0. This functionality, if required, has to be implemented by the developer using shader code and JavaScript.

WebGL is missing lots of early opengl functionality.

All WebGL is used for in XPRA HTML5 web client is opengl accelerated 2d rendering none of the 3d rendering functionality of WebGL is used.

https://github.com/dxdxdt/webglgears Yes this is glxgears ported to webgl there is lots of code differences to the GLX version other than just to conversion to javascript due to the opengl functions that are pure missing from WebGL that GLX has.

To avoid the stall out problems of opengl locking design that completely destroy the indirect rendering performance webgl has the core opengl program in browser as javascript.

To be real the only way you would be using webgl to run Linux native glxgears using the GPU connected to the browser is if you are using something like https://webvm.io/

mSpark like it or not XPRA protocol only transfers over network 2d content. Please do xpra info and look at the fps value it will not be as fast as what you have been claiming. XPRA is very much like pointing a video camera at your screen just like VNC and RDP are. Yes XPRA has a few extra feature like RDP does to make this video stream of screen/application not to appear to be just a video image screen but to appear as if it a local application when in reality is just a really fancy video stream of screen/application..

mSpark the big smoke gun is without modifications glxgears cannot run on webgl the opengl functions glxgears needs webgl simple does not have.

mSpark the X11 protocol that is converted and sent though XPRA protocol is very small subset of X11 protocol and this subset does not include any of the GLX stuff. XPRA being a very restricted subset of X11 make is fairly secure as well.

Please stop trying to claim something works in way that it simple cannot. Only way items like XPRA, RDP and VNC do opengl is render it locally to the application then take 2d captures of that and send over network. History X11 protocol tried indirect rendering but its a performance killer the round tripping required with Opengl implicit sync makes network latency very painful.

[mSparks]

WebGL is missing lots of early opengl functionality.

such as?

Its obviously missing less than wayland which doesnt include any opengl (or vulkan) functionality.

All WebGL is used for in XPRA HTML5 web client is opengl accelerated 2d rendering none of the 3d rendering functionality of WebGL is used.

a webgl html5 canvas can read glx data as is, you just create the canvas and give it a glx byte stream. I would expect xpra simply sends it over a websocket.

that may or may not accually get accelerated.

Point is, it works, in userspace, no extra software to install, on a huge range of devices and operating systems

unlike wayland.

but you just keep pretending wayland applications exist and are in use all you want. Maybe one day in the distant future it will be true, although if they keep finding security issues with it at the current pace I cant imagine anyone will actually end up adopting it.

[mSparks]

btw, source used for pretty much all web browsers looks like it is here:

https://github.com/mozilla/angle/blob/main/include/GLX/glxext.h

[oiaohm]

a webgl html5 canvas can read glx data as is, you just create the canvas and give it a glx byte stream.

No it cannot because a webgl html5 canvas is restricted to opengl ES. This you wild guessing.

I would expect xpra simply sends it over a websocket.

Where in the xpra code does XPRA do this. Stop using expect point to the code. The reality is xpra never put the glx item into the XPRA protocol and that before it gets converted to websocket. So it does not matter if you are using XPRA over ssh or websocket or locally there is no GLX being transmitted.

btw, source used for pretty much all web browsers looks like it is here:

https://github.com/mozilla/angle/blo...e/GLX/glxext.h

https://github.com/mozilla/angle/tree/main

Would have paid to read the front page of that. Yes angle has a GLX backend but it filters the usable opengl instructions to opengl ES. Opengl ES does not have indirect rendering or the GLX instruction coding those functions are used in the back-end bit not accessible from the webgl html5 canvas because of items like angle,.

Here is another killer. GLX only exists on a platform running X11 server. Note angle has a special backend for Android. When build a browser for android device you don't use that glxext.h header because you are not on X11.

GLX is only for X11 platforms nothing else..

[mSparks]

No it cannot because a webgl html5 canvas is restricted to opengl ES. This you wild guessing.

Let me guess, you don't even know what opengl ES is.....

Do you know WHY its limited to openGL ES?

I'll give you a clue

Its the same reason wayland and GLX are restricted to opengl ES.