From mboxrd@z Thu Jan 1 00:00:00 1970 From: Inki Dae Subject: Re: [PATCH 01/11] drm: add plane support Date: Wed, 2 Nov 2011 02:20:58 +0000 (UTC) Message-ID: References: <1319536026-2877-1-git-send-email-jbarnes@virtuousgeek.org> <1319536026-2877-2-git-send-email-jbarnes@virtuousgeek.org> <20111025160945.5049568d@jbarnes-x220> <20111025194117.GG2894@phenom.ffwll.local> <20111031095245.7a95f59e@jbarnes-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by gabe.freedesktop.org (Postfix) with ESMTP id E471F9E779 for ; Tue, 1 Nov 2011 19:21:11 -0700 (PDT) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RLQRy-000267-FB for intel-gfx@lists.freedesktop.org; Wed, 02 Nov 2011 03:21:11 +0100 Received: from 210.94.41.89 ([210.94.41.89]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 Nov 2011 03:21:10 +0100 Received: from daeinki by 210.94.41.89 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 02 Nov 2011 03:21:10 +0100 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org Hi, Jesse. Jesse Barnes virtuousgeek.org> writes: > > On Mon, 31 Oct 2011 11:40:57 +0000 (UTC) > Inki Dae gmail.com> wrote: > > below is my simple idea. > > 1. user requests buffer allocation with pixel format and resolution through > > gem framework. > > 2. gem framework checks pixel format. > > 3. specific gem framework allocates buffers as plane count according to the > > pixel format. (please, know that gem framework provides just interface so > > acctual implementation would be done at specific gem framework) > > 4. user gets the gem handle from gem framework. > > 5. user sets the gem handle to specific drm framebuffer through > > drm_mode_addfb2 function. > > 6. user requests setcrtc with fb id and crtc id. > > 7. drm framework sets framebuffer(corresponding to fb id) to drm_mode_set. > > 8. crtc calls set_config callbacks to configure hardware. > > 9. specific crtc framework gets all buffers through framebuffer(actually, it > > would be specific framebuffer)and sets them to overlay registers of hardware > > appropriately. > > > > > > like this, how about using framebuffer and gem framework instead of plane? I'd > > be glad to give me your opinions. > > I'm not opposed to pushing the multi-object stuff into GEM instead, but > I don't think step (9) will be enough to avoid having a separate plane > object. Say the user passes in 3 RGB buffers. How do you know which > one is the primary and which are overlays? Or are you saying the fb > would have that information as well? If so, it would be a little > harder to specify things like blending options or colorspace correction > on a per-plane basis... > > But maybe I'm missing some part of things; do you have any patches to > illustrate what you mean? I can see how it might work, but I don't > know if it would be any simpler or cleaner than exposing plane objects. > > Thanks, Sorry, there is my missing point. please, ignor step 6 ~ 9. if user requests setplane then drm_mode_setplane function gets fb and crtc object to update the overlay corresponding to plane id. at that time I think we could know which overlay should be set and how many buffers does the overlay has through specific framebuffer object if specific framebuffer has gem object. in our case, specific framebuffer has gem object. and I would try to implement multi planer the way I mentioned if need and I will post the patch. this work takes about a week. I think the way that user allocates buffers for multi planer only with pixel format and resolution(width, height) would be good. but there could be more good ways then this way. please give me your opinion and advices. Thank you, Inki Dae.