drm_hwcomposer moving to fd.o

drm_hwcomposer moving to fd.o

[Robert Foss]

Hey,

After talking to Liviu Dudau at LPC and Sean Paul & Kaveh Nasri at XDC
it seems that we all could benefit from community maintainership of
drm_hwcomposer.

I'm happy to announce that drm_hwcomposer now officially is hosted on
freedesktop.org:
https://cgit.freedesktop.org/drm_hwcomposer/

The chromiumos wiki entries have also been moved to f.do:
https://www.x.org/wiki/Projects/drm_hwcomposer/
https://www.x.org/wiki/Projects/drm_hwcomposer/Overview/

With this I'm hoping we'll be able to merge the changes done by intel
in [1], but more importantly remove the need for an alternative
implementation.

Regarding contributions, they are accepted on the dri-devel list, using
the patch prefix "hwc".

Currently Sean Paul, Zach Reizner, Rob Clark, Rob Herring and Robert
Foss have commit access. This is just the initial set, any contributor
with a few commits under their belt is welcome to request commit
access.

A fd.o account is needed for to grant commit rights, one can be
requested here:
https://www.freedesktop.org/wiki/AccountRequests/

I would also like to thank Sean Paul for taking the initiative and
helping out with the move.


[1] https://github.com/android-ia/external-drm_hwcomposer/


Rob.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm_hwcomposer moving to fd.o

[Chih-Wei Huang]

Great news!
Thanks a lot to make it happen.

I hope I am wrong.
From my understanding most x86 GPUs still
cannot work with drm_hwcomposer since
they lack of atomic mode-setting API support
required by drm_hwcomposer.
Hope this could be addressed soon since
drm_hwcomposer becomes a standard project of fd.o.

How about the gralloc?
There are also several implementations
scattered somewhere.
I think it's also important to standardize it to fd.o
and make it work with fd.o's drm_hwcomposer.

2017-09-22 7:52 GMT+08:00 Robert Foss <robert.foss@collabora.com>:
> Hey,
>
> After talking to Liviu Dudau at LPC and Sean Paul & Kaveh Nasri at XDC
> it seems that we all could benefit from community maintainership of
> drm_hwcomposer.
>
> I'm happy to announce that drm_hwcomposer now officially is hosted on
> freedesktop.org:
> https://cgit.freedesktop.org/drm_hwcomposer/
>
> The chromiumos wiki entries have also been moved to f.do:
> https://www.x.org/wiki/Projects/drm_hwcomposer/
> https://www.x.org/wiki/Projects/drm_hwcomposer/Overview/

Seems I can't connect to it now...

> With this I'm hoping we'll be able to merge the changes done by intel
> in [1], but more importantly remove the need for an alternative
> implementation.
>
> Regarding contributions, they are accepted on the dri-devel list, using
> the patch prefix "hwc".
>
> Currently Sean Paul, Zach Reizner, Rob Clark, Rob Herring and Robert
> Foss have commit access. This is just the initial set, any contributor
> with a few commits under their belt is welcome to request commit
> access.
>
> A fd.o account is needed for to grant commit rights, one can be
> requested here:
> https://www.freedesktop.org/wiki/AccountRequests/
>
> I would also like to thank Sean Paul for taking the initiative and
> helping out with the move.
>
>
> [1] https://github.com/android-ia/external-drm_hwcomposer/

-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm_hwcomposer moving to fd.o

[Jani Nikula]

On Fri, 22 Sep 2017, Robert Foss <robert.foss@collabora.com> wrote:
> After talking to Liviu Dudau at LPC and Sean Paul & Kaveh Nasri at XDC
> it seems that we all could benefit from community maintainership of
> drm_hwcomposer.

Sounds good!

> Regarding contributions, they are accepted on the dri-devel list, using
> the patch prefix "hwc".

dri-devel averages around 2400-2500 messages per month AFAICT. If hwc
community development picks up any kind of momentum, please consider
starting a new list. Or would a joint userspace list with e.g. libdrm be
beneficial? Daniel Stone will help you here.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm_hwcomposer moving to fd.o

