[Mesa-dev] [Freedreno] WebProcess crash on DB410c

Rob Clark robdclark at gmail.com
Thu Feb 2 20:36:11 UTC 2017


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 <robdclark at 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 <robdclark at 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.patchaiperumal at 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 <robdclark at 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.patchaiperumal at 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 <robdclark at gmail.com> wrote:
>>>> >>
>>>> >> On Thu, Feb 2, 2017 at 2:13 AM, Sivasubramanian Patchaiperumal
>>>> >> <sivasubramanian.patchaiperumal at 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


More information about the mesa-dev mailing list