Fedora COSMIC Desktop Spin Being Considered

[mSparks]

Of course it does.

where is the link to the byte meanings then?

[anda_skoa]

X11 clearly defines a highly extensible communication protocol with error checking and correction

wayland doesnt.

Of course it does.

Again one of the approaches by most display servers.

Original Mir differed a bit by keeping the protocol internal and primarily providing a client library, but in principle still the same thing under the hood.

[mSparks]

X11 and Wayland does exactly the same,

Exactly, even to the point of generally using exactly the same system libraries (on linux at least)

Where they differ is in the design choices.

X11 clearly defines a highly extensible communication protocol with error checking and correction

wayland doesnt.

[anda_skoa]

The "X11 protocol" is a file format defined in bytes, an X11 server is identical in operation to an HTTP server or FTP server, instead of hypertext or flat files it transfers keyboard/video/mouse data "as a file in the X11 format".

You always transfer some sort of data in a certain format across the socket as the low level concept is just a stream of bytes.

I assumed you meant that Unix domain sockets allow to pass file descriptors as part of such data transmissions.
Which allows very efficient handover of of larger data blocks than transmitting the actual data over socket.

One of the main difference between a file/http/ftp server and a display server.

X11 and Wayland does exactly the same, the Unix domain socket does not magically later is behavior or capability depending on which of the two protocols are passing through it.

if remote it goes over tcpip

Rarely used since remote connections are usually handled via tunneling, e.g. X11 forwarding via SSH.
Which effectively means Unix domain sockets on both sides being "tied" via the tunnel.

if local it transfers over IPC.

Indeed and that is also the communication channel between Wayland clients and their display server.

wayland doesnt do anything like that

It does exactly do the same thing.

its much lower level, and is defined in terms of system calls like vulkan or opengl

You are confusing content rendering with client/server communication.

On both Wayland and X11 clients can render their content via various techniques and the communicate the result to the respective display server.
The most efficient way to do that in both cases is to pass just a handle to the buffer through the socket.
Especially if the client rendered on the GPU via Vulkan, OpenGL or hardware video decoder, because then the actual data never leaves the GPU memory.

On this level there is virtually no difference between any of the display server approaches, including original Mir or Arcan.
These are the features of the shared system layers and the most efficient way to do these things.

In any case we've again moved quite off the topic at hand.

Any of those display servers is capable of providing the functionality to lock the screen.
It is just very uncommon for an X11 server to do that but it is still a choice the ones implementing it have.

COSMIC developers might also choose not to do it but could do so if they wanted to avoid some of the difficulties incurred by other approaches

[mSparks]

It has nothing in common with a file server other than being a service used by clients.

A file server is much more likely to work through TCP/IP than a local Unix socket and will therefore transfer data instead of passing around file handles.

The "X11 protocol" is a file format defined in bytes, an X11 server is identical in operation to an HTTP server or FTP server, instead of hypertext or flat files it transfers keyboard/video/mouse data "as a file in the X11 format".

if remote it goes over tcpip
if local it transfers over IPC.

https://www.x.org/releases/X11R7.5/doc/x11proto/proto.pdf

Every request contains an 8-bit major opcode and a 16-bit length field expressed in units of four
bytes. Every request consists of four bytes of a header (containing the major opcode, the length
field, and a data byte) followed by zero or more additional bytes of data. The length field defines
the total length of the request, including the header. The length field in a request must equal the
minimum length required to contain the request. If the specified length is smaller or larger than
the required length, an error is generated. Unused bytes in a request are not required to be zero.
Major opcodes 128 through 255 are reserved for extensions. Extensions are intended to contain
multiple requests, so extension requests typically have an additional minor opcode encoded in the
second data byte in the request header. However, the placement and interpretation of this minor
opcode and of all other fields in extension requests are not defined by the core protocol. Every
request on a given connection is implicitly assigned a sequence number, starting with one, that is
used in replies, errors, and events.

wayland doesnt do anything like that, its much lower level, and is defined in terms of system calls like vulkan or opengl but more like early win16.

other than that everything else is the same. even wayland ends up as a stream of bytes eventually, after all, 0s and 1s are all computers have to work with.

[anda_skoa]

the thing to understand is an X11 server is directly synonymous with a file server.

It has nothing in common with a file server other than being a service used by clients.

A file server is much more likely to work through TCP/IP than a local Unix socket and will therefore transfer data instead of passing around file handles.

keyboard, video and mouse are presented as files to clients(applications) in the X11 file format.

You are misunderstanding or misinterpreting the world "file" in this context.

"Everything is a file" refers to the API being used to access various things, one of which being actual files on disk.

In the context of a display server that is almost never the case but instead it refers to "file handles" of "file descriptors" being passed between processes.

The kernel can hand out such handles for various resources, for example to memory buffers.

wayland otoh, doesnt add that "complexity".

Wayland is using exactly the same mechanism.

It is also a technique supported by other communication systems such as D-Bus.

Essentially transferring information on where to get data than the data itself.
With the added benefit of having the kernel's file access control available to restrict that access.

[mSparks]

As MrCooper pointed out earlier, there is virtually no difference between the two systems in this regard.
Both use a local Unix domain socket to communicate between clients and server.

the thing to understand is an X11 server is directly synonymous with a file server.
keyboard, video and mouse are presented as files to clients(applications) in the X11 file format.
wayland otoh, doesnt add that "complexity".

Other than that everything is the same.

this makes wayland great when the use case is a low power/embedded device serving a single user with a single screen, keyboard and mouse - what it was designed for - but useless for anything more complex than this.

It is also why X11 completely dominates the workstation and server space, and will do for the foreseeable future.

everything else is BS, seemingly written by redhats on performance improvement plans, desperate to keep their jobs and justify their existence.

[anda_skoa]

Locking the display server is and always was the easy part

Exactly!

Doing it in a client to that display server is the added difficulty that COSMIC won't have to deal with if they do it directly in the server.

all the data pipes and the data they should contain are very clearly defined with an X11 server, wayland otoh, is just a random collection of system calls.

As MrCooper pointed out earlier, there is virtually no difference between the two systems in this regard.
Both use a local Unix domain socket to communicate between clients and server.

[anda_skoa]

but you are talking exclusively about locking the display server.

Again sorry that this got confusing.

We are discussing the difference in complexity of implementing the locking inside the display server versus implementing it in a separate process talking to the display server.

The latter is more complex, especially if the display server treats the locking process like any other client and does not have a special role and privileges associated with it.

If we were to consider a case where locking is available as kernel functionality and the only doing authentication for unlocking in user land, then this would of course reduce the complexity for that process even further.

Since we don't have that the next best thing is locking in a user space process.

See also the comments from ssokolow for various example how this is easier of that process is the display server and more complicated if it is just a client.

[ssokolow]

libinput and mesa run their own processes, you access them with system libraries.
The fact you and anda_skoa don't know this just highlights neither of you a clue what you are talking about.

Heck, libinput is a whole stack of processes.

And, bundling inputs and displays into seats is out of scope for both of those libraries. You might as well argue that the kernel's evdev subsystem should be responsible for screen locking.