Arcan is a powerful development framework for creating virtually anything between user interfaces for specialised embedded applications all the way to full-blown standalone desktop environments. Boot splash screen? no problem. SCADA HMI for your home? easy peasy. Xorg backend? got you covered. Wayland compositor? sure thing.

At its heart lies a robust and portable multimedia engine, with a well-tested and well-documented interface, programmable using Lua. At every step of the way, the underlying development emphasises security, performance and debugability guided by a principle of least surprise in terms of API design.

See the Videos page for videos from projects built using the engine as a main component.

For a high-level presentation, please refer to this video:

A rough list of features:

  • Input devices: keyboards, mice, joysticks/other game devices, touch displays, VR headsets.
  • Output devices: mixed DPI, multi-monitor, multi-/hotswap- GPU, custom LED controllers
  • Audio: streaming playback, device capture,  sample playback.
  • Network Sharing: Video Streaming, VNC client and server.
  • Video: complex 2D hierarchies and animated transforms, 3D models, offscreen rendering effects, GPU shaders, picking, streaming sources and streaming recording.
  • System integration: client state management, suspend/resume, monotonic timers, hotplug, load balancing, DoS protection.
  • Portability: Native graphics on Linux, FreeBSD, OpenBSD. High-level graphics on OSX.
  • Client support: Dedicated backends for Wayland, SDL2, QEmu, Xorg, terminal emulation.

Among the more uncommon features, we have:

  1. An in-process or multi-process IPC system for hooking up custom or preset data-sources such as online video streams, capture devices, custom input drivers and even other running programs as programmable objects for both graphics, audio and input. It is also used to implement support for various display protocols. This permits aggressive privilege separation for what has historically been error-prone and security challenged tasks.
  2. Capable of being its own compositor, display server and window manager at the same time. There are two build outputs, arcan and arcan_lwa (‘lightweight’). Arcan uses the underlying hardware to present aural and visual information and obtains input from external devices. arcan_lwa re-uses most of the same codebase and API, but uses arcan for input and output.
  3. Built-in monitoring and crash-dump analysis. The engine can serialise vital internal state to a Lua script (“crash dump”) or to another version of itself periodically (“monitoring”) to allow external filters and tools to be written quickly in order to track down bugs or suspicious activity.
  4. Fallbacks and crash recovery – The engine can recover from scripting failure without losing client connections, a feature that is also used to migrate clients between different sets of scripts. The IPC system can recover from server crashes, and all clients can migrate to different instances, should the need arise.
  5. Fine-grained sharing – Advanced tasks that are notably difficult in some environments, e.g. recording / streaming controlled subsets of audio and video data sources (including ‘desktop sharing’) requires little more than a handful of lines of code to get going.

The primary development platforms are Linux and BSDs (Free;Net;Open;DragonFly so far), but releases are actively tested on Mac OS X (but with less fancy features) and, up until recently, Windows.

While it works under various high-level display and input subsystems through the help of SDL, a primary goal is for the framework applications to run with as few layers of ”abstraction” and third party dependencies as possible and can often interface with the lowest exposed system interfaces directly.

Envisioning its role as a Display Server:

Think of an X11-like model where you have a Server, a protocol and a number of clients. The server is responsible for controlling hardware and routing shared resources like input samples or clipboard contents. The clients react on input and provides content. The ‘protocol’ regulates how the clients and server communicate. A special client (Window Manager, WM) takes some control over window management (client drawing properties, like position and size), optionally attaching features such as decorations (border, titlebar, …).

With this model in mind, follow these steps:

  1. Divide clients into different privilege levels. Some clients should get access to receiving copies of screen contents, manipulating the clipboard, or tampering with global keyboard input; others don’t even get to use the GPU or create multiple windows.
  2. Move the WM INSIDE the Server Process and give it access to an API with more advanced- and privileged- features than what is offered over the protocol. This cuts down on protocol complexity, and removes a number of intractable synchronisation problems.
  3. Add a scripting interface for the WM. This drastically reduces the “barrier to entry” for developers and advanced users to tune and reconfigure.
  4. Extend the feature scope to include audio. There are way more similarities between audio and video processing than there are differences. This step cuts down on systemic complexity by solving connection setup and IPC, buffer transfers, privilege separation, user controls etc. once. It also makes the WM more powerful.
  5. Remove the ‘protocol’ parts entirely. Replace it with a lock-step API (updates require recompilation against the display server itself) in order to be able to more quickly adapt- and absorb- new features without suffering from “protocol extension hell” or the problems that come with maintaining backwards compatibility to multiple versions.

Point 5 creates real problems for clients of course, who’s going to use it if that is the case?. To combat this, the following steps are taken:

  1. Add special bridging clients that the Window Manager scripts can take extra consideration for in order to support display server protocols. This is how old X clients will be enabled, as well as newer Wayland- capable clients. This approach leads to a more ‘micro-kernel’ like modularity.
  2. Maintain custom backends that use said API for a select few targets that are easy to keep in lock-step and that would benefit from reduced protocol overhead. Due to the design of the segmentation API, these are typically self-contained applications like CLI- tools, Virtual Machine Monitors, Emulators, Games, Web Browsers and so on.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s