12 ms·

Show HN: Wayland compositor in around 500 lines of annotated C

332 points by ddevault 8y ago

Sir_Cmpwn 8y ago
I saw this discussion yesterday: https://news.ycombinator.com/item?id=17765446 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!
- djsumdog 8y ago
  I think I left a comment on the Lobsters thread about wondering what this would look like on Wayland. Pretty cool.
- dtx1 8y ago
  can i just say that i love sway :D
  - Sir_Cmpwn 8y ago
    Thanks <3
- lllr_finger 8y ago
  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.
- rootlocus 8y ago
  What is the best entry-level documentation on Wayland that you know?
  - Sir_Cmpwn 8y ago
    My blog posts: https://duckduckgo.com/?q=site%3Adrewdevault.com+wayland&ia=web https://duckduckgo.com/?q=site%3Adrewdevault.com+wayland&ia=...
- mrweasel 8y ago
  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?
  - Sir_Cmpwn 8y ago
    >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 :) [0] https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-layer-shell-unstable-v1.xml https://github.com/swaywm/wlr-protocols/blob/master/unstable...
    - mrweasel 8y ago
      Thank you, nice to know that I'm not completely of :-)
    - phkahler 8y ago
- billconan 8y ago
  so this is like a simple weston?
  - Sir_Cmpwn 8y ago
    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.
- abainbridge 8y ago
  > 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.
  - Sir_Cmpwn 8y ago
    >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: https://drewdevault.com/2017/06/10/Introduction-to-Wayland.html https://drewdevault.com/2017/06/10/Introduction-to-Wayland.h... A friend of mine (and core contributor to wlroots) has written a dead-simple example client you can check out as well: https://github.com/emersion/hello-wayland https://github.com/emersion/hello-wayland
    - bitwize 8y ago
      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.
- s73v3r_ 8y ago
  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.
  - Sir_Cmpwn 8y ago
    I'd have to forward declare everything, which is annoying. It's a C thing.
- microcolonel 8y ago
  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?
  - Sir_Cmpwn 8y ago
    Yes. We have standardized a protocol which handles this.
rain1 8y ago
How do I use this on arch linux?
- Sir_Cmpwn 8y ago
  There are instructions in the comments at the top of the C file, should work fine on Arch Linux.
- djsumdog 8y ago
  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.
  - Sir_Cmpwn 8y ago
    The package for xdg-shell is likely called "wayland-protocols".
- rain1 8y ago
  lol you need this which is 40k lines of code https://github.com/swaywm/wlroots.git https://github.com/swaywm/wlroots.git only 500 lines of code (plus 40k but whose counting)
  - Sir_Cmpwn 8y ago
    TinyWM also needs all of this code: https://cgit.freedesktop.org/xorg/xserver/ https://cgit.freedesktop.org/xorg/xserver/ ~500,000 lines of code that wlroots does not depend on, but who's counting.
    - rain1 8y ago
      hate that rude thing people do where they mimic you. Don't do that.
      - zaarn 8y ago
simias 8y ago
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?
- gfiorav 8y ago
  I wouldn't worry too much. I'm sure tiling functionality can be plugged in (i.e. some special snap app like gnome-snap, or something similar)
- PaulHoule 8y ago
  Wayland works the way that Windows has since Windows Vista.
  - yjftsjthsd-h 8y ago
    ...is this an endorsement or a downside?
    - PaulHoule 8y ago
      just a fact.
  - emersion 8y ago
    Hmm, I don't think you could say that. Wayland restricts a lot more what clients can do.
aleksis 8y ago
Without wlroots it would need several times more loc.
- Sir_Cmpwn 8y ago
  Without Xlib and the X11 server, so would TinyWM.
- Shish2k 8y ago
  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
  - rain1 8y ago
    totally missing the point edit: can't reply to you because of all the downvotes
    - Shish2k 8y ago
      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?
      - evmar 8y ago
        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.
amarant 8y ago
you actually went and did it! not that I doubted it ;) thanks, your contributions to the community are invaluable! this looks like a pretty awesome way to learn wayland :)
kazinator 8y ago
For values of 500 exceeding 900, this is about 500 lines.
- sp332 8y ago
  It says 500 lines of C.
  - kazinator 8y ago
    Ah, OK. 500 lines of C, which are (further) annotated.
    - rain1 8y ago
      600
