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

[Chih-Wei Huang]

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+?
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?
>> 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?
>
> 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.
>>
>> Rob



-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org