Originally posted by mSparks
View Post
Announcement
Collapse
No announcement yet.
Fedora COSMIC Desktop Spin Being Considered
Collapse
X
-
- Likes 1
-
Originally posted by ssokolow View Post
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.
Comment
-
Originally posted by mSparks View Post
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.
- Likes 1
Comment
-
Originally posted by ssokolow View Post
System libraries aren't processes. I'm talking about which running process has the decision-making authority.
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.
Comment
-
Originally posted by mSparks View Post
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.
- Likes 1
Comment
-
Originally posted by mSparks View Postbut you are talking exclusively about locking the display server.
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.
Comment
-
Originally posted by mSparks View PostLocking the display server is and always was the easy part
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.
Originally posted by mSparks View Postall 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.
Both use a local Unix domain socket to communicate between clients and server.
Comment
-
Originally posted by anda_skoa View Post
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.
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.
Comment
-
Originally posted by mSparks View Postthe thing to understand is an X11 server is directly synonymous with a file server.
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.
Originally posted by mSparks View Postkeyboard, video and mouse are presented as files to clients(applications) in the X11 file format.
"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.
Originally posted by mSparks View Postwayland otoh, doesnt add that "complexity".
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.
Comment
-
Originally posted by anda_skoa View PostIt 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.
if remote it goes over tcpip
if local it transfers over IPC.
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.
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.Last edited by mSparks; 24 February 2024, 09:57 AM.
Comment
Comment