split each Viture display into an independent fullscreen fallback/menu canvas below fpv-video and a dedicated top-level OSD overlay above it
make the OSD layer transparent and input-transparent before mapping, with fail-safe refusal when X11 SHAPE support is unavailable
keep video-presence lifecycle and restacking independent from telemetry and preserve a separate future MIPI/touch target boundary
Validation
go test -count=1 -race ./...
go vet ./...
gofmt -l .
ARM64 builds of both binaries
git diff --check origin/main
added-lines secrets/security scan
Closes #8
## Summary
- split each Viture display into an independent fullscreen fallback/menu canvas below `fpv-video` and a dedicated top-level OSD overlay above it
- make the OSD layer transparent and input-transparent before mapping, with fail-safe refusal when X11 SHAPE support is unavailable
- keep video-presence lifecycle and restacking independent from telemetry and preserve a separate future MIPI/touch target boundary
## Validation
- `go test -count=1 -race ./...`
- `go vet ./...`
- `gofmt -l .`
- ARM64 builds of both binaries
- `git diff --check origin/main`
- added-lines secrets/security scan
grzesiu
self-assigned this 2026-10-01 15:46:45 +02:00
Drive two independent visual layers per display target from one shared
video presence signal: the fullscreen fallback/menu canvas below video
and a transparent, input-transparent OSD overlay above video, reserved
as the future flight OSD rendering surface. WFB and video decode stay
out of the UI process; pilot video keeps rendering priority.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #8
Summary
fpv-videoand a dedicated top-level OSD overlay above itValidation
go test -count=1 -race ./...go vet ./...gofmt -l .git diff --check origin/maincc916517efto41552b4797