8 ms·

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

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.

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.