On 26 May 2016 at 11:28, Philipp Zabel <p.za...@pengutronix.de> wrote: > Hi Emil, > > Am Mittwoch, den 25.05.2016, 23:42 +0100 schrieb Emil Velikov: > [...] >> Or in other words, in case of egl + gbm, egl inherits the screen from >> the gbm device. As such platform_gbm does not call the core egl setup >> function, dri2_create_screen (like everyone else does x11, wayland...) >> but only the follow-up dri2_setup_screen. > > Thank you for the explanation. What is the reason for this indirection? > The idea is that in order for one to use GBM, alone, you do need a dri_screen at the bare minimum. That's how you interact with the dri module probing/querying various things. At the same time as you use both APIs in the same program you'd want those to be shared, as otherwise, from a dri module point of view, you'll be having two separate users/clients. Which makes it harder/impossible to implement some some extensions such as EGL_EXT_image_dma_buf_import.
^^ Is my non-expert take on it, so it might be a bit off. >> That said this patch will break things when using old libgbm and new >> libEGL and vice-versa. Sadly there's no way around it atm. >> Thus can we get an ABI check so that in the future we printout a >> message and abort early, instead of crashing in spectacular ways down >> the line? > > I didn't think of that. How do you envision this ABI check to look like? > gbm(_drm)_device currently don't have any version fields and I'm not > sure how a new gbm backend would check for an old libEGL. > The first thing that comes to mind is a simple ABI version number to be > incremented in lock-step between libgbm and libEGL. > Sadly there's nothing we can do for old libgbm/libEGL. The proposed approach, on the other hand sounds great imho. Thanks Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
