yserver screenshot demonstrating compiz comptibility

Why Not Yserver? It’s Xserver, But Rust-y.

If you’re not into Wayland as a display manager, it seems like your options are slowly dwindling. Xorg isn’t exactly a hotbed of activity, and the one fork everyone knows about is best known as a political lightning rod. Luckily, Rust developers can apparently never see a tool without pulling it into their heavily oxidized bucket of crabs, so we now have another option: the creatively named yserver, released under the MIT license by [joske].

The name, yserver, for the record, is just a placeholder name, but we rather like the simple logic of “Y comes after X” — sure, you could call it X12, but that could imply continuity, and this is a clean break. It’s also not a full reimplementation of the huge, sprawling mess that Xorg has become over the decades. It can’t launch multiple screens and thus lacks full multi-monitor support. So, for now, it may be too bare-bones for some people’s use cases.

As it uses Vulkan, it is limited to relatively modern hardware, but has been tested on Intel, AMD, Nvidia, and Apple chips. The target kernel is good old Linux, but the docs do cover compiling for FreeBSD; just be aware that that’s very much a secondary target. FreeBSD users are probably used to that, though.

On Linux, a standalone DRM/KMS yserver can successfully run not just window managers but full desktops — specifically MATE, Cinnamon, and XFCE, as they’re not on the Wayland bandwagon. It even supports Compiz, in case you missed the cube and wiggly window animations. You can also use yserver via Xwayland or even Xorg. Speaking of Xorg, [joske] has run the X.Org X Test Suite (xts5) against this proposed successor, and it currently scores 66.2%, which seems pretty good considering the project explicitly does not plan to copy all of Xorg’s functionality.

Aside from multiple screens, one thing that would have been neat to see is support for the Asterinas rust-based Linux-compatible kernel — though if that project achieves full Linux compatibility, that may be a non-issue. Even if you aren’t an oxidization enthusiast, you might find reasons to be happy to see more competition in the display-manager market — after all, Wayland Will Never Be Ready For Every X11 User. If Xorg really is destined to the slow death critics predict, perhaps yserver could cover the holdouts.

How To Better Enjoy VR On Linux

Linux folks are used to having to roll many of their own solutions, and better Linux desktop usability is a goal of the WayVR project, which aims to provide desktop control and app launching from within a VR session.

VR applications can already stream from Linux to standalone headsets with projects like WiVRn (check out this WiVRn setup guide for a fuller understanding), but what WayVR does is let one launch programs and access desktop screens within VR. Put another way, instead of the headset being limited to acting as a pseudo-monitor that only receives the output of an already-running VR application, the headset and controllers can now be used to interact with one’s computer as if one were physically sitting at it. Controls and user interface are highly flexible and help users to do anything they need — including clicking, typing, and launching applications. It’s a considerable step forward for convenience and general usability.

Naturally, when it comes to using a computer from within VR there is plenty of unexplored territory regarding user interfaces. It’s fertile ground for experimentation in everything from DIY headsets to ways to input text without a keyboard, so if you enjoy working on the frontiers of such things, it’s a good scene to dive into.

Wayland Will Never Be Ready For Every X11 User

After more than forty years, everyone knows that it’s time to retire the X Window System – X11 for short – on account of it being old and decrepit. Or at least that’s what the common narrative is, because if you dig into the chatter surrounding the ongoing transition there are some real issues that people have with the 16-year old spring chicken – called Wayland – that’s supposed to replace it.

Recently [Brodie Robertson] did some polling and soliciting commentary from the community, breaking down the results from over 1,150 comments to the YouTube community post alone.

The issues range from the expected, such as applications that haven’t been ported yet from X11 to Wayland, to compatibility issues – such as failing drag and drop – when running X11 and Wayland applications side by side. Things get worse when support for older hardware, like GeForce GT610 and GT710 GPUs, and increased resource usage by Wayland are considered.

From there it continues with the lack of global hotkeys in Wayland, graphics tablet support issues, OBS not supporting embedded browser windows, Japanese and other foreign as well as onscreen keyboard support issues that are somehow worse than on X11, no support for overscanning monitors or multiple mouse cursors, no multi-monitor fullscreen option, regressions with accessibility, inability of applications to set their (previously saved) window position, no real automation alternative for xdotool, lacking BSD support and worse input latency with gaming.

Some users also simply say that they do not care about Wayland either way as it offers no new features they want. Finally [Brodie] raises the issue of the Wayland developers not simply following standards set by the Windows and MacOS desktops, something which among other issues has been a point of hotly debated contention for years.

Even if Wayland does end up succeeding X11, the one point that many people seem to agree on is that just because X11 is pretty terrible right now, this doesn’t automatically make Wayland the better option. Maybe in hindsight Mir was the better choice we had before it pivoted to Wayland.

Continue reading “Wayland Will Never Be Ready For Every X11 User”

Learning X86_64 Assembly By Building A GUI From Scratch

Some professional coders are absolutely adamant that learning to program in assembly language in these modern times is simply a waste of time, and this post is not for them. This is for the rest of us, who still think there is value in knowing at a low level what is going on, a deeper appreciation can be developed. [Philippe Gaultier] was certainly in this latter camp and figured the best way to learn was to work on a substantial project.

