Show a laser-beam pointer while aiming at the menu/keyboard

The flat cross-shaped reticle used while aiming at the game quad is
drawn directly into the game quad's own texture, so it only ever made
sense there - while the menu launcher or keyboard was open, there was
no visual feedback at all until the ray was precisely on target,
making both panels hard to aim at.

Add a second, thin XrCompositionLayerQuad per hand: a billboarded
"laser beam" ribbon from the controller to wherever that hand's ray
currently crosses the plane of whichever overlay (keyboard, then menu)
claims it that frame, oriented via a view-space head pose so it reads
as a line from the viewer's eye regardless of angle, colored per hand
(cyan left, amber right) and clamped to 2m so grazing angles don't
produce an absurdly long beam. Built from data xr_input.c's existing
per-hand hit-testing already computes; the game-quad reticle itself is
untouched.

android/app/src/main/cpp/xr_session.c

@@ -213,19 +213,16 @@ static bool xr_create_instance_and_session(int game_width, int game_height) {
                   "xrCreateReferenceSpace"))
         return false;
 
-    // Non-fatal if it fails (e.g. no controllers bound yet) - rendering
-    // keeps working either way, just without the laser pointer.
-    xr_input_init(g_instance, g_session);
-
     // Prefer a plain linear 8-bit format over GL_SRGB8_ALPHA8: the source
     // SDL surface pixels are already sRGB-encoded (as ordinary 8-bit image
     // data conventionally is) and get uploaded/sampled as plain linear
     // GL_RGBA with no decode step anywhere in this path, matching the
     // desktop SDL_RenderCopy path this replaces - an sRGB swapchain format
     // would auto-gamma-encode on write and double-encode already-encoded
-    // data. Every swapchain below (game quad, menu/keyboard overlays)
-    // shares this one choice - the compositor's supported format set
-    // doesn't depend on swapchain size.
+    // data. Every swapchain below (game quad, menu/keyboard overlays, and
+    // - via xr_input_init() - the per-hand laser-beam overlays) shares
+    // this one choice - the compositor's supported format set doesn't
+    // depend on swapchain size.
     uint32_t formatCount = 0;
     xrEnumerateSwapchainFormats(g_session, 0, &formatCount, NULL);
     int64_t *formats = (int64_t *)malloc(sizeof(int64_t) * formatCount);
@@ -240,6 +237,10 @@ static bool xr_create_instance_and_session(int game_width, int game_height) {
     }
     free(formats);
 
+    // Non-fatal if it fails (e.g. no controllers bound yet) - rendering
+    // keeps working either way, just without the laser pointer/beams.
+    xr_input_init(g_instance, g_session, chosenFormat);
+
     if (!xr_swapchain_create(g_instance, g_session, chosenFormat, game_width, game_height,
                               &g_game_swapchain)) {
         LOGE("XR: game swapchain setup failed");
@@ -367,12 +368,14 @@ void xr_frame_end(void) {
     if (!xr_is_session_running())
         return;
 
-    // Up to 3 layers: the game quad (if a frame was actually rendered),
-    // and, while visible, the menu launcher and keyboard overlays - each
-    // gets its own acquire/render/release cycle against its own swapchain
-    // (see xr_overlay_render_and_build_layer()) any time before xrEndFrame,
+    // Up to 5 layers: the game quad (if a frame was actually rendered),
+    // the menu launcher and keyboard overlays while visible - each gets
+    // its own acquire/render/release cycle against its own swapchain (see
+    // xr_overlay_render_and_build_layer()) any time before xrEndFrame,
     // unlike the game quad there's no per-frame engine rendering to wrap
-    // around here, just each overlay's own blit.
+    // around here, just each overlay's own blit - and, per hand, a
+    // laser-beam quad while that hand's ray is aimed at one of those two
+    // overlays (see xr_input_get_beam_layer()).
     XrCompositionLayerQuad gameQuad = {XR_TYPE_COMPOSITION_LAYER_QUAD};
     gameQuad.space = g_local_space;
     gameQuad.eyeVisibility = XR_EYE_VISIBILITY_BOTH;
@@ -385,7 +388,7 @@ void xr_frame_end(void) {
     gameQuad.size.height =
         QUAD_WIDTH_METERS * (float)g_game_swapchain.height / (float)g_game_swapchain.width;
 
-    const XrCompositionLayerBaseHeader *layers[3];
+    const XrCompositionLayerBaseHeader *layers[5];
     uint32_t layerCount = 0;
     if (g_have_acquired_game_image)
         layers[layerCount++] = (XrCompositionLayerBaseHeader *)&gameQuad;
@@ -413,6 +416,20 @@ void xr_frame_end(void) {
         layers[layerCount++] = (XrCompositionLayerBaseHeader *)&keyboardQuad;
     }
 
+    // Submitted last (frontmost) so a beam doesn't z-fight against the
+    // panel surface it's aimed at/terminates on - see
+    // xr_input_get_beam_layer(). Translucent for the same reason the
+    // keyboard is (see comment above).
+    XrCompositionLayerQuad beamQuad[2];
+    for (int hand = 0; hand < 2; hand++) {
+        if (xr_input_get_beam_layer(hand, &beamQuad[hand])) {
+            beamQuad[hand].space = g_local_space;
+            beamQuad[hand].eyeVisibility = XR_EYE_VISIBILITY_BOTH;
+            beamQuad[hand].layerFlags = XR_COMPOSITION_LAYER_BLEND_TEXTURE_SOURCE_ALPHA_BIT;
+            layers[layerCount++] = (XrCompositionLayerBaseHeader *)&beamQuad[hand];
+        }
+    }
+
     XrFrameEndInfo endInfo = {XR_TYPE_FRAME_END_INFO};
     endInfo.displayTime = g_predicted_display_time;
     endInfo.environmentBlendMode = XR_ENVIRONMENT_BLEND_MODE_OPAQUE;