One more point is westeros always return null window for offscreen target, that why WPE falls back to pbuffer on HiKey and DB410c cases.
On 3 February 2017 at 11:30, Sivasubramanian Patchaiperumal < sivasubramanian.patchaiperu...@linaro.org> wrote: > Thanks Rob for your inputs. Yes, you are looking at the right place. But > the HiKey which takes same pbuffer path and it working with Mali is the > reference now. I'm trying to write a simple egl app that uses pbuffer to > confirm the support with Mesa. Does it sounds correct or you have any > suggestions? > > On 3 February 2017 at 02:06, Rob Clark <robdcl...@gmail.com> wrote: > >> btw, where exactly is it crashing? I grabbed the WebKitForWayland >> tree.. if I'm looking at the right thing, the only place where it >> should try to create a pbuffer is in >> Source/WebCore/platform/graphics/egl/GLContextEGL.cpp and that looks >> like it should only be a fallback after createWaylandContext() fails?? >> >> I suspect pbuffer is not the root problem, that looks like a fallback >> path that shouldn't be hit.. >> >> BR, >> -R >> >> On Thu, Feb 2, 2017 at 9:55 AM, Rob Clark <robdcl...@gmail.com> wrote: >> > hmm, just looking at dri2_wl_display_vtbl: >> > >> > .create_pbuffer_surface = dri2_fallback_create_pbuffer_surface, >> > >> > which just returns null.. so I guess pbuffers are not supported under >> wayland. >> > >> > Bit of google search reveals: >> > >> > https://lists.freedesktop.org/archives/wayland-devel/2012-Ap >> ril/002928.html >> > >> > so I think the answer is don't use pbuffers. >> > >> > BR, >> > -R >> > >> > On Thu, Feb 2, 2017 at 9:50 AM, Rob Clark <robdcl...@gmail.com> wrote: >> >> hmm, tons of older stuff uses pbuffers w/ x11.. although a quick look >> >> at mesa/demos.git and it doesn't look like any of them that build for >> >> wayland do. I don't think pbuffers are used much anymore. But I >> >> would expect there should be some piglit tests which do. >> >> >> >> (Plus, firefox and chromium have been ported to wayland.. and quite a >> >> lot of other sw. And a lot of us are using wayland on our >> >> laptops/desktops these days.) >> >> >> >> BR, >> >> -R >> >> >> >> On Thu, Feb 2, 2017 at 9:39 AM, Sivasubramanian Patchaiperumal >> >> <sivasubramanian.patchaiperu...@linaro.org> wrote: >> >>> Yes, WebProcess(in WebKit) is crashing on DB410c. Any client that uses >> >>> pbuffer surfaces will crash I suspect. Is there is any simple egl >> >>> application that uses pixel buffer to verify and confirm? >> >>> >> >>> On 2 February 2017 at 19:00, Rob Clark <robdcl...@gmail.com> wrote: >> >>>> >> >>>> hmm, ok, so it is a *client* process that is crashing? The wayland >> >>>> winsys (used by client processes, as opposed to gbm/drm winsys used >> by >> >>>> compositor) does support pbuffers. >> >>>> >> >>>> BR, >> >>>> -R >> >>>> >> >>>> On Thu, Feb 2, 2017 at 7:43 AM, Sivasubramanian Patchaiperumal >> >>>> <sivasubramanian.patchaiperu...@linaro.org> wrote: >> >>>> > Westeros code uses EGL window surface only, but the WPE code (at >> >>>> > https://github.com/Metrological/WebKitForWayland/) which uses >> pbuffer >> >>>> > works >> >>>> > on HiKey and RPI as mentioned. >> >>>> > >> >>>> > On 2 February 2017 at 17:38, Rob Clark <robdcl...@gmail.com> >> wrote: >> >>>> >> >> >>>> >> On Thu, Feb 2, 2017 at 2:13 AM, Sivasubramanian Patchaiperumal >> >>>> >> <sivasubramanian.patchaiperu...@linaro.org> wrote: >> >>>> >> > Hi, >> >>>> >> > I'm trying to port WPE on DB410c with Westeros compositor, but >> the >> >>>> >> > webprocess crashes due to null sharingcontext. Webprocess fails >> to >> >>>> >> > create gl >> >>>> >> > context as eglChooseConfig fails when the surface type >> attribute is >> >>>> >> > pbuffer. >> >>>> >> > Also, Westeros sample app works fine and the issue is only when >> >>>> >> > surface >> >>>> >> > type >> >>>> >> > attribute is pbuffer. But the same issue is not observed on >> similar >> >>>> >> > scenerios, HiKey and RPI with westeros. Is there something to >> do with >> >>>> >> > db410c >> >>>> >> > for eglChooseConfig failure when surface type is pbuffer? >> >>>> >> >> >>>> >> Can you point me at the code? Not 100% sure but possibly gbm/drm >> egl >> >>>> >> implementation does not support pbuffer surfaces. I don't see >> weston >> >>>> >> using pbuffer's, for example. >> >>>> >> >> >>>> >> Has this code ever worked with anything other than closed src gles >> >>>> >> drivers? (Like the vc4 driver on r-pi or on x86?) >> >>>> >> >> >>>> >> BR, >> >>>> >> -R >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> > -- >> >>>> > Regards, >> >>>> > Sivasubramanian >> >>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Regards, >> >>> Sivasubramanian >> > > > > -- > Regards, > Sivasubramanian > -- Regards, Sivasubramanian
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