[Robert Foss]

Hey Jani,

On Fri, 2017-09-22 at 14:21 +0300, Jani Nikula wrote:
> On Fri, 22 Sep 2017, Robert Foss <robert.foss@collabora.com> wrote:
> > After talking to Liviu Dudau at LPC and Sean Paul & Kaveh Nasri at
> > XDC
> > it seems that we all could benefit from community maintainership of
> > drm_hwcomposer.
> 
> Sounds good!
> 
> > Regarding contributions, they are accepted on the dri-devel list,
> > using
> > the patch prefix "hwc".
> 
> dri-devel averages around 2400-2500 messages per month AFAICT. If hwc
> community development picks up any kind of momentum, please consider
> starting a new list. Or would a joint userspace list with e.g. libdrm
> be
> beneficial? Daniel Stone will help you here.

A separate ML if there ends up being a significant volume of traffic
sounds like a good idea.

I guess we're following the IGT model here, and will move if/when
sustained development is occurring.

> 
> BR,
> Jani.
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm_hwcomposer moving to fd.o

[Robert Foss]

Hey Chih-Wei,

On Fri, 2017-09-22 at 10:40 +0800, Chih-Wei Huang wrote:
> Great news!
> Thanks a lot to make it happen.
> 
> I hope I am wrong.
> From my understanding most x86 GPUs still
> cannot work with drm_hwcomposer since
> they lack of atomic mode-setting API support
> required by drm_hwcomposer.
> Hope this could be addressed soon since
> drm_hwcomposer becomes a standard project of fd.o.

I haven't personally run drm_hwc ontop of any x86 hardware, but there
are people who do it.
The android-ia project has supported using drm_hwcomposer and an
alternative hwcomposer, so it would think there should be no issues.

> 
> How about the gralloc?
> There are also several implementations
> scattered somewhere.
> I think it's also important to standardize it to fd.o
> and make it work with fd.o's drm_hwcomposer.

Gralloc is a different story, and the right person to ask about it is
not me, but maybe Rob Herring.


Rob.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm_hwcomposer moving to fd.o

[Chih-Wei Huang]

Hey Robert, thank you for the reply.

2017-09-22 23:43 GMT+08:00 Robert Foss <robert.foss@collabora.com>:
> Hey Chih-Wei,
> On Fri, 2017-09-22 at 10:40 +0800, Chih-Wei Huang wrote:
>> Great news!
>> Thanks a lot to make it happen.
>>
>> I hope I am wrong.
>> From my understanding most x86 GPUs still
>> cannot work with drm_hwcomposer since
>> they lack of atomic mode-setting API support
>> required by drm_hwcomposer.
>> Hope this could be addressed soon since
>> drm_hwcomposer becomes a standard project of fd.o.
>
> I haven't personally run drm_hwc ontop of any x86 hardware, but there
> are people who do it.

Indeed we (android-x86 project) are the people who try to use it
but without lucky. Rob Herring also uses (a slightly modified)
drm_hwcomposer with his aosp virgl porting.
Except these I don't know any others use it on x86 hardware.
Though drm_hwcomposer is developed from Chromium
but I've heard Chrome actually use an alternative proprietary
hwcomposer in their Android Runtime for Chrome (ARC).

> 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.

The android-ia doesn't support using fdo's drm_hwcomposer I think.
They use an alternative hwcomposer [1] as you said.
It looks very different than drm_hwcomposer though
both rely on the similar (or same?) atomic API.
Android-ia's kernel has also been patched to work with it.
The vanilla kernel (at least LTS 4.9) can't work with [1]
or drm_hwcomposer.
Actually [1] only works with i915(i965) but we want
a more generic hwcomposer like drm_hwcomposer.

Please correct me if I am wrong.


[1]: git://github.com/01org/IA-Hardware-Composer

>> How about the gralloc?
>> There are also several implementations
>> scattered somewhere.
>> I think it's also important to standardize it to fd.o
>> and make it work with fd.o's drm_hwcomposer.
>
> Gralloc is a different story, and the right person to ask about it is
> not me, but maybe Rob Herring.



