On Tue, Mar 25, 2014 at 7:51 PM, Damien Lespiau damien.lespiau@intel.com wrote:
On Tue, Mar 25, 2014 at 07:23:26PM +0100, Daniel Vetter wrote:
Or we simply do this per-pixel format with one for each framebuffer plane, i.e.
struct drm_get_plane_fb_limits { uint32_t plane_id; /* in */ uint32_t fourcc; /* in */ struct drm_plane_limits limits[MAX_FOURCC_PLANES]; /* the stuff above for all possible planes of a fourcc code */ }
Saner drivers could then return the same thing for all fourccs codes in their backend.
Some of the limits are definitely per format. Plane max dimensions are a good example of a limit that can change per-format (8bpp Vs 10bpp to be contained within the same max bandwidth of the hw).
One thing I've completely missed btw is scaling limits. How we then need to factor in bandwidth I have no idea about ... I guess at one point it boils down to "try it and give up if it doesn't work". And I think we need a few scaling related flags like "can't scale at all" or sub-sampling restrictions. Who knows ... -Daniel