| RAOF | Ha! | 00:01 |
|---|---|---|
| RAOF | When introspecting the set of fds a process has open, be aware that you might actually open an extra fd in the process of introspection... :) | 00:01 |
| rsalveti | kdub: were you able to give it a try? | 00:48 |
| kdub | rsalveti, not yet, distracted by https://bugs.launchpad.net/mir/+bug/1272041 | 00:50 |
| ubot5 | Ubuntu bug 1272041 in Mir "mir nested server failure: what(): error binding buffer to texture" [Critical,Confirmed] | 00:50 |
| rsalveti | got it | 00:53 |
| rsalveti | interesting | 00:53 |
| kdub | never a dull day on the mir team | 00:56 |
| === ^_\\\ is now known as LockeAnarchist | ||
| RAOF | Hm. google mock can't handle returning move-only things. | 02:36 |
| duflu_ | It's so over-featured, I get it can... somehow | 02:37 |
| duflu_ | I *bet* | 02:37 |
| RAOF | Not according to the google mock lists. | 02:38 |
| duflu_ | Then I blame C++ for giving us such things | 02:39 |
| === duflu_ is now known as duflu | ||
| duflu | Stroustrup will be personally responsible for the downfall of humanity, I suspect | 02:40 |
| RAOF | https://code.google.com/p/googletest/issues/detail?id=395 for those playing at home. | 02:44 |
| RAOF | Also annoying: QtCreator is super-confused by >> in templates. | 02:46 |
| duflu | RAOF: That's a common problem with (older?) compilers too. If you have nested templates you need a space: "> >" | 02:52 |
| RAOF | duflu: I >> in templates is a C++11 feature IIRC. | 03:24 |
| duflu | RAOF: Not sure what you mean. But do remember when I started learning and using the STL that ">>" was a syntax error/ambiguity. You have to put a space in the middle. | 03:27 |
| RAOF | duflu: http://en.wikipedia.org/wiki/C%2B%2B11#Right_angle_bracket - >> as not-always-right-shift operator is a C++11 language feature. | 03:28 |
| duflu | That explains why it mysteriously started working when I joined Mir | 03:29 |
| RAOF | So if you weren't building with --std=C++11... ;) | 03:29 |
| duflu | Still, for the cost of one character you can write backward-compatible code. Sounds like a good deal | 03:32 |
| === chihchun_afk is now known as chihchun | ||
| RAOF | Hm. Don't change things out from under cmake *too* much or it might fail to notice that you're changing some code, not compile it, and your tests will inexplicably fail, even though you've added code that should make them pass. | 05:05 |
| anpok_ | RAOF: if I am not mistaken the make generator of cmake does not notice if you change a self defined variable that changes add_definitions or changes CMAKE_CXX_FLAGS without also changing a different variable like CMAKE_BUILD_TYPE .. at least I had some bad experience that made me do all define like settings in header files created through configure_file | 07:33 |
| duflu | anpok_: I think he is past EOD/EOW | 07:49 |
| duflu | Till Tuesday :) | 07:49 |
| anpok_ | oh it is friday again | 07:56 |
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === mpt_ is now known as mpt | ||
| alf_ | duflu: anpok_: alan_g: Any preference for MirOutputCapture vs MirOutputRecording vs ... ? | 09:46 |
| duflu | alf_: Mir*Recording is my preference. Unsure about mentioning "Output" though | 09:47 |
| duflu | It sounds better. "Recording" is clearly an ongoing process whereas "Capture" sounds like an instantaneous screen grab or something | 09:48 |
| duflu | Woo, my Friday afternoon experiments have solved cloned output stutters | 09:49 |
| alan_g | +1 | 09:49 |
| alf_ | duflu: MirScreenRecording? We need to mention something at least since plain MirRecording is too vague (input? output? something else?) | 09:49 |
| duflu | And more generally boosted potential composting performance | 09:49 |
| alf_ | duflu: \o/ sounds good :) | 09:49 |
| duflu | alf_: Yes I thought the same about MirRecording | 09:50 |
| duflu | maybe | 09:50 |
| duflu | Not sure | 09:50 |
| alf_ | duflu: I like Output since the recording is targeting a specific MirDisplayOutput, so perhaps even MirDisplayOutputRecording if we don't mind being more verbose | 09:52 |
| alf_ | duflu: but I think MirOutputRecording is clear enough | 09:52 |
| duflu | alf_: Is it per output or DisplayBuffer? If the latter that's not even a client-visible concept | 09:52 |
| alan_g | ScreenCapture? | 09:52 |
| alf_ | duflu: it is per output | 09:53 |
| anpok_ | as a non native speeker both capture and recording do indicate an ongoing process | 09:53 |
| anpok_ | but recording also indicates that each frame is stored | 09:53 |
| anpok_ | while capture sounds like .. you get the current frame everytime you look at it.. | 09:54 |
| anpok_ | *speaker.. | 09:54 |
| alf_ | anpok_: which is actually what is going on... | 09:54 |
| alan_g | Looking at the mir-devel list we've talked about "screenshotting" and "screencasting" | 09:54 |
| duflu | alf_: ScreenCast? | 09:55 |
| anpok_ | i like screen cast | 09:55 |
| duflu | Since there's no requirement for actual "recording" | 09:55 |
| duflu | Oh. It's one word... MirScreencast with lower c | 09:56 |
| alan_g | Good enough | 09:56 |
| duflu | http://en.wikipedia.org/wiki/Screencast | 09:56 |
| duflu | It's on Wikipedia so it must be true | 09:57 |
| duflu | :) | 09:57 |
| alf_ | A *screencast* is a digital recording of computer screen output, also known as a video *screen capture* | 09:57 |
| duflu | alf_: I have too many memories of bugs where we ask for a screen capture, meaning screenshot | 09:57 |
| duflu | So Capture is ambigous | 09:58 |
| alf_ | alan_g: anpok_: duflu: it's Screencast 1... | 09:59 |
| alf_ | 2... | 09:59 |
| alf_ | 3... | 09:59 |
| alf_ | Sold! | 09:59 |
| duflu | Yay for finding new nouns not yet used in the codebase | 09:59 |
| alf_ | duflu: alan_g: anpok_: And guess what the relevant interface on the server side will be called ;) | 10:00 |
| duflu | Clarence? | 10:00 |
| alf_ | MirDisplayScreenOutputClarence | 10:01 |
| alf_ | ..ProviderManager | 10:01 |
| alan_g | ...er | 10:01 |
| duflu | Hmm, do we really have the words "DisplayScreenOutput" side by side? | 10:01 |
| alf_ | duflu: I hope not! :) | 10:02 |
| anpok_ | MirDOScreencaster | 10:03 |
| anpok_ | no dont take it serious | 10:04 |
| duflu | VideoDisplayScreenOutputViewportBufferImplementation | 10:04 |
| alf_ | anpok_: as you can see we are way past seriousness at the moment :) | 10:05 |
| alan_g | anpok_: we all know "Avoid class names that end in er" | 10:05 |
| duflu | I shouldn't joke. Compiz had function names twice as long | 10:05 |
| anpok_ | alan_g: hm like Verbalizer? | 10:06 |
| alan_g | anpok_: http://www.benhallbenhall.com/2013/01/naming-objects-er-object-names/ | 10:07 |
| alan_g | There was an image floating around that showed a room with "OO" names like "InternalToExternalAccessProvider" (door) - can't find it. | 10:09 |
| duflu | Heh. I'm sure I've been ranting about ER for years :) | 10:11 |
| duflu | "er" not "ER" | 10:11 |
| alf_ | alan_g: anpok_: duflu: Of course, sometimes, especially for narrow interfaces, a name ending in -er is actually a good choice | 10:12 |
| * duflu -> dinner, long weekend | 10:12 | |
| alf_ | dinn-er another name we should avoid! :P | 10:13 |
| === chihchun is now known as chihchun_afk | ||
| anpok_ | alf_: but thats to some degree because of c++ - those narrow interfaces are probably just a single function (op()) and in a different language would just be a function | 11:23 |
| anpok_ | there the verb does not have to become a noun | 11:23 |
| dandrader | have you guys successfully used apitrace on a Nexus 10 (or any other device)? | 11:26 |
| anpok_ | not tried yet | 11:28 |
| dandrader | any other trick for tracing gl calls? | 11:30 |
| anpok_ | it does not work? | 11:32 |
| dandrader | anpok_, apitrace? no. | 11:33 |
| anpok_ | just tried with manual preloading | 11:41 |
| anpok_ | oh | 11:43 |
| anpok_ | it did create something reasonable, | 11:45 |
| anpok_ | but when replaying on the desktop it complains that we never call glViewport | 11:45 |
| anpok_ | maybe I should use a better exmaple than mir_demo_standalon_render_surfaces | 11:46 |
| dandrader | hmm, when I tried with qmlscene it complaining about some missing API function | 11:47 |
| dandrader | complained | 11:47 |
| * dandrader tries with some mir example | 11:47 | |
| anpok_ | we could add that to apitrace then | 11:51 |
| anpok_ | i mean any other trick would involve doing the same, and making it work :) | 11:52 |
| dandrader | yeah, works with mir_demo_client_triangle but with qmlscene it bails out with "error: unavailable function eglBindAPI" | 11:52 |
| anpok_ | strange egltrace.so has it | 11:55 |
| dandrader | anpok_, exactly | 12:00 |
| dandrader | anpok_, do you also get the same with qmlscene? | 12:00 |
| dandrader | maybe it's because of the order or way that qmlscene loads its dependencies (through a qt platform plugin, etc) | 12:05 |
| anpok_ | qmlscene does not start | 12:12 |
| anpok_ | ah ok | 12:14 |
| anpok_ | now I get the same behaviour | 12:15 |
| anpok_ | i tried to find out when egl was added to apitrace | 12:30 |
| alf_ | Debugging boost::asio is not fun... | 12:53 |
| === dandrader is now known as dandrader|afk | ||
| ricmm | kdub: ping / when back | 13:06 |
| ricmm | guys one question | 13:06 |
| ricmm | how do we do handover of a buffer from server to client over ipc | 13:07 |
| ricmm | fd mappings of the server gralloc'd space? | 13:07 |
| === 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 | ||
| anpok | dandrader: hm | 14:32 |
| anpok | dandrader: qmlscene only links libGLESv2.so and not libEGL.so | 14:32 |
| dandrader | anpok, what about the QPA library that it eventually loads? | 14:33 |
| anpok | so whith LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/apitrace/wrappers/egltrace.so:/usr/lib/arm-linux-gnueabihf/libhybris-egl/libEGL.so.1.0.0 | 14:34 |
| anpok | it should work | 14:34 |
| anpok | then egltrace can use eglGetProcAddress to get the real functions | 14:34 |
| dandrader | anpok, namely /usr/lib/arm-linux-gnueabihf/qt5/plugins/platforms/libqubuntumirclient.so | 14:34 |
| dandrader | that one does link against libEGL | 14:35 |
| anpok | ok | 14:35 |
| anpok | i just tried qmlscene with an empty scene | 14:35 |
| anpok | and when libEGL is preloaded it did not aport on eglBindAPI | 14:36 |
| anpok | *abort | 14:36 |
| anpok | oh I have to go.. | 14:36 |
| anpok | bbl | 14:36 |
| === ricmm_ is now known as ricmm | ||
| dandrader | anpok, ok, thanks for the help! | 14:51 |
| dandrader | anpok, damn, it doens't abort on start but the sole contents of the trace are "0 eglBindAPI(api = EGL_OPENGL_ES_API) // incomplete" :/ | 15:09 |
| dandrader | I think I will have to inject the apitrace wrapper via LD_LIBRARY_PATH.... | 15:24 |
| === alan_g is now known as alan_g|tea | ||
| dandrader | anpok, ok, this seems to have done the trick: LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/apitrace/wrappers/egltrace.so:/usr/lib/arm-linux-gnueabihf/libhybris-egl/libEGL.so.1:/usr/lib/arm-linux-gnueabihf/libhybris-egl/libGLESv2.so.2 | 15:37 |
| === dandrader is now known as dandrader|lunch | ||
| anpok | ah ok | 15:49 |
| === alan_g|tea is now known as alan_g | ||
| kdub | ricmm, pong | 16:33 |
| ricmm | kdub: ahoy | 16:33 |
| ricmm | kdub: can you jump in a hangout? | 16:33 |
| kdub | sure | 16:33 |
| ricmm | k | 16:33 |
| ricmm | ill call you | 16:33 |
| ricmm | canon acc | 16:33 |
| kdub | ricmm, https://android.googlesource.com/platform/system/core/+/master/include/cutils/native_handle.h | 16:52 |
| ricmm | kdub: http://pastebin.ubuntu.com/6809300/ | 16:55 |
| === dandrader|lunch is now known as dandrader | ||
| ricmm | E/IMGSRV ( 5712): :0: gralloc_register_buffer: Cannot register a buffer twice (ID=36) | 17:01 |
| ricmm | kdub: did you drop? | 17:05 |
| kdub | i'm still here, hangout stopped | 17:05 |
| ricmm | kdub: http://pastebin.ubuntu.com/6809354/ | 17:07 |
| ricmm | handle.version=12, handle->numFds=1, handle->numInts=13, handle->data[0]=29 | 17:13 |
| ricmm | <mir::client::ClientBuffer> | 17:15 |
| ricmm | kdub: http://pastebin.ubuntu.com/6809480/ | 17:29 |
| ricmm | kdub: http://pastebin.ubuntu.com/6809656/ | 18:06 |
| ricmm | http://pastebin.ubuntu.com/6809667/ | 18:07 |
| ricmm | kdub: http://pastebin.ubuntu.com/6809689/ | 18:14 |
| BullSherd | Wow, Google is making really strange things http://goo.gl/YEkaMA | 18:52 |
| BullSherd | funny haha xD | 18:52 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| dandrader | kdub, ping | 20:06 |
| kdub | hello dandrader | 20:10 |
| dandrader | kdub, hi! | 20:10 |
| dandrader | kdub, is there any code at all in mir | 20:10 |
| dandrader | that clears the contents of a client buffer? | 20:10 |
| kdub | via GL? | 20:11 |
| dandrader | kdub, in any way | 20:11 |
| kdub | glClearColor(0.0, 0.0, 0.0, 0.0); glClear(GL_COLOR_BUFFER_BIT); | 20:11 |
| kdub | will clear to black | 20:11 |
| kdub | if you change the floats (r,g,b,a) itll change it to different colors | 20:12 |
| dandrader | kdub, I mean if mir *does* do it | 20:12 |
| dandrader | kdub, not how to do it | 20:12 |
| kdub | ah :) we do have a 'buffer initializer' class... let me ch eck if its used | 20:12 |
| dandrader | kdub, 'cause I'm debugging the prototype qml mir compositor. and, for a qml client, every now and then one of this frames is shown completely white | 20:13 |
| dandrader | so I'm wondering if this bogus white frame could possibly be caused by mir server | 20:14 |
| dandrader | or if it must be the client messing things up | 20:14 |
| dandrader | afaIct, in the client application there's no call that would clear the frame white (used apitrace to check) | 20:15 |
| dandrader | it has something to do with the interactions between threads | 20:16 |
| anpok | GLRenderer does it in begin i think | 20:16 |
| dandrader | if the scene graph rendering is done in qt's main (GUI) thread, the bogus white frames never show I | 20:16 |
| dandrader | show up | 20:16 |
| anpok | but it uses the default setting | 20:16 |
| anpok | which hopefully is not changed? | 20:17 |
| dandrader | but if I enable the scene graph rendering to be done on its own, separate, thread, then the bogus white frames pop up every now and then | 20:17 |
| kdub | dandrader, there isnt a 'quick way', but our 'examples/render_surfaces.cpp' programs a buffer color initializer | 20:18 |
| kdub | when the buffer is created | 20:18 |
| kdub | currently, the default server does not fill to a color on allocation | 20:18 |
| kdub | anpok, GLRenderer will clear the display composition, i think we're looking for a way to clear the client's buffer only | 20:19 |
| anpok | ok | 20:21 |
| dandrader | if I understood things correctly, mir creates a ring buffer of buffers for a given client once, and after that the contents of those buffers are modified only by the client | 20:22 |
| kdub | dandrader, right | 20:24 |
| kdub | dandrader, the buffers can be destroyed and created again (like on resize), but we won't post a resized buffer until after its been filled by the client | 20:26 |
| dandrader | kdub, ok. but in this case the size of the client doesn't change | 20:26 |
| dandrader | well, will continue debugging it on Monday | 20:27 |
| dandrader | have a nice weekend | 20:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!