-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: drm_hwcomposer moving to fd.o

[Kondapally, Kalyan]

Hi Chih-Wei,

looks very different than drm_hwcomposer though both rely on the similar (or same?) atomic API.
>> Android-ia's kernel has also been patched to work with it.

Not sure why you have that impression. We don't carry any custom Kernel patches in our side. 

Br,
Kalyan

-----Original Message-----
From: Chih-Wei Huang [mailto:cwhuang@android-x86.org] 
Sent: Sunday, September 24, 2017 7:44 PM
To: Robert Foss <robert.foss@collabora.com>
Cc: Zach Reizner <zachr@chromium.org>; Daniel Stone <daniels@collabora.com>; Tomeu Vizoso <tomeu.vizoso@collabora.com>; Liviu Dudau <Liviu.Dudau@arm.com>; dri-devel@lists.freedesktop.org; Marissa Wall <marissaw@google.com>; Nasri, Kaveh <kaveh.nasri@intel.com>; Stephane Marchesin <marcheu@chromium.org>; Kondapally, Kalyan <kalyan.kondapally@intel.com>
Subject: Re: drm_hwcomposer moving to fd.o

Hey Robert, thank you for the reply.

2017-09-22 23:43 GMT+08:00 Robert Foss <robert.foss@collabora.com>:
> Hey Chih-Wei,
> On Fri, 2017-09-22 at 10:40 +0800, Chih-Wei Huang wrote:
>> Great news!
>> Thanks a lot to make it happen.
>>
>> I hope I am wrong.
>> From my understanding most x86 GPUs still cannot work with 
>> drm_hwcomposer since they lack of atomic mode-setting API support 
>> required by drm_hwcomposer.
>> Hope this could be addressed soon since drm_hwcomposer becomes a 
>> standard project of fd.o.
>
> I haven't personally run drm_hwc ontop of any x86 hardware, but there 
> are people who do it.

Indeed we (android-x86 project) are the people who try to use it but without lucky. Rob Herring also uses (a slightly modified) drm_hwcomposer with his aosp virgl porting.
Except these I don't know any others use it on x86 hardware.
Though drm_hwcomposer is developed from Chromium but I've heard Chrome actually use an alternative proprietary hwcomposer in their Android Runtime for Chrome (ARC).

> 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.

The android-ia doesn't support using fdo's drm_hwcomposer I think.
They use an alternative hwcomposer [1] as you said.
It looks very different than drm_hwcomposer though both rely on the similar (or same?) atomic API.
Android-ia's kernel has also been patched to work with it.
The vanilla kernel (at least LTS 4.9) can't work with [1] or drm_hwcomposer.
Actually [1] only works with i915(i965) but we want a more generic hwcomposer like drm_hwcomposer.

Please correct me if I am wrong.


[1]: git://github.com/01org/IA-Hardware-Composer

>> How about the gralloc?
>> There are also several implementations scattered somewhere.
>> I think it's also important to standardize it to fd.o and make it 
>> work with fd.o's drm_hwcomposer.
>
> Gralloc is a different story, and the right person to ask about it is 
> not me, but maybe Rob Herring.



--
Chih-Wei
Android-x86 project
http://www.android-x86.org
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm_hwcomposer moving to fd.o

[Tomeu Vizoso]

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@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).

Regards,

Tomeu

> The android-ia doesn't support using fdo's drm_hwcomposer I think.
> They use an alternative hwcomposer [1] as you said.
> It looks very different than drm_hwcomposer though
> both rely on the similar (or same?) atomic API.
> Android-ia's kernel has also been patched to work with it.
> The vanilla kernel (at least LTS 4.9) can't work with [1]
> or drm_hwcomposer.
> Actually [1] only works with i915(i965) but we want
> a more generic hwcomposer like drm_hwcomposer.
> 
> Please correct me if I am wrong.
> 
> 
> [1]: git://github.com/01org/IA-Hardware-Composer
> 
>>> How about the gralloc?
>>> There are also several implementations
>>> scattered somewhere.
>>> I think it's also important to standardize it to fd.o
>>> and make it work with fd.o's drm_hwcomposer.
>>
>> Gralloc is a different story, and the right person to ask about it is
>> not me, but maybe Rob Herring.
> 
> 
> 

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm_hwcomposer moving to fd.o

