| anpok_ | RAOF: logging::Logger and related went back to logging ... only report implementations are inside report now | 07:10 |
|---|---|---|
| anpok_ | RAOF: report exists only to have a place for report_factory and a place to know which report implementations exist.. so we could also not have report::lttng report::null.. but then we would end up having either one directory with 3 * 2 * n + n classes and three or one static libraries built and a shared library for lttng or three directories that do not add a namespace.. | 07:19 |
| anpok_ | s/classes/files | 07:19 |
| anpok_ | n is 6 now | 07:20 |
| === alf is now known as alf_ | ||
| alan_g | duflu: have you had time for more thoughts on https://code.launchpad.net/~alan-griffiths/mir/SwitchingBundle-controls-completion-of-client_acquire-without-blocking/+merge/205568? | 09:18 |
| duflu | alan_g: On a hangout | 09:18 |
| alan_g | np | 09:18 |
| RAOF | anpok: I don't think I'd object to three directories that don't add a namespace :) | 09:25 |
| anpok | RAOF: hm you only see the other namespaces in test cases when the null reports are used.. | 09:44 |
| anpok | i could get those cases away too | 09:44 |
| anpok | i mean with something like .. NullReportFactory().create_what_needed() .. | 09:44 |
| RAOF | Hm. That looks sensible at a first glance. | 09:46 |
| duflu | alan_g: The answer is no BTW, I haven't thought about it at all. Consider that "Abstain" for now | 10:02 |
| alan_g | duflu: OK. (It's just that I'd like as many good eyes as possible on that bit of code.) | 10:04 |
| duflu | Yeah, agreed | 10:04 |
| duflu | But instead, dinner! | 10:04 |
| alan_g | Enjoy! | 10:05 |
| alf_ | alan_g: anpok: RAOF: at the moment our unit tests for the armhf native CI build run with valgrind, but we completely ignore valgrind errors... I wonder if there is a benefit in running them with valgrind at all at the moment. The only I can think of is the difference in timing that running under valgrind brings, and which may expose races (but then again the different timing may hide races too) | 10:12 |
| RAOF | I thought valgrind was super-flaky on armhf? | 10:13 |
| alan_g | So did I | 10:13 |
| RAOF | As in: I didn't know the unit tests wouldn't SIGILL under valgrind on armhf :) | 10:13 |
| alan_g | If valgrind can produce meaningful results we should use them | 10:14 |
| alf_ | alan_g: anpok: RAOF: They seem to run ok, apart from the thousands uninitialized value errors (running in Nexus 10, ERROR SUMMARY: 609348 errors from 532 contexts) | 10:14 |
| RAOF | That sounds vaguely solvable with judicious overrides. | 10:15 |
| RAOF | (As in: it's probably Android/libhybris stuff) | 10:15 |
| RAOF | If no one feels like generating those overrides, though, I don't think we get any value out of running the tests in valgrind, except a 10x longer test time. | 10:16 |
| alf_ | RAOF: by overrides I guess you mean valgrind suppressions? | 10:17 |
| RAOF | Yeah, that business. | 10:18 |
| alf_ | alan_g: anpok: RAOF: ok, so if no one objects I will 1. first try to create a suppression file if it's reasonable 2. if (1) fails turn off valgrind in mir-team-mir-development-branch-trusty-armhf-ci | 10:20 |
| RAOF | Sounds good to me. | 10:21 |
| alan_g | Sure | 10:21 |
| anpok | ok | 10:21 |
| mlankhorst | RAOF: ping? do you have an updated mir patch for mesa 10.1? | 11:22 |
| mlankhorst | some parts no longer apply and other parts seem to have already been applied upstream in a slightly different form, so a rebase would be nic | 11:23 |
| mlankhorst | nice* | 11:23 |
| === alan_g is now known as alan_g|lunch | ||
| alf_ | alan_g|lunch: anpok: great, our CI tests don't fail when there is a leak... | 13:06 |
| anpok | hm because we would need extra flags to valgrind for that.. --leak-check=full? | 13:12 |
| alf_ | anpok: right | 13:19 |
| alf_ | alan_g|lunch: anpok: ok, the rabbit hole is too deep to deal with the suppressions right now, I will go for disabling valgrind for armhf in our CI | 13:21 |
| alf_ | alan_g|lunch: anpok: ... and at some poin we need to take a good look at what valgrind is actually doing in CI | 13:22 |
| === dandrader is now known as dandrader|afk | ||
| === alan_g|lunch is now known as alan_g | ||
| alan_g | alf_: ack | 13:45 |
| === dandrader|afk is now known as dandrader | ||
| mlankhorst | I pushed mesa 10.1 to https://launchpad.net/~canonical-x/+archive/x-staging/+packages -- i had to rebase the mir patch, so if you want to test if mir still works :-) | 14:07 |
| alf_ | rsalveti: ogra_: Hi! I need some advice for the separate -mesa, -android packages if you have some time | 14:13 |
| mterry | Hello all! I'm looking at USC and trying to do the following: determine when one of my sessions/surfaces has started writing actual content to its frame buffers. i.e. when it has started to draw to the screen. How would I go about doing that from a compositor perspective? | 14:36 |
| ogra_ | alf_, i saldy have to run out for a bit, is it ok to ping you back later ? | 14:39 |
| mterry | ricmm, alan_g ^ ? | 14:39 |
| alan_g | mterry: I'm not sure I understand the question. By "my sessions/surfaces" you mean a client process? | 14:40 |
| ricmm | mterry: you mean you want to catch it *before* it first swaps? | 14:40 |
| mterry | ricmm, no I don't need to intercept, just notice | 14:40 |
| mterry | alan_g, yeah sure. client process | 14:41 |
| ricmm | no I mean, do you want to know while its rendering to the buffer but before swapping? | 14:41 |
| ricmm | thats an odd need | 14:41 |
| alf_ | ogra_: sure, thanks | 14:41 |
| mterry | ricmm, oh maybe I just need swapping | 14:42 |
| mterry | ricmm, I just want to know when something is on screen for a given client | 14:42 |
| alan_g | From the compositor the buffer swapper gets a client_acquire() call before the client gets passed the buffer. And a client_release() after it has drawn | 14:42 |
| alan_g | mterry: what problem are you trying to solve? | 14:42 |
| mterry | alan_g, with a split greeter, lightdm will launch both the greeter and user sessions at the same time. I wanted to have the compositor wait to show either surface until the greeter is actually on screen (i.e. I don't want the user session showing on screen for a second if it wins the race) | 14:44 |
| alan_g | I'm not convinced the compositor is the right place for that logic. | 14:46 |
| * alan_g thinks... | 14:46 | |
| alan_g | Wouldn't it be better to just make the user session hidden? | 14:49 |
| mterry | alan_g, but I want to unhide it when the greeter is drawn | 14:49 |
| mterry | alan_g, (also is there a trivial way to mark it hidden?) | 14:50 |
| anpok | session->hide() | 14:50 |
| alan_g | session::hide() | 14:50 |
| mterry | anpok, ooh, thanks. Didn't notice that method | 14:50 |
| mterry | OK, so that's helpful | 14:50 |
| anpok | but you want both to be shown? | 14:50 |
| anpok | (still confused?) | 14:50 |
| mterry | anpok, yup, greeter is alpha-backed and will show session beneath it | 14:51 |
| anpok | ah ok but you want to un-hide it as soon there are buffers to display? | 14:51 |
| mterry | anpok, yes | 14:52 |
| mterry | anpok, buffers to display by the greeter | 14:52 |
| alan_g | I think this is better handled by detecting the swap_swap_buffers call in shell::Surface - not by hacking the compositor | 14:56 |
| alan_g | until the greeter posts a buffer just hide() all sessions. When it has posted, then show() them | 14:58 |
| alan_g | mterry: does that ^ make sense? | 15:01 |
| mterry | alan_g, so install my own surface factory that returns a surface subclass that hooks into swap_swap_buffers? | 15:02 |
| alan_g | mterry: yes. (If you try it in the compositor you'll never know whose buffer you're dealing with) | 15:03 |
| mterry | alan_g, well. I am in the compositor (I'm in unity-system-compositor). Or do you mean the compositor class? | 15:03 |
| alan_g | compositor component | 15:04 |
| alan_g | s/component/namespace/ | 15:04 |
| mterry | alan_g, OK, cool. Makes sense. Though the compositor has access to session->name(), which will tell me which session it is | 15:05 |
| alan_g | mterry: NB you'll be looking for a swap_buffers() call with a non-null buffer. (It will be null on the first call) | 15:08 |
| mterry | alan_g, OK, thanks. I will play with this today | 15:08 |
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| anpok | our tags seem to be wrong | 15:52 |
| anpok | (or with a certain probablility I fail at using bzr tags) | 15:53 |
| mlankhorst | RAOF: hm testing more.. 10.1 mir *client* fails, if I only upgrade mir server to 10.1 it works correctly.. | 15:55 |
| === dandrader is now known as dandrader|lunch | ||
| rsalveti | alf_: still in meetings, but can try to help | 16:33 |
| rsalveti | alf_: what is the issue? | 16:33 |
| alf_ | rsalveti: Hi! I am trying to setup the dpkg alternatives for the various mir platform libraries (client and server) and was wondering if the preference was to go for symbolic link to the library directly, or to have a link to an ld.so.conf entry | 16:37 |
| rsalveti | alf_: for me linking ld.so.conf is easier, I also use that for libhybris (to replace the mesa drivers) | 16:38 |
| rsalveti | because then you end up having only one alternative | 16:38 |
| rsalveti | ogra_: ^ | 16:39 |
| ogra_ | alf_, have a look at the mesa gles/gl packages | 16:39 |
| ogra_ | they do exactly that iirc | 16:40 |
| ogra_ | (sorry, had to go into a meeting right after i returned) | 16:40 |
| alf_ | ogra_: I have, that's where I got the idea :) We have we have a client platform and a server platform in different packages, which naively leads to two alternatives. I wonder if there is a way to control both of them at the same time without conflict? | 16:42 |
| ogra_ | hmm, on a lib level that smells hairy | 16:42 |
| ogra_ | (unless your lib names differ indeed ... which i assume they dont) | 16:43 |
| alf_ | ogra_: what I have now is libmirclientplatform-mesa (usr/lib/*/mir/clientplatform/mesa/libmirclientplatform.so) and similarly for libmirclientplatform-android, libmirplatformgraphics-mesa/android | 16:45 |
| ogra_ | and you have setups where both are installed ? | 16:46 |
| alf_ | ogra_: the server and client platform alternatives can be controlled independently this way | 16:46 |
| alf_ | ogra_: both = both android and mesa? | 16:47 |
| ogra_ | yes | 16:47 |
| alf_ | ogra_: that's the goal if I understand correctly. If it's not then guess we could go for having *-mesa and *-android packages that replace/conflict each other (so no alternatives) | 16:48 |
| ogra_ | right, thats why i saked | 16:49 |
| ogra_ | *asked | 16:49 |
| ogra_ | well, i dont see any way apart from shipping one ld.so.conf with each package if the binaries are in separate packages ... | 16:49 |
| ogra_ | and have each of them set its alternative | 16:49 |
| alf_ | ogra_: rsalveti: that was my plan, if that sounds ok to you too | 16:51 |
| alf_ | ogra_: rsalveti: I will go ahead | 16:51 |
| ogra_ | yeah | 16:51 |
| ogra_ | DOIT ! | 16:51 |
| ogra_ | :) | 16:51 |
| rsalveti | +1 | 16:51 |
| === dandrader|lunch is now known as dandrader | ||
| === Trevinho_ is now known as Trevinho | ||
| === dandrader is now known as dandrader|bbl | ||
| RAOF | mlankhorst: I think I do have a rebase. Let me check. | 21:34 |
| === dandrader|bbl is now known as dandrader | ||
| * mterry doesn't understand mg::Buffers | 23:02 | |
| RAOF | mterry: What about them? | 23:10 |
| mterry | RAOF, I don't have time to debug this properly now, but tomorrow I might pick some brains in here. I was trying to inspect them in USC to determine if the greeter had posted a frame yet | 23:11 |
| mterry | RAOF, but to inspect actual data I had to go to the native buffer? And that didn't seem to get me sensible results | 23:11 |
| RAOF | You'll probably find it easier printf debugging (using the buffer ID that's exported in mir_client_library_debug.h) and matching up that way. | 23:12 |
| RAOF | That's what I've done in the past. | 23:12 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!