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-April/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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
