On Mon, May 30, 2016 at 10:38 AM, Daniel Vetter <daniel@xxxxxxxx> 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@xxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
