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?
Aside from handling details on how the actual drawing happens, Wayland compositors also dictate how window management is done. Obviosly, there is a lot of room for different designs in that space. Just look at how many different Window Managers there exist for X. My understanding is that wlroots handles a lot of heavy lifting related to drawing and input handling making experimentation with new compositors a lot easier.
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.
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.
> One super important feature I use every day is being able to invert a SINGLE window and not the entire screen
While it's not per window inversion, for years I've been using the tiny (100KB) and wondrous xcalib package for screen inversion*
Should note that in order to get per screen inversion working I need to use Nvidia's Xinerama extension (without this extension inversion happens across all screens).
* bound to alt-o/alt-i hotkeys with xbindkeys. Here's the .xbindkeysrc if anyone's interested.
I haven't tried it recently but if kde has gotten better on Wayland it might offer this feature. You can set a compositing effect for this in x11 with it last I looked. But last time I tried kde Wayland it was far from stable.
GNU Emacs is a text editor, extensible in Emacs Lisp.
A Lisp Machine usually is a real computer - one with an OS written in Lisp.
GNU Emacs OTOH is hosted on an OS and doesn't even have multiple threads. It's more an application development and execution environment, for applications based on Emacs text-buffer abstraction.
The actual Lisp operating system user interfaces were not built on a text-buffer abstraction.
Which Lisp Machine is GNU Emacs emulating? Actually existing ones or a conceptual model of a 'Lisp Machine'?
If we look at the existing ones, there were two main ones: Interlisp-D based systems from Xerox and the MIT Lisp Machine and its later variants from LMI, Symbolics and TI. There were a bunch of lesser known ones, which didn't have much influence. Both the Xerox Lisp Machine and the MIT Lisp Machines have emulators - they allow you to run them usually on some Unix/Linux + X11. None of them had any sophisticated terminal capabilities - all were needing/providing a full GUI environment.
If you boot a Symbolics, it starts into a GUI environment with a Listener as the console. This Listener is not an editor window and it is not text only - it supports full graphics and mouse input. The listener runs commands and Lisp forms. The commands are providing typical servives like a login command, listing directories, copying files, enabling and disabling of network services, reading tape drives, compressing files and more. Editing files is usually done in a text editor, which is actually an Emacs called Zmacs. Applications are usually fullscreen windows with subpanes. These subpanes are arranged by layout descriptions provided by the application. But the window system is actually also providing the ability to have overlapping windows or multiple windows on the screen or even windows composed of subwindows. The implementation of all of this is heavily object-oriented using something like Flavors, New Flavors or, later, CLOS.
If you look at GNU Emacs, it does not provide a GUI-first environment, its basic abstraction is the text buffer and a UI representation of that in a terminal or a window. You don't login into GNU Emacs. Its programming model is different, since it doesn't use OOP at its core. It's not multithreaded.
The main similarities to the MIT Lisp Machine OS: they appear to be text-based (which the MIT Lisp Machine uses a lot, but in different ways and mostly not editor-based), there programming and extension languages are variants of Maclisp, they provide things like REPLs, Lisp code execution, Lisp debugger, Lisp interpreter, etc... But all the latter is also provided by Multics Emacs written in Maclisp in the late 70s. These are not features of a Lisp Machine, but generally the features of a typical Lisp system. The Lisp Machine extended this with real GUIs, real OS code written in Lisp (like serving network interfaces, event handlers, frame buffer interfaces, file systems, process schedulers, dumping memory to create worlds which can be booted into, ...)
The main reason the Lisp Machine existed was that they were a fast track to personal workstations for AI programmers/researchers and the groups knew Lisp, it was a good prototype environemnt for them, and they could built such personal workstations within a few years.
But interactive Lisp systems existed before and after. Before usually on 'mainframes' (see Interlisp with its terminal-based tools) and after that on many types of machines: like UNIX workstations and Windows-based personal computers
Now: what parts of GNU Emacs make you think that it emulates a Lisp Machine? Is it emulating real existing ones or parts of them? Is it emulating comcepts? Concepts which probably existed also outside of Lisp Machines in interactive Lisp systems?
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?
> 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.
Apropos the need for better programming languages,
> FWIW [...] Haskell
Sigh. So the wizziest Haskell programmer I know, has repeatedly done the following. They build a model of the mathematics of a problem domain. And then they mentally/manually compile that down to Haskell. Sometimes extending GHC internals to get an adequate target.
He's the compiler. It's a compilation process built of wizzy wet-ware, and Coq, and ... with very little tooling support. GHC is just the compiler target.
I'm not good enough to do that. I can't bridge that gap manually. That gap between insightful description of problem domain, and inexpressive language. I can't be the primary compiler, floating unsupported in air. I need a language and environment that has at least some clue what I'm trying to do. That participates and checks and supports me. That has a type system rich enough to directly describe problem domains, to describe math. Not merely a low-level target for a mental compiler.
Otherwise, everything I write is still just sculpting kludges.
GHC makes a nifty compiler target. All we need now, is a nifty compiler. ;)
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)?
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.
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.
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).
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.
A helpful exercise is to consider the work that a compositor actually does and then try implementing a simple CPU-based one. The main operation you'll need is a blit - which you'll find somewhat difficult to optimize. Hardware-accelerated blitting (OpenGL) is so much faster that it's entirely worth it. The only tradeoff is the complexity of OpenGL, but Mesa or other libraries can abstract all of that away.
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.
> 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.
I used Windows primarily for over 20 years. I experimented with dwm back in 2006 and really enjoyed the idea. Something clicked in my brain a while back and I tried Arch Linux. It took a lot, and I mean a lot of stubbornness on my part (and on Arch) for me to figure out how to get a minimalist desktop with just about everything working. Now that I do though, it is very easy and simple to understand. I really don't need any bloat and my OS is pretty much portable at this point, and I have great software to do pretty much everything I want.
My computer isn't terrible, but it is much older. I've got external monitors connected to it. Using i3 just feels natural at this point. I definitely feel more efficient. I have everything integrated that on Windows requires compatibility layers.
My passwords are stored using Pass, so I can even use latest encryption. I use browserpass for password integration. I've got integrations in rofi for Chrome tabs. I mean, the simplicity and speed make using a computer exciting and enjoyable for me.
If I were using a VR or AR device, I don't want to manage location of items. I like technology helping me and not getting in the way. This is what I think a properly optimized and configured desktop could be like, and I haven't ran into any issues. I can even watch YouTube and other streaming services natively and with graphics acceleration using mpv and youtube-dl.
With this framework, we won't need Android for mobile and Vulkan integration isn't too far away. I feel like with a little creative thinking, that tiling window managers can be whatever you want them to be.
Now take GTK/Gnome or Qt/KDE + X11, which are a strong learning curve for UI development, and bloated upon dependencies galore (some of this is just poor packaging) and evaluate how much of that codebase is actually producing quality applications to win the Desktop space for Linux.
You have 2 (some would argue 3 or more) commercial Linux distros that have been unable to do so, and now partner with Microsoft. I see developers flocking towards JavaScript because that is being pushed as the solution for UI development.
There is a reason that Linux desktop is failing, and I believe that tiling window managers help solve that.
No offense to Mozilla or Chrome teams, but damn your browsers are bloated and unnecessary. I can't wait for chopsui or whatever else the right scripting language is to come along and sweep it all up, because that is what will happen. Sorry Microsoft, but your 4GB OS will be blown away by something that will probably clock in at less than 1GB with Wayland/Vulkan.
Now wrap that into container isolation, and you've got yourself a policy framework.
I really don't recommend running a Windows or Mac VM simply for compatibility, because then you lose out on a bunch of perks, but you can. I mean you can use something that is free and the source code is available for rich and poor people alike, and the web is full of information and communities to help you get started and prosper from your new open source skills and education. Or you can pay for spyware and then pay more to supposedly protect yourself from spyware, while installing more spyware to make you safer, and then you will need adware for that spyware, and then some additional apps to make sure that you only install OS-approved spyware.
Well, you had to admit that with auto-complete, it is pretty cool to just type a couple letters and tab your way to heaven. Have you tried Rofi? There are some descent themes, but in all honesty the terminal is great. It is a text-based dynamic solution which makes it extremely versatile and compatible.
What is more natural than just typing and tabbing to what you want? That is some simple voice navigation stuff as well, or once you get to VR, then tab-complete can be like auto-suggest.
Have you seen Vim with perfect horizontal, vertical windows, and re-scaling? I have, and it is glorious! Once you add proper icon font support and Airline, it is hard to beat... yes, Neovim is probably better.
However, it is a matter of time before chopsui or another UI toolkit comes along that will essentially wrap around all these great terminal applications in a way that will create the layouts and styling that web users are mostly used to. I hope instead though that, it is more general, and that information is decoupled from design. Instead, I hope that sites will be able to request to change layouts, and that we will build better decentralized marketplaces for developers.
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
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
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.
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.
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.
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.
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...
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...
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.
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.
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.
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-fe...).
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) where the person was actually trying to tune a gamepad.
Wow. Thanks for the detailed reply. I'll add that to my notes. I'm curious to see how this plays out with wlroots and how people will build on it to bring the something like variety of window manager X has to Wayland.
Using Xwayland for a significant number of things makes me curious about how much overhead it adds. The only article I found was from 2014 and it showed it adding significant overhead. Anyone know of any newer data?
> "trackball/input configuration" is too vague to make any promises about but input configuration is possible
This is my current config setup. As you can see I make multiple changes. I remap the buttons, set the pointer acceleration, set mousewheel emulation, etc.
mouse_id="Kensington Kensington Slimblade Trackball"
if xinput --query-state "$mouse_id" > /dev/null 2>&1 ; then
# We need to map names to prop numbers for the settings below
props=`xinput --list-props "$mouse_id"`
getid () {
echo "$props" | grep -i "$1" | grep -o "([0-9]\+)" | grep -o "[0-9]\+"
}
# below numbers come from 'xinput --list-props [mouse_id]'
# these property ids seem to be persistent between reboots
xinput --set-prop "$mouse_id" "$(getid profile)" 2
# NOTE need to look up these properties by name to get ids for settings
## mouse speed (change 'constant decel' first to change speed)
# fast movement acceleration velocity scaling
xinput --set-prop "$mouse_id" "$(getid accel\ velocity)" 1024
# slow movement decelleration scaling
xinput --set-prop "$mouse_id" "$(getid constant\ decel)" 6
xinput --set-prop "$mouse_id" "$(getid adaptive\ decel)" 10 # no effect?
## remap buttons (swap 2 and 8)
xinput --set-button-map "$mouse_id" 1 8 3 4 5 6 7 2
# orig: 2 8 new: 8 2
# 1 3 1 3
## mouse wheel emulation
xinput --set-prop "$mouse_id" $(getid emulation\ axes) 6 7 4 5
xinput --set-prop "$mouse_id" \
$(getid wheel\ emulation\ button) 8 # pre-remapping
xinput --set-prop "$mouse_id" $(getid "wheel emulation (") 1
xinput --set-prop "$mouse_id" $(getid emulation\ inertia) 15 #lower=faster
fi
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.
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.
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?
Aside from handling details on how the actual drawing happens, Wayland compositors also dictate how window management is done. Obviosly, there is a lot of room for different designs in that space. Just look at how many different Window Managers there exist for X. My understanding is that wlroots handles a lot of heavy lifting related to drawing and input handling making experimentation with new compositors a lot easier.
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.
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.
> One super important feature I use every day is being able to invert a SINGLE window and not the entire screen
While it's not per window inversion, for years I've been using the tiny (100KB) and wondrous xcalib package for screen inversion*
Should note that in order to get per screen inversion working I need to use Nvidia's Xinerama extension (without this extension inversion happens across all screens).
* bound to alt-o/alt-i hotkeys with xbindkeys. Here's the .xbindkeysrc if anyone's interested.
With xcalib I never got inversion working on all screens, only the first one (Intel graphics).
However, XRandR Invert Colors [1] has worked flawless with multi-monitor setups.
[1] https://github.com/zoltanp/xrandr-invert-colors
I haven't tried it recently but if kde has gotten better on Wayland it might offer this feature. You can set a compositing effect for this in x11 with it last I looked. But last time I tried kde Wayland it was far from stable.
Do you mean invert as in turn over 180 degrees? Sway 1.0 will be able to do that.
I believe they mean invert colors.
Ah. That seems like a pretty odd dealbreaker. It's possible in theory, I guess.
> 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.
Well, I want to embed a Wayland compositor in Emacs using the new native modules support. wlroots makes that remotely possible.
That sounds genuinely interesting. That said, I have to ask, why you would want to do such a thing?
Hasn't the goal of emacs always been to be everything? It can be init (1), a web browser (2), and already a X11 WM (3).
(1) http://www.informatimago.com/linux/emacs-on-user-mode-linux....
(2) https://www.emacswiki.org/emacs/CategoryWebBrowser
(3) https://www.emacswiki.org/emacs/XWindowEmacsManager
Some of us actually want Lisp machines, and Emacs is effectively a Lisp machine emulator disguised as a text editor.
GNU Emacs is a text editor, extensible in Emacs Lisp.
A Lisp Machine usually is a real computer - one with an OS written in Lisp.
GNU Emacs OTOH is hosted on an OS and doesn't even have multiple threads. It's more an application development and execution environment, for applications based on Emacs text-buffer abstraction.
The actual Lisp operating system user interfaces were not built on a text-buffer abstraction.
That is why I said "Lisp Machine emulator" and not "Lisp Machine".
The text-buffer abstraction is the "disguise".
But I take the point that the paradigm is not quite the same.
Just let us explore this for a moment.
Which Lisp Machine is GNU Emacs emulating? Actually existing ones or a conceptual model of a 'Lisp Machine'?
If we look at the existing ones, there were two main ones: Interlisp-D based systems from Xerox and the MIT Lisp Machine and its later variants from LMI, Symbolics and TI. There were a bunch of lesser known ones, which didn't have much influence. Both the Xerox Lisp Machine and the MIT Lisp Machines have emulators - they allow you to run them usually on some Unix/Linux + X11. None of them had any sophisticated terminal capabilities - all were needing/providing a full GUI environment.
If you boot a Symbolics, it starts into a GUI environment with a Listener as the console. This Listener is not an editor window and it is not text only - it supports full graphics and mouse input. The listener runs commands and Lisp forms. The commands are providing typical servives like a login command, listing directories, copying files, enabling and disabling of network services, reading tape drives, compressing files and more. Editing files is usually done in a text editor, which is actually an Emacs called Zmacs. Applications are usually fullscreen windows with subpanes. These subpanes are arranged by layout descriptions provided by the application. But the window system is actually also providing the ability to have overlapping windows or multiple windows on the screen or even windows composed of subwindows. The implementation of all of this is heavily object-oriented using something like Flavors, New Flavors or, later, CLOS.
If you look at GNU Emacs, it does not provide a GUI-first environment, its basic abstraction is the text buffer and a UI representation of that in a terminal or a window. You don't login into GNU Emacs. Its programming model is different, since it doesn't use OOP at its core. It's not multithreaded.
The main similarities to the MIT Lisp Machine OS: they appear to be text-based (which the MIT Lisp Machine uses a lot, but in different ways and mostly not editor-based), there programming and extension languages are variants of Maclisp, they provide things like REPLs, Lisp code execution, Lisp debugger, Lisp interpreter, etc... But all the latter is also provided by Multics Emacs written in Maclisp in the late 70s. These are not features of a Lisp Machine, but generally the features of a typical Lisp system. The Lisp Machine extended this with real GUIs, real OS code written in Lisp (like serving network interfaces, event handlers, frame buffer interfaces, file systems, process schedulers, dumping memory to create worlds which can be booted into, ...)
The main reason the Lisp Machine existed was that they were a fast track to personal workstations for AI programmers/researchers and the groups knew Lisp, it was a good prototype environemnt for them, and they could built such personal workstations within a few years.
But interactive Lisp systems existed before and after. Before usually on 'mainframes' (see Interlisp with its terminal-based tools) and after that on many types of machines: like UNIX workstations and Windows-based personal computers
Now: what parts of GNU Emacs make you think that it emulates a Lisp Machine? Is it emulating real existing ones or parts of them? Is it emulating comcepts? Concepts which probably existed also outside of Lisp Machines in interactive Lisp systems?
Yes. Emacs is more akin to fantastically-extensible shell.
Which is what makes it well-suited for managing the display windows of subprocesses, if you ignore the threading issues.
For Wayland-based 3D VR Compositor in the works: 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. :]
You might appreciate this: https://github.com/swaywm/hsroots
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?
> 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
> 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.
FWIW, Simula (linked to above) is written in Haskell.
Apropos the need for better programming languages,
> FWIW [...] Haskell
Sigh. So the wizziest Haskell programmer I know, has repeatedly done the following. They build a model of the mathematics of a problem domain. And then they mentally/manually compile that down to Haskell. Sometimes extending GHC internals to get an adequate target.
He's the compiler. It's a compilation process built of wizzy wet-ware, and Coq, and ... with very little tooling support. GHC is just the compiler target.
I'm not good enough to do that. I can't bridge that gap manually. That gap between insightful description of problem domain, and inexpressive language. I can't be the primary compiler, floating unsupported in air. I need a language and environment that has at least some clue what I'm trying to do. That participates and checks and supports me. That has a type system rich enough to directly describe problem domains, to describe math. Not merely a low-level target for a mental compiler.
Otherwise, everything I write is still just sculpting kludges.
GHC makes a nifty compiler target. All we need now, is a nifty compiler. ;)
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)?
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.
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.
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).
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.
A helpful exercise is to consider the work that a compositor actually does and then try implementing a simple CPU-based one. The main operation you'll need is a blit - which you'll find somewhat difficult to optimize. Hardware-accelerated blitting (OpenGL) is so much faster that it's entirely worth it. The only tradeoff is the complexity of OpenGL, but Mesa or other libraries can abstract all of that away.
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.
> 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.
I used Windows primarily for over 20 years. I experimented with dwm back in 2006 and really enjoyed the idea. Something clicked in my brain a while back and I tried Arch Linux. It took a lot, and I mean a lot of stubbornness on my part (and on Arch) for me to figure out how to get a minimalist desktop with just about everything working. Now that I do though, it is very easy and simple to understand. I really don't need any bloat and my OS is pretty much portable at this point, and I have great software to do pretty much everything I want.
My computer isn't terrible, but it is much older. I've got external monitors connected to it. Using i3 just feels natural at this point. I definitely feel more efficient. I have everything integrated that on Windows requires compatibility layers.
My passwords are stored using Pass, so I can even use latest encryption. I use browserpass for password integration. I've got integrations in rofi for Chrome tabs. I mean, the simplicity and speed make using a computer exciting and enjoyable for me.
If I were using a VR or AR device, I don't want to manage location of items. I like technology helping me and not getting in the way. This is what I think a properly optimized and configured desktop could be like, and I haven't ran into any issues. I can even watch YouTube and other streaming services natively and with graphics acceleration using mpv and youtube-dl.
With this framework, we won't need Android for mobile and Vulkan integration isn't too far away. I feel like with a little creative thinking, that tiling window managers can be whatever you want them to be.
Take this for example,
https://i.redd.it/lcz6566yfwsz.png
Or this,
https://imgur.com/a/VBQML#fIjDknv
Now take GTK/Gnome or Qt/KDE + X11, which are a strong learning curve for UI development, and bloated upon dependencies galore (some of this is just poor packaging) and evaluate how much of that codebase is actually producing quality applications to win the Desktop space for Linux.
You have 2 (some would argue 3 or more) commercial Linux distros that have been unable to do so, and now partner with Microsoft. I see developers flocking towards JavaScript because that is being pushed as the solution for UI development.
There is a reason that Linux desktop is failing, and I believe that tiling window managers help solve that.
No offense to Mozilla or Chrome teams, but damn your browsers are bloated and unnecessary. I can't wait for chopsui or whatever else the right scripting language is to come along and sweep it all up, because that is what will happen. Sorry Microsoft, but your 4GB OS will be blown away by something that will probably clock in at less than 1GB with Wayland/Vulkan.
Now wrap that into container isolation, and you've got yourself a policy framework.
"But it can't proberly open .docx and play PUBG"
If you have an integrated and separate card for gaming, then you can do just about anything, including running Mac inside Linux:
https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVM...
I doubt that any of that has anything to do with the reasons that there's no "mass Linux desktop adoption".
And I wouldn't count Linux running Windows in a VM most of the time as a "Linux desktop".
What do you consider some reasons then?
I really don't recommend running a Windows or Mac VM simply for compatibility, because then you lose out on a bunch of perks, but you can. I mean you can use something that is free and the source code is available for rich and poor people alike, and the web is full of information and communities to help you get started and prosper from your new open source skills and education. Or you can pay for spyware and then pay more to supposedly protect yourself from spyware, while installing more spyware to make you safer, and then you will need adware for that spyware, and then some additional apps to make sure that you only install OS-approved spyware.
> What do you consider some reasons then?
Too often users need to use the terminal.
Well, you had to admit that with auto-complete, it is pretty cool to just type a couple letters and tab your way to heaven. Have you tried Rofi? There are some descent themes, but in all honesty the terminal is great. It is a text-based dynamic solution which makes it extremely versatile and compatible.
What is more natural than just typing and tabbing to what you want? That is some simple voice navigation stuff as well, or once you get to VR, then tab-complete can be like auto-suggest.
Have you seen Vim with perfect horizontal, vertical windows, and re-scaling? I have, and it is glorious! Once you add proper icon font support and Airline, it is hard to beat... yes, Neovim is probably better.
However, it is a matter of time before chopsui or another UI toolkit comes along that will essentially wrap around all these great terminal applications in a way that will create the layouts and styling that web users are mostly used to. I hope instead though that, it is more general, and that information is decoupled from design. Instead, I hope that sites will be able to request to change layouts, and that we will build better decentralized marketplaces for developers.
I am building my own terminal emulator on the side, not very seriously: 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
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
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.
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.
I'm really looking forward to using wlroots with sway! Thanks for all of your great work Drew!
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.
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.
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.
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.
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...
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...
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.
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.
> 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.
That's a pity. I'll check if KWin has any way to configure libinput beyond very limited KDE system settings.
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...).
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-fe...).
I found a RFC on a mailing list: [RFC] Interface for injection of input events (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=...) 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) 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) where the person was actually trying to tune a gamepad.
Also see https://www.reddit.com/r/linux/comments/7bm9az/what_cant_be_... where people are saying that Wayland is further fracturing the Linux desktop world.
A while back I looked into Wayland and what was missing that I would need to replicate my current setup. Here's the list I came up with...
Most of these had no Wayland equivalents that I could find. I have no plans on switching anytime soon.Much of this doesn't have a 1:1 equivalent tool, but is workable anyway. This comment got really long so I moved it into a gist: https://gist.github.com/SirCmpwn/594040cb476f93c503715d4635b...
Wow. Thanks for the detailed reply. I'll add that to my notes. I'm curious to see how this plays out with wlroots and how people will build on it to bring the something like variety of window manager X has to Wayland.
Using Xwayland for a significant number of things makes me curious about how much overhead it adds. The only article I found was from 2014 and it showed it adding significant overhead. Anyone know of any newer data?
I don't think it should add a lot of overhead. Performance wise it shouldn't be any worse than regular X.
The article I mentioned in case you were curious.
https://www.phoronix.com/vr.php?view=20956
Thanks. I should run some Witcher 3 in Wine benchmarks with XWayland.
Though currently TW3 suffers from low performance regression in general, so it won't be very conclusive.
Also, I suspect some of it can be compositor specific.
> "trackball/input configuration" is too vague to make any promises about but input configuration is possible
This is my current config setup. As you can see I make multiple changes. I remap the buttons, set the pointer acceleration, set mousewheel emulation, etc.
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.
> The problem is there is no common desktop permissions framework on Linux.
Oh yes there is, it's called polkit and it's quite nifty !
Yeah, combining security and automation is something that Wayland developers should solve in a serious way. It seems it's far from ready.
What a nice tutorial, thanks for putting the effort in!
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?
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.