The future of Wayland, and Sway's role in it

After he releases 1.0, they are doing to focus on wlroots which he does mention in the post. It is looking really promising and even now sway is still very usable.

Do you have any pointers to info on using Hammerspoon as you describe above? I have a low dpi 4K (43") monitor and would like to be able to assign windows to pre-determined regions of the screen.

When work hands you a Macbook and you go ewww gross I get looks :) I HATE Mac OS user interface. It is so convoluted and decisions based on things that were wierd 15 years ago.

I doubt I'll get permission to install it on the mac. The mac is super locked down.

Windows 8 was a decient compromise for me but I am in the tiny minority that liked the Windows 8 interface it was the closest thing to a tiled window manager.

Well using a terminal splicer is different than a Tiled Window Manager. I love my ursvt with Tmux but that is a different beast then i3.

I think the primary use for layouts is for people that want complicated layouts of windows at startup that would be cumbersome to set up every time you log in.

I think in practice with as many workplaces as you like the most productive layouts on medium to small screens, which is to say most of them, is a number of workspaces each with a relatively simple layout and 1-3 windows only.

You can wrap the layout saving restoring functionality in a tiny bit of scripting to make it more useful on the fly. Basically the json isn't useful right from the rip because you have to manually uncomment whatever fields make a given window unique but a script can pretty much do that unless it requires a regex and window title to distinguish between 2 windows.

AMDGPU Pro is actually built on top of the open source driver, so if AMD wants and can commit its features into the open source driver it shouldn't be that hard. I don't know why they decided to build the proprietary interface if AMDGPU was working so well, maybe 3rd party licensed code?

As a consumer, I feel that Nvidia’s Linux support is shoddy at best. It seems like they do the bare minimum to get it to work. Some things work best with the proprietary drivers, some work best with the open source drivers. Then there are weird limitations on both, that don’t exist on other platforms.

Recently I finally managed to get 4K at 60fps over HDMI 2.0a working on Linux. For some reason the Nvidia drivers (both) only advertised 4K at 30fps, where as on Windows it works out of the box. I had to manually add my monitors EDID (which is extracted from Xorg in the first place), and now I get 4K 60fps HDR.

I hope AMD continue their rejuvenation, as it’s good to see Intel and Nvidia have some competition again.

Redshift works on sway. Use this fork: https://github.com/giucam/redshift

> Does working in VR sound appealing to you?

Heck yeah!

Not only because of feature-richness (a debugger that lets me climb up and down the execution stack sounds rad) but also for space-saving: I live in a school bus, so a 3-monitor standing desk isn't really a very viable option.

But if a VR or AR headset can turn a hallway into that, I'm in!

I used the automatic reporting tool. Reproduction is simple. Run firefox on NV44 (Ben used to have one. I have a spare with less RAM if anyone cares about nouveau on that any more). Bring up cookie clicker in the browser and let it run for a bit. It will crash.

More recently gnome crashes right after login, but then doesn't when I login a second time. I don't think the automatic reporting is working for this one.

I figure at this point I'll let it slide until I upgrade and then get more vigilant about reporting problems. Unfortunately the auto-upgrade didn't work for me this time, so I'll reinstall 26 or 27 from scratch.

From what I can tell, there are issues both with sway and alacritty that lead to the current incompatibility.

https://github.com/jwilm/alacritty/issues/97 https://github.com/swaywm/sway/issues/1390 https://github.com/swaywm/sway/issues/1054

From what I gather, alacritty and its window system abstraction layers (glutin & winit) are still somewhat immature w.r.t. their wayland support and that sway, due to the limited nature of its wlc layer, do not quite meet in the middle. As stated in TFA, sway is moving toward a more capable wlroots foundation. And the rust-based alacritty ecosystem is also moving forward with tremendous pace. I have little doubt that class of incompatibility will not exist much longer.

Given the newness of not just wayland, but also alacritty, glutin/winit, rust, and sway, I remain astonished that they work as well as they do. But make no mistake, wayland is new tech and thus has some sharp corners where X11 is a well-established quantity after 30 years of existence.

Yes, this is quite possible.. Wayland is much lower level than X11 so each compositor has to add its own additional protocols which could 'in theory' be incompatible but note that 1) these additional protocols are most of the time a port of the existings protocols 2) the real reason that a Gnome app can run on top of KDE and vice versa is not just because of X11, it's because the developers of the applications and the DE worked together to make it happen so as long as the will is still here the inter-operability will be here eventually. Eventually is important here because I expect a long instability period..

In theory, yes. In practice, you could build something on top of wlroots, which does a lot of the work for you. In fact, check this out:

https://github.com/swaywm/hsroots

An X window manager would likely have to be completely rewritten to work on Wayland, I doubt many of them have much abstraction of the underlying window system.

Sway 1.0 will have a different means of configuring the keyboard, but only incedentally. I think that there's nothing wrong with the environment variable approach _or_ with writing scripts.

The wayland protocol itself doesn't handle network transparency like X11 tries to (i say tries because there are issues with it). My understanding is that a large portion of it is done through shared memory, unix sockets and other things like that.

A detailed overview of it is here, https://en.wikipedia.org/wiki/Wayland_(display_server_protoc... .

Essentially the client connects to the socket created by the compositor and asks it to pass a surface (basically the same as a frame buffer) back that matches what the client wants to draw. The client then draws on the surface (via GL, raw pixels, cairo, etc.) and then tells the wayland compositor that the surface is ready to display. The surfaces can have a number of things set about them, such as the color depth, if they're hardware (gl, vulkan etc) capable and other things like that.

This is why it's hard to make wayland network transparent because the compistor and the client are much more intertwined than X11 and it's clients were. This enables better performance and eliminating tearing and a few other problems that X11 just isn't equipped to do normally. It does mean however that you should be able to make a wayland compositor that forwards the surfaces from itself to another wayland compositor similar to how X11 forwarding works, but this isn't specified as part of the wayland protocol itself.

My expectation for what will work best for that is something that allows using modern video and image compression to allow the transfer to occur without using as much bandwith as modern X11 apps require when forwarding them. This would also mean then that clients have to use the hardware available to them rather than the hardware available to the display server. With X11 it's possible to do GL remotely (i've never had that work well) but it'd be much more difficult to set this up over wayland.