drm_hwcomposer moving to fd.o

[Tomeu Vizoso]

On 09/28/2017 09:08 AM, Daniel Vetter wrote:
> On Thu, Sep 28, 2017 at 8:49 AM, Chih-Wei Huang <cwhuang at android-x86.org> wrote:
>> 2017-09-26 13:26 GMT+08:00 Daniel Vetter <daniel at ffwll.ch>:
>>> On Mon, Sep 25, 2017 at 09:06:55AM +0200, Tomeu Vizoso wrote:
>>>> On 09/25/2017 04:44 AM, Chih-Wei Huang wrote:
>>>>> Hey Robert, thank you for the reply.
>>>>>
>>>>> 2017-09-22 23:43 GMT+08:00 Robert Foss <robert.foss at collabora.com>:
>>>>>> Hey Chih-Wei,
>>>>>> On Fri, 2017-09-22 at 10:40 +0800, Chih-Wei Huang wrote:
>>>>>
>>>>>> The android-ia project has supported using drm_hwcomposer and an
>>>>>> alternative hwcomposer, so it would think there should be no issues.
>>>>>
>>>>> By x86 GPUs, I meant i915(i965)/nouveau/radeon/amdgpu/virgl/vmwgfx.
>>>>> Among these only virgl works with the current drm_hwcomposer.
>>>>> All the others don't have a ready atomic mode-setting API to use it.
>>>>> That's the problem which should be addressed I meant.
>>>>
>>>> Most if not all of those drivers support the atomic updates API in
>>>> mainline (and have for a few releases by now).
>>>
>>> amdgpu does not (but will once DC has landed, at least when you enable
>>> DC). Radeon doesn't, and likely never will. Nouveau is atomic only for
>>> nv50+.
>>
>> Thank you for the clarification.
>>
>> I have made test with kernel 4.13 +
>> gbm_grallc + drm_hwcomposer + mesa 17.1
>> on Android-x86 7.1.
>> Except virgl all others just failed as expected.
>>
>> i915 (i965) was tested in Intel Broxton.
>> It's the best result. SurfaceFlinger runs and
>> bootanimation is shown. However, after boot
>> complete it only shown systemui + navbar with
>> black background. No app icons or mouse cursor
>> in the desktop. I guess the composition of 3+
>> layers has some problems.
> 
> Could be a bug in either drm_hwcomposer making assumptions that don't
> hold, or i915 for implementing stuff wrongly. Would need someone to
> debug. Given that we have products shipping on bxt using atomic (CrOS)
> I'm leaining towards drm_hwcomposer making bad assumptions.

An easy way of making sure that the problem is with compositing with
overlays is applying this hack:

https://git.collabora.com/cgit/user/tomeu/drm_hwcomposer.git/commit/?h=android-etnaviv&id=dbe21cb52f602eef11bf5ac083691e5b2b0a35ba

It should also allow you to move on and test more stuff.

>> vmwgfx also has issues on drm_hwcomposer
>> initialization. SurfaceFlinger didn't crashes but
>> no bootanimation. It seems just blocked.

If you want to test another driver in qemu, you can test Varad's patches
in https://patchwork.freedesktop.org/series/29006/ for atomic updates in
the Cirrus driver.

Regards,

Tomeu