Linux wayland HDR

[road2react]

Currently, tev is running using X11 which does not support HDR; tev loads the images but doesn't display them in HDR format. GNOME 48 and KDE Plasma 6 support HDR, and mpv can use this to show videos in HDR. It would be excellent if tev can do this for images too.

[Tom94]

Hi, completely on board with wanting to support HDR on all systems -- it turns out Windows HDR support would be implemented similarly to Linux Wayland.

tev is based on GLFW for its Windowing and graphics implementation which does already support Wayland, but doesn't support HDR yet. See glfw/glfw#890 and glfw/glfw#1907

We're already on a custom GLFW fork (downstream of nanogui) to run Metal+HDR on macOS, so the easiest plan of attack would be to extend that fork with a patch that enables HDR on Wayland & Windows (e.g. one of the third party patches from the issue thread above).

I plan to do this at some point in the future, but no concrete ETA yet. Could be weeks or months. Would be happy to merge external contributions if someone wants to give it a shot, too.

[road2react]

I compiled with IMS212/glfw#1; the tonemapping isn't great (bright colors get clipped), and the GUI is overly bright, but it appears to work.

[road2react]

Taking that back, looks like it's displaying the same content but with a different color transfer function, so everything is brighter than usual

[road2react]

Got it working, I updated dependencies/nanogui/ext/glfw/src/egl_context.c line 293 to

        // TODO ACTUALLY MAKE THIS DO SOMETHING IMS
        enum frog_color_managed_surface_primaries primaries = FROG_COLOR_MANAGED_SURFACE_PRIMARIES_REC709;
        enum frog_color_managed_surface_transfer_function tf = FROG_COLOR_MANAGED_SURFACE_TRANSFER_FUNCTION_SRGB;

and updated src/main.cpp line 563 to contain

    capability10bit = true;
    capabilityEdr = true;

[Tom94]

Very nice! Thank you for digging deeper.

The next step to get this into tev would be to check for wayland & HDR capabilities before enabling. Could be made part of nanogui::test_10bit_edr_support() or directly added to tev (e.g. bool supports_hdr() in Common.cpp). The important thing for me is that X11 and older distros / Wayland versions don't break.

Anyway, completely understand if you prefer to keep using your own fork locally rather than adding this extra functionality and upstreaming. But if you're interested in doing so, please feel free to open a PR for tev and one over at https://github.com/Tom94/glfw that cherry picks the relevant GLFW commits from IMS212 fork.

[Tom94]

I have to admit I got nerd sniped a bit here. I implemented HDR display support, but it is slightly different from the fork you were using. Most notably using Wayland's recently merged official color management protocol rather than Valve's frog protocol. -- It should already work on Gnome, KDE, Hyprland, and Jay with other compositors hopefully following suit soon.

Since there are a lot of system-dependent things to react to at runtime, could I get you to test latest master and let me know whether HDR works on your system before I close this issue?

[sjuxax]

I just tried a master build on Plasma HDR and it reports that its working:

tev on  master via △ v4.0.3-dirty took 8s
❯ install/bin/tev
17:44:10 SUCCESS  Initialized IPC, listening on 127.0.0.1:14158
17:44:13 INFO     Obtained 8 bit fixed point frame buffer with primaries=bt2020 and transfer=pq. HDR display is supported.

But not sure I have good sample data to test it out. The EXR I'm viewing looks the same after toggling the LDR option.

[Sidenote: I had to add -nostdinc++ -I/usr/include/c++/v1 to my CXXFLAGS get it to link successfully]

[Tom94]

Thanks you very much for checking!

It looks like tev is able to get an HDR capable buffer on your end, but toggling LDR should absolutely make a difference in image regions that have values >1. Could try this sample image just to make sure?

If that also doesn't work, my best guess would be that either HDR isn't enabled in KDE's display settings or your display isn't actually HDR capable (or not configured to HDR mode if it needs manual setting). Otherwise, could you share your display (or laptop model if a laptop), graphics hardware, and distro?

The build issue is certainly funky as well. Any chance you could share your compiler details?

Thanks again!

[sjuxax]

No change with the LDR toggle on that sample image. Here's my Plasma display settings:

You can see that HDR is detected and enabled. It works with mpv, etc. The settings are the same on both monitors.

I'm on a RTX3090Ti on Arch Linux with nvidia-open-dkms 575.64.05.

On the build, everything would build fine until the final link, at which point the static libs for libjxl, libheif, etc. would error about not being able to find __std or __glibcxx methods that are unique to libstdc++ rather than libc++.

Compilation env info

❯ gcc --version
gcc (GCC) 15.1.1 20250425
Copyright (C) 2025 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

❯ clang++ --version
clang version 20.1.8
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