[Daniel Vetter]

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@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+.

Cheers, Daniel

> Regards,
> 
> Tomeu
> 
> > The android-ia doesn't support using fdo's drm_hwcomposer I think.
> > They use an alternative hwcomposer [1] as you said.
> > It looks very different than drm_hwcomposer though
> > both rely on the similar (or same?) atomic API.
> > Android-ia's kernel has also been patched to work with it.
> > The vanilla kernel (at least LTS 4.9) can't work with [1]
> > or drm_hwcomposer.
> > Actually [1] only works with i915(i965) but we want
> > a more generic hwcomposer like drm_hwcomposer.
> > 
> > Please correct me if I am wrong.
> > 
> > 
> > [1]: git://github.com/01org/IA-Hardware-Composer
> > 
> >>> How about the gralloc?
> >>> There are also several implementations
> >>> scattered somewhere.
> >>> I think it's also important to standardize it to fd.o
> >>> and make it work with fd.o's drm_hwcomposer.
> >>
> >> Gralloc is a different story, and the right person to ask about it is
> >> not me, but maybe Rob Herring.
> > 
> > 
> > 
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm_hwcomposer moving to fd.o

[Chih-Wei Huang]

2017-09-26 13:26 GMT+08:00 Daniel Vetter <daniel@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@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.


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);


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

Full log:
https://drive.google.com/open?id=0B3GICgSwrKXcci1lbDdaSlJBRE0


Shall I create bugs in the Bugzilla?
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm_hwcomposer moving to fd.o

[Daniel Vetter]

On Thu, Sep 28, 2017 at 8:49 AM, Chih-Wei Huang <cwhuang@android-x86.org> wrote:
> 2017-09-26 13:26 GMT+08:00 Daniel Vetter <daniel@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@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 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@android-x86.org> wrote:
>> 2017-09-26 13:26 GMT+08:00 Daniel Vetter <daniel@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@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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: 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@android-x86.org> wrote:
>>> 2017-09-26 13:26 GMT+08:00 Daniel Vetter <daniel@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@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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm_hwcomposer moving to fd.o

[Daniel Vetter]

On Thu, Sep 28, 2017 at 9:43 AM, Tapani Pälli <tapani.palli@intel.com> wrote:
>
>
> 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@android-x86.org>
>>> wrote:
>>>>
>>>> 2017-09-26 13:26 GMT+08:00 Daniel Vetter <daniel@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@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

Both of these should be fixed in the generic code I'd say. Cursor is a
perfect case of random special cases that might make some planes
unsuable in certain conditions (but there's really nothing special
with it being the cursor plane).

And the 2nd patch shows how we probably want to expose the can_scale
and can_position stuff from the plane's atomic_check functions as
hints to the compositor. Plus ofc the compositor should try to only
use the supported drm_fourcc codes (if it indeed gets that wrong).

So yeah I'd say that's bugs in drm_hwcomposer, if this helps with fixing it.
-Daniel


>>>> 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@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: drm_hwcomposer moving to fd.o

[Chih-Wei Huang]

2017-09-28 15:08 GMT+08:00 Daniel Vetter <daniel@ffwll.ch>:
> On Thu, Sep 28, 2017 at 8:49 AM, Chih-Wei Huang <cwhuang@android-x86.org> wrote:
>> 2017-09-26 13:26 GMT+08:00 Daniel Vetter <daniel@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@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?

Ah! Thank you for the hint.
By setting atomic=1 for nouveau it works.
But similar to i965 case, after boot complete
it only shows systemui + navbar + black background
Besides, it's quite unstable.
I tried to do something (move mouse, press some keys)
then system_server crashes.

Log: https://drive.google.com/open?id=0B3GICgSwrKXcVTJfblY1NGllUXM

>> 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.

Will do. Thank you!


-- 
Chih-Wei
Android-x86 project
http://www.android-x86.org
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel