On Mon Apr 27 18:35:39 2026 +0000, Twaik Yont wrote:
The main I agree that overriding TRACE/WARN is not ideal. I can switch this to explicit Android-side helpers (e.g. ATRACE/AWARN/AERR or a LOG(level, ...) macro), so it's clear these are not the standard Wine debug macros, while still preserving debug channel filtering via checking __WINE_GET_DEBUGGING to avoid spamming logs unconditionally. This is a bit off-topic, but related to testing.
How did you test OpenGL support on Android? From what I can tell, Android typically does not advertise full desktop GL through EGL, even on devices using Mesa with full GL support. Instead, only GLES (v1/v2/v3) is exposed. I haven’t found clear evidence of full GL being exposed in standard Android environments. Also, from the Windows side, using GLES directly does not seem very useful, since most applications rely either on desktop OpenGL or DirectX, and more modern ones may use Vulkan. Since I’m planning to rework parts of the WSI layer, I need to test both the GDI path and the GL path, and I’m trying to understand what the expected/realistic setup is for GL on Android in this context. If you have any details about how GL testing was done or what configurations are expected to work, that would be helpful. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10710#note_137791