Hi Tom, Thank you, and thank you for Greg's notes: they describe exactly the problems our desktop is built to remove. Your page and Greg's notes show the pattern every project we write to has met. Each display brings its own setup: a runtime picked in a vendor's app, a list of known model names, a guess about which eye comes first. The program carries that work one device at a time, and that maintenance is why stereo modes so often fall behind. Our desktop moves that work out of the program: ChimeraX speaks one thing, stereo quad buffers, and the compositor does the per-display part, the same for every program. How it works on Sparky Stereo OS: - ChimeraX runs in sequential stereo (`--stereo`, or `camera stereo`), the mode made for shutter glasses, and asks OpenGL for quad buffers as it already does. - Our Mesa gives it a stereo window and hands the compositor both eyes as one full side-by-side picture, declared as stereo. - Our KWin shows that window in 3D where it is, at full resolution for each eye, while the rest of the desktop (panels, other windows, the pointer) is drawn the same in both eyes and stays flat at the screen. - The compositor converts the result for each screen: HDMI 1.4a 3D for a 3D TV or projector (frame packing, side by side, top and bottom), or red-cyan anaglyph on any monitor. What that changes in Greg's list: - No full-screen mode is needed: the 3D view stays inside the normal ChimeraX window, with its tools and panels around it, flat at the screen, as OpenSCAD's editor did in our stereo build. - The pointer is drawn in both eyes, and ChimeraX gets ordinary mouse coordinates over its whole window, so hovering, selecting and rotating should work as in mono; that is the first thing we will test. The half-window cursor comes from `camera sbs` splitting the window, which this path does not do. - A projector still serves many viewers at once. For the eye-tracked panels, your `xr on` path is the one we would follow on Linux. We work with the DisplayXR developers (an open OpenXR runtime for 3D displays, shipping on Linux): our KWin publishes the window geometry their runtime needs on KDE Plasma. And the vrto3d driver that Andre Michaelis used for the Samsung panels is part of our SteamVR work on Linux, toward 3D TVs. What we offer, respecting our development agenda: - tests of `--stereo` and `xr on` on our desktop, on a 3D TV and in anaglyph, with both eyes captured, reported here; - patches in your style if ChimeraX itself needs any change. And if Greg or anyone here would like to try it when our first image is out, we would be glad to have you as testers: https://github.com/Sparky-OS/sparky-stereo-os/issues/26 Daniel Ramos https://github.com/Sparky-OS/sparky-stereo-os This message was written with AI assistance for clarity.