[Android][Vulkan][HDR][Regression] Odin 3: Enabling HDR blacks out video (diagonal artifact) and forcing HDR via config crashes on launch (regressed between 2026-01-25 and 2026-01-26 nightlies)

[sayenah]

Is there an existing issue for this?

• This is a bug in RetroArch frontend
• I have searched the existing issues

Description

On Ayn Odin 3 (Android 15), RetroArch Android nightly HDR worked on 2026-01-25. Starting with the 2026-01-26 nightly (and still on 2026-01-28), enabling HDR with the Vulkan video driver immediately turns the entire screen black with a faint diagonal line from lower-left to upper-right. Additionally, if HDR is enabled ahead of time via retroarch.cfg (so it should start in HDR), RetroArch immediately closes on launch.

Builds tested (from buildbot nightlies):
Working:

• 2026-01-25-RetroArch_aarch64.apk
  https://buildbot.libretro.com/nightly/android/2026-01-25-RetroArch_aarch64.apk

Broken:

• 2026-01-26-RetroArch_aarch64.apk
  https://buildbot.libretro.com/nightly/android/2026-01-26-RetroArch_aarch64.apk

• 2026-01-28-RetroArch_aarch64.apk (still broken; vanilla)
  https://buildbot.libretro.com/nightly/android/2026-01-28-RetroArch_aarch64.apk

Regression window / evidence (build + git history notes):

• Buildbot directory listing shows distinct Android nightlies for 2026-01-25 vs 2026-01-26 (and later), including aarch64 APKs:
  https://buildbot.libretro.com/nightly/android/
• RetroArch commit history shows that Jan 25, 2026 had only “Fetch translations from Crowdin” (a458d7e).
• On Jan 26, 2026 multiple changes landed, including several Vulkan/HDR menu related commits:
  • e6bf544: “Fixed Vulkan driver HDR menu when we’re using a HDR native shader”
  • 12d188e: “Fixed menu system displaying incorrectly in HDR on D3D11, D3D12 and Vulkan”
  • 091d35c: “Fixed the menu in D3D11 and D3D12 when using HDR native shader’s” and the commit message explicitly states: “Vulkan still has issues”
    (Jan 26 also includes smb/libsmb2 changes like fb117f5 “smb: change android to use griffin build of libsmb2”, etc.)

Suspected commits / quick links:

• Jan 25 baseline commit: a458d7e (Fetch translations from Crowdin)
• Jan 26 HDR/menu commits:
  • e6bf544 e6bf544
  • 12d188e 12d188e
  • 091d35c 091d35c

Suggested compare range for maintainers:

• Compare Jan 25 baseline to end-of-day Jan 26 (includes the HDR/menu changes above):
  a458d7e...d79d2de

Workarounds attempted:

• Installing 2026-01-28 nightly did not resolve the issue (still black screen on HDR enable with vanilla config; no shader/preset).
• Forcing HDR via retroarch.cfg causes immediate crash/exit on launch (can’t keep HDR enabled that way).

Attachments / diagnostics (available if needed):

• Can provide a short video showing the black screen and diagonal artifact upon enabling HDR.
• Can provide Android crash buffer output (adb logcat -b crash) captured immediately after the startup crash when HDR is forced via config.

Expected behavior

Expected behavior:

• HDR should enable without loss of video output (as on 2026-01-25 nightly). Menu/content should remain visible and render correctly.

Actual behavior:

• Enabling HDR causes a black screen (with faint diagonal artifact). RetroArch becomes unusable because the UI is not visible.
• Force-closing the app resets HDR to off because settings cannot be saved after the screen goes black (RetroArch requires saving config for settings to persist after restart).

Steps to reproduce the bug

Steps to reproduce (black screen when toggling HDR):

1. Install and launch 2026-01-26 nightly (aarch64).
2. Ensure the video driver is Vulkan.
3. Go to the HDR setting and enable HDR.
4. Result: display immediately goes black. A faint diagonal line appears from lower-left to upper-right. UI/menu is not visible.

Additional repro (startup crash when HDR is forced via config):

1. Edit retroarch.cfg to force HDR on:
   video_driver = "vulkan"
   video_hdr_enable = "true"
2. Launch RetroArch.
3. Result: RetroArch immediately closes on startup (crash/exit).

Repro rate:

• 100% on this device.

Version/Commit

1.22.2

Bisect Results

