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