I read the blog posts you linked to yesterday, regarding wlroot and understanding how Wayland works. They help a lot in understand what Wayland is and how it work. It's really well written, thanks.
There's just one thing that's still a little weird. You show with Wayland McWayface how you can start clients, and use gnome-terminal in the example. The Gnome terminal shows up with window decorations, and as I understand it, that's because Wayland encourage (require?) the client to provide those decorations.
If the client provides the windows decoration, then that sort of eliminates what most of us would define as a Windows Manager, at least for the very simple ones. So it seems like you could write a GTK application for instance, say a desktop like the old Windows 3.11, theme it and then just start it with a random compositor.
I guess the question really is, could you write a general compositor, which just handle inputs and output, and then use that compositor to run any number of different desktop environments where the authors technically doesn't need to worry about Wayland?
>I guess the question really is, could you write a general compositor, which just handle inputs and output, and then use that compositor to run any number of different desktop environments where the authors technically doesn't need to worry about Wayland?
This is a goal we're working towards in the wlroots camp. You could do this, but the issue would be running a lot of the things that tend to define the desktop environment, such as the panel, menus, desktop feel, etc. In order to support that, we need a Wayland protocol that lets clients have some say in where they are displayed on-screen, such as a taskbar wanting to be shown across the bottom. For wlroots we made such a protocol[0], and it is slowly being adopted across the ecosystem. Porting DEs to use it would be a great way to help improve Wayland :)
>> You could do this, but the issue would be running a lot of the things that tend to define the desktop environment, such as the panel, menus, desktop feel, etc. In order to support that, we need a Wayland protocol that lets clients have some say in where they are displayed on-screen, such as a taskbar wanting to be shown across the bottom.
Isn't that the job of something higher level? I thought the wayland compositor would implement some desktop environment functionality. In other words the compositor itself would also define the DE by starting a panel and placing it at the top/bottom/side and by starting and placing any other items/processes that are part of that environment. I understand that this would add complexity to the compositor but isn't that where it really belongs? I still feel like it's a security concern for general processes to know much about the environment they are running in. OTOH I want to start several things at login and have the ability to place the windows from a script (like .login and passing window geometry to X). These are interesting issues and I hope the people making the decisions are keeping things both secure and simple in the software.
BTW, I'm hoping for animated wallpaper on my desktop. This is a low priority, but would that be an application that runs in root window, or would that be something the compositor knows to start an places it there? IMHO that's so special it's more of a compositor feature, but who knows... Should there be added protocols to do these things or just make a special compositor feature? I'm in favor of having it a compositor feature rather than increasing complexity of a protocol - I think it's less complex.
> I thought the wayland compositor would implement some desktop environment functionality. In other words the compositor itself would also define the DE by starting a panel and placing it at the top/bottom/side and by starting and placing any other items/processes that are part of that environment
It can, that's how GNOME works today. It's not how it generally works on X, though, and it's not very modular.
As far as security is concerned, our layer shell protocol assumes that the client is trusted. We're working on ways of securely allowing third-parties to access this, but it's possible today to start implementing layer shell and restrict its use to trusted clients.
>BTW, I'm hoping for animated wallpaper on my desktop
This is possible with the layer shell protocol I'm talking about.
I don't think that makes it simpler. I think that just makes a massive compositor which tries to please everyone and ends up pleasing no one, and being 10x the size it needs to be.
Ultimately the compositor IS the desktop environment. You can try all you want to keep it simple and enable functionality via other apps using a protocol, but that's essentially a complicated way of making plug-ins to the compositor. You will end up delegating security to everyone else.
That's not true. It's true for GNOME, and I guess Enlightenment, but they are not the only players. If you think there are legitimate security concerns with our approach then I'm open to hearing them but so far as I'm concerned so far you haven't said anything of value.
> If the client provides the windows decoration, then that sort of eliminates what most of us would define as a Windows Manager, at least for the very simple ones.
Ouch, that's pretty ugly — that would imply that if I'm running a tiling window manager I'll get stuck with window decorations I don't want. Surely that can't be right!
Maybe the idea is that desktop environments decorate windows containing their clients?
Yeah, we feel the same way. We've recently standardized a protocol[0] for negotiating server side decorations and client support is underway for Qt and GTK+.
- the client and compositor need both implement this protocol extension
- the client needs to ask the compositor whether it should provide its window decorations
- the compositor needs to cooperate and tell the client that the decorations are server-side
Is that right?
I'm also puzzled by something else now: in Wayland, any access to absolute screen coordinates is considered a security risk. So how can a client provide windows decorations then? The main functionality there is moving the window around, which means setting a new absolute window position after a user interaction. How is this possible when the position is hidden away?
EDIT: if I had read the compositor source code before posing the question, I'd have known that the client merely provides the window decoration as a visual area, but not its behaviour. The move and resize behaviour itself including user interaction is part of the compositor.
> if I had read the compositor source code before posing the question, I'd have known that the client merely provides the window decoration as a visual area, but not its behaviour. The move and resize behaviour itself including user interaction is part of the compositor.
Things get weirder and weirder. So clients are supposed to draw in controls, but compositors determine how they behave‽ What if a client draws a close button, but a compositor doesn't have any such concept? What if a client doesn't draw a close button: how does a compositor expose the ability to close the window?
Either this is poorly though-out (unlikely) or I'm really missing something (rather more likely).
I'm not clear on the precise history, but I get the sense that Wayland was largely originated out of the Gnome/GTK/mobile side of things, where client side decorations are considered the way to go and the standardization comes from assuming everyone will be using the same set of UI libraries.
It seems to fit that specific use pretty well, and there's a lot of things I like, but it's certainly got some catching up to do when it comes to the mix-and-match flexibility of the X-server/compositor/window manager/client stack.
I am not sure if Wayland actually intends to catch up. Mostly the work seems to focused on supporting Gnome and KDE without bothering with all the rest. For example, there was a discussion a while ago about taking screenshots. Adding a protocol extension for that was declined for security reasons. Instead, the compositor itself should contain that feature. This only makes sense in the "big" desktop environments that contain everything from the compositor to the utilities and the kitchen sink.
That's just Gnome's opinion. wlroots and KDE are working together to standardize these sorts of protocols, just in the past few months our screenshot and screen capture protocols began to stablize.
How does that work securely? What determines if a process can take a screenshot or not? I mean clearly (I hope) only the compositor has access to all the pixels and needs to capture the image, but what determines who can request it to do so?
>What determines if a process can take a screenshot or not
We're slowly working on standardizing means of granting third-party software access to these protocols, but a cross-compositor mechanism has not yet been built. It is entirely possible for the compositor to only allow certain clients to use certain protocols, though. A mechanism like Android's "grant app this permission" popup, for example, might be possible. Today sway lets you configure different executables to receive different policies.
> A mechanism like Android's "grant app this permission" popup, for example, might be possible.
What possible relationship could this sentence have to the question of determining "if a process can take a screenshot or not?"
The correct answer for an ostensible improvement on X is that arbitrary processes should not be able to take screenshots, ever. If you start punting that question to the app users we're back in the land of Certificate-Error-Continue-Not-Recommended.
Even on this Chromebook I'm using, I'd shut it down immediately if Chrome legitimately popped up a request from a site asking for the permission to take screenshots.
Besides, most of the time on Gnu/Linux it's the buggiest processes for which I want screenshots to send to the developers. If no one in the Wayland community has a design that fits that use case please just leave screenshot functionality out altogether.
Well, with the way we hope to do it we'll leave it to your package manager to establish trust in most cases. So if you install a screenshot tool from your package manager, it'll be installed with all of the necessary permissions set up, and you'll never be prompted. It's important to us that users are able to use tools and workflows that they're comfortable with on X in a secure manner on Wayland.
>> It's important to us that users are able to use tools and workflows that they're comfortable with on X in a secure manner on Wayland.
X is a free-for-all. X-eyes is cute but should not be possible.
At some point, a web application is going to want to take a screen-shot (webX anyone?). The web browser will then be given permission to take screen shots without user interaction, and then it's all over. Sharing ones screen is NOT a browser function, it's an OS function. Changing the way software developers see this is the correct path forward, but it's hard. Providing people the same functionality that X did will lead to the same problems that X has.
> Happy to answer questions about Wayland if anyone has some!
OK then! Hopefully this isn't too off topic.
How should I write an application that does smooth animation in Wayland? I'd like to have a main loop like this:
while (1) {
DrawStuffIntoAPrivateBitmap();
GiveBitmapToTheCompositor();
WaitUntilNextFrameNeeded();
// This loop should iterate at 60 Hz or whatever the monitor's frame rate is.
}
Does that seem like a reasonable approach? I've searched for this info before and got nowhere. Does Wayland even have a mechanism to allow the compositor to tell the application that it is time to draw another frame? If I give the compositor a bitmap every 60th of a second, to I get any guarantee it will display it at the right time?
An application I have in mind is smooth scrolling in a text editor. I have a mild preference for doing the private bitmap update on the CPU rather than the graphics card for various reasons.
>Does Wayland even have a mechanism to allow the compositor to tell the application that it is time to draw another frame?
Yes, Wayland will tell you when it's time for another frame.
>If I give the compositor a bitmap every 60th of a second, to I get any guarantee it will display it at the right time?
Basically you should wait for the compositor to tell you when it's time to draw the next frame, diff it from the time you drew the last frame, and smoothly animate over the difference.
If you don't want to draw on the GPU, what you can do is allocate a pixel buffer with wl_shm (shared memory). Then the compositor will read from this and presumably upload it to the GPU (with wlroots the GPU is always used, but you can probably convince it to use blitting instead with a custom renderer).
Check out my intro to writing Wayland clients article:
So, since we're asking about clients -- do you have any recommendation for terminal emulators that are actual Wayland clients rather than X clients? Last I checked even vte-based terminal emulators were still running under XWayland.
Not really, personally I use urxvt. I might switch to alacritty once it gets a little better. A friend uses termite, another uses gnome-terminal, but I don't like either.
That said, it's 2018 and you should be using the GPU for all rendering. The only compositor I know of that actually works without one is plain old Weston, so it's not like falling back to CPU-munged bitmaps is some sort of compatibility mode. If you want to do pixel-level operations on your output framebuffer, write a fragment shader.
Sometimes there are tasks that are not really suited for the GPU. For instance, drawing text is much easier to do on the CPU. Also for clients that only draw a few frames occasionally (status bars, background images) drawing on the CPU is totally fine.
Yeah, that's a thing I should learn to do. When I last tried, about 10 years ago, the OpenGL drivers on my then Windows system used to decide to make my app take 20 seconds to start every now and again. The OpenGL init function would just block for that long. That was a show stopper for me. Also, my machine uses the graphics hardware embedded in the processor. That shares system DRAM. The DRAM bandwidth is already the bottleneck with my CPU routines, so it's not clear how much performance benefit the GPU would offer (although there could be power savings, I guess). But basically, my CPU based rendering code is already fast enough and I'm pretty sure it's simpler than getting the GPU involved and easier to debug and more portable (to, say, an Amiga 1200). Therefore I consider writing a fragment shader to be a form of premature optimization. I realize this makes me a mad man :-)
Thank you for taking the initiative and time to do this. I'm excited to dig into both the wm and the compositor and try porting them for fun, as I'm sure others will.
It seems like putting the entry point at the top would make the code easier to read, at least in the annotated form you provided. Gist doesn't really have a good way to read from the bottom up like suggested.
Kind of. Weston is a reference compositor, it exists to demonstrate the features of wayland.xml and act as a testbed for Wayland development. These days though I think people are better off reading the wlroots source code than the Weston code, though.
Has there been any progress on telling applications that standard decorations are not desired, particularly on the application/toolkit side? (as I understand, there is a solution at the protocol level) The sole major benefit of server-side decorations has been the option to forego them entirely. When I rejigger my little dwm fork into a Wayland compositor, I think it would be nice if applications didn't suddenly start rendering decorations where previously I had none.
Said another way, how soon can I expect that GTK and Qt/KDE frameworks will hide the close/maximize/windowize/minimize buttons and disable toolkit-provided dragging/resizing cues (and the whole bar, if the standard decoration is all that's there) when server side decorations are preferred?
Been hoping Wayland would help improve the sad state of remote desktop on Linux but from what I can see I'll have to way another 5+ years for something useful :(
I've installed KDE Neon on a NUC to play around with and I really like it a lot. But the lack of proper RDP server support is the primary thing keeping Windows on my primary machines.
Key features required:
- Ability to resume local session from remote client and later locally again.
- Ability to start session from remote client if no local session exist, and later resume it locally.
- Performance (framebuffer-delta ala VNC is no-go).
- Functional clipboard, so I can copy/paste between client and host. Text required, though images and files would be nice.
Anyway, really nice piece of code. Sure it's 500 lines but it seems quite straight forward.
We haven't forgotten about you, but we could use your help if you want it done fast. We've made some important progress towards supporting this functionality recently. A protocol our people have been working on is currently undergoing standardization[0] which enables software keyboard devices. A similar protocol could enable software pointer devices. We also made another[1] protocol for efficiently capturing the contents of the display.
Plug all of these together and an RDP server is probably possible. Maybe a few weeks of work with FreeRDP for the motivated programmer. My email is in my profile, reach out if you want to make some connections and get started.
Another issue with remote desktop (using VNC) on Linux is keyboard layouts (for inputting non-latin characters). With X server, the server passes a physical key number (keycode) and modifiers state (whether keys like Shift or Caps Lock are active) to the client and the client converts it to the corresponging character (keysym) using translation tables loaded earlier from the X server.
When you are accessing another computer remotely using protocols like VNC the local computer's keyboard layout can be different and it can produce characters not present in remote computer's translation tables. The VNC protocol itself transmits keysyms, not keycodes. So there can be a situation when there is no matching physical key number (keycode) for given character. So VNC servers like x11vnc had to modify translation tables on the fly and insert non-existing key into the tables and pass that key's number to X clients.
I wonder if this problem is solved with Wayland. As I understand, Wayland uses similar scheme and the compositor sends only a physical key number (keycode) along with the modifiers to the client and the latter does the translation. By the way, would not it be easier if the compositor did the translation itself?
The hack I described can also cause issues with hot keys. If I run application locally and it has a hotkey like Ctrl + S, and my keyboard has two layouts (English and Russian) then it will probably work with both of them because the application can bind the hotkey to physical key number. But when we send key presses remotely over VNC we send only a keysym (a letter code), not a keycode. If the remote server doesn't have Russian layout it is unable to guess what physical key was pressed and cannot recognize that I pressed Ctrl + S in Russian layout.
Great to hear! I did some minor contributions to FreeRDP before, but it felt a bit too daunting to contribute to this.
However as mentioned the Wayland code posted looked quite nice, and so did FreeRDP as I remember it, so I'll at least have a look and see if I can help.
"Xpra is an open-source multi-platform persistent remote display server and client for forwarding applications and desktop screens.
It gives you remote access to individual applications or full desktops.
On X11, it is also known as screen for X11: it allows you to run programs, usually on a remote host, direct their display to your local machine, and then to disconnect from these programs and reconnect from the same or another machine, without losing any state.
It can also be used to forward full desktops, from X11 servers, MS Windows, or Mac OS X.
Xpra also allows forwarding of sound, clipboard and printing services.
Sessions can be accessed over SSH, or password protected over plain TCP sockets with or without SSL.
Xpra is usable over reasonably slow links and does its best to adapt to changing network bandwidth constraints."
This code is so well-commented that it makes me want to do some graphics programming – and I haven’t needed to do any graphics programming other than HTML canvas in 30 years. What a fantastic contribution. Thank you.
There was Mir the protocol and Mir the library/codebase implementing the protocol. Since the Mir protocol and Wayland weren't that different — after all both were intended as replacements for X — it didn't take much effort to adapt the Mir library to use the Wayland protocol.
(As for why Canonical thought that developing their own protocol was a good idea, I'm not sure, but based on what I remember reading about it from various sources — don't have links on hand, so take the following with a pinch of salt:
1. They, rightly or wrongly, thought that some bad decisions were made with Wayland
2. They preferred to have control over the protocol to be able to experiment / make quick adjustments based on their needs, and the experience they gained while using it in Unity8 (the main DE using the Mir library).
3. They were aware that porting the Mir library to use Wayland, if/once this was decided valuable, would not be difficult (as turned out to be the case).
From a technical point of view, IMO it wasn't a completely terrible decision, but from a PR one it was.)
I haven't really followed Wayland very closely but as a huge fan of tiling WMs (I've used StumpWM for more than a decade, although I switched to dwm lately) I've been a bit worried by the claims that Wayland doesn't have a window manager per se etc... Although I admit that's mainly because I haven't taken the time to understand what Wayland is exactly.
Just in order to aleviate my fears, can somebody tell me if in this brave new world it'll still be possible to effectively implement something like DWM or some other tiling WM "within" Wayland? Are there pitfalls I should be aware of?
I suppose there's got to be a way to do custom tiling, but I worry that there might be other less obvious limitations. For instance every time I attempted to use custom "window manager" on Windows (to add virtual workspaces for instance) I quickly noticed that it didn't work very well. One problem was that the window management was cooperative instead of preemptive: when the "window manager" attempted to hide a window it'd basically send a message to the application requesting that the window be minimized. If the app was frozen or simply uncooperative it'd remain where it was. Could that happen in Wayland?
Reading through this source code should tell you that pretty much any user interaction paradigm is possible with Wayland. I am the maintainer of Sway[0], a drop-in replacement for the i3 tiling window manager of X11 fame, and of wlroots[1], the library doing the heavy lifting in this example compositor and which is the basis of several other[2] Wayland compositors, several of which are tiling.
>1 pretty much any user interaction paradigm is possible
Is it possible to implement an interaction bound to a global hotkey (e.g. middle click) that takes the current selected text (in any window) and send it to the event target window as keypress events? Without special support from either program? [xselection pasting]
Can I monitor and/or intercept (block) input events of any program without special (voluntary) support from the monitored program? Can I send arbitrary synthetic input events? [hotkey macros]
Features that require opt-in support from the application don't count (it needs to work on proprietary programs and programs that use any toolkit (not just GTK/Qt).
I rely on these features, so I will be sticking with X11 if Wayland isn't compatible.
The answer is "it depends on how much work you want to put into making custom protocols for these purposes".
>Is it possible to implement an interaction bound to a global hotkey (e.g. middle click) that takes the current selected text (in any window) and send it to the event target window as keypress events? Without special support from either program? [xselection pasting]
Yes, doing it the way you described is possible. Or you could just use the existing and moderately-well-supported primary selection protocol:
>Can I monitor and/or intercept (block) input events of any program without special (voluntary) support from the monitored program? Can I send arbitrary synthetic input events? [hotkey macros]
Sure, from the compositor. If you want clients to call the shots you need a protocol.
Yes, but so does Wayland support in general. Protocols are the bread and butter of Wayland, the core Wayland protocol is very conservative (it doesn't even specify application windows).
It is not at the wm level. It replaces X. Your favorite tiling wm would need significant rewrite, but there are some tiling wms out for wayland including an i3 clone.
No, a very similar setup is possible depending on the compositor. wlroots enables this. The Wayland protocol only exposes up to one keyboard per seat to the client, but wlroots lets you pass input to seats in any manner you choose. In sway you can have multiple keyboards with multiple layouts and we swap them out whenever you start typing on a different keyboard.
Not to mention if you didn't use libc - and think of how many loc it'd need if you wanted to implement the kernel and userspace tools too!
Thankfully, we live in a world where libraries exist and we can use them to handle the low-level details, and then we only need to care about the 500 lines of meaningful application-specific logic :D
So explain the point? In several threads recently I've seen people say "The application's line count is higher if you also count the libraries as part of the application!" - I mean yeah, sure, that's a factually correct statement, but... so what?
The point is that this app is 500 lines of C but it'd be two lines of Python:
from wayland import solution_to_the_problem
solution_to_the_problem()
In this case, wlroots is literally a library for writing a compositor.
("A small demonstration of the wlroots API" would have been a fine title for this post. Pretending it's a small amount of code is silly.)
"I made a tiny webserver using only the Linux kernel" is impressive. "I made a tiny webserver using only the Golang webserver API" is not as impressive. "I made a tiny social networking website using the Golang webserver API" is heading back towards impressive.
You don't have to be impressed, but I don't necessarily think it's disingenuous. A "small" Wayland compositor which doesn't use a library like wlroots is nigh impossible. The code for handling DRM+KMS alone is over 2000 lines of code, and that's tangental to the goal of "make a Wayland compositor". I'd compare it to saying a game written with GLFW isn't impressive because they didn't do all of the work to set up an application window.
For a toy compositor, is there any reason not to just use SDL? The DRM and KMS side of things is interesting, but doesn't help much in understanding the Wayland protocol.
You certainly could make a compositor with SDL, but I don't think it would be any better than wlroots. We also provide an abstraction of the underlying window system, the same code which runs your compositor in an X11 window can also run it on KMS+DRM without any changes (the compositor in this very link can run on X11, Wayland, and DRM+KMS with no changes). It also gives you a number of useful things like an implementation[0] of xdg-shell, which alone can be a couple thousand lines long. Also, negotiating graphics resources with clients is going to require you to get into the gritty OpenGL details if you intend to be efficient (and some clients don't even support shared memory, so it's also a matter of compatability). You'd also need to implement the seat to have input support, which can be another ~1,000 lines of code. GTK+ requires the data device to be implemented as well - over 1,000 more lines of code in wlroots[2].
That being said, a simple compositor which only supports a subset of this stuff, uses SDL for rendering, doesn't support a lot of important features (like GTK+ dropdowns and context menus), and directly implements the Wayland protocols, could probably be done in one or two thoundand lines of code. In order to be equivalent in functionality to the TinyWL compositor I posted today, it would probably need to approach 5-6,000 lines.
>That being said, a simple compositor which only supports a subset of this stuff, uses SDL for rendering, doesn't support a lot of important features [...], and directly implements the Wayland protocols, could probably be done in one or two thoundand lines of code.
That's what I'm interested in. wlroots hides pretty much all of the details about what's going on. This would be more about producing an example than an actual functional compositor. My next Rust project, maybe. Or even C#, for that matter.
If you're producing an actual functioning compositor you should be using wlroots anyway. It's unopinionated, we call it "40,000 lines of code you were going to write anyway". It's not practical to make a compositor without leveraging wlroots unless you have a huge team like GNOME or KDE - this is advice from several compositors who tried and are now using wlroots.
Still, if you insist on making everything yourself, the wlroots code is pretty accessible and I've heard from people working on KDE and Mir that it's the best reference code to study for understanding how everything works and applying it to their own software.
I agree. It's a spectrum and my Python example is showing one extreme of obviously unimpressive. I was just trying to answer the comment I was responding to.
The line I'd draw is application logic (how the WM acts, how it reacts to user inputs, how it feels to the end user, the unique things which make it different to any other WM) vs library logic (the necessary groundwork which every WM is forced to implement in exactly the same way because of the protocol spec)
tinywl is 500 lines of application logic + 40,000 lines of library logic; compared to your example which is two lines, but doesn't include the application logic, which I think makes it an apples-to-oranges comparison.
I think in your rush to be sarcastic you forgot to read the part where I gave "application logic" and "library logic" some practical definitions :)
To clarify anyway - "tiling vs free-floating" is an application behaviour, "move window from (x1,y1) to (x2,y2)" is a library function; "focus follows mouse vs click-to-focus" is an application behaviour, "set_focus(window_id)" is a library function; "apps have icons vs apps have text labels" is an application behaviour, "render_icon()" and "render_text()" are library functions; etc.
As somebody who is interested in creating my own window manager, because none of the existing ones behave in the way that I want them to, I find the definition used by the author here to be very useful - the 500 lines are what I need to grok in order to build a WM which works in the way I want it to, and the 40,000 lines are what I can just call without needing to care about the internals. (To use parent's 2-line example as a counterexample - grokking those two lines is not sufficient to build the WM of my dreams)
Please note that it is not written from scratch and is using a wlroots library that does most of the job. Most of the code are just the handlers for events emitted by the library. You cannot write a Wayland compositor and implement all required interfaces with just 500 lines.
My question would be: given that current Wayland implementation kills all my windows when an error happens, in contrast with X11 where the session is killed but the windows are kept; what is the behavior of this compositor regarding errors?
Same, a crash will kill all of your applications. But that's also what happens when xorg-server crashes. The difference is that window management is usually handled in a separate process, and if that process crashes you don't lose the windows themselves. xorg-server is generally stable enough so long as your graphics drivers are stable and you don't do anything weird. It'll take time for Wayland compositors to become similarly mature.
There has been some discussion around making Wayland compositors that behave similarly, and on crash reslience with a Wayland-specific design as well, notably:
It looks like you should just be able to run make so long as you have all the dev packages for wayland, wlroot, and xdg-shell installed for your given distribution.
the docs says -c termite but you need -s actually. nothing shows up just a grey screen. Also the ctrl-alt-Fn keys do not change console. Had to look up alt-esc on another computer to get out of it.
xorg-server does do more things than wlroots, but it's mostly legacy stuff. In terms of features anyone wants from a modern display server, they're pretty close. wlroots is repsonsible for spinning up an EGL context, talking to libinput, configuring DRM and KMS display resources, allocating GPU resources with GBM, negotiating pixel buffers with clients, etc, all things that xorg-server is doing for TinyWM.
It's a very effective way to show that the argument you just made can be easily turned around and at the same time mocks the argument or declares it silly.
It's not really rude but rather a pointer that the argument made is not standing on very solid legs.
Assuming you did some kind of primitive `find . -name "*.c" | wc -l` kind of operation to arrive at this number, you also got all of the rootston code. Rootston is a test compositor we use for working on wlroots but it's not actually included in the final wlroots package.
If Wayland is the "Linux desktop" then all the advantages are gone.
You do know that Wayland's design effectively destroys any choice and customization right? Wayland's protocol is basically an isolation prison that requires "big DE's" and destroys choice. The protocol moves everything into one central place called the "compositor" this machinery must provide:
- the window manager
- the hotkey daemon
-the compositing effects
-the windowing server
-screen reading tools
-screenshots
-screen casting
-magnifying glass tools
-global dictionary tools
-etc etc etc everything.
Wayland's design makes it impossible to write a portable hotkey daemon for instance. Supposedly for "security reasons". Wayland is a GNOME dev's dream, it kills the ability of people to control their own system. If you're actually excited for Wayland you either thoroughly misunderstand what it brings and just like it because it's new or you're a drooling GNOME-lover who hates customization.
This is FUD. One of wlroots core goals from day one has been to promote the standardization of cross-desktop protocols that allow for these features. We have already addressed two of the points you brought up, namely screenshots and screen casting, via these protocols:
3 delegates from wlroots, including myself, who together represent 8 distinct Wayland compositors, are joining 3 delegates from KDE at XDC 2018 to discuss the standardization of these protocols and propose them for integration across the whole ecosystem.
After 9 years there is not even anything close to a universal standard and discussion across compositors has just started this year. That's embarrassing.
There's already been universal standards under discussion for a long time, for example xdg-shell for application windows. The recent discussions are attempting to make more standards, and has been going on for 2 or 3 years now. This is a lot of work, we're replacing the X11 stack which has a legacy going back over 20 years.
Which is implemented by literally who? I can see a GNOME mutter commit but can't find anyone else from a few minutes of googling.
Also: "As of June 2014, XDG-Shell protocol was not versioned and still prone to changes. "[1]
Who else loves to build software atop unstable APIs?
>The recent discussions are attempting to make more standards, and has been going on for 2 or 3 years now.
These should've been going on since the begin, really makes you think what kind of intent the Wayland founders had. Wayland is being pushed as the future and there still isn't even a way to have a universal fucking screenshotter, I guess it's a security feature to be locked out of your own desktop, right?
Uh... everyone. Mutter, Kwin, qwayland, wlroots, wlc, Sway, waymonad, Way Cooler, Weston, Enlightenment, and Mir all support it, as well as clients like GTK+, Qt, GLFW, SDL, EFL...
Look, you don't have to use Wayland. No one has said it's done, and Xorg still works fine. If it doesn't support everything you need, then it's not for you, no big deal.
Kinda have to agree here. Wayland is clearly the way forward for Linux desktop, but it's still at least 10 years behind WDDM, and Linux desktop people have maintained their love of needless fragmentation so I doubt it will ever catch up.
https://news.ycombinator.com/item?id=17765446
And thought I'd whip up something for Wayland, too. Happy to answer questions about Wayland if anyone has some!