<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <meta name="Generator" content="Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="blue" vlink="purple"> <div class="WordSection1"> To whom it may concern:<o:p></o:p> <o:p> </o:p> We would like to bring your attention to a potential wayland-egl issue with openCV Python script.<o:p></o:p> <o:p> </o:p> The issue is that both Mesa and our mechanism to identify the wl_display client from eglGetDIspaly() call fails for openCV Python script.<o:p></o:p> Mesa implementation:<o:p></o:p> <o:p> </o:p> …<o:p></o:p> if (_eglPointerIsDereferencable(nativeDisplay)) {<o:p></o:p> void *first_pointer = *(void **) nativeDisplay;<o:p></o:p> <o:p> </o:p> (void) first_pointer; /* silence unused var warning */<o:p></o:p> <o:p> </o:p> #ifdef HAVE_WAYLAND_PLATFORM<o:p></o:p> /* wl_display is a wl_proxy, which is a wl_object.<o:p></o:p> * wl_object's first element points to the interfacetype. */<o:p></o:p> if (first_pointer == &wl_display_interface)<o:p></o:p> return _EGL_PLATFORM_WAYLAND;<o:p></o:p> #endif<o:p></o:p> <o:p> </o:p> TI wayland-egl WS implementation:<o:p></o:p> <pre>if (hNativeDisplay && is_ptr(hNativeDisplay)) {<o:p></o:p></pre> <pre> struct wl_display *dpy = (struct wl_display *)hNativeDisplay;<o:p></o:p></pre> <pre> <o:p></o:p></pre> <pre> if (*(void **)dpy == &wl_display_interface)<o:p></o:p></pre> <pre> return WSEGL_SUCCESS;<o:p></o:p></pre> <pre> }<o:p></o:p></pre> <pre>The problem is that the link address of wl_dispaly_interface at the caller and callee of API eglGetDispaly(wl_dispaly) are different. <o:p></o:p></pre> <pre>Here is what we found:<o:p></o:p></pre> The following parameters from libwayland-client.so are dumped at three different *.so location.<o:p></o:p> <![if !supportLists]>� <![endif]>mDisplay(dpy): struct wl_display* return from API wl_display_connect<o:p></o:p> <![if !supportLists]>� <![endif]>*mDisplay(*dby): the first element within struct wl_display and it should be a pointer to constant table wl_display_interface<o:p></o:p> <![if !supportLists]>� <![endif]>&wl_display_interface: address of this const table (@libwayland-client.so)<o:p></o:p> <![if !supportLists]>� <![endif]>wl_display_interface.name: the first entry within the wl_display_interface and it should be "wl_display"<o:p></o:p> <![if !supportLists]>� <![endif]>wl_display_connect: address of this API (@libwayland-client.so)<o:p></o:p> What I found is that the const table wl_display_interface resides at different location at different *.so as shown below:<o:p></o:p> libQt5WaylandClient.so: mDisplay is created here and therefore all parameters are consistent: QWaylandDisplay: mDisplay=0xd6770, *mDisplay=0xb0b0c6ac &wl_display_interface=0xb0b0c6ac, wl_display_interface.name=wl_display, wl_display_connect=0xb0cb5aec, init done<o:p></o:p> QT plugins\wayland-graphics-integration-client\libwayland-egl.so: only wl_display_interface is moved, the API wl_display_connect stays at the same location: QWaylandEglClientBufferIntegration::initialize: mDisplay=0xd6770, *mDisplay=0xb0b0c6ac &wl_display_interface=0xb0cc9970, wl_display_interface.name=wl_display, wl_display_connect=0xb0cb5aec<o:p></o:p> SGX DDK libpvrws_WAYLAND.so: only wl_display_interface is moved, the API wl_display_connect stays at the same location wlpvr: dpy=0xd6770, *dpy=0xb0b0c6ac &wl_display_interface=0xb1df96b0 wl_display_connect =0xb0cb5aec, wl_display_interface.name=wl_display<o:p></o:p> With python openCV API cv2.imShow, the location of data table such as wl_display_interface is moved at each plugin as shown at the previous comment. However, the table content seems to be preserved at the old location. The following log shows the table content at the first and last location.<o:p></o:p> // old location = 0xb0bb46ac, new location = 0xb1ea16b0<o:p></o:p> wlpvr: dpy=0xd6770, *dpy=0xb0bb46ac &wl_display_interface=0xb1ea16b0 wl_display_connect =0xb0d5daec, wl_display_interface.name=wl_display<o:p></o:p> // new location; name @0xb1e905f8 = "wl_display", where methods and events are also table pointers <o:p></o:p> wlpvr: wl_display_interface (new location):name=0xb1e905f8, version=1, method_count=2, methods=0xb1ea16e0, event_count=2, events=0xb1ea16c8<o:p></o:p> // old location: name @0xb0b7c228 = "wl_display"<o:p></o:p> wlpvr: wl_display_interface:name=0xb0b7c228, version=1, method_count=2, methods=0xb0bb46dc, event_count=2, events=0xb0bb46c4<o:p></o:p> We have also confirmed that the WL connection handle wl_display still works even though it still points to the old interface table.<o:p></o:p> Best regards,<o:p></o:p> Eric<o:p></o:p> <o:p> </o:p> </div> </body> </html>