MobileGL/docs/Disaggregated/notes/anland/brief-mobilegl.md

Brief B — MobileGL inventory for a "GL provider for Linux-on-Android (Anland)" scenario (READ-ONLY)

Context: Anland (github.com/SuperTurtleDev/anland, 6.x) is a Wayland host on rooted Android: Linux apps run in a glibc container (Droidspaces chroot; also Termux native (bionic) and PRoot) and connect to a root Android daemon waylandbridge over a wayland socket. waylandbridge accepts wl_shm and zwp_linux_dmabuf_v1 buffers (today: single-plane ARGB8888/XRGB8888, LINEAR/INVALID modifier only), forges an AHardwareBuffer around the dma-buf and hands it to SurfaceFlinger (SurfaceControl mode) or composites it with GLES (EGL mode); it also implements zwp_linux_explicit_synchronization_v1. Container apps get GPU today only through Mesa (turnip/freedreno on kgsl, zink) — i.e. Adreno only. The question: what must MobileGL implement so that Linux apps in that container (and Xwayland/X11 apps) render through MobileGL — most plausibly by using the disaggregated split: a glibc aarch64 client in the container, the Android render server using the vendor driver — and hand frames to Anland.

Code: the up-to-date integration tree is in Arch WSL at ~/w7/p9-main (branch feat/disaggregated, P8 closed). Operate it ONLY through wsl.exe -d Arch -- bash -lc "<cmd>" and read-only commands (cat/grep/git log/git grep/find). Do NOT build, do NOT edit, do NOT run git commands that change the tree (checkout/restore/stash/reset/commit), do NOT touch other trees or devices. Docs to start from: docs/Disaggregated/ARCHITECTURE.md, design/*.md (esp. 06-transport, 08-runtime-and-platform, 09-build-switches-counters), ROADMAP.md, notes/p12/*, notes/DEBTS.md, notes/OPEN-QUESTIONS.md, MobileGL/MG_Remote/CONTRACT-*.md, then the code (MobileGL/MG_Remote/, MobileGL/MG_Impl/EGLImpl*, MobileGL/MG_Impl/GLXImpl/, backends' surface/swapchain/present code, CMake options for Linux/client/server builds, android-plugin/ server APK / MobileGLDisplayActivity / MobileGLServerService).

Answer each with file:line citations (paths relative to the tree root):

1. Linux client build. Can the client side be built for Linux glibc today (x86_64 WSL/CI yes? aarch64?) Which CMake options/presets; which libraries are produced (names/sonames: libGL? libEGL? libMobileGL.so?); which API entry points are exported (desktop GL core/compat versions, GLES API via eglBindAPI(EGL_OPENGL_ES_API)? GLX? EGL?). Is there libglvnd vendor integration (__egl_Main, __glx_Main, egl_vendor.d JSON) or does it replace libGL/libEGL directly?
2. EGL frontend capabilities. Supported EGL platforms/native window types on Linux (surfaceless only? EGL_PLATFORM handling, x11/wayland/gbm?), eglGetPlatformDisplay, config attributes, window/pbuffer/pixmap surfaces, context sharing, multiple contexts/threads per client, which EGL extensions are advertised (esp. EGL_EXT_image_dma_buf_import(_modifiers), EGL_MESA_image_dma_buf_export, EGL_KHR_fence_sync / EGL_ANDROID_native_fence_sync, EGL_KHR_swap_buffers_with_damage, EGL_EXT_buffer_age). What does GLXImpl do (does it talk to an X server? DRI? or is it a stub for desktop builds)?
3. Present path in split mode today. Trace eglSwapBuffers from client to server for (a) client-owned window (SetWindowHandle, Rule H), (b) MOBILEGL_IPC_SURFACE=server ServerOwned (P12), (c) pbuffer/surfaceless. Where does the server get its presentation target in each backend (Espryt: VkSurfaceKHR/VkSwapchainKHR from ANativeWindow? Magma: EGL window surface?). Is there ANY existing code that renders the default framebuffer into an exportable buffer (AHardwareBuffer, dma-buf, VK_ANDROID_external_memory_android_hardware_buffer, VK_KHR_external_memory_fd, EGLImage from AHB, eglGetNativeClientBufferANDROID) and sends it back to the client, or that exports a fence fd (VK_KHR_external_semaphore_fd SYNC_FD / EGL_ANDROID_native_fence_sync)? Grep for AHardwareBuffer, dma_buf, DMA_BUF, SCM_RIGHTS, sync_file, SYNC_FD, external_memory across the tree and report every hit's purpose (e.g. P11 adoption / T0 POST).
4. Fd passing & transports. Which transports can carry file descriptors (control plane is said not to; the ShmLink aux AF_UNIX rendezvous does SCM_RIGHTS) — where is that code, and how hard is it to add "server → client: here is a buffer fd + a fence fd per present"? Who creates the shm segments (client-owned SEG_CMD/SEG_STAGE via memfd on Linux) — relevant because an Android untrusted_app server may be SELinux-denied fd use on fds created by a root container process.
5. Session/multiplicity limits. One server per device, one session at a time (Refuse{Busy}), one surface mode per session, server-owned single window, "fork-per-session" supervisor for offscreen — cite where these limits live and how deep they are (supervisor only, or process-global state in backends?). What would it take to serve N concurrent clients each with M windows (a Linux desktop runs many GL apps + possibly Xwayland glamor)?
6. Window-system-facing events already in the protocol. Resize/geometry, SurfaceOp/SurfaceReply, WindowKind, device-lost behavior, present credit (MOBILEGL_IPC_PRESENT_CREDIT) and how a compositor's frame callbacks / buffer release would plug in.
7. GL coverage relevant to generic Linux desktop apps (not only Minecraft): max GL version per backend, compatibility profile / fixed-function support, GLES contexts, GLX_ARB_create_context, known gaps listed in docs. One short table.
8. Anything in docs/notes/OPEN-QUESTIONS/DEBTS that already anticipates Linux-on-Android, Wayland, dma-buf, AHB export, multi-client, or Termux — quote it.

Output: write the full report (Markdown; Chinese OK; tables welcome; every claim cited) to the Windows path <scratchpad>/report-mobilegl.md using your own file-writing tool (not a heredoc inside bash -lc), BEFORE your final message; then make your final message a 10-line summary. Mark anything you inferred (not read) as "inferred".