I was trying to implement a window system agnostic library which will be used in creating opengl apps with different windows systems. Lets name that library as WSAL.Now to achieve this WSAL implements window system interfaces which is used in creating native windows etc of specific window system while egl calls are in main WSAL library.Consider wayland and X as examples of such two libraries. As I separate several implementations of wayland and and X from different team members.So to test them efficiently I have to create several function pointers and object pointers that are present in those library implementations and load them with symbols from libraries using dlsym utility so that at compile time I donot have to link with any library. For X I was successfully in creating X backend. For wayland I first got stuck at functions which are inline in wayland_client_protocol.h. For them I cannot do the same.Instead I created a function pointer which these functions actually calls in inline definition. Like when wl_display_get_registry is called wl_proxy_marshal_constructor is ultimately called. The terrible fucntions are wl_proxy_marshal_constructor and wl_proxy_marshal as they are defined with variable arguments.So I declared new_wl_proxy_marshal_constructor a function pointer of same type as wl_proxy_marshal_constructor and loaded the symbol from library using dlsym into new_wl_proxy_marshal_constructor. But faced a fundamental problem of determing argument types as these terrible functions (TFs) don't have constant argument signature i.e it may sometime pass a int as its 4th aguments in one inline expansion while a char * in some other inline function. So I explored this wl_proxy_marshal_constructor which actually calls wl_proxy_marshal_array_constructor after forming a variable arguments to a single argument using some wl_proxy object signature which I have no access to in main wayland interface. dlsym option of using rtld_now doesnot work. How to implement such functionality in wayland or provide a way to create a app with no linking at build time. Thanks Rohit Nandan
if possible please mail me a copy of resolution steps or idea with subject starting as WASL_WAYLAND to pulkitnandan@gmail.com
Rohit, what you describe here is a problem with your software architecture and not a bug in Wayland, so I'm closing this as invalid. You are welcome to ask your question on the Wayland mailing list. http://lists.freedesktop.org/archives/wayland-devel/
Created attachment 97469 [details] contains stack trace of working app with no visuals on screen This contains the stacktrace of looking to be ok wayland app but not showing any visual on the screen.
Created attachment 97470 [details] contains stack trace of working app with all the visuals on screen This file has complete stacktrace of working app using all debug flags. The diffrence between the two stacktrace is of visual on screen.
Firstly how will wayland can be made dynamically loadable at runtime.Suppose we have a hypervisor based platform where switching of windowing system is essential often while in execution.This will clot ram and cache if wayland protocol architecture doenot provide it. The two stacktraces which are added as attachment contains no sigsev this time.First app passes maximum possible extractable arguments to dynamically loaded fp pwl_proxy_socket_listener as function where each argument is extracted using " void * a = NULL; a = va_arg(ap, void *);" With this modification I was able to compile app while failed in getting actual visual behavior while stack behaviour seems to be. How to post this and get help on this globally. Second attached backtrace contains orthodox,minimal "simple-egl.c" like implementation without dlsym.So its runs perfectly. How to post this and get help on this globally. Thanks and regards Rohit Nandan
According to the protocol traces (they are not stack traces), your application is not using the wl_shell_surface interface to set a top-level role for the wl_surface, hence it does not appear on screen. Neither of the applications these traces came from should have appeared on screen at all. So if there is a bug, the bug is in the compositor, mapping a surface without a role. Please, ask questions on the mailing list. Bugzilla is for bugs, and I do not see any specific bug claimed here.
For the record, the surface mapping bug is now reported as bug #77527.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.