gnomewascool 8y ago
This is very valuable educationally! Thanks! A slightly less minimal, but still small — 2000 lines total among all files — DE, leveraging Mir†, rather than wlroots, is here: https://github.com/AlanGriffiths/egmde https://github.com/AlanGriffiths/egmde † yes, Mir can now use the wayland protocol [trigger warning: C++]
- Sammi 8y ago
  I'm confused. Wasn't Mir supposed to be an alternative to Wayland?
  - Sir_Cmpwn 8y ago
    It was, but when it became clear that Wayland was winning they changed gears and started developing it into a generic Wayland compositor instead.
  - gnomewascool 8y ago
    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.)
    - eximius 8y ago
      If they had used Mir as a test bed like Chalk is for Rust, it might have made sense.
magicalhippo 8y ago
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.
- Sir_Cmpwn 8y ago
  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. [0] https://lists.freedesktop.org/archives/wayland-devel/2018-August/039237.html https://lists.freedesktop.org/archives/wayland-devel/2018-Au... [1] https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-export-dmabuf-unstable-v1.xml https://github.com/swaywm/wlr-protocols/blob/master/unstable...
  - magicalhippo 8y ago
    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.
  - codedokode 8y ago
tomcam 8y ago
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.
- Sir_Cmpwn 8y ago
  Any of these projects could use your help :) https://github.com/swaywm/wlroots https://github.com/swaywm/wlroots https://github.com/swaywm/wlroots/wiki https://github.com/swaywm/wlroots/wiki
deleted 8y ago
[deleted]
chris111 8y ago
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.
- Sir_Cmpwn 8y ago
  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: https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-screencopy-unstable-v1.xml https://github.com/swaywm/wlr-protocols/blob/master/unstable... https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-export-dmabuf-unstable-v1.xml https://github.com/swaywm/wlr-protocols/blob/master/unstable... There are several more protocols we have written and are working on to address similar concerns: https://github.com/swaywm/wlr-protocols/issues https://github.com/swaywm/wlr-protocols/issues 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.
  - chris111 8y ago
    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.
Shorel 8y ago
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?
- Sir_Cmpwn 8y ago
  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: https://arcan-fe.com/2017/12/24/crash-resilient-wayland-compositing/ https://arcan-fe.com/2017/12/24/crash-resilient-wayland-comp...
vthriller 8y ago
> seat, <…> conceptually includes up to one keyboard, pointer, touch, and drawing tablet device. So it seems that hacks like [0] are impossible here. Is this a limitation of protocol or just this compositor (and/or wlroots library)? [0] https://news.ycombinator.com/item?id=17760255 https://news.ycombinator.com/item?id=17760255
- Sir_Cmpwn 8y ago
  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.
codedokode 8y ago
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.

332 points by ddevault 8y ago

I saw this discussion yesterday: https://news.ycombinator.com/item?id=17765446 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!

djsumdog 8y ago
I think I left a comment on the Lobsters thread about wondering what this would look like on Wayland. Pretty cool.
dtx1 8y ago
can i just say that i love sway :D
- Sir_Cmpwn 8y ago
  Thanks <3
lllr_finger 8y ago
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.
rootlocus 8y ago
What is the best entry-level documentation on Wayland that you know?
- Sir_Cmpwn 8y ago
  My blog posts: https://duckduckgo.com/?q=site%3Adrewdevault.com+wayland&ia=web https://duckduckgo.com/?q=site%3Adrewdevault.com+wayland&ia=...
mrweasel 8y ago
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?
- Sir_Cmpwn 8y ago
  >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 :) [0] https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-layer-shell-unstable-v1.xml https://github.com/swaywm/wlr-protocols/blob/master/unstable...
  - mrweasel 8y ago
    Thank you, nice to know that I'm not completely of :-)
  - phkahler 8y ago
billconan 8y ago
so this is like a simple weston?
- Sir_Cmpwn 8y ago
  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.
abainbridge 8y ago
> 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.
- Sir_Cmpwn 8y ago
  >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: https://drewdevault.com/2017/06/10/Introduction-to-Wayland.html https://drewdevault.com/2017/06/10/Introduction-to-Wayland.h... A friend of mine (and core contributor to wlroots) has written a dead-simple example client you can check out as well: https://github.com/emersion/hello-wayland https://github.com/emersion/hello-wayland
  - bitwize 8y ago
    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.
s73v3r_ 8y ago
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.
- Sir_Cmpwn 8y ago
  I'd have to forward declare everything, which is annoying. It's a C thing.
microcolonel 8y ago
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?
- Sir_Cmpwn 8y ago
  Yes. We have standardized a protocol which handles this.

rain1 8y ago

How do I use this on arch linux?

Sir_Cmpwn 8y ago
There are instructions in the comments at the top of the C file, should work fine on Arch Linux.
djsumdog 8y ago
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.
- Sir_Cmpwn 8y ago
  The package for xdg-shell is likely called "wayland-protocols".
