<div dir="ltr">Tried writing a simple EGL pbuffer application and tested it on DB410c. As expected, eglChooseConfig returned no matched config available. Is there something we can do to get pbuffer support on Mesa?<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 3 February 2017 at 20:33, 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">Hmm, could be that westeros is doing something wrong that causes the<br>
pbuffer path to be hit.  I'm not entirely sure why pbuffer is not<br>
supported in wayland (other than just that these days there are better<br>
ways to do things than pbuffer), although I thought I remembered<br>
seeing a fallback to surfaceless in webkit..<br>
<br>
BR,<br>
-R<br>
<br>
On Fri, Feb 3, 2017 at 1:05 AM, Sivasubramanian Patchaiperumal<br>
<div class="HOEnZb"><div class="h5"><<a href="mailto:sivasubramanian.patchaiperumal@linaro.org">sivasubramanian.<wbr>patchaiperumal@linaro.org</a>> wrote:<br>
> One more point is westeros always return null window for offscreen target,<br>
> that why WPE falls back to pbuffer on HiKey and DB410c cases.<br>
><br>
> On 3 February 2017 at 11:30, Sivasubramanian Patchaiperumal<br>
> <<a href="mailto:sivasubramanian.patchaiperumal@linaro.org">sivasubramanian.<wbr>patchaiperumal@linaro.org</a>> wrote:<br>
>><br>
>> Thanks Rob for your inputs. Yes, you are looking at the right place. But<br>
>> the HiKey which takes same pbuffer path and it working with Mali is the<br>
>> reference now. I'm trying to write a simple egl app that uses pbuffer to<br>
>> confirm the support with Mesa. Does it sounds correct or you have any<br>
>> suggestions?<br>
>><br>
>> On 3 February 2017 at 02:06, Rob Clark <<a href="mailto:robdclark@gmail.com">robdclark@gmail.com</a>> wrote:<br>
>>><br>
>>> 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/<wbr>graphics/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>
>>><br>
>>> On Thu, Feb 2, 2017 at 9:55 AM, Rob Clark <<a href="mailto:robdclark@gmail.com">robdclark@gmail.com</a>> wrote:<br>
>>> > hmm, just looking at dri2_wl_display_vtbl:<br>
>>> ><br>
>>> >    .create_pbuffer_surface = dri2_fallback_create_pbuffer_<wbr>surface,<br>
>>> ><br>
>>> > which just returns null.. so I guess pbuffers are not supported under<br>
>>> > wayland.<br>
>>> ><br>
>>> > Bit of google search reveals:<br>
>>> ><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-<wbr>April/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">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">sivasubramanian.<wbr>patchaiperumal@linaro.org</a>> wrote:<br>
>>> >>> Yes, WebProcess(in WebKit) is crashing on DB410c. Any client that<br>
>>> >>> 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">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<br>
>>> >>>> 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">sivasubramanian.<wbr>patchaiperumal@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/<wbr>Metrological/WebKitForWayland/</a><wbr>) which uses<br>
>>> >>>> > 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">robdclark@gmail.com</a>><br>
>>> >>>> > wrote:<br>
>>> >>>> >><br>
>>> >>>> >> On Thu, Feb 2, 2017 at 2:13 AM, Sivasubramanian Patchaiperumal<br>
>>> >>>> >> <<a href="mailto:sivasubramanian.patchaiperumal@linaro.org">sivasubramanian.<wbr>patchaiperumal@linaro.org</a>> wrote:<br>
>>> >>>> >> > Hi,<br>
>>> >>>> >> > I'm trying to port WPE on DB410c with Westeros compositor, but<br>
>>> >>>> >> > the<br>
>>> >>>> >> > webprocess crashes due to null sharingcontext. Webprocess fails<br>
>>> >>>> >> > to<br>
>>> >>>> >> > create gl<br>
>>> >>>> >> > context as eglChooseConfig fails when the surface type<br>
>>> >>>> >> > 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<br>
>>> >>>> >> > similar<br>
>>> >>>> >> > scenerios, HiKey and RPI with westeros. Is there something to<br>
>>> >>>> >> > 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<br>
>>> >>>> >> egl<br>
>>> >>>> >> implementation does not support pbuffer surfaces.  I don't see<br>
>>> >>>> >> weston<br>
>>> >>>> >> using pbuffer's, for example.<br>
>>> >>>> >><br>
>>> >>>> >> Has this code ever worked with anything other than closed src<br>
>>> >>>> >> 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>
>><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>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Regards,<br></div>Sivasubramanian<br></div></div>
</div>