[PATCH hwc v2 1/6] drm_hwcomposer: Remove threading

[Robert Foss]

On Fri, 2017-09-29 at 17:07 +0800, Chih-Wei Huang wrote:
> 2017-09-29 16:44 GMT+08:00 Robert Foss <robert.foss at collabora.com>:
> > On Fri, 2017-09-29 at 13:49 +0800, Chih-Wei Huang wrote:
> > > 2017-09-29 5:29 GMT+08:00 Rob Herring <robh at kernel.org>:
> > > > Perhaps just leave the current state as a separate branch.
> > > 
> > > Did you mean we maintain the branch in our repo?
> > > (that's what we do now, but I hope to avoid that)
> > > 
> > > Or fd.o could help to maintain the two branches (HWC1 and HWC2)?
> > 
> > Android later than O will not support HWC1 (as far as I understand
> > it),
> > so HWC2 is the way forward.
> 
> If all x86 GPUs we want to support
> can work with drm_hwcomposer,
> I'm happy to switch to HWC2.
> However it seems impossible at this moment. :(
> 
> > Furthermore I think targeting aosp/master at all time is the right
> > thing to do for drm_hwcomposer.
> > 
> > I for one am less than keen on maintaining branch that is
> > incompatible
> > with aosp/master upstream.
> > 
> > Ideally we wouldn't maintain a compile time switch either, not on
> > principle but because of the development overhead it causes.
> > We have very finite resources contributing to drm_hwcomposer.
> > If it was cheap&&easy to support old Android versions we should,
> > but I
> > don't think it is.
> 
> My point is not to support old Android versions,
> but to support old(?) GPUs that can't work with drm_hwcomposer.
> 

If some GPU (which supports fences and atomic) does not work on
drm_hwcomposer, I would consider that a bug.

So the idea would be to fix it, and fixing it would prevent you from
having any issues with HWC2 being the only supported API as far as I
understand our IRC chat.


Rob.