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.
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.
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.
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.
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
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.
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.
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.
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
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?
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?
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=andro...
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
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=andro...
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/f9029ff42f7f925...
introduce own planner for IA:
https://github.com/android-ia/external-drm_hwcomposer/commit/e5f32f820a93352...
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
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=andro...
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/f9029ff42f7f925...
introduce own planner for IA:
https://github.com/android-ia/external-drm_hwcomposer/commit/e5f32f820a93352...
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
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!
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.
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@lists.freedesktop.org
-
Chih-Wei Huang -
Daniel Vetter -
Jani Nikula -
Kondapally, Kalyan -
Robert Foss -
Tapani Pälli -
Tomeu Vizoso