12 ms·

Writing a Wayland Compositor, Part 1: Hello Wlroots

195 points by ddevault 9y ago

shmerl 9y ago
Is there something like xinput for Wayland? I tried switching to Wayland session in recent KDE Plasma 5.12.0, but lost the setting that emulated middle click with left + right clicks, that I was setting with xinput.
- ddevault 9y ago
  I'm afraid not. Some configuration via libinput is possible, but they have been nerfing a lot of features like that. In the future I intend to close some of this gap at the compositor level, but that's not prioritized right now.
  - phs2501 9y ago
    One of the most annoying input-related things that happened to my desktop (Arch) in the last year is when evdev got replaced with libinput by default as the X11 input module. Easy enough to revert, but quite frustrating trying to figure out why mouse acceleration suddenly feels acutely horrible. All the tweakable options were different (and fewer) in xinput, and I was not able to recreate an acceleration curve that felt comfortable. I realize it's an old refrain, but its quite frustrating having old, featureful software replaced with new, more limited/broken versions.
    - lima 9y ago
      I fully agree. However, it can go the other way, too: my ThinkPad trackpad (with virtual buttons for the trackpoint) FINALLY started working properly with libinput, with zero configuration, after weeks of tweaking evdev options without success. YMMV... It did break two-finger-drag though :( On the general topic of removing functionality: I get where they're coming from. I had a look at the old synaptics evdev code, and it really complicated with tons of long-forgotten special cases and obscure settings. I see why they're actively getting rid of those, the libinput code is much nicer to look at (and, presumably, maintain). I just wish they weren't that aggressive about it...
      - nitrogen 9y ago
        It's just as likely that the removal of all those forgotten special cases is exactly what's ruining the experience for those complaining about the switch. Throw away the old ugly code, bring back the old ugly bugs...
        yjftsjthsd-h 9y ago
        Yeah, the thing about "really complicated with tons of long-forgotten special cases and obscure settings" is that people were using those settings, and those special cases were fixing bugs and allowing odd uses. Your rewrite is simple and elegant... until you fix all the bugs and make it feature-complete, by which point you will accumulate your own pile of ugly hacks. Then the next generation comes along and says, "Why all the hacks? We should rewrite this. We will surely not have such odd-looking code!" Rinse, repeat.
        zenhack 9y ago
        Yeah, but there are also often a lot of things that just genuinely don't make sense anymore. Xterm is packed with support for an insane number of old tty devices that no one needs. There are plenty of terminal emulators that successfully skip all that and no one ever complains. I don't know of a magic formula for being able to tell the difference, so it's hard thing to talk about in the abstract.
        yjftsjthsd-h 9y ago
        > devices that no one needs Maybe it's this? Nobody would care if you rolled out X11.1 that was perfectly compatible with everything in use and dropping stuff that nobody will miss. We care because Wayland killed features that we are actively using.
  - shmerl 9y ago
    That's a pity. I'll check if KWin has any way to configure libinput beyond very limited KDE system settings.
- jcrben 9y ago
  I was just looking at a similar topic yesterday - trying to find a Wayland-compatible replacement to tools such as xdotool or xcape (see e.g. https://askubuntu.com/questions/956640/equivalent-to-xdotool-for-wayland/977801#comment1630814_977801 https://askubuntu.com/questions/956640/equivalent-to-xdotool...). People keep saying this was "decided" for security, but usually with no sources cited. I wasn't able to find a firm decision and discussion/roadmap. Instead it seems more like it was viewed as "handling this in a secure way is hard, let's skip trying to figure it out". Which is pretty sad, since as far as I can tell users didn't really get much in the way of tangible benefits from Wayland aside from security (altho the KWin maintainer points to Wayland being easier to test automatically https://blog.martin-graesslin.com/blog/2018/01/kwinx11-is-feature-frozen/ https://blog.martin-graesslin.com/blog/2018/01/kwinx11-is-fe...). I found a RFC on a mailing list: [RFC] Interface for injection of input events (https://lists.freedesktop.org/archives/wayland-devel/2017-March/033514.html https://lists.freedesktop.org/archives/wayland-devel/2017-Ma...) where the xdotools maintainer chimed in with some thoughts. But it seems to have died quick. I then scoured the Wayland freedesktop bugs (https://bugs.freedesktop.org/describecomponents.cgi?product=Wayland https://bugs.freedesktop.org/describecomponents.cgi?product=...) and one of the closest things I could find to a discussion of related issues was an open bug "Add an API for taking screenshots and recording screencasts" (https://bugs.freedesktop.org/show_bug.cgi?id=98894 https://bugs.freedesktop.org/show_bug.cgi?id=98894) which has to deal with similar security challenges. Ultimately I, along with other automation-minded folks, will be sticking with x11 until this is figured out. macOS also has a decent automation story, with tools like Hammerspoon, Automator, and so on. I've got a fair bit of other notes on the topic which I can share with anyone interested - for example I saw "Some way to inject automated libinput events?" (https://bugs.freedesktop.org/show_bug.cgi?id=99800 https://bugs.freedesktop.org/show_bug.cgi?id=99800) where the person was actually trying to tune a gamepad. Also see https://www.reddit.com/r/linux/comments/7bm9az/what_cant_be_done_on_wayland_still/ https://www.reddit.com/r/linux/comments/7bm9az/what_cant_be_... where people are saying that Wayland is further fracturing the Linux desktop world.
  - nly 9y ago
    The problem is there is no common desktop permissions framework on Linux. On macOS a lot of these privileges (being able to inject and monitor input) are behind accessibility APIs and require the users express permission & password.
- thomastjeffery 9y ago
  This is the most frustrating thing about Wayland. Since when should the compositor/window-manager handle keyboard layouts? At the very least, there should be a configurable library that can be used.
niftich 9y ago
When I'm unfamiliar with the internals of a piece of software, it can seem like black magic; but it's illuminating to see something you didn't know break down into familiar steps. When the rationale behind the steps and the secret sauce -- business logic -- between them is explained incrementally, my understanding of the system grows even more, so I love posts like this. However, can you say a few words about why one would want to a write an alternate Wayland compositor professionally (i.e. reasons other than learning and exploration) -- as in: does the protocol offer places where meaningful feature differentiation can be achieved, while still achieving full compliance? The existence of something like 'wlroots' to me is an indicator that prospective Wayland compositors are, by necessity of supporting the Wayland architecture, more similar than different. Is that accurate?
- shmerl 9y ago
  > prospective Wayland compositors are, by necessity of supporting the Wayland architecture, more similar than different. Is that accurate? They all support Wayland protocol, but they can be quite different. For instance see the whole topic on server side vs client side window decorations.
- Sir_Cmpwn 9y ago
  wlroots is designed to support many different user interaction paradigms. Many Wayland compositors do share the same nuances, sure, but many do not. In addition to the typical desktop experience, you can use wlroots to make a compositor which arranges windows in 3D space for VR, or make a compositor that runs a phone interface, or a dashboard for a car, or any number of other use-cases. Even within the desktop paradigm, there's a lot of variance and room for compositors to specialize, but it's more subtle.
  - katastic 9y ago
    I'm still waiting for someone to make a wayland compositor that compares to compiz. One super important feature I use every day is being able to invert a SINGLE window and not the entire screen. For all the "omg it's slow" posts about compiz and x-server, it's fast enough to run on my netbook with a 5-watt processor.
mwcampbell 9y ago
Is there any advantage to using OpenGL even if one isn't interested in 3D effects in either the compositor or applications? IIUC, the Weston reference compositor has a back-end that doesn't require OpenGL but just uses the framebuffer device and pixman. Wouldn't that be faster on systems that don't have 3D hardware, or that don't have free drivers for that hardware (e.g. some ARM boards)?
- Sir_Cmpwn 9y ago
  We don't just paste pixels on the screen, we composite them. This involves alpha blending, projecting the scene onto an orthographic output projection, and more. Even in two dimensions, OpenGL is very useful here. On systems without suitable hardware, you should be able to use OpenGL in software (via mesa) and it will still be very fast here.
  - mwcampbell 9y ago
    Ah, thanks for that clarification; I'm pretty ignorant about graphics. Good to know that Mesa will be fast in this case. I tried running full-blown GNOME on an ARM board (Wandboard) without proper driver support for the GPU, and GNOME Shell used ~40% of a CPU at idle. I'm guessing that something like Sway, even though it uses OpenGL, is less demanding.
    - emersion 9y ago
      Even with software rendering, a wlroots compositor should use 0% when idle thanks to damage tracking (ie. only redrawing parts of the screen that changed).
- emersion 9y ago
  A fbdev backend and a pixman renderer are planned for this kind of situations. However, most desktop computers and laptops support OpenGL ES 2, and using them in the compositor offers better performance than using the CPU even if there aren't fancy 3D effects.
- aspaceman 9y ago
georgewsinger 9y ago
For Wayland-based 3D VR Compositor in the works: http://GitHub.com/SimulaVR/Simula http://GitHub.com/SimulaVR/Simula Good Wayland tutorials are rare in the wild. A guide like this would have been helpful when starting this projec several months ago. :]
- mncharity 9y ago
  When it is useful to point at the future? And when not? Looking back, did all the discussion of whether PCs had a role in homes actually accomplish anything? Or all the "well, there's only the Vatican archive so far, but the WWW is going to be big!" conversations? Or about tablets and phones? People often don't picture design spaces and their critical constraints; and don't track tech changes and their impact on those constraints; and say so many silly things. So here we are again, this time with VR/AR. GNOME, KDE, Qt? Well, I guess Motif still exists. And MUMPS. It was clear in the early 1990's that tablets would be a thing a decade later (eg, DEC was showing a prototype and nice year-vs-performance/size/cost curves), and that mice wouldn't be sufficient. We ended up writing a lot of Java (from 1995) and Objective-C (1985) and C++ (1985). And fought Microsoft over JavaScript. But a lot of known programming language features, which would have helped us, we didn't get to use. I really wish our programming languages today, were a little further along towards not sucking. Because we're about to rewrite the world again. But when/where is it worth taking the time to discuss such?
  - shmerl 9y ago
    > So here we are again, this time with VR/AR. Until OpenXR will be ready, there won't much movement in this regard. See: https://www.khronos.org/openxr https://www.khronos.org/openxr
    - mncharity 9y ago
      > Until OpenXR will be ready, there won't much movement in this regard. Maybe. I can't comment on the market economics. But I've learned to be very careful about attributing XR design space constraints. Because such care is often skipped. And I suspect it matters. When Varjo says their high-resolution HMD users will need dual Optimuses, there's an implicit assumption that users will be running Autodesk monsters. When Valve says Vive and WMR require 90 fps and low-variance latency and a gtx 1060, they're assuming immersive gaming. In contrast, I normally run my HMDs at 30 fps on an old laptop with integrated graphics. Using a full-screen web browser as compositor, and a little WebVR-like hack. How? It's remote desktop not gaming; with a ducktaped-on camera for passthrough AR (helps with low-fps tolerance); and no lens correction (also helps); and mixed-resolution 3D rendering; and desktop windows not participating in the 3D rendering. And it's ok. Different VR/AR "markets" have very very different constraints. Silly example: Vive HMDs have an table of their measured OLED-pixel brightnesses. Because individual pixels vary. And the Valve render compensates for that. Because otherwise, as you turn your head, you would notice the pattern. For Valve, that would be a "horrible" (quote) immersion-breaking visual artifact. Gasp. But for me, meh. I don't pretend the screen on my laptop is my desk, and I see no reason to pretend the screen on my face is my office. Sometimes you want to fix annoyances, but sometimes you simply want to get used to them. So yes, XR stacks can be crazy hard. But they can also be pretty easy. And people with markets that require the hard, often speak as if the easy didn't exist. But does that matter? Let's imagine Xmas 2018 gets us inexpensive laptops with discrete GPUs, and an HMD with 2k-pixel-square/eye and rectangular subpixels (for subpixel rendering). And let's say that's still without eye tracking. From the perspective of "hard", that's merely a larger market for low-end VR gaming. But from the perspective of "easy"... that may be tipping point on software dev being better done in XR than on physical monitors. So I look forward to OpenXR. And it seems likely that movement, in some directions, really does have it as a blocking dependency. But as with so many other suggestions of VR hardware and software blockers, perhaps some transformational disruptive change may be possible without it.
craftyguy 9y ago
I'm really looking forward to using wlroots with sway! Thanks for all of your great work Drew!
robert_foss 9y ago
What a nice tutorial, thanks for putting the effort in!
braderhart 9y ago
I believe that Sway will be the key to mass Linux desktop adoption, once someone wraps it into a modern distro like Arch. Unfortunately work on kmscon has discontinued. I'm currently using rxvt-unicode. I've been looking at exploring alacritty. Is there any chance you'll be building your own console emulator? I've had this idea floating around, that in addition to supporting ANSI escape codes, of a terminal that supports a lightweight markup language for UI. I saw your recent activity regarding Vulkan support. Your WM has just about all the components necessary to build these kickass graphical "console" applications.
- Sir_Cmpwn 9y ago
  I am building my own terminal emulator on the side, not very seriously: https://git.sr.ht/~sircmpwn/scurvy https://git.sr.ht/~sircmpwn/scurvy I'm not particularly interested in extending ANSI any further than, say, xterm. I do have big plans for Sway and the rest of the ecosystem, though. I am working on a GUI toolkit: https://github.com/SirCmpwn/chopsui https://github.com/SirCmpwn/chopsui And I'm also thinking about pulling the TUI layout out my work on aerc2 into a standalone library: https://git.sr.ht/~sircmpwn/aerc2 https://git.sr.ht/~sircmpwn/aerc2
  - braderhart 9y ago
    chopsui is right on track with what I'm thinking. The web and browsers are broken, and this is the answer. You're a wizard.
- braderhart 9y ago
  Did I mention that all this amazing work is being done by a few forward-thinking people vs the bloated desktop crap we've seen from billion dollar companies for years.
- eikenberry 9y ago
  > I believe that Sway will be the key to mass Linux desktop adoption... I'm curious what the basis of this thinking is. Sway looks like a nice i3-like tiling window manager for Wayland, but I don't see how such a piece of software would make so much of a difference.
eximius 9y ago
Somewhat off topic, but still highly relevant: Sir_Cmpwn, now that your stretch goal in your crowdfunding campaign has been reached, what will you do? Do you have ideas for a new goal? I expect a fair portion of the traffic came from this post. So if you have ideas for them, comment below?
- Sir_Cmpwn 9y ago
  Thanks for asking! We honestly weren't expecting to get this far this fast, so our plans are a bit nebulous. We're trying to figure out how to schedule for an additional dev to come out to Philly as a new stretch goal. More details later, I'm heading to bed.

195 points by ddevault 9y ago

Is there something like xinput for Wayland? I tried switching to Wayland session in recent KDE Plasma 5.12.0, but lost the setting that emulated middle click with left + right clicks, that I was setting with xinput.

ddevault 9y ago
I'm afraid not. Some configuration via libinput is possible, but they have been nerfing a lot of features like that. In the future I intend to close some of this gap at the compositor level, but that's not prioritized right now.
- phs2501 9y ago
  One of the most annoying input-related things that happened to my desktop (Arch) in the last year is when evdev got replaced with libinput by default as the X11 input module. Easy enough to revert, but quite frustrating trying to figure out why mouse acceleration suddenly feels acutely horrible. All the tweakable options were different (and fewer) in xinput, and I was not able to recreate an acceleration curve that felt comfortable. I realize it's an old refrain, but its quite frustrating having old, featureful software replaced with new, more limited/broken versions.
  - lima 9y ago
    I fully agree. However, it can go the other way, too: my ThinkPad trackpad (with virtual buttons for the trackpoint) FINALLY started working properly with libinput, with zero configuration, after weeks of tweaking evdev options without success. YMMV... It did break two-finger-drag though :( On the general topic of removing functionality: I get where they're coming from. I had a look at the old synaptics evdev code, and it really complicated with tons of long-forgotten special cases and obscure settings. I see why they're actively getting rid of those, the libinput code is much nicer to look at (and, presumably, maintain). I just wish they weren't that aggressive about it...
    - nitrogen 9y ago
      It's just as likely that the removal of all those forgotten special cases is exactly what's ruining the experience for those complaining about the switch. Throw away the old ugly code, bring back the old ugly bugs...
      - yjftsjthsd-h 9y ago
        Yeah, the thing about "really complicated with tons of long-forgotten special cases and obscure settings" is that people were using those settings, and those special cases were fixing bugs and allowing odd uses. Your rewrite is simple and elegant... until you fix all the bugs and make it feature-complete, by which point you will accumulate your own pile of ugly hacks. Then the next generation comes along and says, "Why all the hacks? We should rewrite this. We will surely not have such odd-looking code!" Rinse, repeat.
        zenhack 9y ago
        Yeah, but there are also often a lot of things that just genuinely don't make sense anymore. Xterm is packed with support for an insane number of old tty devices that no one needs. There are plenty of terminal emulators that successfully skip all that and no one ever complains. I don't know of a magic formula for being able to tell the difference, so it's hard thing to talk about in the abstract.
        yjftsjthsd-h 9y ago
        > devices that no one needs Maybe it's this? Nobody would care if you rolled out X11.1 that was perfectly compatible with everything in use and dropping stuff that nobody will miss. We care because Wayland killed features that we are actively using.
- shmerl 9y ago
  That's a pity. I'll check if KWin has any way to configure libinput beyond very limited KDE system settings.
jcrben 9y ago
I was just looking at a similar topic yesterday - trying to find a Wayland-compatible replacement to tools such as xdotool or xcape (see e.g. https://askubuntu.com/questions/956640/equivalent-to-xdotool-for-wayland/977801#comment1630814_977801 https://askubuntu.com/questions/956640/equivalent-to-xdotool...). People keep saying this was "decided" for security, but usually with no sources cited. I wasn't able to find a firm decision and discussion/roadmap. Instead it seems more like it was viewed as "handling this in a secure way is hard, let's skip trying to figure it out". Which is pretty sad, since as far as I can tell users didn't really get much in the way of tangible benefits from Wayland aside from security (altho the KWin maintainer points to Wayland being easier to test automatically https://blog.martin-graesslin.com/blog/2018/01/kwinx11-is-feature-frozen/ https://blog.martin-graesslin.com/blog/2018/01/kwinx11-is-fe...). I found a RFC on a mailing list: [RFC] Interface for injection of input events (https://lists.freedesktop.org/archives/wayland-devel/2017-March/033514.html https://lists.freedesktop.org/archives/wayland-devel/2017-Ma...) where the xdotools maintainer chimed in with some thoughts. But it seems to have died quick. I then scoured the Wayland freedesktop bugs (https://bugs.freedesktop.org/describecomponents.cgi?product=Wayland https://bugs.freedesktop.org/describecomponents.cgi?product=...) and one of the closest things I could find to a discussion of related issues was an open bug "Add an API for taking screenshots and recording screencasts" (https://bugs.freedesktop.org/show_bug.cgi?id=98894 https://bugs.freedesktop.org/show_bug.cgi?id=98894) which has to deal with similar security challenges. Ultimately I, along with other automation-minded folks, will be sticking with x11 until this is figured out. macOS also has a decent automation story, with tools like Hammerspoon, Automator, and so on. I've got a fair bit of other notes on the topic which I can share with anyone interested - for example I saw "Some way to inject automated libinput events?" (https://bugs.freedesktop.org/show_bug.cgi?id=99800 https://bugs.freedesktop.org/show_bug.cgi?id=99800) where the person was actually trying to tune a gamepad. Also see https://www.reddit.com/r/linux/comments/7bm9az/what_cant_be_done_on_wayland_still/ https://www.reddit.com/r/linux/comments/7bm9az/what_cant_be_... where people are saying that Wayland is further fracturing the Linux desktop world.
- nly 9y ago
  The problem is there is no common desktop permissions framework on Linux. On macOS a lot of these privileges (being able to inject and monitor input) are behind accessibility APIs and require the users express permission & password.
thomastjeffery 9y ago
This is the most frustrating thing about Wayland. Since when should the compositor/window-manager handle keyboard layouts? At the very least, there should be a configurable library that can be used.

niftich 9y ago

When I'm unfamiliar with the internals of a piece of software, it can seem like black magic; but it's illuminating to see something you didn't know break down into familiar steps. When the rationale behind the steps and the secret sauce -- business logic -- between them is explained incrementally, my understanding of the system grows even more, so I love posts like this. However, can you say a few words about why one would want to a write an alternate Wayland compositor professionally (i.e. reasons other than learning and exploration) -- as in: does the protocol offer places where meaningful feature differentiation can be achieved, while still achieving full compliance? The existence of something like 'wlroots' to me is an indicator that prospective Wayland compositors are, by necessity of supporting the Wayland architecture, more similar than different. Is that accurate?

shmerl 9y ago
> prospective Wayland compositors are, by necessity of supporting the Wayland architecture, more similar than different. Is that accurate? They all support Wayland protocol, but they can be quite different. For instance see the whole topic on server side vs client side window decorations.
Sir_Cmpwn 9y ago
wlroots is designed to support many different user interaction paradigms. Many Wayland compositors do share the same nuances, sure, but many do not. In addition to the typical desktop experience, you can use wlroots to make a compositor which arranges windows in 3D space for VR, or make a compositor that runs a phone interface, or a dashboard for a car, or any number of other use-cases. Even within the desktop paradigm, there's a lot of variance and room for compositors to specialize, but it's more subtle.
- katastic 9y ago
  I'm still waiting for someone to make a wayland compositor that compares to compiz. One super important feature I use every day is being able to invert a SINGLE window and not the entire screen. For all the "omg it's slow" posts about compiz and x-server, it's fast enough to run on my netbook with a 5-watt processor.

mwcampbell 9y ago

Is there any advantage to using OpenGL even if one isn't interested in 3D effects in either the compositor or applications? IIUC, the Weston reference compositor has a back-end that doesn't require OpenGL but just uses the framebuffer device and pixman. Wouldn't that be faster on systems that don't have 3D hardware, or that don't have free drivers for that hardware (e.g. some ARM boards)?

Sir_Cmpwn 9y ago
We don't just paste pixels on the screen, we composite them. This involves alpha blending, projecting the scene onto an orthographic output projection, and more. Even in two dimensions, OpenGL is very useful here. On systems without suitable hardware, you should be able to use OpenGL in software (via mesa) and it will still be very fast here.
- mwcampbell 9y ago
  Ah, thanks for that clarification; I'm pretty ignorant about graphics. Good to know that Mesa will be fast in this case. I tried running full-blown GNOME on an ARM board (Wandboard) without proper driver support for the GPU, and GNOME Shell used ~40% of a CPU at idle. I'm guessing that something like Sway, even though it uses OpenGL, is less demanding.
  - emersion 9y ago
    Even with software rendering, a wlroots compositor should use 0% when idle thanks to damage tracking (ie. only redrawing parts of the screen that changed).
emersion 9y ago
A fbdev backend and a pixman renderer are planned for this kind of situations. However, most desktop computers and laptops support OpenGL ES 2, and using them in the compositor offers better performance than using the CPU even if there aren't fancy 3D effects.
aspaceman 9y ago

georgewsinger 9y ago

For Wayland-based 3D VR Compositor in the works: http://GitHub.com/SimulaVR/Simula http://GitHub.com/SimulaVR/Simula Good Wayland tutorials are rare in the wild. A guide like this would have been helpful when starting this projec several months ago. :]

mncharity 9y ago
When it is useful to point at the future? And when not? Looking back, did all the discussion of whether PCs had a role in homes actually accomplish anything? Or all the "well, there's only the Vatican archive so far, but the WWW is going to be big!" conversations? Or about tablets and phones? People often don't picture design spaces and their critical constraints; and don't track tech changes and their impact on those constraints; and say so many silly things. So here we are again, this time with VR/AR. GNOME, KDE, Qt? Well, I guess Motif still exists. And MUMPS. It was clear in the early 1990's that tablets would be a thing a decade later (eg, DEC was showing a prototype and nice year-vs-performance/size/cost curves), and that mice wouldn't be sufficient. We ended up writing a lot of Java (from 1995) and Objective-C (1985) and C++ (1985). And fought Microsoft over JavaScript. But a lot of known programming language features, which would have helped us, we didn't get to use. I really wish our programming languages today, were a little further along towards not sucking. Because we're about to rewrite the world again. But when/where is it worth taking the time to discuss such?
- shmerl 9y ago
  > So here we are again, this time with VR/AR. Until OpenXR will be ready, there won't much movement in this regard. See: https://www.khronos.org/openxr https://www.khronos.org/openxr
  - mncharity 9y ago
    > Until OpenXR will be ready, there won't much movement in this regard. Maybe. I can't comment on the market economics. But I've learned to be very careful about attributing XR design space constraints. Because such care is often skipped. And I suspect it matters. When Varjo says their high-resolution HMD users will need dual Optimuses, there's an implicit assumption that users will be running Autodesk monsters. When Valve says Vive and WMR require 90 fps and low-variance latency and a gtx 1060, they're assuming immersive gaming. In contrast, I normally run my HMDs at 30 fps on an old laptop with integrated graphics. Using a full-screen web browser as compositor, and a little WebVR-like hack. How? It's remote desktop not gaming; with a ducktaped-on camera for passthrough AR (helps with low-fps tolerance); and no lens correction (also helps); and mixed-resolution 3D rendering; and desktop windows not participating in the 3D rendering. And it's ok. Different VR/AR "markets" have very very different constraints. Silly example: Vive HMDs have an table of their measured OLED-pixel brightnesses. Because individual pixels vary. And the Valve render compensates for that. Because otherwise, as you turn your head, you would notice the pattern. For Valve, that would be a "horrible" (quote) immersion-breaking visual artifact. Gasp. But for me, meh. I don't pretend the screen on my laptop is my desk, and I see no reason to pretend the screen on my face is my office. Sometimes you want to fix annoyances, but sometimes you simply want to get used to them. So yes, XR stacks can be crazy hard. But they can also be pretty easy. And people with markets that require the hard, often speak as if the easy didn't exist. But does that matter? Let's imagine Xmas 2018 gets us inexpensive laptops with discrete GPUs, and an HMD with 2k-pixel-square/eye and rectangular subpixels (for subpixel rendering). And let's say that's still without eye tracking. From the perspective of "hard", that's merely a larger market for low-end VR gaming. But from the perspective of "easy"... that may be tipping point on software dev being better done in XR than on physical monitors. So I look forward to OpenXR. And it seems likely that movement, in some directions, really does have it as a blocking dependency. But as with so many other suggestions of VR hardware and software blockers, perhaps some transformational disruptive change may be possible without it.

craftyguy 9y ago

I'm really looking forward to using wlroots with sway! Thanks for all of your great work Drew!

robert_foss 9y ago

What a nice tutorial, thanks for putting the effort in!

braderhart 9y ago

I believe that Sway will be the key to mass Linux desktop adoption, once someone wraps it into a modern distro like Arch. Unfortunately work on kmscon has discontinued. I'm currently using rxvt-unicode. I've been looking at exploring alacritty. Is there any chance you'll be building your own console emulator? I've had this idea floating around, that in addition to supporting ANSI escape codes, of a terminal that supports a lightweight markup language for UI. I saw your recent activity regarding Vulkan support. Your WM has just about all the components necessary to build these kickass graphical "console" applications.

Sir_Cmpwn 9y ago
I am building my own terminal emulator on the side, not very seriously: https://git.sr.ht/~sircmpwn/scurvy https://git.sr.ht/~sircmpwn/scurvy I'm not particularly interested in extending ANSI any further than, say, xterm. I do have big plans for Sway and the rest of the ecosystem, though. I am working on a GUI toolkit: https://github.com/SirCmpwn/chopsui https://github.com/SirCmpwn/chopsui And I'm also thinking about pulling the TUI layout out my work on aerc2 into a standalone library: https://git.sr.ht/~sircmpwn/aerc2 https://git.sr.ht/~sircmpwn/aerc2
- braderhart 9y ago
  chopsui is right on track with what I'm thinking. The web and browsers are broken, and this is the answer. You're a wizard.
braderhart 9y ago
Did I mention that all this amazing work is being done by a few forward-thinking people vs the bloated desktop crap we've seen from billion dollar companies for years.
eikenberry 9y ago
> I believe that Sway will be the key to mass Linux desktop adoption... I'm curious what the basis of this thinking is. Sway looks like a nice i3-like tiling window manager for Wayland, but I don't see how such a piece of software would make so much of a difference.

eximius 9y ago

Somewhat off topic, but still highly relevant: Sir_Cmpwn, now that your stretch goal in your crowdfunding campaign has been reached, what will you do? Do you have ideas for a new goal? I expect a fair portion of the traffic came from this post. So if you have ideas for them, comment below?

Sir_Cmpwn 9y ago
Thanks for asking! We honestly weren't expecting to get this far this fast, so our plans are a bit nebulous. We're trying to figure out how to schedule for an additional dev to come out to Philly as a new stretch goal. More details later, I'm heading to bed.