rain1 8y ago
lol you need this which is 40k lines of code https://github.com/swaywm/wlroots.git https://github.com/swaywm/wlroots.git only 500 lines of code (plus 40k but whose counting)
- Sir_Cmpwn 8y ago
  TinyWM also needs all of this code: https://cgit.freedesktop.org/xorg/xserver/ https://cgit.freedesktop.org/xorg/xserver/ ~500,000 lines of code that wlroots does not depend on, but who's counting.
  - rain1 8y ago
    hate that rude thing people do where they mimic you. Don't do that.
    - zaarn 8y ago

simias 8y ago

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?

gfiorav 8y ago
I wouldn't worry too much. I'm sure tiling functionality can be plugged in (i.e. some special snap app like gnome-snap, or something similar)
PaulHoule 8y ago
Wayland works the way that Windows has since Windows Vista.
- yjftsjthsd-h 8y ago
  ...is this an endorsement or a downside?
  - PaulHoule 8y ago
    just a fact.
- emersion 8y ago
  Hmm, I don't think you could say that. Wayland restricts a lot more what clients can do.

aleksis 8y ago

Without wlroots it would need several times more loc.

Sir_Cmpwn 8y ago
Without Xlib and the X11 server, so would TinyWM.
Shish2k 8y ago
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
- rain1 8y ago
  totally missing the point edit: can't reply to you because of all the downvotes
  - Shish2k 8y ago
    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?
    - evmar 8y ago
      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.

amarant 8y ago

you actually went and did it! not that I doubted it ;) thanks, your contributions to the community are invaluable! this looks like a pretty awesome way to learn wayland :)

kazinator 8y ago

For values of 500 exceeding 900, this is about 500 lines.

sp332 8y ago
It says 500 lines of C.
- kazinator 8y ago
  Ah, OK. 500 lines of C, which are (further) annotated.
  - rain1 8y ago
    600

gnomewascool 8y ago

This is very valuable educationally! Thanks! A slightly less minimal, but still small — 2000 lines total among all files — DE, leveraging Mir†, rather than wlroots, is here: https://github.com/AlanGriffiths/egmde https://github.com/AlanGriffiths/egmde † yes, Mir can now use the wayland protocol [trigger warning: C++]

Sammi 8y ago
I'm confused. Wasn't Mir supposed to be an alternative to Wayland?
- Sir_Cmpwn 8y ago
  It was, but when it became clear that Wayland was winning they changed gears and started developing it into a generic Wayland compositor instead.
- gnomewascool 8y ago
  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.)
  - eximius 8y ago
    If they had used Mir as a test bed like Chalk is for Rust, it might have made sense.

magicalhippo 8y ago

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.

Sir_Cmpwn 8y ago
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. [0] https://lists.freedesktop.org/archives/wayland-devel/2018-August/039237.html https://lists.freedesktop.org/archives/wayland-devel/2018-Au... [1] https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-export-dmabuf-unstable-v1.xml https://github.com/swaywm/wlr-protocols/blob/master/unstable...
- magicalhippo 8y ago
  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.
- codedokode 8y ago

tomcam 8y ago

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.

Sir_Cmpwn 8y ago
Any of these projects could use your help :) https://github.com/swaywm/wlroots https://github.com/swaywm/wlroots https://github.com/swaywm/wlroots/wiki https://github.com/swaywm/wlroots/wiki

deleted 8y ago

[deleted]

chris111 8y ago

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.

Sir_Cmpwn 8y ago
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: https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-screencopy-unstable-v1.xml https://github.com/swaywm/wlr-protocols/blob/master/unstable... https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-export-dmabuf-unstable-v1.xml https://github.com/swaywm/wlr-protocols/blob/master/unstable... There are several more protocols we have written and are working on to address similar concerns: https://github.com/swaywm/wlr-protocols/issues https://github.com/swaywm/wlr-protocols/issues 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.
- chris111 8y ago
  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.

Shorel 8y ago

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?

Sir_Cmpwn 8y ago
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: https://arcan-fe.com/2017/12/24/crash-resilient-wayland-compositing/ https://arcan-fe.com/2017/12/24/crash-resilient-wayland-comp...

vthriller 8y ago

> seat, <…> conceptually includes up to one keyboard, pointer, touch, and drawing tablet device. So it seems that hacks like [0] are impossible here. Is this a limitation of protocol or just this compositor (and/or wlroots library)? [0] https://news.ycombinator.com/item?id=17760255 https://news.ycombinator.com/item?id=17760255

Sir_Cmpwn 8y ago
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.

codedokode 8y ago

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.