Help test Oku3D

How to report

What is missing for each item below is not code but a device. My own machines cover NVIDIA and AMD graphics, GNOME on Wayland on Linux, a Samsung Odyssey 3D and a Quest 3. One report settles most items, and a report of "it just worked" answers as much as a failure.

The in-app diagnostics report (Ctrl+P by default) copies everything a report needs to your clipboard: system, graphics driver and version, audio path, decoder route, and the state of the open file. Pasting it with a line on what you saw and the model of the device you tested is the most useful report, on the Discord server or by mail to jens@oku3d.com.

3D displays, TVs and projectors

1. Any glasses-free 3D display that uses Leia SR, another Samsung Odyssey 3D included. Ghosting correction is a picture-quality setting: it cancels the faint double image that appears when part of one eye's picture leaks through the lens into the other eye, known as crosstalk. Each display ships with its own amount, and on my Odyssey 3D the double image only disappeared at three to five times that, depending on the picture. Results from other models and from other units of the same model would show whether the best value follows the model, the individual unit or the viewer, and whether the default should then be set per model. To measure it, click Calibrate with test picture under Ghosting correction in Settings > Display > Advanced. With one eye shut, move the slider until the squares labeled for the other eye fade into the gray, check with the other eye, and confirm. Then press Ctrl+P: the whole report, pasted as it is, together with your viewing distance is the most useful answer, plus a note if your two eyes clearly preferred different values.
2. A 3D TV or projector with an HDMI 3D input. Frame Packing sends each eye at full resolution, the signal a 3D Blu-ray player sends. In testing, a projector switched into 3D from it, while a passive LG TV stayed flat because it waits for an extra HDMI 3D marking. How many displays behave like the one or the other is open. To try it, choose the display as Fullscreen Monitor in Settings > Display > Fullscreen, set the fullscreen Output Format to Frame Packing, open a 3D film, press F11 and then Ctrl+P. The report's "Frame packing:" line says what was sent. On Windows with AMD or Intel graphics, the 3D resolution has to be added once beforehand. On Linux it has never been tried. The Linux page says what to set up first there, and the graphics card matters, since the driver decides whether the TV gets the 3D marking.
3. NVIDIA 3D Vision glasses on a 1080p 3D Vision display, on Windows. The 3D Vision (NV3D-Glass) output hands the 3D picture to NV3D-Glass, which shows it through the shutter glasses. A tester has confirmed that it works, with the eyes the right way round. Since then it hands over the picture at the display's own resolution instead of a fixed size, and that has not been seen on a 1080p display yet. To try it, start NV3D-Glass with Katanga as its capture source, choose 3D Vision (NV3D-Glass) as the fullscreen Output Format in Settings > Display > Fullscreen, open a 3D film and press F11. Look at the film, the controls and the subtitles through the glasses, then press Ctrl+P: the report's "Katanga hand-off:" line names the size that was handed over. Worth adding: whether the picture fills the display without borders and stays steady, or flickers or rebuilds itself every few seconds, and your Windows display scaling if it is above 100%.

Audio

1. An AV receiver over HDMI, on Linux. The one item that unblocks a feature rather than confirming one: bitstream audio needs a way to ask whether an output will carry it, and this is the measurement that decides how. Even without installing anything, the output of cat /proc/asound/card*/eld#* says whether your receiver announces Dolby Digital or DTS, and that alone is what the feature's safety gate would be built on.

Graphics

1. Intel integrated graphics on Linux. The vendor most laptops ship with, and the one I have no machine for. Rendering, the 2D-to-3D conversion and hardware decoding all run through interfaces Intel's driver implements, measured on AMD. Open any video and look at the diagnostics report (Ctrl+P): it names which route decoded. Worth adding: whether 4K plays smoothly, and what the processor load is.
2. A Linux computer with an ARM processor other than an NVIDIA DGX Spark or a Raspberry Pi 5 - a Steam Frame in developer mode, an NVIDIA Jetson, or a board with Mali graphics. The ARM64 archive is built and tested on an ordinary PC that imitates an ARM processor, which says nothing about the graphics driver of a real one, and each of these uses a different one. Unpack the archive, start ./oku3d from a terminal, open a 4K video, turn on the 2D-to-3D conversion and let it run for a minute, then press Ctrl+P and send the report together with what the terminal printed. Worth adding: whether it started at all - a message naming a missing library or "GLIBC" means the system is older than the archive needs.

Cameras

1. An HDMI capture card on Linux. A webcam works end to end there, microphone included; a capture card has never been plugged in. Does the picture appear, and does the paired audio device play with it?
2. An Acer SpatialLabs or ASUS 3D OLED device with a built-in camera. While the 3D mode runs, its eye tracking may hold the built-in camera, which would leave Oku3D with a black picture. On Samsung's monitor the player already explains that instead; for Acer and ASUS I need to know first. Turn the 3D mode on, pick the built-in camera under Capture Device on the start screen, and send the Ctrl+P report with a word on what the picture showed. One result per brand is enough.

VR headsets

1. A VR headset on Linux that is not a Quest over WiVRn. An Index, a Vive or a Pimax on SteamVR or Monado, a headset its runtime drives as a display instead of streaming to it. That is the half WiVRn cannot stand in for.

Disc drives

1. A Blu-ray drive and an unencrypted 3D disc, such as one you authored yourself. Played from a slow drive, a 3D disc used to hitch every few seconds. The player now reads further ahead and plays smoothly against a simulated slow drive, but has not been tried on a real one. Open the drive with Open Folder, play the main film for ten minutes with one jump in between, then press Ctrl+P. Only the first run says anything: a second one reads from the system's cache and hides the stalls.

Linux desktops

1. KDE Plasma as your everyday desktop. Screen capture, revealing a file, the media controls and the idle inhibitor each have more than one implementation behind them, and none of them has been tried on Plasma yet. Whether those four work on Plasma is a question its own users answer fastest.