Shims

0 entries
Name Status Updated Notes

Status:
Updated:
Author:
License:
Source:

Pico Neo 2 - Hardware & Software Specs

sourced from teardown & decomp

Reference specs for the Pico Neo 2 headset. Hardware data comes from teardowns and chip identification. Software/runtime info comes from decomp work. Edit via MR in /data/specs/.

Pico Neo 2 - SDKs

official Pico SDKs & tools

Documentation for the Pico Neo 2 SDKs and development tools. All SDKs are licensed under the Pico SDK License Agreement and are not available for download on this site. Edit via MR in /data/sdks/.

News

0 posts

Updates from the revival effort. New posts are typically from maintainers, but anyone can edit or suggest corrections via MR.

Date:
Author:

Contribute

no coding required

How to add or update an entry

Every entry on this site is a markdown file in the /data directory. You don't need to write any code, just edit a text file and open a merge request.

The repo lives at gitlab.com/HttpAnimations/neorevived. You can do everything from the GitLab web interface — no local clone, no terminal, no build tools required.
Closed-source projects are not allowed. All entries must point to an openly licensed repository. If you're not sure which license to use, go with AGPL-3.0.

Steps

  1. Go to the /data/<category>/ folder in the repo (e.g. /data/shims/)
  2. Click New file (or edit an existing one)
  3. Name it after the project's host path, e.g. gitlab.HttpAnimations.neorevived.md (format: platform.owner.project.md)
  4. Copy the template below into the file
  5. Fill in the frontmatter and write your content in markdown
  6. Commit to a new branch and submit the merge request
  7. GitLab CI will validate your file, if it passes, it gets merged and the site updates automatically

File template (entries)

---
name: gitlab.HttpAnimations.neorevived
humanname: NeoRevived
category: shims
status: working
updated: 2026-07-10
author: calico
license: AGPL-3.0
readme_url: https://gitlab.com/HttpAnimations/neorevived/-/raw/main/data/shims/example.md
sourceurl: https://gitlab.com/HttpAnimations/neorevived
downloads: false
notes: Drops in as libopenxr_loader.so, translates OpenXR 1.0 to native runtime
tags:
  - openxr
  - api-shim
---
The body below the second --- is ignored for entries — the build fetches and renders the README from readme_url instead.

File template (entries with downloads)

---
name: gitlab.HttpAnimations.neorevived
humanname: NeoRevived
category: shims
status: working
updated: 2026-07-10
author: calico
license: AGPL-3.0
readme_url: https://gitlab.com/HttpAnimations/neorevived/-/raw/main/README.md
sourceurl: https://gitlab.com/HttpAnimations/neorevived
downloads: true
download_list:
  - version: RC5
    url: https://gitlab.com/HttpAnimations/neorevived/-/releases/RC5
    date: 2026-07-10
    notes: Fix lobby flickering, improve stuttering
    commit: 9d99acc0dcf0d58008930e10f6eda1fcabde2896
  - version: RC4
    url: https://gitlab.com/HttpAnimations/neorevived/-/jobs/artifacts/RC4/raw/app-debug.apk
    date: 2026-07-01
    notes: Harden rendering, fix controller buttons
    commit: 13457b85ce3a656dd60ace3279cdf1a2d05f2313
notes: Drops in as libopenxr_loader.so, translates OpenXR 1.0 to native runtime
tags:
  - openxr
  - api-shim
---
When downloads is true, a downloads section appears on the project's detail page. Each version shows the version label, release date, a direct download or external link (detected automatically from the URL), and a link to the exact commit it was built from.

File template (entries with compatibility)

---
name: gitlab.HttpAnimations.neorevived
humanname: NeoRevived
category: shims
status: working
updated: 2026-07-10
author: calico
license: AGPL-3.0
readme_url: https://gitlab.com/HttpAnimations/neorevived/-/raw/main/README.md
sourceurl: https://gitlab.com/HttpAnimations/neorevived
downloads: false
compatibility: true
compatibility_url: https://gitlab.com/HttpAnimations/neorevived/-/raw/main/COMPATIBILITY.md
notes: Drops in as libopenxr_loader.so, translates OpenXR 1.0 to native runtime
tags:
  - openxr
  - api-shim
---

