=== duflu_ is now known as duflu === duflu_ is now known as duflu === marcusto_ is now known as marcustomlinson_ === marcustomlinson_ is now known as marcustomlinson === chihchun_afk is now known as chihchun === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [10:41] alan_g: hm if we copy the wrapper instead of linking it the gdb symptoms would be gone [10:43] anpok_: I don't understand [10:45] alf_: small update, still happy? https://code.launchpad.net/~alan-griffiths/mir/improved-Rectangles/+merge/247161 [10:46] hm we talked about the wrapper causing troubles.. i.e. with gdb.. hmm on monday? [10:48] alan_g: looks good [10:49] anpok_: surely the wrapper needs to be linked to execute [10:50] i mean that gdb does not cope with mir_what_ever beging a symbolic link to ./wrapper [10:50] when you try to restart for example.. [11:04] * alan_g understands now [11:30] anpok_: alf_ either of you want to review this (otherwise I'll TA) https://code.launchpad.net/~albaguirre/mir/dialogs_and_tooltips/+merge/246655 [11:32] alan_g: feel free to TA [11:34] done === dandrader is now known as dandrader|afk === alan_g is now known as alan_g|lunch === dandrader|afk is now known as dandrader === alan_g|lunch is now known as alan_g [13:58] kdub: Hi! I was looking into mir_native_buffer.h and noticed we have a special case there for Android. Can we remove that special case by making Android serialize its data into a BufferPackage ? [13:58] kdub: (background: I am working on making the Mir core more platform agnostic) [14:00] alf_, which is the android-specific part? [14:01] kdub: #ifdef ANDROID typedef struct ANativeWindowBuffer MirNativeBuffer; [14:03] alf_, ah, yes, well I dunno [14:04] I mean, I guess we can convert ANativeWindowBuffer to a MirBufferPackage, but its tricky, mostly because ANativeWindowBuffer has a refcounting system [14:08] alf_, remembering a bit more... for android, we're given a native window interface, for mesa, we had to define one ourselves [14:09] like, the only place I see that struct needed is in the client API is in common/mir_toolkit/mesa/native_display.h [14:09] kdub: which struct are you referring to? [14:10] MirBufferPackage [14:10] kdub: (btw, a branch that's up for review move mesa/native_display.h out of common/) [14:11] * kdub will look [14:11] okay, that branch seems a good idea [14:12] (lp:~afrantzis/mir/remove-mesa-specific-code-from-mircommon) [14:13] and it makes sense to me that MirBufferPackage ends up in mir-client-platform-mesa-dev [14:14] kdub: I see MirBufferPackage used throughout the client code (MirSurface, ClientBufferDepository etc) [14:14] alf_, right, it was mostly for convenience [14:15] because, MirBufferPackage is the analogue to ANativeWindowBuffer [14:16] so, I see a distinction in that MirBufferPackage is something we have to define for the mesa eglNativeWindow [14:16] and its also what we happen to be using internally from convenience [14:17] kdub: Wasn't the point that MirBufferPackage would be a platform-independent container of buffer information interchange between server and client? [14:17] kdub: the platform independent parts being the data[] and fd[] arrays [14:18] kdub: which only the client/server platforms would know how to read [14:21] alf_, I suppose, but I've always thought of MirBufferPackage as more of the mesa-analogue to ANativeWindowBuffer [14:23] * kdub rethinks from the perspective that MirBufferPackage is the platform-agnostic type, and mesa eglnative types just happen to use it [14:25] I guess though that means that the mir_native_buffer.h header should be shipped in that new mesa package, but be used internally in the server code [14:29] and... coming back to the original question :) I think serializing it for the purposes of the client code is okay for now [14:30] with the caveat that, mir_surface_get_current_buffer() is a public mesa-specific function I guess [14:31] kdub: I wonder if this could be changed to be a "platform operation" instead. [14:32] yeah, that would be good [14:32] and then getting the buffer for the mesa egl would just be a platform operation === chihchun is now known as chihchun_afk === mpt_ is now known as mpt