Hacker News Reader

Comment by Sir_Cmpwn | Hacker News Reader

I saw this discussion yesterday:

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!

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 :)

[0] https://github.com/swaywm/wlr-protocols/blob/master/unstable...

Thank you, nice to know that I'm not completely of :-)

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

>> It can, that's how GNOME works today. It's not how it generally works on X, though, and it's not very modular.

We don't need modular.

>>>BTW, I'm hoping for animated wallpaper on my desktop

>> This is possible with the layer shell protocol I'm talking about.

It's also possible by building the feature into the compositor. No new protocols or possible security issues needed. Simpler is better in most cases.

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

[0] https://cgit.freedesktop.org/wayland/wayland-protocols/tree/...

For that to work,

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

No, it's definitely poorly thought out. This is one of the problems that we're trying to deal with over in the wlroots camp.

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.

Isn't that the way Windows handles decorations? I know if an app freezes on Windows sometimes I can't even move it around.

> 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:

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

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.

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 :-)

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.

Nice answer. Thanks. The example app looks like a great starting point.

In case you haven't found it yet, the "please draw a frame" event you get from the compositor is wl_surface.frame: https://wayland.freedesktop.org/docs/html/apa.html#protocol-...

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.

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.

I think I left a comment on the Lobsters thread about wondering what this would look like on Wayland. Pretty cool.

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.

I'd have to forward declare everything, which is annoying. It's a C thing.

What is the best entry-level documentation on Wayland that you know?

My blog posts:

https://duckduckgo.com/?q=site%3Adrewdevault.com+wayland&ia=...

can i just say that i love sway :D

Thanks <3

so this is like a simple weston?

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?

Yes. We have standardized a protocol which handles this.

Reply on news.ycombinator.com