[Mesa-dev] About drm_hwcomposer (Was Re: About the PixelFormat mappings in drm_gralloc)

[Sean Paul]

On Thu, Jan 21, 2016 at 10:00 AM, Sean Paul <seanpaul at chromium.org> wrote:

>
>
> On Wed, Jan 20, 2016 at 8:49 PM, Chih-Wei Huang <cwhuang at android-x86.org>
> wrote:
>
>> CC to the android-x86 devel list so more developers can follow.
>>
>> 2016-01-21 6:19 GMT+08:00 Rob Clark <robdclark at gmail.com>:
>> > On Wed, Jan 20, 2016 at 4:59 PM, Rob Herring <robh at kernel.org> wrote:
>> >> Hi Sean,
>> >>
>> >> On Thu, Jan 14, 2016 at 1:15 PM, Sean Paul <seanpaul at chromium.org>
>> wrote:
>> >>>
>> >>>
>> >>> On Thu, Jan 14, 2016 at 9:47 AM, Chih-Wei Huang <
>> cwhuang at android-x86.org>
>> >>> wrote:
>> >>>>
>> >>>> Hello Sean,
>> >>>> My last try of drm_hwcomposer failed due to
>> >>>> my limited time and knowledge.
>> >>>>
>> >>>> Fortunately more developers join us
>> >>>> to work on this topic now, including
>> >>>> Rob Herring (kernel drm developer),
>> >>>> Rob Clark and Emil Velikov (Mesa developers)
>> >>>> We are working on drm_hwcomposer
>> >>>> for virtio-gpu, the emulated GPU for QEMU.
>> >>>>
>> >>>> If you don't mind, I would invite you to join
>> >>>> our devel group for the discussion.
>> >>>
>> >>>
>> >>> [adding Emil, Rob, and Rob]
>> >>>
>> >>> Hi,
>> >>> Ok, I've signed up for the android-x86 list. I don't anticipate
>> seeing all
>> >>> posts, so please cc me on threads needing feedback.
>> >>>
>> >>> We also just today open-sourced drm_hwcomposer on the chromium gerrit
>> >>> instance, such that we'll be doing all of our development in the open
>> on
>> >>> that repo.
>> >>>
>> >>> The repo is here:
>> >>> https://chromium.googlesource.com/chromiumos/drm_hwcomposer
>> >>>
>> >>> Contributing instructions are here:
>> >>>
>> https://sites.google.com/a/chromium.org/dev/contributing-to-drm_hwcomposer
>> >>
>> >> Thanks for the pointer. This is essentially what I'm based on.
>> >>
>> >> Is there a testing target we need to use for submitting patches? Pixel
>> >> C? The first problem is the use of the pre mainline atomic functions,
>>
>> Dear Sean,
>> I echo Rob's words.
>> We planned to use kernel 4.4 and libdrm 2.4.66+
>> for marshmallow-x86.
>> Do you have an updated drm_gralloc that
>> can work with libdrm 2.4.66+?
>>
>
> No.
>
>
>
>> Or do you hope me to submit a patch for it?
>>
>> >> so using mainline kernel and libdrm are a problem. What is your plan
>> >> to handle that?
>>
>
> I'll look at updating android's libdrm today. In the long term, we're
> hoping to centralize libdrm between cros and android much like
> drm_hwcomposer, but there are still some moving parts that have yet to be
> sorted out.
>
> Once libdrm is updated, we can look at getting robh's patch in.
>
>
I just updated Android's libdrm to 2.4.66, there's a mirror here:
https://github.com/crseanpaul/libdrm/tree/merge-2.4.66

The old and new atomic apis are beside each other. Once we have
drm_hwcomposer using the new atomic apis, I'll remove the old ones from
libdrm.

robh, can you please upload your drm_hwcomposer to gerrit so we can get it
merged?

Sean


>
> >> It also no longer works with the drm_gralloc in AOSP due to missing
>> >> GRALLOC_MODULE_PERFORM_GET_USAGE support, so is there any plan to also
>> >> host drm_gralloc?
>> >
>>
>
> To be honest, I don't think we have any plans to use drm_gralloc, so I'm
> not sure where it'll be hosted in the future.
>
> For the time being, I think adding a stub to drm_gralloc to implement this
> call might be the best solution.
>
>
> > Just my own $0.02, but I would really like to move drm_gralloc into
>> > mesa.. or at least the gallium pipe-driver part.
>> >
>> > Having gralloc essentially being a sort of state-tracker is great for
>> > a lot of reasons.. ie. don't have to add new gralloc specific code for
>> > new drivers like freedreno/vc4/etnaviv, and also by sharing a common
>> > pipe_screen we can avoid some refcnt'ing / handle lifecycle issues.
>> >
>> > But that also means using API's which aren't really intended to be
>> > exposed outside of mesa.  Ie. gallium is not intended to be consumed
>> > as a stable API from external state trackers.
>> >
>> > I know that chromium had started adding support for some other
>> > non-mesa drivers.  I'm not sure how best to handle that.  Maybe what
>> > makes most sense is to just copy/paste some code into mesa, and leave
>> > external drm_gralloc just for blob drivers..
>> >
>> > (I was kinda hoping Emil would someday tackle moving the code into
>> > mesa, since whenever I mess with mesa build system I make a mess of
>> > things :-P)
>> >
>> > BR,
>> > -R
>> >
>> >> Anything you can share about planned changes/features you are working
>> >> on so we can better coordinate work Linaro is doing here.
>>
>
> I've been kicking around multi-monitor support for a while, and have some
> WIP patches. I can ping you when I post them to gerrit.
>
> Aside from that, I know zachr (cc'd) is playing around with some cleanup
> stuff, I'm not sure whether he has anything concrete.
>
> Sean
>
>
> >>
>> >> Rob
>>
>>
>>
>> --
>> Chih-Wei
>> Android-x86 project
>> http://www.android-x86.org
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20160203/edce970f/attachment.html>