On Thu, May 03, 2018 at 09:39:31AM -0500, Rob Herring wrote:
On Thu, May 3, 2018 at 9:32 AM, Sean Paul seanpaul@chromium.org wrote:
On Thu, May 03, 2018 at 09:14:41AM -0500, Rob Herring wrote:
On Thu, May 3, 2018 at 8:47 AM, Sean Paul seanpaul@chromium.org wrote:
On Wed, May 02, 2018 at 04:56:29PM -0700, Alistair Strachan wrote:
Use of the sw_sync API is not allowed any more. Until drm_hwcomposer is weaned off of sw_sync, build our own copy.
I don't think it is used any longer. AFAICT, with 2 seconds of grep, it's referenced in drmcompositorworker.cpp, virtualcompositorworker.cpp, and hwcomposer.cpp
I think these are all HWC1 legacy files, so they can probably just get cleaned up.
Are you sure? Doesn't the GL compositor have to wait on the fences of the input buffers and create new fences for the GL compositing output buffer(s) to pass into the kernel? It looked to me like sw_sync fences are used in the latter case and that needs to be converted to use eglCreateSyncKHR.
Hmmm, yeah thanks for pointing that out. It does look like drmdisplaycomposition is using sw_sync to handle the GL compositor release fences.
I'm pretty confident that despite the known issues causing GLC to not work on open stacks, there are probably a bunch of unknown issues that have been introduced while we try to tiptoe around it.
If anyone wants to remove it, I'd certainly be interested in reviewing that patch :-). I'd do it myself, but unfortunately the amount of time I have to dedicate to drm_hwc at this point is just enough to perform [incorrect] reviews.
Removing GL compositor or sw_sync? I've already written a patch to do the former.
Removing GL compositor. Is your patch on the list?
Sean
Rob