PQ et. al., I've finally found the time to sit down and draft up my proposal for how events and requests get handled to make it easier to write language bindings. As a word of disclaimer, I've tried to pick through the source code on connection.c and a few other places but my working knowledge of libwayland's code-base isn't perfect. I'm taking a few ideas here from the way some of the JNI interfaces work. My recommendation would be to add the following type definition in wayland-util.h: union wl_argument { int32_t i; uint32_t u; wl_fixed_t f; const char * s; struct wl_object * o; uint32_t n; struct wl_array * a; int32_t h; }; We then add the following additional variants of wl_resource_post_event and wl_resource_queue_event: void wl_resource_post_event_array(stuct wl_resource *resource, uint32_t opcode, wl_argument *arguments); void wl_resource_queue_event_array(stuct wl_resource *resource, uint32_t opcode, wl_argument *arguments); This allows for easier posting of events with arguments determined at runtime. Right now I have to wrap wl_resource_post_event in a JNI native method for every event. This would allow me to do all of the event handling in Java except for one JNI native method that does all of the argument handling at runtime. To handle requests, we make the following modifications to wl_object: struct wl_object { const struct wl_interface * interface; void (* const * implementation)(struct wl_object *, uint32_t, void *, void *, union wl_argument *); void *implementation_data; uint32_t id; }; and define: void wl_object_c_client_implementation(struct wl_object * reciever, uint32_t opcode, void * data, void * server_object, union wl_argument *args); void wl_object_c_server_implementation(struct wl_object * reciever, uint32_t opcode, void * client, void * resource, union wl_argument *args); Then for declaring objects in C, you simply assign one of wl_object_c_client_implementation or wl_object_c_server_implementation (as appropriate) to the implementation field and the array of function pointers that we currently call "implementation" to the implementation_data field. The wl_object_c_implementation function then uses libffi to compile everything into a closure and calles the requested function just as before. Built into this is an assumption about the types of the void pointers and the assumption that, for server code, any wl_object pointers in args would refer to a wl_object inside a resource. This would allow me to replace the way that requests are called with something JNI-specific. Again, right now I have a separate function for each request that simply wraps a call to a variadic function called wl_jni_resource_call_request; I could get rid of this extra step. This would have two major advantages for java (or any other language) bindings. The first is that with these two modifications I can have all my auto-generated code in Java instead of having to also generate C wrappers for everything. This would also allow the language border to be much more "natural" and more reliable. Second, we could break libffi out as an optional dependency. We would still use libffi on most platforms but for the android case it could probably be removed which would make building far simpler. I realize that this isn't quite as simple as it looks because we're using the libffi [de]marshaler to handle requests to the wl_display object. However, it wouldn't be too hard to write a custom marshaler for wl_display and not require libffi. There is still the issue of comparing interfaces. PQ said something about the current implementation comparing pointers. Perhaps we could simply compare the interface name and version to determine if two interfaces are the same. That's what I have in mind. It probably needs to be tweaked but this should at least give a flavor of what I'm looking for. --Jason Ekstrand <div class="gmail_quote">On Tue, Dec 18, 2012 at 2:32 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Mon, 17 Dec 2012 12:17:48 -0600 Jason Ekstrand <<a href="mailto:jason@jlekstrand.net">jason@jlekstrand.net</a>> wrote: > I'll send out an e-mail later about API ideas once I have more time. I've > got an idea of what I'd like to see but I haven't had a chance to write it > down and formalize it yet. </div>... <div class="im">> I'm sorry if that got a bit long-winded but I hope you all can understand > what I'm trying to do a bit better. I appreciate any input you can offer. > --Jason Ekstrand > </div>Alright, thank you. You clearly have the Android specifics thought out. With libhybris and some Wayland protocol magic, I think you could actually get the hardware accelerated graphics going also inside a chroot, too, all the way onto the screen. I'm looking forward to seeing your libwayland proposals. - pq </blockquote></div>