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@xxxxxxxxxxxxx>: > > On Fri, 2017-09-29 at 13:49 +0800, Chih-Wei Huang wrote: > > > 2017-09-29 5:29 GMT+08:00 Rob Herring <robh@xxxxxxxxxx>: > > > > 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
