Bug 77521

Summary: cannot create opengl by dynamically loading wayland symbols from library
Product: Wayland Reporter: Rohit Nandan <pulkitnandan>
Component: waylandAssignee: Rohit Nandan <pulkitnandan>
Status: RESOLVED INVALID QA Contact:
Severity: blocker    
Priority: highest CC: pulkitnandan
Version: 1.4.0   
Hardware: All   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: contains stack trace of working app with no visuals on screen
contains stack trace of working app with all the visuals on screen

Description Rohit Nandan 2014-04-16 11:25:26 UTC
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
Comment 1 Rohit Nandan 2014-04-16 11:27:31 UTC
if possible please mail me a copy of resolution steps or idea with subject starting as WASL_WAYLAND to pulkitnandan@gmail.com
Comment 2 Ander Conselvan de Oliveira 2014-04-16 11:41:47 UTC
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/
Comment 3 Rohit Nandan 2014-04-16 12:36:44 UTC
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.
Comment 4 Rohit Nandan 2014-04-16 12:39:33 UTC
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.
Comment 5 Rohit Nandan 2014-04-16 12:47:46 UTC
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
Comment 6 Pekka Paalanen 2014-04-16 13:00:21 UTC
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.
Comment 7 Pekka Paalanen 2014-04-16 13:48:16 UTC
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.