What is deliberately absent
Capabilities that are missing on purpose — no OCR, no XDamage, no streaming — and the reason given for each.
A tool is defined as much by what it refuses to do as by what it does. This page lists what eensh does not attempt, and the reason for each, because several of these would be easy to add and would each make the tool worse.
Not implemented, deliberately
| Absent | Why |
|---|---|
| OCR and text recognition | Reading text is a modelling problem with a large dependency surface and a confidence question that a capture tool has no business answering. |
| Object detection | The same, more so. A caller that needs it should run it, on the frames this tool returns, in the language of its choice. |
| Semantic ROI discovery | Every region comes from a caller-supplied rectangle. Guessing which areas matter would make behaviour depend on a heuristic rather than on the request. |
| Connected components | The changed area is returned as one rectangle. Splitting it into meaningful clusters is a judgement call — and getting it wrong silently merges or separates changes the caller cared about. |
| XDamage | Change detection remains pixel comparison. Damage events are a backend efficiency, not a semantic change, and pixel comparison is something a caller can reason about. |
| XShm | Capture goes through the ordinary X11 path, so it works over any transport without a setup step or a capability check. |
| Optical flow | Frames are ordered by capture time and nothing else. The tool reports how things looked, not how they moved between looks. |
| Push streaming | Every response is a reply to a request. There is no subscription to a stream, because a caller that asks and waits has a much simpler failure model than one that must handle unsolicited messages. |
| Adaptive capture scheduling | The schedule is fixed at request time and cannot be influenced by presentation. This is what makes sampling reproducible, and it is verified by a test rather than assumed. |
What these refusals have in common
There is a common thread. Every item above would make behaviour depend on something other than the request: a heuristic, a capability, a timing race, or a model’s confidence. The tool would still work, and it would be much harder to predict.
The presentation layer, in particular, contains no image analysis beyond cropping, resizing, and encoding. It has no notion of what is in a frame — only where a rectangle is and what was asked for. That is what keeps its behaviour explicable from the policy alone.
Also absent, for reasons other than predictability
- Disk persistence of frames. History lives in memory and is deliberately not written anywhere. A frame spool on disk is a privacy and lifecycle problem the caller should own.
- A network service. The socket is local. Exposing it is a deployment decision, not a capture decision.
- Input injection. This observes. Sending synthetic input is a different tool with a different risk profile, and combining them would make it impossible to hand out the observation half safely.
- Wayland. The capture path is X11. Wayland’s compositor-mediated model is sufficiently different that treating it as a transport detail would produce something that half works.
Deferred rather than refused, and addable without changing any answer
Two things are backend efficiency rather than scope, and could be added without breaking anything above: damage-assisted wakeup, which would make observation cheaper without changing what it means; and shared-memory capture, which would make large captures faster without changing the pixel path.
Neither changes an answer. That is the test anything of this kind has to pass.