superturtlee/anland

★ 15CAudience · developerComplexity · 5/5Setup · hard

Mindmap

mindmap
  root((Anland V3))
    Architecture
      Daemon broker
      Linux producer
      Android consumer
    Channels
      Control socket
      Data socket pair
      Buffer-ready eventfd
      Fence socket pair
    V3 additions
      Bidirectional clipboard
      Variable-length events
      ABI break from V2
    Tech
      C language
      DMA-BUF
      SCM_RIGHTS
      Unix domain sockets

mindmap root((Anland V3)) Architecture Daemon broker Linux producer Android consumer Channels Control socket Data socket pair Buffer-ready eventfd Fence socket pair V3 additions Bidirectional clipboard Variable-length events ABI break from V2 Tech C language DMA-BUF SCM_RIGHTS Unix domain sockets

Click or tap to explore — scroll the page freely

Things people build with this

USE CASE 1

Mirror a KWin or Weston Linux desktop onto an Android device's screen without a network encoder.

USE CASE 2

Implement a custom Android consumer that receives GPU frames and clipboard data from a Linux compositor.

USE CASE 3

Upgrade an existing V2 Anland consumer or producer to handle V3 variable-length clipboard events without corrupting the socket stream.

Tech stack

CLinuxAndroidUnix socketsDMA-BUF

Getting it running

Difficulty · hard Time to first run · 1day+

Requires a Linux system with a compatible compositor backend, an Android device, and low-level C build tooling, V2 integrations must be updated for V3 ABI changes.

License not specified in this repository.

In plain English

Anland Display Protocol V3 is a low-level C library and set of binaries that let a Linux desktop compositor share its GPU-rendered frames with an Android device over a Unix domain socket. The practical use case is displaying a Linux desktop on an Android screen in real time, without going through a network connection or video encoder. The system has three components. A small daemon process sits in the middle and brokers the connection between the other two. The producer is the Linux side: a compositor like KWin or Weston renders the desktop into shared GPU memory buffers. The consumer is the Android side: it owns the GPU memory, allocates the shared buffers, and presents the frames to the display. Because the consumer controls the memory, it manages all the file descriptor passing between processes using a Linux feature called SCM_RIGHTS. Version 3 adds bidirectional clipboard exchange, which V2 did not have. Both the producer and the consumer can now push clipboard text to each other over a data channel. This involves a variable-length message format: clipboard events have a header followed by a payload of varying size. This is an intentional breaking change from V2. A V2 client that reads fixed-size events will leave leftover bytes in the socket buffer after a clipboard message, corrupting all subsequent messages. Callers upgrading from V2 must handle or drain every event type, including ones they do not use. Communication uses four channels: a control socket to the daemon for the handshake, a data socket pair for events and clipboard content, an eventfd for signaling that a buffer is ready to render, and a socket pair for the render-done fence. The daemon socket lives at a fixed path on the device. This is a niche, systems-level project targeting developers who work on Linux-to-Android display bridging or compositor backends.

Copy-paste prompts

Prompt 1

How do I implement the V3 handle_unhandled_event call in my Anland consumer so variable-length clipboard payloads do not corrupt the socket stream?

Prompt 2

Walk me through building and running the Anland daemon, a test SDL consumer, and a KWin producer backend on a Linux system.

Prompt 3

Explain the four communication channels in Anland V3 and which process creates each one.

Prompt 4

How does the Anland consumer pass DMA-BUF file descriptors to the producer using SCM_RIGHTS during the hello handshake?

Open on GitHub → Explain another repo

← superturtlee on gitmyhub — every repo by this author, as a profile.

Verify against the repo before relying on details.