[RFC] drm: Introduce max width and height properties for planes

[Rob Clark]

On Mon, May 30, 2016 at 10:38 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
> On Mon, May 30, 2016 at 09:47:53AM -0400, Rob Clark wrote:
>> On Mon, May 30, 2016 at 5:32 AM, Daniel Vetter <daniel at ffwll.ch> wrote:
>> > drm_hwcomposer (developed by Google) is a generic hwc implementation along
>> > the lines of weston and any other generic kms compositor. I think it makes
>> > a lot of sense to aim for a reasonable baseline API which works the same
>> > way everywhere. And that reasonable baseline abi imo includes that at
>> > least 1 plane can be used full-screen, without jumping through hooks.
>> >
>> > Because if you don't have that, then it's not just weston and android you
>> > need to patch up. But also
>> > - fbdev
>> > - any boot splash
>> > - any igt testcases (I'm starting to push hard to make those a requirement
>> >   for kms drivers)
>> > - X
>> > - any other compositor, like mutter, kwin, ozone, ...
>>
>> I think it's not so bad.  We fix the setcrtc helpers to do this for
>> legacy crtc path (which should pretty much cover most existing
>> compositors, X, splash, fbdev, etc).  After all they already pick one
>> plane, it shouldn't be too hard to make them pick two.
>>
>> But for atomic, we make userspace deal with it, since things get more
>> complicated than what setcrtc/pageflip has to deal with.  Afaiu there
>> are basically two atomic compositors (and the weston one isn't even
>> merged), so I think dealing with this in userspace is not so bad.
>
> What exactly is more complicated with doing this for full atomic? If you
> do it in userspace for setcrtc, plus fbdev, plus

s/userspace/kernel/ (for setcrtc/pageflip)

> weston/ozone/drm_hwcomposer/ and maybe more, then that's already an
> impressive pile of copies of that logic. And I really think it should be
> pretty simple to type this up into a helper that works on any plane.

For legacy setcrtc/pageflip, I think we just change crtc->primary into
an array of N (where N is worst case # of planes).  It is a scenario
where you don't have to care about scaling, or really other planes in
use, and a static association of planes to crtc's should be fine.  And
we wouldn't expose the additional primaries to userspace so no
conflicts to worry about..

Seems like a fairly small change in the atomic helpers, vs having to
invent virtual planes mapping to physical planes, etc.

BR,
-R

> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch