Fedora COSMIC Desktop Spin Being Considered

[ssokolow]

right, and that and all the other stuff is the hard part.
doesnt matter if its a wayland or an X11 display server, its still the hard part, because the problems are the same for both and they both use the same system libraries.
Locking the display server is and always was the easy part - actually easier for an X11 display server than wayland, because 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.

The point is that, with Wayland as implemented so far, the screen locker and the thing that gates access to the input devices are in the same process while, in X11, the screen locker is just another process and it's proven problematic to reconcile that with things that use the same APIs for stuff as simple as ensuring that clicking outside a popup menu will close it.

[mSparks]

The point is that, with Wayland as implemented so far, the screen locker and the thing that gates access to the input devices are in the same process while, in X11, the screen locker is just another process and it's proven problematic to reconcile that with things that use the same APIs for stuff as simple as ensuring that clicking outside a popup menu will close it.

No, the system libraries gate the access, libinput for input, the gpu driver (generally mesa aiui) for the screens, wayland accesses those system libraries in exactly the same way as X11, because they are defined by the system/kernel, not the display server.

[ssokolow]

No, the system libraries gate the access, libinput for input, the gpu driver (generally mesa aiui) for the screens, wayland accesses those system libraries in exactly the same way as X11, because they are defined by the system/kernel, not the display server.

System libraries aren't processes. I'm talking about which running process has the decision-making authority.

[mSparks]

System libraries aren't processes. I'm talking about which running process has the decision-making authority.

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.

[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.

[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.

[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.

[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]

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]

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.