alexei.dolgolyov/wled-screen-controller-mixed
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
b9ec509f56be3dd7cc76c197089a5345e5fd8b3d
wled-screen-controller-mixed/TODO.md
alexei.dolgolyov b9ec509f56 Add OpenRGB device support for PC peripheral ambient lighting 
New device type enabling control of keyboards, mice, RAM, GPU, and fans
via the OpenRGB SDK server (TCP port 6742). Includes auto-discovery,
health monitoring, state snapshot/restore, and fast synchronous pixel
send with brightness scaling. Also updates TODO.md with complexity notes.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-01 11:30:02 +03:00

5.2 KiB
Raw Blame History

Pending Features & Issues

Priority: P1 quick win · P2 moderate · P3 large effort

Processing Pipeline

  • P1 Noise gate — Suppress small color changes below threshold, preventing shimmer on static content
  • P1 Color temperature filter — Already covered by existing Color Correction filter (2000-10000K)
  • P1 Zone grouping — Merge adjacent LEDs into logical groups sharing one averaged color
    • Complexity: medium — doesn't fit the PP filter model (operates on extracted LED colors, not images); needs a new param on calibration/color-strip-source config + PixelMapper changes
    • Impact: high — smooths out single-LED noise, visually cleaner ambilight on sparse strips
  • P2 Palette quantization — Force output to match a user-defined palette (preset or custom hex)
  • P2 Drag-and-drop filter ordering — Reorder postprocessing filter chains visually
  • P3 Transition effects — Crossfade, wipe, or dissolve between sources/profiles instead of instant cut
    • Complexity: large — requires a new transition layer concept in ProcessorManager; must blend two live streams simultaneously during switch, coordinating start/stop timing
    • Impact: medium — polishes profile switching UX but ambient lighting rarely switches sources frequently

Output Targets

  • P1 Rename picture-targets to output-targets — Rename API endpoints and internal references for clarity
    • Complexity: low — mechanical rename across routes, schemas, store, frontend fetch calls; no logic changes, but many files touched (~20+), needs care with stored JSON migration
    • Impact: low-medium — improves API clarity for future integrations (OpenRGB, Art-Net)
  • P2 OpenRGB — Control PC peripherals (keyboard, mouse, RAM, fans) as ambient targets
    • Complexity: medium — new device type + client (OpenRGB SDK uses a TCP socket protocol); new target processor subclass; device discovery via OpenRGB server
    • Impact: high — extends ambient lighting beyond WLED to entire PC ecosystem
  • P2 Art-Net / sACN (E1.31) — Stage/theatrical lighting protocols, DMX controllers
    • Complexity: medium — UDP-based protocols with well-documented specs; similar architecture to DDP client; needs DMX universe/channel mapping UI
    • Impact: medium — opens stage/theatrical use case, niche but differentiating

Automation & Integration

  • P2 Webhook/MQTT trigger — Let external systems activate profiles without HA integration
    • Complexity: low-medium — webhook: simple FastAPI endpoint calling SceneActivator; MQTT: add asyncio-mqtt dependency + subscription loop
    • Impact: high — key integration point for home automation users without Home Assistant
  • P2 WebSocket event bus — Broadcast all state changes over a single WS channel
    • Complexity: low-medium — ProcessorManager already emits events; add a WS endpoint that fans out JSON events to connected clients
    • Impact: medium — enables real-time dashboards, mobile apps, and third-party integrations
  • P3 Notification reactive — Flash/pulse on OS notifications (optional app filter)
    • Complexity: large — OS-level notification listener (platform-specific: Win32 WinToast/pystray, macOS pyobjc); needs a new "effect source" type that triggers color pulses
    • Impact: low-medium — fun but niche; platform-dependent maintenance burden

Multi-Display

  • P2 Investigate multimonitor support — Research and plan support for multi-monitor setups
    • Complexity: research — audit DXGI/MSS capture engine's display enumeration; test with 2+ monitors; identify gaps in calibration UI (per-display config)
    • Impact: high — many users have multi-monitor setups; prerequisite for multi-display unification
  • P3 Multi-display unification — Treat 2-3 monitors as single virtual display for seamless ambilight
    • Complexity: large — virtual display abstraction stitching multiple captures; edge-matching calibration between monitors; significant UI changes
    • Impact: high — flagship feature for multi-monitor users, but depends on investigation results

Capture Engines

  • P3 SCRCPY capture engine — Implement SCRCPY-based screen capture for Android devices
    • Complexity: large — external dependency on scrcpy binary; need to manage subprocess lifecycle, parse video stream (ffmpeg/AV pipe), handle device connect/disconnect
    • Impact: medium — enables phone screen mirroring to ambient lighting; appeals to mobile gaming use case
  • P3 Camera / webcam — Border-sampling from camera feed for video calls or room-reactive lighting
    • Complexity: medium — OpenCV VideoCapture is straightforward; needs new capture source type + calibration for camera field of view; FPS/resolution config
    • Impact: low-medium — room-reactive lighting is novel but limited practical appeal

UX

  • P3 PWA / mobile layout — Mobile-first layout + "Add to Home Screen" manifest
    • Complexity: medium-large — responsive CSS overhaul for all tabs; service worker for offline caching; manifest.json; touch-friendly controls (larger tap targets, swipe gestures)
    • Impact: high — phone control is a top user request; current desktop-first layout is unusable on mobile
Reference in New Issue View Git Blame Copy Permalink