On Tue, Mar 25, 2014 at 7:51 PM, Damien Lespiau
<damien.lespiau@xxxxxxxxx> 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
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
