Project direction
How CrossPoint is evolving, what we're focused on, and where we're intentionally drawing the line.
Roadmap
CrossPoint transitions from its current state into the tighter scope below in sequential phases. We close out commitments already in flight before locking down to the stricter "fill gaps the stock firmware leaves" delineator. Phases are sequential — we do not start the next phase until the prior one is wrapped or explicitly carried over.
Goal: Land the work already in motion under the prior, broader scope so contributors are not left hanging, and so we enter the stricter phases with a clean slate.
In Phase 0
Exit criteria
Once Phase 0 closes, the tighter scope is fully enforced. "But it was on the old roadmap" is no longer a valid argument.
Goal: Reduce memory and flash usage and clean up the codebase so that future device support and reading-quality work has room to breathe.
Focus areas
Goal: Land the SDK / HAL generalization work so CrossPoint runs cleanly on ESP32-based e-reader hardware beyond Xteink (X3 / X4), including ESP32-S3 class devices. In parallel, lay the groundwork for CrossPoint to act as a safe bridge onto community firmware for users on locked devices.
Focus areas
Bootloader / recovery bridge: a workflow that helps users on locked devices reach community firmware (CrossPoint or other forks) without bricking. Includes a recoverable fallback when a flash goes wrong. Fork-neutral — CrossPoint should be a bridge, not a trap. Driven by @jeremydk alongside the SDK abstraction work.
Depends on Phase 1 cleanup landing first; otherwise we generalize a moving target.
Goal: With the codebase smaller and portable, invest in the things only a focused reader firmware should do: EPUB rendering, typography, hyphenation, layout edge cases, and gap-filling for languages and scripts that neither stock nor other CrossPoint forks handle well.
Focus areas
Explicitly not on the roadmap. May live in other CrossPoint forks; won't be picked up here.
Scope
The goal of CrossPoint Reader is to create an efficient, open-source reading experience for ESP32-based e-reader devices. Xteink hardware (X3, X4) is where the project started and remains a primary target, but CrossPoint is broadening to support the wider ecosystem of small ESP32 e-ink readers. A dedicated e-reader should do one thing exceptionally well: facilitate focused reading.
A lightweight, high-performance firmware that maximizes the potential of ESP32-based e-reader hardware, prioritizing legibility, performance, and usability over "swiss-army-knife" functionality. Not a kitchen-sink firmware. Not Xteink-only. Device-specific code lives behind the HAL / SDK boundary so the reader core stays portable across ESP32-C3, ESP32-S3, and adjacent variants.
Fill the gaps the stock firmware leaves.
Language priority: English first, then languages where stock firmware fails or forks haven't addressed gaps.
Intentionally narrowing scope to consolidate the codebase as we open it up to more ESP32 e-reader devices.
Memory footprint
DRAM & heap. ESP32-C3 sets the ceiling.
Flash footprint
Room for more device targets & features.
Code cleanup
Refactors, dead code, tighter abstractions.
Reading experience
EPUB, typography, hyphenation, legibility.
Temporarily closed
New themes (theming surface is frozen) and new external network connectors (sync engines, cloud storage, OPDS extensions, remote file access). Open a Discussion first if you're unsure.
Rendering engine, CSS/image handling, parsing performance.
Fonts, hyphenation, spacing, margins.
Fewer full-screen flashes, better ghosting management.
Bookmarks, progress, button mapping, navigation.
Simple, intuitive local-collection organization.
Pull-based loading via web server or widely-used standards.
Local, offline dictionary lookup.
Refactors that reduce resource use, even without a user-visible feature.
Helps users on locked devices reach any community firmware safely.
No notepads, calculators, or games.
Input hardware and RAM are wrong for this.
No RSS, news aggregators, or web browsers.
No audio players or audiobooks.
No typed-out notes.
If it already works well, we don't reimplement it.
If another popular fork solves it well, we defer.
Fixed layout makes for a poor e-ink reading experience on this hardware class.
Before proposing a feature, ask:
Note to contributors: CrossPoint is intentionally narrow. "It would be cool if..." features are not enough; the bar is "this fixes something the stock firmware does poorly, or it makes the firmware leaner and easier to maintain."
Where contributor help is most valuable right now. Open a Discussion or issue first so we can coordinate.
Abstract themes out of firmware so they load from SD card instead of consuming flash.
Status: @itsthisjustin plans to take this on eventually but is open to someone claiming it sooner.
Generalize SDK layers (display, input, storage, battery) away from Xteink-specific assumptions.
Status: @jeremydk is actively working. Coordinate before touching open-x4-sdk/ or lib/hal/.
Bootloader / recovery-flash workflow that lets users reach any community firmware without bricking, with a recoverable fallback when a flash goes wrong.
Status: @jeremydk alongside SDK abstraction. ESP32 bootloader / OTA experience welcome.
Catalogue what stock (and other popular forks) handle poorly: RTL text, underserved languages, rendering edge cases, accessibility, input quirks.
Feedback even without code is genuinely useful — open a Discussion with screenshots, sample EPUBs, and expected vs actual behavior.
CrossPoint uses Royalty.dev (a product built by @itsthisjustin) to fund contributors. There has been some tension in the community around this, so the intent is being clarified here directly.
Why we do this
How it works
This is not fixed in stone. Weighting, eligibility, and distribution rules can be tweaked. If you have concerns or suggestions, open a Discussion. The goal is a system that fairly recognizes the people doing the work, not a perfect one on day one.