❯ paru -Qi clang gcc
Name            : clang
Version         : 20.1.8-1
Description     : C language family frontend for LLVM
Architecture    : x86_64
URL             : https://clang.llvm.org/
Licenses        : Apache-2.0 WITH LLVM-exception
Groups          : None
Provides        : clang-analyzer=20.1.8  clang-tools-extra=20.1.8
Depends On      : llvm-libs  gcc  compiler-rt
Optional Deps   : openmp: OpenMP support in clang with -fopenmp [installed]
                  python: for scan-view and git-clang-format [installed]
                  llvm: referenced by some clang headers [installed]
Required By     : bcc  bpftrace  castxml  ccls  clazy  cninja  doxygen  flutter-bin  gnome-builder  ispc  kde-development-environment-meta  kdevelop  lldb  opencl-mesa  openshadinglanguage  pocl  qtcreator  rust-bindgen  shiboken2  shiboken6  sourcetrail  tacentview-git
Optional For    : bat-extras  codelite-unstable  cppcheck  faust  hotdoc  kate  koka-bin  orbiton  qt5-tools  qt6-tools  zed
Conflicts With  : clang-analyzer  clang-tools-extra
Replaces        : clang-analyzer  clang-tools-extra
Installed Size  : 210.15 MiB
Packager        : Leonidas Spyropoulos <artafinde@archlinux.org>
Build Date      : Fri 11 Jul 2025 05:22:51 AM MDT
Install Date    : Tue 15 Jul 2025 07:28:28 PM MDT
Install Reason  : Installed as a dependency for another package
Install Script  : No
Validated By    : Signature

Name            : gcc
Version         : 15.1.1+r7+gf36ec88aa85a-1
Description     : The GNU Compiler Collection - C and C++ frontends
Architecture    : x86_64
URL             : https://gcc.gnu.org
Licenses        : GPL-3.0-with-GCC-exception  GFDL-1.3-or-later
Groups          : None
Provides        : gcc-multilib
Depends On      : gcc-libs=15.1.1+r7+gf36ec88aa85a-1  binutils>=2.28  libmpc  zstd  libisl.so=23-64
Optional Deps   : lib32-gcc-libs: for generating code for 32-bit ABI [installed]
Required By     : abi-compliance-checker  base-devel  clang  clang10  clang13  clang14  clang16  clang17  clang18  clang19  cmake_tui  dkms  dmd  gcc-ada  gcc-d  gcc-fortran  gcc-objc  gcovr  ghc  hactool-git  home-assistant  kde-development-environment-meta  koka-bin  ldc  lib32-clang  lib32-eatmydata
                  libgccjit  mindi-busybox  nim  rpclib  scantools  vala  virtualbox-host-dkms  xframe  xtl
Optional For    : bauh  codelite-unstable  dmd  node-gyp  xorg-xrdb
Conflicts With  : None
Replaces        : gcc-multilib
Installed Size  : 208.12 MiB
Packager        : Frederik Schwan <freswa@archlinux.org>
Build Date      : Sun 27 Apr 2025 08:13:35 AM MDT
Install Date    : Thu 01 May 2025 12:00:10 AM MDT
Install Reason  : Installed as a dependency for another package
Install Script  : No
Validated By    : Signature

I tried several variations of CXXFLAGS before hitting on -nostdinc and then manually including the include path to libc++. I don't get those issues on the stable build, so I assume it's some change in the submodules' CMakeFiles no longer properly detecting that they're being built with clang and should default to libc++.

I also uploaded an AUR package for the -git build at https://aur.archlinux.org/packages/tev-git.

[sjuxax]

This may be something with Plasma. The LDR toggle works (meaning the image changes) when used with that sample image in Hyprland.

... Maybe my settings on KDE are just too blown out for the difference to be noticeable?

[Tom94]

Weird. I guess the KDE setting being too blown out is an explanation, but I don't think it's a likely one. FWIW, HDR works fine on Gnome, KDE, and Hyprland on my end (nixos rather than arch, though). Also using a discrete NVIDIA card w/ latest drivers.

I'll try to reproduce the build issue with clang in the meantime -- thanks for sharing the details.

[Tom94]

I can't get the build issues reproduced in pure clang environments -- but I also can't easily create a mixed gcc/clang environment of the sort you might have in a nix flake.

Any chance using C=clang CXX=clang++ cmake ... as opposed to -DCMAKE_C_COMPILER et al. as resolves the problem? If so, could you also try forwarding CMAKE_C_COMPILER and CMAKE_CXX_COMPILER here and here while dropping the C and CXX env vars again?

If that works, that'd be in line with your suspicion... but on the other hand, I don't see why that would have broken recently rather than months ago.