On Wed, Dec 18, 2024 at 5:32 AM Brian Starkey <brian.starkey@xxxxxxx> wrote:
On Wed, Dec 18, 2024 at 11:24:58AM +0000, Simona Vetter wrote:
>
> For that reason I think linear modifiers with explicit pitch/size
> alignment constraints is a sound concept and fits into how modifiers work
> overall.
> -Sima
Could we make it (more) clear that pitch alignment is a "special"
constraint (in that it's really a description of the buffer layout),
and that constraints in-general shouldn't be exposed via modifiers?
It doesn't matter how many modifiers we have. No app should ever parse the modifier bits. All apps must treat modifiers as opaque numbers. Likewise, documentation of all modifiers in drm_fourcc.h is only meant for driver developers. No developers of apps should ever use the documentation. There can be a million modifiers and a million different devices, and the whole system of modifiers would fall apart if every app developer had to learn all of them.
The only thing applications are allowed to do is query modifier lists from all clients, compute their intersection, and pass it to one of the clients for allocation. All clients must allocate the exact same layout, otherwise the whole system of modifiers would fall apart. If the modifier dictates that the pitch and alignment are not variables, but fixed values derived from width/height/bpp, then that's what all clients must allocate.
If any app uses DRM_FORMAT_MOD_LINEAR directly instead of querying supported modifiers from clients, it's a misuse of the API.
DRM_FORMAT_MOD_LINEAR will be deprecated because it's the only modifier that is generally non-functional (it's only functional in special cases). After new linear modifiers land, drivers will stop supporting DRM_FORMAT_MOD_LINEAR if they can't support all pitches and alignments because we only want to have functional software.
Marek
