diff --git a/docs/design/15-community-ecosystem.md b/docs/design/15-community-ecosystem.md index eeaeba0d3..c5677dff8 100644 --- a/docs/design/15-community-ecosystem.md +++ b/docs/design/15-community-ecosystem.md @@ -809,21 +809,21 @@ WLED is the most natural ally. It's already open source, already has a massive c **Hypercolor's pitch:** -> "Everything proprietary tools do, but open source, Linux-native, and yours to keep." - -| Dimension | Closed-Source Alternative | Hypercolor | -| ------------------------ | ---------------------------- | ------------------------------------ | -| **Platform** | Windows only | Linux-first (future: cross-platform) | -| **License** | Proprietary | Apache-2.0 | -| **Effect compatibility** | Native | ~90% via Servo compatibility layer | -| **Effect format** | HTML/Canvas (proprietary) | HTML/Canvas + native wgpu shaders | -| **Performance** | 60fps (proprietary renderer) | 60fps (Servo) + 1000s fps (wgpu) | -| **Customization** | Limited (closed source) | Infinite (modify anything) | -| **Price** | Free tier + subscription | Free forever | -| **Community effects** | Curated store | Open marketplace (GitHub) | -| **Smart home** | None | Home Assistant integration | - -**Key narrative:** Hypercolor doesn't need to beat closed-source tools on Windows. It needs to be **so good on Linux** that Windows users consider switching. The existence of a compelling open-source alternative creates pressure regardless. +> "Everything proprietary tools do, but open source, native on every desktop, and yours to keep." + +| Dimension | Closed-Source Alternative | Hypercolor | +| ------------------------ | ---------------------------- | ---------------------------------- | +| **Platform** | Windows only | Linux, Windows, and macOS | +| **License** | Proprietary | Apache-2.0 | +| **Effect compatibility** | Native | ~90% via Servo compatibility layer | +| **Effect format** | HTML/Canvas (proprietary) | HTML/Canvas + native wgpu shaders | +| **Performance** | 60fps (proprietary renderer) | 60fps (Servo) + 1000s fps (wgpu) | +| **Customization** | Limited (closed source) | Infinite (modify anything) | +| **Price** | Free tier + subscription | Free forever | +| **Community effects** | Curated store | Open marketplace (GitHub) | +| **Smart home** | None | Home Assistant integration | + +**Key narrative:** Hypercolor meets the closed-source tools on their own platform and everywhere else. It needs to be **so good on every desktop** that vendor apps have nothing left to offer. The existence of a compelling open-source alternative creates pressure regardless. ### 6.3 vs. OpenRGB @@ -1095,14 +1095,14 @@ The README is the most important marketing asset. It should: **Target conferences:** -| Conference | When | Talk Angle | -| ----------------------------- | --------- | ------------------------------------------------------------------- | -| **FOSDEM** | February | "RGB Lighting as a Linux-First Problem" -- embedded systems devroom | -| **Linux Plumbers Conference** | September | "USB HID RGB Device Support in Linux" -- kernel/userspace devroom | -| **SCALE** | March | "Open Source RGB: From Reverse Engineering to Community" | -| **RustConf** | September | "Embedding Servo for Real-Time LED Control" -- Rust ecosystem talk | -| **FOSDEM Rust devroom** | February | "wgpu + Servo: A Dual-Path Render Engine for IoT" | -| **All Things Open** | October | "Building Sustainable Open Source Hardware Projects" | +| Conference | When | Talk Angle | +| ----------------------------- | --------- | -------------------------------------------------------------------- | +| **FOSDEM** | February | "RGB Lighting as an Open Source Problem" -- embedded systems devroom | +| **Linux Plumbers Conference** | September | "USB HID RGB Device Support in Linux" -- kernel/userspace devroom | +| **SCALE** | March | "Open Source RGB: From Reverse Engineering to Community" | +| **RustConf** | September | "Embedding Servo for Real-Time LED Control" -- Rust ecosystem talk | +| **FOSDEM Rust devroom** | February | "wgpu + Servo: A Dual-Path Render Engine for IoT" | +| **All Things Open** | October | "Building Sustainable Open Source Hardware Projects" | **Talk formats:** @@ -1443,7 +1443,7 @@ The path: 1. **Solve the pain** (RGB on Linux sucks → Hypercolor fixes it) 2. **Build the community** (contributors, effect authors, plugin developers) 3. **Win the ecosystem** (hardware partnerships, distro integration, smart home) -4. **Transcend the platform** (Linux-first → everywhere) +4. **Transcend the platform** (every OS, every device, every room) Hypercolor isn't just software. It's the argument that open source can do creative, visual, hardware-integrated things better than closed-source alternatives. And it's built by someone who has proven that argument before. diff --git a/docs/research/faces/nzxt-cam.md b/docs/research/faces/nzxt-cam.md index ac176e430..efaeb5c4f 100644 --- a/docs/research/faces/nzxt-cam.md +++ b/docs/research/faces/nzxt-cam.md @@ -261,7 +261,7 @@ Complaints: 1. **The web-face model itself is validated.** NZXT proved that "embedded browser renders HTML to a small LCD" is a shippable, mainstream-loved product feature. Hypercolor's Servo pipeline is the same bet with a better engine story (in-process, - GPU-interop, Linux-first). Lean into it. + GPU-interop, cross-platform). Lean into it. 2. **Tiny versioned injected API** — `window.nzxt.v1` with a static display descriptor (`width/height/shape/targetFps`) plus a typed npm package is exactly the right shape. Hypercolor's face context should expose geometry + shape + diff --git a/docs/specs/01-core-engine.md b/docs/specs/01-core-engine.md index c06d3bd7a..a158f1ba0 100644 --- a/docs/specs/01-core-engine.md +++ b/docs/specs/01-core-engine.md @@ -1533,7 +1533,7 @@ pub enum EngineCommand { ## 8. Cross-Platform Considerations -Hypercolor is Linux-first, but the architecture isolates platform-specific code behind trait boundaries. This section catalogs what is universal and what needs platform-specific implementations. +Hypercolor runs on Linux, Windows, and macOS, and the architecture isolates platform-specific code behind trait boundaries. This section catalogs what is universal and what needs platform-specific implementations. ### 8.1 Platform Matrix diff --git a/docs/specs/23-session-power-awareness.md b/docs/specs/23-session-power-awareness.md index 523bd7754..4cfeda075 100644 --- a/docs/specs/23-session-power-awareness.md +++ b/docs/specs/23-session-power-awareness.md @@ -50,7 +50,7 @@ This spec defines a **session monitor** subsystem that observes desktop and hard **Design principles:** -- **Linux-first.** D-Bus (logind, freedesktop screensaver) and kernel (evdev) are the primary backends. Cross-platform can follow later. +- **Native backends per platform.** D-Bus (logind, freedesktop screensaver) and kernel evdev on Linux, `WM_POWERBROADCAST` plus WTS session events on Windows, and NSWorkspace plus IOKit power notifications on macOS, all feeding the same `SessionEvent` stream. - **Event-driven, not polling.** Subscribe to D-Bus signals and kernel input events. No timers ticking to check state, except as a fallback for idle detection on X11. - **Graceful degradation.** Each monitor is independent. If logind is unreachable (container, WSL), the screensaver monitor still works. If neither D-Bus bus is available, the daemon runs without session awareness. - **Inhibitor-aware.** Acquire a logind sleep inhibitor lock so the daemon can complete its fade-out before the kernel actually suspends. diff --git a/docs/specs/56-linux-servo-gpu-surface-interop.md b/docs/specs/56-linux-servo-gpu-surface-interop.md index 6bca69580..2ed5a7548 100644 --- a/docs/specs/56-linux-servo-gpu-surface-interop.md +++ b/docs/specs/56-linux-servo-gpu-surface-interop.md @@ -224,7 +224,7 @@ after composition, not Servo-specific. ## 6. Linux Import Strategy -The Linux first implementation should use the proven external-memory shape: +The Linux implementation should use the proven external-memory shape: 1. Create a Vulkan image with exportable opaque-FD memory using the same Vulkan device behind SparkleFlinger's `wgpu::Device`. diff --git a/docs/specs/60-user-media-and-layer-stack.md b/docs/specs/60-user-media-and-layer-stack.md index 163d1408f..16159e4a6 100644 --- a/docs/specs/60-user-media-and-layer-stack.md +++ b/docs/specs/60-user-media-and-layer-stack.md @@ -730,7 +730,7 @@ or audio band can drive playback rate at runtime. | 1 | APNG | `image` + `png` (APNG support) | CPU | Same as GIF. | | 1 | PNG sequence (dir) | `image` | CPU | Discovery + ordering policy needed. | | 2 | Animated WebP | `image-webp` / `webp-animation` | CPU | WebP-VP8L vs VP8 path differences. | -| 3 | MP4 / WebM video | `gstreamer-rs` (Linux first) | GPU upload | LGPL surface; codec packages required. | +| 3 | MP4 / WebM video | `gstreamer-rs` | GPU upload | LGPL surface; codec packages required. | | 4 | Lottie | `rlottie` | CPU | Native C++ dependency. Rasterizes per frame. | | 5 | HTTP / HLS livestream| `gstreamer-rs` `playbin` | GPU upload | Network failure model; reconnect policy. |