The issue without "Direct Mode" is latency, as your link says. You need to bypass both the browser compositor and the system compositor. On Linux, most compositors will implement something like Direct Mode (compositor bypass) when you go fullscreen, but it's a bit hit and miss with multimonitor setups. It might fly as a stopgap, though. Here's the tracking bug for WebVR on Linux, if you want to follow progress: https://bugzilla.mozilla.org/show_bug.cgi?id=1310655

Something more directly analogous to "Direct Mode" on Windows are DRM leases, which give direct control over the scanout, rather than simply bypassing the compositor. This isn't possible on Linux at all yet, but Valve is working on it: https://keithp.com/blogs/DRM-lease/

Here is the DocOk/Vrui post on latency, A Trip Down the Graphics Pipeline (2014) http://doc-ok.org/?p=1057 (from which the reddit-linked graphs came).

Highlights include:

> Under a non-compositing window manager, regular double-buffering under OpenGL does not incur undue latency (and there is a window manager hint to tell a compositing manager to grant pass-through to a window).

> At least using the Nvidia graphics driver [...] OpenGL can vsync to any connected display, primary or secondary.

> OpenGL and X Windows allow applications to draw directly into a video controller’s frame buffer, allowing single-buffered rendering and racing the video controller’s scanout. [...] With front buffer rendering, display latency on the Rift DK2 dropped to about 4.3ms

And from Zero-latency Rendering (2015) http://doc-ok.org/?p=1313

> with some new rendering configuration options in Vrui 4.0 I can disable vsync, and render directly into the display window’s front buffer. In other words, I can let these applications “race the beam.”

Not just WebVR. Hardware video decoding was dropped for Linux years ago, never added back. Hardware compositing is only provided in edge cases.

The performance results are ridiculous, you're maxing out an entire processor core just for a 1440p H264 video on Firefox.

For hardware decoding to make sense, there needs to be a way to present the decoded frames in a way that doesn't involve a read-back and that works with the rest of the browser graphics pipeline. That's currently a problem on Linux.

That used to be one, but not with the Quantum compositor, which already can use frames from the GPU's memory.