How does wayland communicate modifier limitations to clients?
I was looking at the weston code and noticed that only EGL supported modifiers are sent over zwp_linux_dmabuf_v1 to clients:
https://gitlab.freedesktop.org/wayland/weston/blob/master/libweston/linux-dmabuf.c#L499
Q1) Why aren't KMS supported formats also sent?
According to:
https://www.x.org/wiki/Events/XDC2017/widawsky_fb_modifiers.pdf
All sink APIs should be queried, and the set of supported modifiers common to all APIs in use should be sent. For example, if the buffer is going to be rendered to and scanned-out, then union of KMS and EGL modifiers should be sent.
This could be fixed, but I'm also wondering about how wayland handles hardware limitations. For example, on some devices AFBC (ARM Framebuffer Compression) can be only used on the primary KMS plane. If the compositor client is running full-screen, it's advantageous to allocate an AFBC buffer and then scan-it out. But if the client becomes smaller, the best option is to use a linear strided buffer and schedule that as an overlay.
Intel also doesn't advertise CCS modifiers based on HW/pipe specific attributes:
Q2) How does wayland communicate which specific plane the client will be scheduled on, so it can allocate the optimal modifier for that plane?
Q3) zwp_linux_dmabuf_v1_listener can be used to listen to modifier related events. Is an event only sent once (when the the client binds to the interface) or based on size/plane changes?