A simpler description of wayland

[Renaud Hebert]

Hello,

my view is very different from yours.
I wonder if discussing here can be interesting.

 >>The X server contains lots and lots of crufty old code going back to 
the 1980s that nobody uses and nobody (including the X developers) wants 
to maintain, but is required to claim to be an X server.<<

More precisely these 'obsolete' features are needed only if you want to 
claim to implement the X protocol version 11.
If X developers wanted really to get rid of these features, it would be 
technically very easy: just increment the major protocol version to 12 
and remove the support of these features.

The difficult part is sociological: agreeing on which features to drop 
and convince all the X clients to use X version 12 instead of X version 
11 (not difficult technically if they don't use the dropped features).



The big differences between Wayland and X that I see are:
1) with Wayland communications between the applications and the 'display 
manager' are made with 'shared video memory'.
This means that GPUs will be used very efficiently.
But this also means that the network transparency is not done anymore in 
the display subsystem but above it.

2) with X, the communications between the programs and the 'display 
server' use the X API which has two variants:
a- a shared memory variant for local usage, but here this is the main 
memory used (RAM) not video memory, so the GPU cannot be used will full 
efficiency (either the application don't use the GPU or it has to copy 
the GPU's video memory back into the main memory to share it with the X 
server which is not very efficient).
b- a socket variant, which allow network transparency.

I wonder if it would be possible to add to X a third variant for local 
usage: use shared video memory to communicate between the client and the 
server.

What would be the difference between this and Wayland?

BR,
Renaud.