Now, there are some valid reasons to write directly in assembler; for example hand-crafting unusual code sequences for creating software exploits would be hindered by an optimising compiler. Creating code optimised for speed and size is unlikely to be among those reasons, as doing a better job than a modern compiler would be a considerable challenge. Some folks would follow the tried and trusted route and work towards getting a “hello world!” output to the console or a serial port, but not [Philippe]. This project aimed to get a full-custom GUI application running as a client to the X11 server running atop Linux, but the theory should be good for any *nix OS.

Hello World! In X11!

The first part of the process was to create a valid ELF executable that Linux would work with. Using nasm to assemble and the standard linker, only a few X86_64 instructions are needed to create a tiny executable that just exits cleanly. Next, we learn how to manipulate the stack in order to set up a non-trivial system call that sends some text to the system STDOUT.

To perform any GUI actions, we must remember that X11 is a network-orientated system, where our executable will be a client connected via a socket. In the simple case, we just connect the locally created socket to the server path for the local X server, which is just a matter of populating the sockaddr_un data structure on the stack and calling the connect() system call.

Now the connection is made, we can follow the usual X11 route of creating client ids, then allocating resources using them. Next, fonts are opened, and a graphical context is created to use it to create a window. Finally, after mapping the window, something will be visible to draw into with subsequent commands. X11 is a low-level GUI system, so there are quite a few steps to create even the most simple drawable object, but this also makes it quite simple to understand and thus quite suited to such a project.

We applaud [Phillip] for the fabulous documentation of this learning hack and can’t wait to see what’s next in store!

Not too long ago, we covered Snowdrop OS, which is written entirely in X86 assembly, and we also found out a thing or two about some oddball X86 instructions. We’ve also done our own Linux assembly primer.

Porting DOOM To A Forgotten Apple OS

Apple hasn’t always had refined user experiences in their operating systems. In the distant past of the ’90s they were still kind of clunky computers that were far from the polished, high-end consumer machines of the modern era. That wasn’t all that Apple offered back then, though. They had a long-forgotten alternative operating system that was called A/UX designed for government applications, and [Keriad] is here to show us this relic operating system and port DOOM to it.

A/UX was designed in the pre-PowerPC days when Macintosh computers ran on Motorola 68000 chips. Luckily, [Keriad] has a Mac Quadra 800 with just such a chip that is still fully-functional. DOOM was developed with the NeXTSTEP operating system which can run on old Macs thanks to another tool called MacX which allows X11 applications to run on Mac. A version of gcc for A/UX was found as well and with the source code in hand they were eventually able to compile a binary. There were several hiccups along the way (including the lack of sound) but eventually DOOM was running on this forgotten operating system.

The main problem with the build in the end, besides the lack of sound, is that the game only runs at 2 – 3 frames per second. [Keriad] speculates that this is due to all of the compatibility layers needed to compile and run the game at all, but it’s still impressive. As far as we know, [Keriad] is the first person to port DOOM to this OS, although if you’re looking for something more straightforward we would recommend this purpose-built Linux distribution whose sole task is to get you slaying demons as quickly as possible.

Linux On The Windows 11 Desktop

A month ago Microsoft officially released Windows 11. One of its features is the ability to run Linux GUI applications side by side as peers to normal Windows desktop apps. [Jim Salter] of Ars Technica took a closer look and declared it works as advertised.

This is an evolution of the Windows Subsystem for Linux (WSL), which has existed for a few years but only in command-line form. Linux being Linux, it was certainly possible to put visuals onscreen, but doing so required jumping through some hoops and dealing with limitations. Now “WSLg” gives a smoother and more accessible experience.

While tremendously valuable for those who need it, WSLg is admittedly a niche feature. The circumstances will be different for different needs. Around these parts, one example is letting us work with pieces of proprietary Windows software (such as low level hardware drivers or hardware-specific dev tools) while still retaining Linux tools for the rest of our workflow.

It’s also interesting to take a peek behind the scenes for an instructive look at bridging two operating systems. A Microsoft blog post describes the general architecture, where we were happy to see open-source work leveraged. And by basing this work on Wayland, it is more forward-looking than working with just X11.

The bad news is that WSLg is limited to Windows 11, at least for now. WSL users on Windows 10 will have to continue jumping through hoops (We described one method using X11.) And opening this door unfortunately also opened the door to security issues, so there’s still work ahead for WSL.

Linux Fu: The Windows X11 Connection

The life of a Linux user can be a bit difficult. Sometimes you have to — or want to — run Windows. Why Windows? Sometimes you have a work computer or a laptop that Linux doesn’t support well. Or it might be software. Although there are plenty of programs that can edit, say, Word documents, there’s always that one document that doesn’t quite translate correctly. Things like videoconferencing software sometimes works on Linux but might have fewer features.

So what do you do? You can dual boot, of course, but that’s not very handy. You can run Windows in a virtual machine if you have enough horsepower. There’s also Wine, but that often has its own set of problems with features and stability of complex programs. However, recent versions of Windows provide the Windows Subsystem for Linux (WSL).

With WSL, you can have most of what you like about Linux inside your Windows session. You just have to know how to set it up, and I’m going to show you one way that works for me with reasonably stable versions of Windows 10. Continue reading “Linux Fu: The Windows X11 Connection”