v0.3.1

Release 0.3.1: clean Extend picture on Qualcomm tablets, X11 touch on…

v0.3.0

Host: zero-copy capture through VA-API

The compositor's DMA-BUF now goes straight into the encoder: it is mapped
as a VA surface (no copy) and the GPU's video processor scales, letterboxes
and converts it to NV12 (scale_vaapi + pad_vaapi) before VA-API encodes it.
No pixel crosses the CPU.

Measured on a 60 fps 1080p test pattern mirrored to a 1600x720 phone:
  CPU per frame   20.9 ms (0.3.0) -> 8.1 ms (SIMD scaler) -> 1.1 ms
  capture thread  16 ms -> 4.8 ms -> 0.04 ms
  frame rate      31-33 -> 50 -> 58 fps; phone latency 36 -> 22 ms
The whole daemon streams at 6.6% of a core. Colours match the CPU path to
within 1-3/255 (the VPP needs matrix, primaries and transfer all set to
BT.709; with the matrix alone it converted with BT.601).

- lamco-pipewire: DMA-BUF passthrough is configurable from the builder, and
  passthrough frames carry the negotiated fourcc (BGRx was labelled BGRA).
- capture: Frame/RawFrame carry an optional GpuFrame (fd, stride, modifier,
  fourcc). Captures ask for passthrough only while a VA-API encoder has
  zero-copy ready; any import failure turns it off and frames are read back
  to the CPU (GpuFrame::read_linear), so a missing filter (FFmpeg 4.4 in the
  AppImage has no pad_vaapi) degrades to the old path instead of failing.
- encoder: encoder/zerocopy.rs (DRM frames -> derived VA-API frames ->
  filter graph); rebuilt when the source changes or a bitrate change reopens
  the encoder. DISPLAYSWARM_ZEROCOPY=0 turns it off.
- CI: libavfilter-dev for the Debian/Ubuntu builds.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0136ntADhC7Bm2oH17uq1UTA

v0.2.0

Update pointer speed default, shortcut keys, pointer acceleration, IM…

v0.1.4

v0.1.4