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?
On 3 February 2017 at 20:33, Rob Clark <[email protected]> wrote: > Hmm, could be that westeros is doing something wrong that causes the > pbuffer path to be hit. I'm not entirely sure why pbuffer is not > supported in wayland (other than just that these days there are better > ways to do things than pbuffer), although I thought I remembered > seeing a fallback to surfaceless in webkit.. > > BR, > -R > > On Fri, Feb 3, 2017 at 1:05 AM, Sivasubramanian Patchaiperumal > <[email protected]> wrote: > > 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 > > <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 > >>> >> <[email protected]> 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 <[email protected]> > 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 > >>> >>>> <[email protected]> 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 <[email protected]> > >>> >>>> > wrote: > >>> >>>> >> > >>> >>>> >> On Thu, Feb 2, 2017 at 2:13 AM, Sivasubramanian Patchaiperumal > >>> >>>> >> <[email protected]> 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 > -- Regards, Sivasubramanian
_______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
