drm_hwcomposer moving to fd.o

[Tapani Pälli]

On 09/28/2017 10:35 AM, Tomeu Vizoso wrote:
> 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.

back when Android-IA used drm_hwcomposer there were some fixes made 
before things started to work, this is a shot in the dark but following 
commits might fix something (disclaimer, this is based on some old 
snapshot of drm_hwcomposer but one might be able to port relevant 
changes ...)

handle cursor separately:

https://github.com/android-ia/external-drm_hwcomposer/commit/f9029ff42f7f925a2e34aad1caa1481f72f347ac

introduce own planner for IA:

https://github.com/android-ia/external-drm_hwcomposer/commit/e5f32f820a93352c631b379d9721795c783fc4e7


>>> 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
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>