Hi Emil, Ok, thanks for picking that up.
On Tuesday, 2 October 2018 12:23:30 CEST Emil Velikov wrote: > On Thu, 20 Sep 2018 at 15:13, Mathias Fröhlich > <mathias.froehl...@gmx.net> wrote: > > > > > If I replace the above with > > > > EGLint surface_type = 0; > > /* Only advertise pbuffer configs for non swrast devices */ > > if (dri2_dpy->image_driver) > > surface_type = EGL_PBUFFER_BIT; > > > > dri2_conf = dri2_add_config(dpy, dri2_dpy->driver_configs[i], > > config_count + 1, surface_type, NULL, > > visuals[j].rgba_masks); > > > > then I can easily prohibit the crash that I mentioned when trying to > > create a pbuffer surface on the swrast device. > > At least I do no longer get a valid pbuffer config from eglChooseConfig > > and without that we cannot reach the crashing > > dri2_dpy->image_driver->createNewDrawable > > call somewhere from eglCreatePbufferSurface anymore. > > > > Still getting a surface less context on swrast should work... > > > Issue is that we do not know how to create a "pbuffer only" swrast. > > Hence one resolves to hacks like the ones we have in platform_surfaceless. > Effectively pilling hacks upon hacks - see swrast_loader_extensions > and "software path w/o DRM.". > > That said, I'm working on proper solution but since it will take some > time to finish/merge I'll drop this and 7/8 for now. That's fine too. What I wanted to avoid is that people using the extension correctly fail with a crash in the application when running on mesa. Think about it. Thats really bad from an application writers point of view as you do all right with checking extensions and that and then the opengl stack suddenly crashes. best Mathias _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev