Introduce wlr_format_set

[emersion]

This type adds a container for formats + modifiers.

This is cherry-picked from #1355. wlr_format_set is only used in one place for now, but it'll be useful in other places too in #1641.

[agx]

Look good to me. I'd like wlr_dmabuf_format_set better but that's maybe a little long.

[ascent12]

@agx

I'd like wlr_dmabuf_format_set better but that's maybe a little long.

The idea is that we would standardise everything in the codebase to "speak" these formats, and the modifier would just go unused or possibly be set to DRM_FORMAT_MOD_LINEAR where modifiers didn't make sense. I don't really think any extra qualification to the name is needed, but wlr_drm_format_set would be a slightly shorter compromise.

@emersion
This code is largely written by me, so can you preserve this in the commit author or possibly with a Co-authored-by.

Not really related to this PR, but it was/is intended for a intersection function to exist for this. I didn't get around to writing it, because I didn't get to the point where I needed it yet. It could be added later.

[agx]

wlr_drm_format_set sounds good to me (but this is mostly bikeshedding)

[ghost]

No need for an array of modifiers in the struct, just make it a single uint64_t. Modern kernels only use the first plane's modifier and very old kernels expect all plane modifiers to be identical.

[ascent12]

It's done as a array of modifiers because that's how the GBM API works; it's the possible modifiers it can use, and the driver can pick the one it wants. It's not a separate modifier for each plane.

[emersion]

This code is largely written by me, so can you preserve this in the commit author or possibly with a Co-authored-by.

Err, you're right, thanks for pointing this out!

Updated to split it in two commits.

Changes I made to yours:

• Renamed to wlr_drm_format_set
• Fixed a realloc size bug (didn't include the fixed part)

[emersion]

Ping