2010/5/18 Kristian Høgsberg <k...@bitplanet.net>: > On Tue, May 18, 2010 at 12:41 PM, Chia-I Wu <olva...@gmail.com> wrote: >> 2010/5/18 Jakob Bornecrantz <wallbra...@gmail.com>: >>> 2010/5/17 Kristian Høgsberg <k...@bitplanet.net>: >>>> The EGL native platform API is determined at compile time and resolves >>>> to Win32, X11 or Symbian at this point. This means that if we want to >>>> support XCB or a native DRM implementation, they have to be their platforms >>>> and result in different libEGL.so's with identical ABI but different >>>> entrypoint semantics. From a distro point of view, and really, any point >>>> of view, this is a mess, since the different libraries can't easily >>>> co-exist >>>> without fiddling with linker paths. And if you get it wrong, an >>>> application >>>> requiring the X11 platform libEGL.so will happily link against any other >>>> libEGL.so and segfault when eglGetDisplay() doesn't do what it expects. >>>> >>>> We can get around this by overloading the X11 native entrypoints instead. >>>> The X Display struct has as its first member a pointer to XExtData. The >>>> pointer will always have bits 0 and 1 set to 0, which we can use to >>>> distinguish a struct that's not an X display. This lets us pass in a >>>> custom struct that can provide initialization data for other platforms >>>> in the same libEGL.so. >>>> >>>> The convention we're establishing is that the first field of such a struct >>>> must be a pointer, so as to overlap with the layout of the X display >>>> struct. We can then enummerate the different display types using odd >>>> numbers cast to a pointer (ensuring bit 0 is set). This patch introduces >>>> two new types of displays: EGL_DISPLAY_TYPE_DRM_MESA which lets us >>>> initialize EGL directly on a DRM file descriptor or device filename and >>>> EGL_DISPLAY_TYPE_XCB_MESA which lets us initialize EGL on X using an >>>> xcb_connection_t instead of a classic Xlib Display. >>> >>> This sounds good to me, there are just some minor nitpicks that would >>> be nice to be resolved. >>> >>> 1. Could you write some docu about EGLDisplayTypeDRMMESA, like that >>> the display should return the FD after init in the struct. Also what >>> happens if (drm->device_name == null && drm->fd < 0) looking at the >>> code it would fail to load is this what we want? >> I think the EGL prefix should be dropped. We are defining a new >> platform here: a platform whose display can be an xlib display, xcb >> connection or drm. It should not have the "EGL" prefix. > > That is a good point - so we'll call it MesaDisplayTypeDRM and > MESA_DISPLAY_TYPE_DRM and similar for XCB. > >> Actually, I think this platform should have its own header file. >> eglplatform.h will include the header file and typedef the native >> types defined there to EGL types. > You mean that the native types for the other platforms are defined in > their respective header files and so should these new types? I can > see that point of view, but from a more pragmatic point of view, I > don't think it's worth the trouble. Also, the types are specific to > the mesa implementation, they are not data types from another display > system or platform, and the Khronos implementors guide suggests that > the vendor/implementor can modify eglplatform.h. I just figured that if an application uses xcb_connection_t for the display, it might as well use xcb types for windows and pixmaps. Things could get really complex. Do you have in mind how/when xcb_connection_t will be used?
-- o...@lunarg.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
