<div dir="ltr">One more point is westeros always return null window for offscreen target, that why WPE falls back to pbuffer on HiKey and DB410c cases.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 3 February 2017 at 11:30, Sivasubramanian Patchaiperumal <span dir="ltr"><<a href="mailto:sivasubramanian.patchaiperumal@linaro.org" target="_blank">sivasubramanian.patchaiperumal@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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?<br><div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On 3 February 2017 at 02:06, Rob Clark <span dir="ltr"><<a href="mailto:robdclark@gmail.com" target="_blank">robdclark@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">btw, where exactly is it crashing?  I grabbed the WebKitForWayland<br>
tree.. if I'm looking at the right thing, the only place where it<br>
should try to create a pbuffer is in<br>
Source/WebCore/platform/graphi<wbr>cs/egl/GLContextEGL.cpp and that looks<br>
like it should only be a fallback after createWaylandContext() fails??<br>
<br>
I suspect pbuffer is not the root problem, that looks like a fallback<br>
path that shouldn't be hit..<br>
<br>
BR,<br>
-R<br>
<div class="m_-1044011159458856003HOEnZb"><div class="m_-1044011159458856003h5"><br>
On Thu, Feb 2, 2017 at 9:55 AM, Rob Clark <<a href="mailto:robdclark@gmail.com" target="_blank">robdclark@gmail.com</a>> wrote:<br>
> hmm, just looking at dri2_wl_display_vtbl:<br>
><br>
>    .create_pbuffer_surface = dri2_fallback_create_pbuffer_s<wbr>urface,<br>
><br>
> which just returns null.. so I guess pbuffers are not supported under wayland.<br>
><br>
> Bit of google search reveals:<br>
><br>
> <a href="https://lists.freedesktop.org/archives/wayland-devel/2012-April/002928.html" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>archives/wayland-devel/2012-Ap<wbr>ril/002928.html</a><br>
><br>
> so I think the answer is don't use pbuffers.<br>
><br>
> BR,<br>
> -R<br>
><br>
> On Thu, Feb 2, 2017 at 9:50 AM, Rob Clark <<a href="mailto:robdclark@gmail.com" target="_blank">robdclark@gmail.com</a>> wrote:<br>
>> hmm, tons of older stuff uses pbuffers w/ x11.. although a quick look<br>
>> at mesa/demos.git and it doesn't look like any of them that build for<br>
>> wayland do.  I don't think pbuffers are used much anymore.  But I<br>
>> would expect there should be some piglit tests which do.<br>
>><br>
>> (Plus, firefox and chromium have been ported to wayland.. and quite a<br>
>> lot of other sw.  And a lot of us are using wayland on our<br>
>> laptops/desktops these days.)<br>
>><br>
>> BR,<br>
>> -R<br>
>><br>
>> On Thu, Feb 2, 2017 at 9:39 AM, Sivasubramanian Patchaiperumal<br>
>> <<a href="mailto:sivasubramanian.patchaiperumal@linaro.org" target="_blank">sivasubramanian.patchaiperuma<wbr>l@linaro.org</a>> wrote:<br>
>>> Yes, WebProcess(in WebKit) is crashing on DB410c. Any client that uses<br>
>>> pbuffer surfaces will crash I suspect. Is there is any simple egl<br>
>>> application that uses pixel buffer to verify and confirm?<br>
>>><br>
>>> On 2 February 2017 at 19:00, Rob Clark <<a href="mailto:robdclark@gmail.com" target="_blank">robdclark@gmail.com</a>> wrote:<br>
>>>><br>
>>>> hmm, ok, so it is a *client* process that is crashing?  The wayland<br>
>>>> winsys (used by client processes, as opposed to gbm/drm winsys used by<br>
>>>> compositor) does support pbuffers.<br>
>>>><br>
>>>> BR,<br>
>>>> -R<br>
>>>><br>
>>>> On Thu, Feb 2, 2017 at 7:43 AM, Sivasubramanian Patchaiperumal<br>
>>>> <<a href="mailto:sivasubramanian.patchaiperumal@linaro.org" target="_blank">sivasubramanian.patchaiperuma<wbr>l@linaro.org</a>> wrote:<br>
>>>> > Westeros code uses EGL window surface only, but the WPE code (at<br>
>>>> > <a href="https://github.com/Metrological/WebKitForWayland/" rel="noreferrer" target="_blank">https://github.com/Metrologica<wbr>l/WebKitForWayland/</a>) which uses pbuffer<br>
>>>> > works<br>
>>>> > on HiKey and RPI as mentioned.<br>
>>>> ><br>
>>>> > On 2 February 2017 at 17:38, Rob Clark <<a href="mailto:robdclark@gmail.com" target="_blank">robdclark@gmail.com</a>> wrote:<br>
>>>> >><br>
>>>> >> On Thu, Feb 2, 2017 at 2:13 AM, Sivasubramanian Patchaiperumal<br>
>>>> >> <<a href="mailto:sivasubramanian.patchaiperumal@linaro.org" target="_blank">sivasubramanian.patchaiperuma<wbr>l@linaro.org</a>> wrote:<br>
>>>> >> > Hi,<br>
>>>> >> > I'm trying to port WPE on DB410c with Westeros compositor, but the<br>
>>>> >> > webprocess crashes due to null sharingcontext. Webprocess fails to<br>
>>>> >> > create gl<br>
>>>> >> > context as eglChooseConfig fails when the surface type attribute is<br>
>>>> >> > pbuffer.<br>
>>>> >> > Also, Westeros sample app works fine and the issue is only when<br>
>>>> >> > surface<br>
>>>> >> > type<br>
>>>> >> > attribute is pbuffer. But the same issue is not observed on similar<br>
>>>> >> > scenerios, HiKey and RPI with westeros. Is there something to do with<br>
>>>> >> > db410c<br>
>>>> >> > for eglChooseConfig failure when surface type is pbuffer?<br>
>>>> >><br>
>>>> >> Can you point me at the code?  Not 100% sure but possibly gbm/drm egl<br>
>>>> >> implementation does not support pbuffer surfaces.  I don't see weston<br>
>>>> >> using pbuffer's, for example.<br>
>>>> >><br>
>>>> >> Has this code ever worked with anything other than closed src gles<br>
>>>> >> drivers?  (Like the vc4 driver on r-pi or on x86?)<br>
>>>> >><br>
>>>> >> BR,<br>
>>>> >> -R<br>
>>>> ><br>
>>>> ><br>
>>>> ><br>
>>>> ><br>
>>>> > --<br>
>>>> > Regards,<br>
>>>> > Sivasubramanian<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Regards,<br>
>>> Sivasubramanian<br>
</div></div></blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font color="#888888">-- <br><div class="m_-1044011159458856003gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Regards,<br></div>Sivasubramanian<br></div></div>
</font></span></div></div></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Regards,<br></div>Sivasubramanian<br></div></div>
</div>