Vision track: camera and screen input on taOS, accelerated where hardware allows

[jaylfc]

Splitting this out of #1771 so it is tracked properly rather than living as a side thread. Raised after a community tester (@doc62fr) asked whether a firmware 5.1.x to 5.3.0 upgrade was planned to enable the camera path, and the honest answer was that vision is scoped as a separate track rather than unwanted.

Why this matters beyond one accelerator

Giving an AI access to a camera or a screen is becoming a normal expectation rather than an exotic one, and it is precisely the capability people are least willing to send to someone else's cloud. A vision pipeline that runs entirely on hardware the user owns is one of the strongest arguments taOS has: the footage never leaves the house.

The Hailo-10H is also a vision accelerator that happens to do LLMs. Using it only for chat leaves most of what the silicon is for on the table.

Current scope boundary

docs/design/hailo-llm-backend.md states it explicitly: "Camera/vision workloads on Hailo are the optional Store track (section G), not this backend." That boundary was right for the LLM slice and should stay. This issue is the other side of it.

Hard dependency

#2086 (AI HAT+2 not detected at install) blocks this entirely. Until taOS reliably sees the accelerator, no vision work can reach it, and firmware version is irrelevant. Do not start here.

Scope to decide

1. Firmware. 5.1.0 runs LLMs; 5.3.0 adds the V4L2 stream a USB camera needs. Any upgrade must be an explicit, user-consented step with a clear warning, never something the installer performs silently. Upgrading firmware is risky and hard to reverse, and on second-hand hardware doubly so.
2. What a vision pipeline actually delivers in taOS. Object and person detection feeding the event bus, a camera source an agent can query, or frames into the Library and memory. These are different products and the choice shapes everything downstream.
3. Permissions. Camera access is the sharpest case for Per-agent permission model: filesystem, network, clipboard, camera granted explicitly #133 (per-agent permission model) and Per-app permissions: padlock in the window title bar → permissions manager (models, file access, capabilities) #622 (per-app permissions). A camera an agent can silently open is not acceptable; the consent surface has to exist before the capability does.
4. Model track. Gemma 4 E4B + E2B Non censuré (Agressif) — GGUF + K_P Quants (Multimodal : Vision, Vidéo, Audio) #1836 (Gemma 4 multimodal, vision/video/audio) is the natural model-side companion. Vision .hef models for Hailo are a separate catalogue question from chat models.
5. Non-Hailo paths. Screen capture and existing webcams on x86 hosts should not be forgotten because the trigger was an NPU HAT. The permission and consent design should be device-agnostic even if the first acceleration target is not.

Reference

gregm123456/raspberry_pi_hailo_ai_services, surfaced by the community on #1771, is a working Pi plus Hailo AI-services project and the ground-truth reference for the pipeline shape.

Related: #1771 (LLM backend), #2086 (detection, blocking), #1836 (multimodal models), #133 and #622 (permissions), #854 (dynamic island, screenshot-to-attach).