Well, if you dug a bit deeper and checked out the github repo it stands for: "SirCmpwn's Wayland compositor" I think the reference you are trying to draw is unrelated.
Edit: Found it on Wikipedia. Ignore me but the Sway acronym still stands.
> largely unrelated, but why is this and its reference compositor named after adjacent metro boston towns?
They were driving through Wayland when they came up with the idea for the project. (Wayland and Weston are neighboring towns and sports rivals, so it sort of fits to use Weston as the name of the reference implementation.)
As an i3 user who harbors a non-zero amount of hatred for X11 it's exciting to see sway has (nearly!) reached 1.0! I had the checklist for feature parity with i3 bookmarked so I could check in on it but I've forgotten to look at it recently, so it's nice to have this reminder pop up here!
Looks like i3-gaps support is basically done so I have no excuse not to switch over now. Good work SirCmpwn and everyone else who helped!
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.
I've always wanted to try my hand at making a window manager(or what is now called a compositor I think), so I may use wlroots as my base when it's done(or at least more done). The article confused me a bit, is the goal to have wlroots 'done' for the 1.0 release, or to release the 1.0, and then at some point move it over to wlroots?
We're releasing sway 0.15 based on wlc. It will be the final wlc-based release, and the final 0.x release. The subsequent release, 1.0, will be based on wlroots, which is nearing completion now. https://github.com/swaywm/wlroots
I just wish there was a way to use it on Windows and Mac OS! i3 and Window Tiling is such a better user interface for my work flow. I have having to use the mouse or track pad.
On macOS I use Hammerspoon which I have configured to move and resize windows to specific slots. It's not the same as tiling but it relieves me from having to move windows around manually. On Windows there is Window Sizer or similar.
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.
What's different for mine is that I use a single prefix key, that pops up a notification giving you information what you can do next, and then I press one of those keys. I don't need to move windows that often, so having to hit two keys is not a problem. And it prevents Hammerspoon from hogging too many key combinations.
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.
Sometimes it's not about autonomy, but simply the availability of tools. Lots of software for various industries is OS-specific, so you may not have a choice but to use a certain OS for work (usually Windows, but macOS in the case of iOS development).
I agree with the sentiment but I think it very much depends on the role. I wouldn't expect iOS development to happen on another platform for instance. There are probably many niches with similar constraints.
I was really surprised how well a modest VM (Virtual box etc) with Ubuntu + X11 + i3 runs. I use that fullscreen in a virtual desktop to switch between host OS and Linux/i3 and am increasingly surprised by how much time I am finding myself in the "simple" VM which flies and the host OS. I've found it a great way to make a simple first step to switching over on the desktop.
Emacs does what i3wm does... When I have to use Windows I used emacs as much as I can and just switch between other full screen windows like web browser etc. Obviously not as good, but not too far away.
There are quite a few tiling window managers for either of those OSes, you just need to do some googling.
I develop and use Stack on Windows. https://losttech.software/stack.html
I wish they hadn't decided to not support layout saving. Really liked that feature from i3. I suppose it'll be possible to cobble something together in a bash script that arranges everything the way I like on boot, but annoying.
I found layout saving cumbersome in i3, mostly because of the manual editing you would sometimes have to do to the JSON file[1]. I have used it a few times, and didn't run into many of the common problems, but there have been many layout related questions/problems on the i3 subreddit.
I wonder if because people had so many problems with it the developer chose to skip over it due to lack of demand. Surely there's a better way to implement it, but that way may break compatibility with i3. This is all speculation of course.
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.
I've been awaiting sway as well. My big issue has been rotated displays, since I have two vertical monitors that this simply wouldn't work with.
After that there's also the Nvidia proprietary drivers not supporting Wayland, but I'll be switching to a FOSS driver stack with AMD by the time 1.0 hits.
I got a Fury to try to show support during the initial releases of AMDGPU. I'm not sure if they noticed but it gave me a good reason to ditch my gtx 770 :D
AMDGPU is really good now, and the parts that are proprietary (AMDGPU Pro) are eventually (hopefully) going to be folded into the FOSS side soon.
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?
I believe it does have to do with 3rd party licensing. Last time I checked the freesync portion of the driver was only in AMDGPU-Pro, which is what I'm looking forward to the most.
It's sort of sad that nvidia does actually support wayland, but only on embedded side. Can't say how good the drivers are but I've worked for a good while for nvidia tegra's & wayland and they well. There was one issue one the drivers that I had access to: mmaped memory leaked file descriptors but besides that, performance was better than other hw in similar price range I was provided with.
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.
No need to wait. AFAIK currently there is no way in the 'pure wayland' world to display remotely windows unless you use X11.
Are there VNC application on top of Wayland?
"Sway is a tiling Wayland compositor, if you didn’t know."
Let me just say thank you very much for adding this sentence :)
I feel like 50% of headlines on HN are written like "New version of qx58g" and somehow none of the headline, the comments, or the linked article will give any indication what qx58g is.
Great - is this any relation to the 2 Pandoras or the several Nexuses? Does this play music on my phone or move assets into a VM? Neither, it syncs bookmarks between browsers.
Yeah. The "why do I care?" part if often missing from posts on HN.
The other posts I see are the ones exclaiming "X is harmful" while often only presenting a very narrowly construed use case, that doesnt fit the norm - or making a big to do about a nothing - another trope is posts promoting YAPL (yet another programming language) and YAF (yet another
framework) - without making it clear why this programming language or framework is any better than the eleventeen other ones.
My favorite ones are the projects with project pages that describe themselves in terms of other buzzwordy project and trend names.
"Buzzy is a new rewrite of Salad using an extensible monad-free Vomit dialect based on modern neopatterns. (note you'll need FooQwang3.7.2.1-R2 extensions installed in your pillar-tab in order to use it interactively)"
At least techno-babble [1] could make you feel intimidated. This word salad nonsense just makes me feel utterly lost and apathetic.
First time I hear about wlc. And I'm curious about something. Does wlc only help to write compositors or can Window/3D libraries also access that? For example when writing a 3D library which should run on Wayland - do I have to write support for every compositor out there to get things like input and copy-paste working or is there a common base-library I can use (like wlc maybe)?
I've been happily using sway everywhere I've found it to be stable. At the moment that's every machine I have access to that has intel or AMD graphics. I think my one system with nouveau graphics may be ready to convert from i3 also, since I've been trying it periodically and it seems to be OK. The one machine I'm still scared to touch has to use nvidia because it flat-out refuses to work with nouveau. At any rate, I'm quite pleased with sway. It's compatible with i3 to the point that I often forget which one I'm using.
Can anyone share his/her experience with Wayland? I'm on Arch, using i3wm, and have thought about switching to Wayland, but I'm not sure what problems I will encounter, and I would love to not have to spend a weekend to fix or revert back to X11 if things are still immature. Has anyone used it daily for a decent amount of time?
I tried using it on Fedora 26, where it's the default. It worked well. I tried to install binary Nvidia drivers since that's supposedly possible with some hackery, but couldn't get it to work.
I run it on Fedora 25. It's nice, but Firefox still uses xwayland and tends to crash the entire session too often. This may be my ancient video card, or it may be xwayland or some combination. Everything else works quite well and I'm looking forward to Fedora 27 which will hopefully fix my issue.
Firefox IMHO really needs to get native Wayland support out of the box. Not sure if Fedora is using the wayland version of LibreOffice, but it should be by now.
Firefox is undergoing a major redesign of the engine, so may be after its switch to WebRender, Wayland support will get some traction. I suspect it's the reason for several other features being stalled in Firefox now as well, like hardware accelerated video playback.
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.
It's progressing in KDE, but it's not quite there yet. Some applications still require XWayland are not even moving to Wayland so far, and XWayland path has its own bugs.
For instance Wine was quite glitchy for me (mouse movements were messed up) last time I tried it under XWayland in KDE.
KDE just shipped Plasma 5.11 which I would consider the beta of Wayland. It is almost there, but it has its fair of glitches, but none of them seem to be game breaking or complicated to overcome at this point.
I compare Plasma Wayland now to Plasma X 5.2-5.4. Almost there, and in two or so releases it should be prime.
Using Ubuntu 17.10 with Gnome and Wayland. Fast and stable.
Before that and a small step to Ubuntu 17.04, I used Wayland with Arch and Gnome. Not that stable experience back then, but now I'd say it's ready for production use, at least if you're using an Intel GPU.
I have been running sway on Arch on an XPS13 for the past nine months. As a longtime i3 user, I found the transition as painless as I could have hoped given the bleeding-edge nature of the wayland+sway stack.
A couple of findings from my time with sway:
- It was non-obvious how to tweak keyboard options (I like remapping capslock to ctrl). Various XKB_DEFAULT_* environment variables have to be set before starting sway.
- Firefox used to render poorly due to HiDPI scaling issues. Those seem to have been resolved and FF now works like a champ.
- I was excited about using alacritty as a wayland-native terminal, but it does not yet work with sway. It can be run as an X11 client with sway without issue. Hopefully the wlroots situation helps resolve the remaining issues with alacritty.
- Integer-only display scaling made it somewhat challenging to achieve my sweet-spot for my HiDPI display. I ended up not scaling the display (scale=1) and adjusting various font sizes. I'm happy to see that wlroots will enable fractional display scaling.
> I was excited about using alacritty as a wayland-native terminal, but it does not yet work with sway.
Forgive me if I'm being dense, but: do you mean it's possible for a Wayland app to be incompatible with a particular Wayland window manager (or compositor)? That seems like a huge regression from the X11 status quo.
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.
So it does sound like there's a potentially incompatible layer of libraries between application and WM to a degree that isn't really the case with X11, by design. Well, I hope standardization happens quickly. One of the things I like about X11 is how agnostic applications and WMs are to each other, as well as how applications written years and years ago are still compatible with modern X servers.
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..
It's very close to be able to be working with the HTC Vive. With this, you could put on a headset and see 50 terminals in front of you, next to your 50 web browsers :)
Text resolution is the main issue; on current hardware, it's still not good enough to use for extended periods of time, but I think this is partially because nobody has bothered to optimize 3D text rendering to the extent that a viable 3D Desktop would require it.
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'm getting confused about the term 'compositor'. I thought it was something like Compton, which sat between the application and X to combine layers on the GPU. The word has a similar meaning when talking about, say, browser rendering.
But sway is much more than that – it manages windows, handles input, etc. Why does it refer to itself as a compositor everywhere?
I believe this is a result of wayland. The window manager now includes what you think of as compositing in the world of X11. The compositor just also happens to do the window placement. I think. I do not yet understand wayland, so if someone knows more I'd love if they shared.
Few years back when I was working with Wayland on a particular automotive project I came up with an explanation we could use with those outside the project.
Wayland is a protocol, which isn't really instructive. But the reference implementation, libwayland, is easier to comprehend. You can think of libwayland as a library for writing window managers directly on the framebuffer. Sure - that's a lie, but it's a helpful lie.
So does that mean that if you wanted to port, say, Xmonad to Wayland, you would have to reimplement compositing logic again? (Since the existing compositing-logic implementation also handles things like window placement that you would want to override)
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.
Alas, I've still seen no news of X11 forwarding or an equivalent capability. I've heard that it isn't wayland's job anymore, but nothing to replace that major feature yet.
Are there any sort of dead simple Wayland compositors, like MWM or OpenBox, for people who doesn't want the full KDE or Gnome desktop, but still prefer a tiling windows manager.
Is this still the only way to use Wayland that doesn't require running everything on a single machine? I still don't understand why Wayland is getting so much attention when it doesn't seem to have any native clients.
While I'd be surprised if it doesn't work for that, Xwayland support is more for running older X11 programs that either haven't or won't receive a wayland port. It'd the way for backwards compatibility so that it's not an all or nothing endeavor.
When an app has been ported to Wayland, how does it work? At the risk of sounding dumb, how do the pixels get from the datacenter to the framebuffer if not by Xwayland?
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.
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.
I've used i3 for many years now. It's wonderful to see a tiling WM for Wayland with near feature-parity to i3. It probably makes it much easier when i3 has avoided feature creep, and has clean readable code.
Being a happy i3 user, as promising as sway is, I was disappointed last time I tried it, due to usability concerns to do with very basic functionality.
Specifically, the necessary hops for just setting the keymap.
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.
i3 doesn't have any keyboard configuration options, so... unless you're just talking about keybindings, which you can totally reconfigure in Sway and reload without restarting. What you can't do in either is set the keymap on the fly without restarting. This is something you can do on i3 but it's an X thing, unrelated to the i3 config. On sway you can configure multiple keymaps ahead of time and switch between them without restarting, but cannot change the configured keymaps on the fly.
Changing your keymap at runtime is something we hope to have in sway 1.0. We'd also like to support multiple keyboards with different keymaps and even configuring which keymap you use on specific windows.
Is there any sense of if/when nvidia's proprietary drivers will work with Wayland? I built a new machine with an Nvidia 1080Ti less than 4 weeks ago. I'd rather not have to switch...
Unfortunately, no. It's entirely up to NVIDIA to fully support KMS and Wayland, since they make a proprietary out-of-tree driver, and it doesn't seem likely in the near future.
This is, IMHO, the biggest advantage (other than hardware cost) that AMD has over NVIDIA right now.
You are making bad choices as a consumer by spending all of that money on flashy new graphics cards from Nvidia. I'm not interested in supporting a company that treats Linux as poorly as Nvidia does. Buy cards that have good open source driver support. The burden is not on sway to support Nvidia, but on Nvidia to support sway. AMD and Intel seemed to manage it just fine.
I would have loved switching to Sway back when I tried it months ago, but what held me back was the clipboard story between X and Wayland apps being either finicky or nonexistent. Has this been solved yet, as in, is there a way to copy-paste between X and Wayland apps?
113 comments
[ 3.4 ms ] story [ 184 ms ] threadrootston -> pun on weston, the official wayland reference compositor
Edit: Found it on Wikipedia. Ignore me but the Sway acronym still stands.
They were driving through Wayland when they came up with the idea for the project. (Wayland and Weston are neighboring towns and sports rivals, so it sort of fits to use Weston as the name of the reference implementation.)
Looks like i3-gaps support is basically done so I have no excuse not to switch over now. Good work SirCmpwn and everyone else who helped!
https://github.com/kgrossjo/hammerspoon-config
What's different for mine is that I use a single prefix key, that pops up a notification giving you information what you can do next, and then I press one of those keys. I don't need to move windows that often, so having to hit two keys is not a problem. And it prevents Hammerspoon from hogging too many key combinations.
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.
I wonder if because people had so many problems with it the developer chose to skip over it due to lack of demand. Surely there's a better way to implement it, but that way may break compatibility with i3. This is all speculation of course.
[1] https://i3wm.org/docs/layout-saving.html#_restoring_a_vertic...
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.
After that there's also the Nvidia proprietary drivers not supporting Wayland, but I'll be switching to a FOSS driver stack with AMD by the time 1.0 hits.
AMDGPU is really good now, and the parts that are proprietary (AMDGPU Pro) are eventually (hopefully) going to be folded into the FOSS side soon.
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.
https://github.com/jonls/redshift/issues/260
Let me just say thank you very much for adding this sentence :)
I feel like 50% of headlines on HN are written like "New version of qx58g" and somehow none of the headline, the comments, or the linked article will give any indication what qx58g is.
"New version of Pandora Nexus released."
Great - is this any relation to the 2 Pandoras or the several Nexuses? Does this play music on my phone or move assets into a VM? Neither, it syncs bookmarks between browsers.
Eventually we're going to run out of fancy nouns.
The other posts I see are the ones exclaiming "X is harmful" while often only presenting a very narrowly construed use case, that doesnt fit the norm - or making a big to do about a nothing - another trope is posts promoting YAPL (yet another programming language) and YAF (yet another framework) - without making it clear why this programming language or framework is any better than the eleventeen other ones.
I think you have to know that Wayland uses the word "compositor" in a slightly odd way to get the right guess first.
"Buzzy is a new rewrite of Salad using an extensible monad-free Vomit dialect based on modern neopatterns. (note you'll need FooQwang3.7.2.1-R2 extensions installed in your pillar-tab in order to use it interactively)"
At least techno-babble [1] could make you feel intimidated. This word salad nonsense just makes me feel utterly lost and apathetic.
1 - https://www.youtube.com/watch?v=PnkT6C9Ose8
https://drewdevault.com/2017/06/10/Introduction-to-Wayland.h...
For rendering clients will generally either use shared memory and dump pixels buffers into it, or will use shared EGL handles.
I've been using wayland for ~6 months now and except for the aforementioned limitations it has been working flawlessly for me.
Firefox IMHO really needs to get native Wayland support out of the box. Not sure if Fedora is using the wayland version of LibreOffice, but it should be by now.
step 2: make 'x compatibility' terrible
step 3: profit!
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.
Hacker News isn't the right place for your bug report, though, please file a GitHub issue here: https://github.com/swaywm/sway/issues/new
Works pretty good in my experience.
For instance Wine was quite glitchy for me (mouse movements were messed up) last time I tried it under XWayland in KDE.
I compare Plasma Wayland now to Plasma X 5.2-5.4. Almost there, and in two or so releases it should be prime.
Before that and a small step to Ubuntu 17.04, I used Wayland with Arch and Gnome. Not that stable experience back then, but now I'd say it's ready for production use, at least if you're using an Intel GPU.
A couple of findings from my time with sway:
- It was non-obvious how to tweak keyboard options (I like remapping capslock to ctrl). Various XKB_DEFAULT_* environment variables have to be set before starting sway.
- Firefox used to render poorly due to HiDPI scaling issues. Those seem to have been resolved and FF now works like a champ.
- I was excited about using alacritty as a wayland-native terminal, but it does not yet work with sway. It can be run as an X11 client with sway without issue. Hopefully the wlroots situation helps resolve the remaining issues with alacritty.
- Integer-only display scaling made it somewhat challenging to achieve my sweet-spot for my HiDPI display. I ended up not scaling the display (scale=1) and adjusting various font sizes. I'm happy to see that wlroots will enable fractional display scaling.
Sway has made an X11-free system viable for me.
Forgive me if I'm being dense, but: do you mean it's possible for a Wayland app to be incompatible with a particular Wayland window manager (or compositor)? That seems like a huge regression from the X11 status quo.
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.
It's very close to be able to be working with the HTC Vive. With this, you could put on a headset and see 50 terminals in front of you, next to your 50 web browsers :)
Is it actually possible with current hardware to have a workable development environment... err... ... world?
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!
http://thisisthebus.com/travels.html
But sway is much more than that – it manages windows, handles input, etc. Why does it refer to itself as a compositor everywhere?
edit: that was sort of correct. More info here: https://en.wikipedia.org/wiki/Wayland_(display_server_protoc...
Wayland is a protocol, which isn't really instructive. But the reference implementation, libwayland, is easier to comprehend. You can think of libwayland as a library for writing window managers directly on the framebuffer. Sure - that's a lie, but it's a helpful lie.
Previously: displays & input devices -> xorg-server -> compton -> window manager -> X11 protocol -> X11 clients
Now: displays & input devices -> wayland compositor -> wayland protocol -> wayland clients
https://github.com/swaywm/hsroots
> Xwayland (X11) support
Is this still the only way to use Wayland that doesn't require running everything on a single machine? I still don't understand why Wayland is getting so much attention when it doesn't seem to have any native clients.
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.
Specifically, the necessary hops for just setting the keymap.
Sure. Which needs to be in the env sway gets passed. Which makes for some seriously ugly wrapper script needed, just to pass the stupid variable.
>If you can't set an environment variable then power user tools probably are not for you.
I think you're missing the point. It'll be a shame if sway 1.0 is released like this.
Can you do the same with sway without restarting it?
Changing your keymap at runtime is something we hope to have in sway 1.0. We'd also like to support multiple keyboards with different keymaps and even configuring which keymap you use on specific windows.
I'm looking forward to giving Sway and Wayland a try.
This is, IMHO, the biggest advantage (other than hardware cost) that AMD has over NVIDIA right now.