atomic req test nor driver db would be able to cover all the embedded device

[hizukiayaka]

I have talked with some weston guys in IRC, they refer this project. We don't know much about this project's current plane

The algorithm is not bad, but in the embedded world, the issue is not about whether the layer could be compatible with plane(pixel format check is enough and work for the most of time). It is about whether they could work together(sharing limited resources)

For example, in Intel Apollo Lake platform, you can submit more than one plane with a buffer with UHD(3840x2160) size in I915_FORMAT_MOD_Y_TILED_CCS format(I think once such I915_FORMAT_MOD_Y_TILED_CCS buffer is used, you can't use more than one plane).

And RGBA I915_FORMAT_MOD_Y_TILED buffer can't be scale up from FHD to UHD, while MODIFIER_PRIORITY_LINEAR could. When we are enabled two CRTC(Pipe A and Pipe B), you can't assign any I915_FORMAT_MOD_Y_TILED buffer to the plane if you have to use two drm plane.

And driver would not know until the display engine told the driver watermark is over(resources is not enough)

I think the better would be prepare a place that people can edit the plane assignment easily and well document for it. They are more embedded device than we thought.

[emersion]

I don't see why libliftoff would fail in this case. libliftoff will try to use as many planes as possible, and fall back to less planes if the bw limitations are reached.