If Or When Will X12 Actually Materialize?

[nanonyme]

This can't be true, because X existed for more than a year before Windows 1.0 was even born. (And before X, there was W.)

Well, yeah. X has been around for half eternity. (in the form of Xfree86 and possibly others I don't know of) X.org is relatively new though.

[nanonyme]

I personally think the UI components of the toolkits themselves should be network-transparent, not drawn client-side

How the heck would you use a server with no display adapter card with remote X if graphics weren't fully drawn on client-side?

[blacknova]

How the heck would you use a server with no display adapter card with remote X if graphics weren't fully drawn on client-side?

It always possible to use Xvfb.

[jrch2k8]

How the heck would you use a server with no display adapter card with remote X if graphics weren't fully drawn on client-side?

using for example the software rasterizer from gallium rendering in offscreen and sending the pseudo processed info or the full rendered frame through the client in the network xorg to just end the render or render the frame on the screen. in this case theorically you dont need a gpu, so it possible.

another method could be if you can send the raw requirememnts to an networked xorg, so the other xorg do the render onscreen wich whatever hardware you have, ofc this would need some sort of initialization protocol to at least inform the base xorg server wich screen size you want and what proportion and wich feature your hardware support(for example if your crd can use exa and composite/xrender). in that case you would need the chance to send glx commands too with shaders.

if you want to render in more than 1 computer, would be nice to overhaul the damage extension so you can save band just sending the modifications to the orginal frame. that is in case of using multi input and each user having a different desktop. muticast could help too if you only wanna work in 1 pc and watch only in many pc's so that way you avoid multiple renders

[siride]

using for example the software rasterizer from gallium rendering in offscreen and sending the pseudo processed info or the full rendered frame through the client in the network xorg to just end the render or render the frame on the screen. in this case theorically you dont need a gpu, so it possible.

another method could be if you can send the raw requirememnts to an networked xorg, so the other xorg do the render onscreen wich whatever hardware you have, ofc this would need some sort of initialization protocol to at least inform the base xorg server wich screen size you want and what proportion and wich feature your hardware support(for example if your crd can use exa and composite/xrender). in that case you would need the chance to send glx commands too with shaders.

if you want to render in more than 1 computer, would be nice to overhaul the damage extension so you can save band just sending the modifications to the orginal frame. that is in case of using multi input and each user having a different desktop. muticast could help too if you only wanna work in 1 pc and watch only in many pc's so that way you avoid multiple renders

Better would be to just leave it as it is and have the toolkits be done client-side and the rendering server-side. Then you wouldn't have to jump through hoops and have parts of the system on the wrong side of the client/server boundary.

I see server-side toolkit ideas pop up from time to time when people talk about X. First of all, no other OS uses server-side toolkits, so that should say something right there. Secondly, server-side toolkits introduce policy and application-level details into the server in a non-generic way. Server is supposed to just render and demultiplex input (and interface with hardware to do all that). Now it has to deal with things like buttons, accessibility, colors and themes, etc. Now, instead of being able to just update the Qt libraries, you also have to update the X server. And while you can have side-by-side installations of toolkit libraries, you can't have two instances of the X server running to support old and new apps. No more Qt3 apps alongside Qt4 apps. Either the toolkit API must remain extremely stable and backwards compatible over time, or you just lose the apps that run on the older version of the toolkit. Some people propose some way where toolkit code is uploaded into the server. It's obvious that this is a ridiculous solution and not worth trying.

So once again, we are left with the reality that X really is okay in its fundamental architecture. Tweaking and upgrading, rather than a wholesale rewrite or reworking is the way to go.

[bridgman]

How the heck would you use a server with no display adapter card with remote X if graphics weren't fully drawn on client-side?

There are a number of systems around which perform most or all of the rendering on the server side then push bitmaps down to the client. X terminals are often referred to as one example of thin-client systems, but some of the systems out there have *really* thin clients.

[nanonyme]

There are a number of systems around which perform most or all of the rendering on the server side then push bitmaps down to the client.

Right. But assuming it's fully CPU-rendered and there might be tons of people using the same server with remote X at the same time, that doesn't essentially sound very fast to me unless we're talking of really simple graphical apps.

[Wingfeather]

How the heck would you use a server with no display adapter card...

Perhaps I'm being obtuse, but why on Earth would you run an X server on a machine with no display adapter? Isn't displaying things the very point of the X server?

[movieman]

Perhaps I'm being obtuse, but why on Earth would you run an X server on a machine with no display adapter? Isn't displaying things the very point of the X server?

The server is the X client, the X server runs on the client, so to speak .

In other words, you run an X app on the server which talks to the X server on your desktop machine which does have a graphics card.

[phtpht]

As I understand it, the main desire behind Wayland was to have a simple playground for testing various techniques with the new Linux graphics stack (KMS/DRI2). I'm pretty sure it's meant to complement Xorg, not replace it.

Doesn't seem that way from the hype around it.