Well, I got it working...Windows kept fooling me because it likes to hide startup files in about a million different places, but it ultimately came down to a mis-configured startup file for VcXsrv.
The details:
mzimmers@mzimmers-home:~$ glxinfo -B
name of display: 172.27.32.1:0.0
display: 172.27.32.1:0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Mesa/X.org (0xffffffff)
Device: llvmpipe (LLVM 12.0.0, 256 bits) (0xffffffff)
Version: 21.0.3
Accelerated: no
Video memory: 25543MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.5
Max compat profile version: 3.1
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
OpenGL vendor string: Mesa/X.org
OpenGL renderer string: llvmpipe (LLVM 12.0.0, 256 bits)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 21.0.3 - kisak-mesa PPA
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 3.1 Mesa 21.0.3 - kisak-mesa PPA
OpenGL shading language version string: 1.40
OpenGL context flags: (none)
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 21.0.3 - kisak-mesa PPA
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
Of note from a forum I asked on:
The hardware (including the GPU) is virtualised. So the Linux video drivers can’t access the GPU directly as in a standard Linux installation; they have to use the virtual GPU provided by WSL, and I don’t think that supports OpenGL at present. In which case, you’re limited to the llvmpipe driver, which uses the CPU for rendering. There is some work being done on providing OpenGL support atop DirectX for WSL, but I believe that’s still work in progress.
It appears that he's right about needing llvmpipe, since that appears in my info dump above.
So, anyway, glxgears runs right now, and so does cube. Thanks for all the suggestions; hopefully someone else will find this useful.