Good: 2026-01-25 nightly (HDR works). Bad: 2026-01-26 nightly (HDR black screen). Still bad on 2026-01-29 nightly.

Present in the nightly version

Yes, this is reproduced in the nightly build

Platform & operating system

Android 15

Affected Cores

No response

Environment information

Environment:

• Device: Ayn Odin 3
• OS: Android 15
• RetroArch: Android nightly (aarch64)
• Video driver: Vulkan
• Setup: Vanilla (no shaders/presets/overlays; reproduces from a clean/default configuration)

Relevant log output

[hizzlekizzle]

@MajorPainTheCactus has been doing a lot of work on HDR lately. Hopefully, he can figure out what's going on there.

[MajorPainTheCactus]

Weirdly enoughI literally installedthe latest nightly on my brand new android tablet that arrrived today and saw that issue. I thought it was my tablet not supporting hdr. Ok Ill take a look at this but its going to take me a while as Im not setup with android build environment or even know where to start.

[sayenah]

Weirdly enoughI literally installedthe latest nightly on my brand new android tablet that arrrived today and saw that issue. I thought it was my tablet not supporting hdr. Ok Ill take a look at this but its going to take me a while as Im not setup with android build environment or even know where to start.

Thanks @MajorPainTheCactus , the regression happened after your commits to the 01/26 nightly and still continues. I have now tested this on my S25 Ultra and it is present there as well. Let me know how I can help.

[MajorPainTheCactus]

So Im up and running and am able to debug. Ive fixed the crash issue but we're now getting a corrupt menu. Im pretty sure this is to do with incorrect transitions but Ive fixed all the issues I can see and nothing has changed. Ill keep on plugging away at it tomorrow - hopefully should fix it tomorrow as there was A LOT of messing about getting things setup and running today.

[sayenah]

So Im up and running and am able to debug. Ive fixed the crash issue but we're now getting a corrupt menu. Im pretty sure this is to do with incorrect transitions but Ive fixed all the issues I can see and nothing has changed. Ill keep on plugging away at it tomorrow - hopefully should fix it tomorrow as there was A LOT of messing about getting things setup and running today.

What would we ever do without you folks haha! Thanks man. And hopefully you enjoy that HDR on that lovely Android tablet (if the screen supports it). I am not sure I am ever using any shader other than beam simulator megatron HDR one under "presets". Absolutely lovely shader!

Looking forward to your fixes. Thanks again!

[MajorPainTheCactus]

The fixes are now in the open PR 'Fixed HDR Vulkan bugs #18658' It all works on my OnePlus Pad 3 at least - an amazing screen for HDR it must be said. These fixes will probably up the compatibility for Vulkan HDR quite considerably as the Windows drivers are apparently very forgiving. It may well work under Linux etc now also.

@sayenah thanks on the shader work - you'll be pleased to know that the built in scanline simulation of HDR effectively uses a cut down version of the megatron shader (its visually identical though). For many users they didn't understand why HDR was in there for retro games and at least now they might be able to see at least one good reason for using HDR.

[sayenah]

The fixes are now in the open PR 'Fixed HDR Vulkan bugs #18658' It all works on my OnePlus Pad 3 at least - an amazing screen for HDR it must be said. These fixes will probably up the compatibility for Vulkan HDR quite considerably as the Windows drivers are apparently very forgiving. It may well work under Linux etc now also.

@sayenah thanks on the shader work - you'll be pleased to know that the built in scanline simulation of HDR effectively uses a cut down version of the megatron shader (its visually identical though). For many users they didn't understand why HDR was in there for retro games and at least now they might be able to see at least one good reason for using HDR.

Hey man, I am just floored by your turn around time on this. A couple of things I noticed:

• there are some UI elements which are getting corrupted. Take a look at the lower left corner of the screenshot attached. That's where the message about save state being saved appears. I have noticed that any message appearing there seems to come up as this jumbled up artifact.

• secondly, and I am not sure how to prove this, but for some reason there is a very high likelihood of the app simply stalling and throwing up the message spam of "AARCH64 is not responding: Close the app or Wait". I will try to get logs for this but the best way to recreate this is to try changing shaders mid gameplay. This behavior was quite more contained before the regression (I understand that changing shaders mid-play can cause issues sometimes, but it is very sensitive now, post regression)

Let me know how I can help you. Thank you for bringing the goodness of HDR shaders to folks who haven't experienced this game changer yet!

[LibretroAdmin]

Are these issues fixed now in current master or still ongoing?