Linux backend: how to start, and where the seams are

[iagodpassos]

The platform matrix lists Linux as planned, and that is still true. This is
the map for anyone who wants to start it — including how to make the first
useful contribution without implementing the whole thing.

How backends are structured here

There is no backend trait, deliberately —
backend/mod.rs
explains why: only one backend exists in any given build, so a trait would buy
dynamic dispatch nobody wants and hide which implementation is in play. The
contract is instead structural: a pub(crate) struct Inner exposing a fixed
set of methods, selected by cfg in
autoit.rs.

So a Linux backend is autoitx/src/backend/linux/inner.rs with the same 47
methods as
backend/macos/inner.rs,
plus one cfg arm in autoit.rs. The macOS backend is the model to copy: it
is the one that was written against an API bearing no resemblance to AutoIt's,
which is exactly the position X11 is in.

Please do not send it in one PR

The macOS backend is ~3,000 lines across nine modules and took several weeks.
Reviewing that in one piece serves nobody. Suggested slices, each independently
useful and mergeable:

1. Input and clipboard — send, send_text, mouse_*, clip_get,
   clip_put, clip_sequence. XTEST via x11rb
   for input; XFIXES selection-notify for the clipboard counter. Note that
   clip_sequence returning Option<u32> is what makes
   recipes::read_screen_text race-free — if X11 cannot give a real counter,
   return None rather than a fake one, and say so in the module docs.
2. Windows via EWMH — _NET_CLIENT_LIST, _NET_WM_NAME, _NET_WM_PID.
   Covers win_exists / win_activate / win_get_* / win_set_state.
   Selector's CLASS: maps to WM_CLASS here, which is a closer fit than
   it was on macOS.
3. Pixels — XGetImage, or xcb_shm if you want it fast.
4. Processes and run — mostly /proc and std::process, little X11.
5. AT-SPI via zbus for the control API
   and recipes::wait_until_idle. Last, because it is the piece that needs the
   most design and the least of it is shared with the rest.

Wayland is explicitly out of scope for a first pass. There is no portable
input injection there; it needs libei or a portal, and that is its own issue.
Starting X11-only is the right call, and the matrix should say X11.

Rules the backend has to hold to

• Coordinates are logical points, top-left origin, primary display on every
  platform. That invariant is what lets the portable core mean one thing
  everywhere — read the Coordinates section at the top of
  backend/macos/mod.rs
  before writing any geometry.
• Capability gaps are compile errors, not runtime errors. Whatever X11
  cannot do goes in ext::linux, and the matrix in the README gets an honest
  ❌. Do not add an Err(Unsupported) arm to a portable method.
• The Options defaults are emulated, not reinvented — same table as
  AU3_Init leaves behind. See
  options.rs.
• #![deny(missing_docs)] is on, and CI runs clippy with -D warnings for
  every feature combination.

Before you invest time

Please say here which slice you are taking, so two people do
not write the same one. I would rather answer design questions early than
review a large PR that took a different shape than the rest of the crate.