Check your XR glasses in the browser
Plug the glasses into a computer and this page shows what the machine can actually see: the HID interface they expose, whether input reports are flowing, and how steady they are. It ends with a report you can paste into a support thread instead of describing the problem in words.
What this can and cannot see
| Item | Visible? | Why |
|---|---|---|
| Device identity (vendor, product, name, serial) | Yes | Read from the USB/HID descriptors once you approve the device |
| HID collections (what the device exposes) | Yes | This is the hard evidence that the cable and the link are real, not a charge-only connection |
| Input report rate and jitter | Yes | Counts real reports for three seconds — the first number to look at when head tracking stutters |
| Display mode, refresh rate, DP Alt-Mode status | No | That lives below the browser: no web API exposes it. The OS display panel is the place to look |
| Firmware version / flashing | No | Vendor-specific protocol; updates belong to the vendor's own tool |
Which devices this page can talk to
- USB-C glasses with a HID interface — VITURE, XREAL, Rokid, RayNeo and similar. They are accessories: the computer is the host, so the browser can see them.
- Standalone headsets (Quest, Pico, Vive Focus) — no. They are Android computers running their own OS, and their browser cannot open a USB accessory. There is nothing for a web page to connect to.
- Apple Vision Pro — no. visionOS is not Android and its browser is WebKit, which does not implement WebHID.
- PC-tethered headsets (Index, Reverb, Bigscreen Beyond) — usually no: they enumerate as display/audio or need a vendor runtime, not a HID device a page may open.
Which brands can be checked — and updated — in a browser
Two different questions that get mixed up: can a web page read the device at all, and does the vendor ship a web firmware tool. Both answers are per brand, so here is the table. "Check" means this page can read it; "Update" links to the vendor's own tool — this page never writes firmware.
| Brand | Check here | Update in a browser | Desktop app | Phone app |
|---|---|---|---|---|
| VITURE One, Lite, Pro XR, Luma, Pro 2 | Yes — HID interface confirmed (usage 0xFF00, 64-byte reports) | static.viture.com/dfu-util | SpaceWalker (Windows) | Yes |
| XREAL Air, Air 2, Air 2 Pro, One | Yes — same HID channel (model not measured yet) | xreal.com/ota | Nebula (macOS; Windows beta) | Nebula |
| RayNeo / TCL NXTWEAR S, Air 2, Air 2s, Air 3s | Yes — HID channel (model not measured yet) | ota.rayneo.com | — | Yes |
| Rokid Max, Air | Yes, as a generic HID device | No — the vendor updates through the phone app only | — | Hi Rokid |
| Quest / Pico / Vive Focus | No — they are computers running their own OS | On the headset itself | — | Yes |
| Apple Vision Pro | No — visionOS browser has no WebHID | On the device | — | — |
Table checked on 5 November 2026: the VITURE, XREAL and RayNeo update pages were fetched and answered, and the VITURE USB/HID descriptor was read on a real device. Fields we have not measured are marked that way rather than guessed.
Reading the result
Model-specific queries (read-only)
For models whose control protocol is publicly documented, this page can ask the glasses two questions: their serial number and their current display mode (mirror / SBS / half-SBS and refresh rate). It builds the 64-byte MCU packet, sends it, and decodes the reply.
Where that protocol comes from: the MIT-licensed open-source driver ar-drivers-rs, which documents the packet layout (head 0xFD, CRC32 over the length-delimited body, command ids 0x15 serial and 0x07 display mode). The page only sends these read commands — nothing is written, nothing is flashed.
What difference a vendor makes
XREAL answers over a 64-byte MCU frame with a CRC32 header — serial number and current display mode.
Rokid has no reachable read command from a browser (its serial number uses a vendor control transfer WebHID cannot send), but its periodic state packet carries brightness, volume, key state and all three sensor axes, so state can be read by listening.
VITURE uses a different frame entirely: header 0xFFFE, CRC-16/CCITT-FALSE, command id at offset 14 and an end marker byte 0x03. Readable: firmware version, board serial and brightness. That protocol was measured up to the Pro (0x101D); the PRO 2 (0x1301) is a different generation and may ignore it — which is exactly why the page shows what the device actually answered instead of a green tick.
Where these protocol facts come from
We did not guess at command numbers, and we did not lift anyone's code either. What we used is the facts — which vendor ids belong to which model, how a frame is laid out, where the command id sits, how the checksum is computed, and what a reply means. Those facts are published in two places:
- XREAL, Rokid, Mad Gaze — the write-up of three AR-glasses USB protocols by the author of ar-drivers-rs (MIT): frame headers, command ids and the display-mode table.
- VITURE — go-macos/iokit (BSD-3), which also records what the glasses actually answered: requesting
0x3003returned the ASCII string20.0.01.027_20260825.
The browser implementation is ours, written from those facts — same protocol, different code, because WebHID hands you 64-byte reports and events rather than a file descriptor. Nobody's binaries, firmware or vendor tooling is redistributed here. See NOTICE in the source for the full provenance note.
Honest status: the packet construction and reply decoding are covered by an offline test with a simulated device, but they have not been verified against physical hardware yet. If a query fails, the page prints the raw bytes and the error — copy that into the report and it becomes a precise bug report instead of "it didn't work".
What a healthy read looks like: a vendor-defined usage page (commonly 0xFF00) with one collection and two reports — a 64-byte input and a 64-byte output. That is the control/telemetry channel of the glasses, and its presence is what separates "the cable works" from "the cable only charges".
Reports arriving, steady intervals — the link is healthy; if the picture still misbehaves, look at the display side (resolution, refresh, cable bandwidth) rather than the glasses.
Connected but silent — the device is there but sends nothing. Usually the cable carries data but the session has not started, or this model has no HID input at all. Try the vendor's own app on the same port before blaming the glasses.
Uneven intervals (p95 much larger than the median) — jitter, not absence. Swap the cable, try another port (avoid hubs), and re-measure before drawing conclusions.
Limits, stated plainly
- Desktop Chromium only. Chrome or Edge on Windows, macOS, Linux or ChromeOS. Not Safari, not Firefox, not phones, not headset browsers.
- Read-only. Nothing is written to the device: no brightness, no mode switches, no firmware.
- You approve the device. The browser shows its own picker; the page never gets silent access, and you can revoke it in the browser's site settings.
- Vendor-specific protocols are not decoded. This reports what the USB layer exposes, not what a brand's private commands mean.
Why does a charge-only cable matter?
A cable without data lines gives you power and nothing else: no device appears, or it appears without a HID interface. That is the single most common false alarm in glasses support threads, and it is exactly what the "collections" line above tells you.
Is anything sent anywhere?
No. The device is opened locally through the browser API; the report is generated in the tab. Copy or download it yourself if you want to share it.
Related: About DepthSnap · Per-headset setup · When a 3D file will not play · All tools
Protocol facts referenced from ar-drivers-rs (MIT) and go-macos/iokit (BSD-3); the implementation here is independent. DepthSnap — free browser-based 2D to 3D SBS converter. No upload, no signup, no watermark.