dzfranklin / drm-fourcc-rs Goto Github PK

I noticed that Debug and Display will output the same thing. For example if I create a DrmFourcc::Argb8888, the Debug and Display implementations both return AR24. It might be useful if Debug could return Argb8888 instead.

Like DRM_FORMAT_BGRX8888_A8

Thanks for this!

Citing the drm_fourcc.h inline comments:

In addition to the
fourcc code, a Format Modifier may optionally be provided, in order to
further describe the buffer's format - for example tiling or compression.

Could this crate also expose the DRM_FORMAT_MOD constants in a separate enum?

This library is quite useful for low-level interaction with other system components or for embedded image interchange. In those cases, including and depending on all of Rust's std is quite heavy. It also isn't really integral to any use case addressed here.

The only current interface (unless I've overlooked any) is DrmFourcc::string_form. However, it's not necessary at all as Display can be written without an allocated container such as String—making string_form redundant because it would then be a call to the standard to_string for those callers that desire it.

I'd be willing to provide a PR if desired, this will be a breaking change to 3.0 though.

To be specific:

pub const DRM_FOURCC_I915_Yf_TILED: u64 = 72057594037927939;
pub const DRM_FOURCC_I915_Yf_TILED_CCS: u64 = 72057594037927941;

I tried regenerating the bindings locally but that didn't change anything. They are defined at https://github.com/torvalds/linux/blob/d615b5416f8a1afeb82d13b238f8152c572d59c0/include/uapi/drm/drm_fourcc.h#L497-L530

The assumed header location in the buildscript does not work on Arch Linux.

pkg-config should be used to find the header instead.

The generator code is extremely messy and needs to be refactored

Steps to reproduce:

println!("{:?}", DrmFourcc::R8);

It appears that the representation of this format is 0x20203852, which translates to ['R', '8', ' ', ' '], while the fourcc_string_form function expects the 3 first bytes to be alphanumeric, which is not the case here.