```json compat
{
  "table_header": "| Game | Status | Notes |",
  "columns": [
    { "key": "game", "label": "Game", "type": "text" },
    { "key": "status", "label": "Status", "type": "status" },
    { "key": "notes", "label": "Notes", "type": "text" }
  ]
}
```
When compatibility is true, the build fetches the markdown file at compatibility_url and parses the table whose header matches table_header in the JSON spec. The ```json compat block goes in the body of your entry file (after the second ---). Each column maps a table cell to a key. Supported column types: text, link (renders as clickable URL), status (colored badge). The table is rendered on the project's detail page.
The table_header string must exactly match the header row in the remote markdown file, including pipes and spacing. The parser finds that line, skips the separator row, and reads all subsequent pipe-delimited rows.
URL shorteners and ad-supported download services (adfly, linkvertise, bit.ly, etc.) are not allowed. All download URLs must be direct links to the file or the official release page. Every version must be locked to a specific commit hash or commit URL. Entries that don't follow these rules can still be submitted but have a high chance of not being merged or updated.

File template (news)

---
date: 2026-07-14
title: OpenXR shim v0.3 released
author: calico
summary: v0.3 brings full OpenXR 1.0 conformance for the core API.
tags:
  - shims
  - release
---

## What's new

Version 0.3 of the OpenXR shim is out...

File template (specs - table)

---
section: Hardware
order: 1
type: table
rows:
  - key: SoC
    value: Qualcomm Snapdragon 845 (SDM845)
  - key: RAM
    value: 6 GB LPDDR4X
---

Optional freeform notes go here in markdown.

File template (specs - quirks)

---
section: Known Quirks
order: 3
type: quirks
quirks:
  - label: Compositor crash on VR mode entry
    desc: The native compositor segfaults when entering VR mode after a cold boot.
  - label: Controller 6DOF drift
    desc: Electromagnetic tracking drifts after ~20 min of continuous use.
---

Frontmatter fields

The YAML block between the --- markers is required. Here's what each field means:

  • name: must follow the format platform.owner.project (e.g. gitlab.HttpAnimations.neorevived or github.user.project). Must match the filename (without .md). Nested groups use dots: gitlab.group.subgroup.project
  • humanname: human-readable display name shown in the listing and detail pages (e.g. Pico Neo 2 WiVRn)
  • category: one of: shims, streaming, decomp, projects
  • status: one of: planned, in-progress, working, broken
  • updated: date of last meaningful change, format YYYY-MM-DD
  • author: your username or name
  • license: the SPDX identifier of the project's license (e.g. AGPL-3.0, MIT, GPL-3.0)
  • readme_url: raw URL to the project's README file (fetched and rendered at build time)
  • sourceurl: URL to the project's repository page (e.g. https://gitlab.com/HttpAnimations/neorevived)
  • downloads: boolean, set to true if the project has downloadable releases
  • download_list: required when downloads is true. List of download entries, each with:
  • version: version label (e.g. RC5, v0.3)
  • url: direct download link or release page URL. Optional — if omitted, the version is listed for tracking only with no download link
  • date: release date in YYYY-MM-DD format
  • notes: optional short changelog for that version
  • commit: full commit hash (e.g. fa32a521f16d3f697b6357c737940df3548301b2) or full commit URL. Required when url is present. If both url and commit are omitted, the entry is version-tracking only. If a bare hash is provided and sourceurl is a GitLab/GitHub URL, the build auto-generates the commit link
  • compatibility: boolean, set to true if the project has a remote compatibility table to embed
  • compatibility_url: required when compatibility is true. Raw URL to a markdown file containing a pipe-delimited table
  • deprecated: boolean, set to true if the project is no longer actively maintained. Shows a deprecated badge in the listing and a warning banner on the detail page
  • notes: one-line summary shown in the listing table
  • tags: optional list of tags for search/filtering

News files use date, title, author, summary, and optional tags, no status field.

Specs files use section, type (table / quirks / freeform), optional order, and either a rows or quirks list depending on type.

README fetching

For entry categories (shims, streaming, decomp, projects), the build fetches the README from readme_url and renders it on the detail page. The markdown body in the .md file itself is ignored — only the frontmatter matters.

What happens after I submit?

  1. GitLab CI runs a validate job that checks your frontmatter is correct
  2. If it fails, you'll see an error in the MR, fix it and push again
  3. Once merged, the build job bundles all markdown files into the site
  4. The deploy job publishes to GitLab Pages, usually live within a minute