color_management_v1: add helpers to get supported TFs/primaries

This avoids hardcoding lists of TFs/primaries in compositors.

I've considered adding wlr_color_manager_v1_create_with_renderer()
instead, but I'm worried that some aspects of the options struct
don't really depend on the renderer, but on the compositor. Such
things are features and render intents.

I've considered returning a const array, but this would tie our
hands if we want to make the renderer advertise the set of
TFs/primaries it supports, instead of having a single flag gating
all of them.
This commit is contained in:
Simon Ser 2025-06-18 22:31:30 +02:00 committed by Simon Zeni
parent ba931024a5
commit 9b4d9eabb1
2 changed files with 62 additions and 0 deletions

View file

@ -14,6 +14,7 @@
#include <wlr/render/color.h>
struct wlr_renderer;
struct wlr_surface;
struct wlr_image_description_v1_data {
@ -119,4 +120,18 @@ wlr_color_manager_v1_primaries_to_wlr(enum wp_color_manager_v1_primaries primari
enum wp_color_manager_v1_primaries
wlr_color_manager_v1_primaries_from_wlr(enum wlr_color_named_primaries primaries);
/**
* Get a list of supported transfer functions for a renderer. The caller is
* responsible for free'ing the array.
*/
enum wp_color_manager_v1_transfer_function *
wlr_color_manager_v1_transfer_function_list_from_renderer(struct wlr_renderer *renderer, size_t *len);
/**
* Get a list of supported named primaries for a renderer. The caller is
* responsible for free'ing the array.
*/
enum wp_color_manager_v1_primaries *
wlr_color_manager_v1_primaries_list_from_renderer(struct wlr_renderer *renderer, size_t *len);
#endif