drm_hwcomposer moving to fd.o

[Daniel Vetter]

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.

> nouveau is tested on GTX 1060.
> drm_hwcomposer init failed so SurfaceFlinger crashed.
> Seems the driver is not atomic:
>
> 09-28 13:21:39.719  3096  3096 E hwc-drm-resources: Failed to set atomic cap -1
>
> which comes from this line of drmresources.cpp:
>
>  ret = drmSetClientCap(fd(), DRM_CLIENT_CAP_ATOMIC, 1);

nouveau.atomic=1 or you won't get the atomic ioctl. Not sure why it's
not enabled by default for nv50+. If it works, perhaps submit a patch
to change the default?

> vmwgfx also has issues on drm_hwcomposer
> initialization. SurfaceFlinger didn't crashes but
> no bootanimation. It seems just blocked.
>
> 09-28 04:46:09.043  3389  3389 E hwcomposer-drm: Failed to set active
> config d=1 ret=-19
> 09-28 04:46:09.043  3389  3389 E hwcomposer-drm: Failed to set initial
> config for d=1 ret=-19
> 09-28 04:46:09.043  3389  3389 E hwcomposer-drm: Failed to initialize display 1
> 09-28 04:46:09.043  3389  3389 E hwcomposer-drm: Failed to enumerate
> displays: Unknown error -19

Sounds like the vmwgfx implementation of atomic is a big buggy. Bug
filing for this would be good I think.

Cheers, Daniel

> Full log:
> https://drive.google.com/open?id=0B3GICgSwrKXcci1lbDdaSlJBRE0
>
>
> Shall I create bugs in the Bugzilla?



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch