On Tue, Aug 2, 2016 at 9:27 PM, Tomasz Figa <tf...@chromium.org> wrote: > Hi Rob, > > On Wed, Aug 3, 2016 at 2:32 AM, Rob Herring <r...@kernel.org> wrote: >> On Tue, Aug 2, 2016 at 6:07 AM, Tomasz Figa <tf...@chromium.org> wrote: >>> From: Nicolas Boichat <drink...@chromium.org> >>> >>> Existing image loader code supports creating images only for window >>> surfaces. Moreover droid_create_surface() passes wrong surface type to >>> dri2_get_dri_config(), resulting in incorrect configs being returned for >>> pbuffers. This patch fixes these issues. >>> >>> In addition, the config generation code is fixed to include single >>> buffered contexts required for pbuffers and make sure that generated >>> configs support only surfaces which can handle their supported buffering >>> modes. >>> >>> v2: Return error only in case of real error condition and ignore requests >>> of unavailable buffers. >>> Improve coding style. >> >> This still breaks Android for me. Just adding the hunks below is >> enough to break things. It results in get_buffers() being called with >> type == EGL_WINDOW_BIT and buffer_mask == __DRI_IMAGE_BUFFER_FRONT. I >> don't see any requests for the front buffer without this change. I've >> looked through the tree, but don't really see what would cause >> buffer_mask to change. > > Thanks for testing again and sorry to hear that it still doesn't work > correctly. > > It looks like somehow a single buffered config ends up being used for > a window surface with your driver. > > Could you give me some instructions how to set up some environment for > testing to reproduce the issue?
https://github.com/robherring/generic_device/wiki/KConfig-based-Multi-platform-Android-Device-(and-Mesa-graphics) _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev