| racarr | got a failing acceptance test for touch input picking (i.e. multiple visible clients stacked, such as the launcher and an application) | 00:14 |
|---|---|---|
| racarr | and a plan...lots of steps though | 00:14 |
| racarr | hopefully should finish by tomorro | 00:14 |
| === mmrazik is now known as mmrazik|afk | ||
| === mmrazik|afk is now known as mmrazik | ||
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| alf__ | alan_g: Good morning! | 08:21 |
| alan_g | alf__: Good morning! | 08:21 |
| alf__ | alan_g: @message-processor-report-lttng, can you please paste(bin) the full (detailed) output of the failing test runs | 08:22 |
| alf__ | alan_g: (when you get the time) | 08:22 |
| alan_g | alf__: I can, but there's nothing that looks more useful than I pasted to the comments. Would it be a better use of our time for me to try debugging for an hour or so? | 08:23 |
| alf__ | alan_g: Probably :) The error from lttng indicates that the communication threads that lttng uses to communicate with its daemon have either died or never started. I was wondering if there were any other error messages, perhaps at the beginning of the tests, that would give us more hints about what happened. | 08:35 |
| alan_g | alf__: I woudln't expect lttng to be doing anything unless asked. (which it wasn't) | 08:36 |
| alan_g | alf__: http://paste.ubuntu.com/5686305/ | 08:37 |
| alf__ | alan_g: it opens a connection to its daemon as soon as the lttng-ust shared object is loaded (through a shared object "constructor" function) | 08:37 |
| alan_g | Hmm is that a cost we want in "normal" operation? | 08:38 |
| alan_g | alf__: without having dived into the code is lttng waiting for a connection to its daemon? And might a timeout there cause a problem with our test setup timeouts? | 08:41 |
| alan_g | alf__: I'll see if I can track down exactly what the failure mode is... | 08:43 |
| alf__ | alan_g: @cost, if it turns out to be a problem, we can work around it by loading liblttng-ust dynamically at runtime when an lttng reporter is constructed | 08:43 |
| alan_g | alf__: ack. | 08:44 |
| === mmrazik is now known as mmrazik|afk | ||
| alf__ | alan_g: also, looking at the lttng-ust man page, there are the following env. variables: LTTNG_UST_DEBUG and LTTNG_UST_REGISTER_TIMEOUT which may help debug the problem | 08:45 |
| alf__ | alan_g: I think I should go with dlopen anyway, and hopefully that will fix the problem you are seeing, too | 08:53 |
| alan_g | alf__: the env variables don't affect the test failure (or output) | 08:54 |
| * alan_g would like to understand the problem, not just avoid it | 08:54 | |
| alf__ | alan_g: Interesting, I can know reproduce the failures you are seeing! I have no idea what changed :/ | 08:56 |
| alan_g | alf__: :/ | 08:57 |
| alf__ | alan_g: ok, so make test passes, but ctest (or running e.g. bin/integration-tests directly) fails | 08:58 |
| alan_g | alf__: I never run "make test" - but you're right, it passes | 08:59 |
| * alan_g thinks that is unreasonable | 09:00 | |
| alf__ | alan_g: I think I found the problem: | 09:00 |
| alan_g | \o/ | 09:01 |
| alf__ | From the manpage: "Some extra care is needed when using liblttng-ust with daemon applications that call fork(), clone(), or BSD rfork() without a following exec() family system call. The library "liblttng-ust-fork.so" needs to be preloaded for the application (launch with e.g. LD_PRELOAD=liblttng-ust-fork.so appname)" | 09:01 |
| alf__ | alan_g: and doing this solves the problem for me | 09:01 |
| alan_g | alf__: me too. (How does running via cmake do that?) | 09:02 |
| alan_g | alf__: In any case, I think we should be dynamically loading lttng - not requiring it regardless. | 09:06 |
| alf__ | alan_g: Agreed, I will give dynamic loading a spin and see what comes of it | 09:07 |
| alan_g | alf__: I wonder if you can dynamically load liblttng-ust-fork.so in the test configuration or if it needs to be preloaded. | 09:09 |
| alf__ | alan_g: no idea, I will experiment | 09:11 |
| alan_g | Good luck! | 09:11 |
| === mmrazik|afk is now known as mmrazik | ||
| hikiko | alf__, ping :) | 09:41 |
| alf__ | hikiko: pong | 09:42 |
| hikiko | hello, question: what exactly the vt does? you said I don't need it to run the render_to_fb example but without it I get runtime errors: Failed to find the current VT, so I guess I have to add it to my display... | 09:45 |
| hikiko | (or maybe I should just add it and have only one vt active? I am not sure I got 100% what it does :)) | 09:46 |
| alf__ | hikiko: The vt is an abstraction for the linux virtual terminal, which is not needed for SDL. 1. are you sure render_to_fb is using the sdl backend when you run it 2. do you use the vt in the sdl platform/display code? | 09:49 |
| hikiko | 1. I guess so, I configured cmake to use sdl, I would get a compile error if it didn't isn't it? 2. no | 09:51 |
| hikiko | shall I use it? | 09:51 |
| alf__ | hikiko: you shouldn't use it, SDL doesn't care about VTs | 09:56 |
| alf__ | hikiko: but you need to find out why you end up in VT code | 09:56 |
| hikiko | yes I will :) I just asked you to get sure I don't need the vt! | 09:57 |
| hikiko | thanks :) | 09:57 |
| alf__ | hikiko: sure, np :) | 09:57 |
| === mmrazik is now known as mmrazik|lunch | ||
| === mmrazik|lunch is now known as mmrazik | ||
| === hikiko is now known as hikiko_lunch | ||
| === hikiko_lunch is now known as hikiko | ||
| === alan_g is now known as alan_g|lunch | ||
| === greyback is now known as greyback|food | ||
| === alan_g|lunch is now known as alan_g | ||
| === greyback|food is now known as greyback | ||
| alan_g | alf__: do you know why OverlayRenderer::render() needs a graphics::DisplayBuffer? (As opposed to, say, a ViewArea) I can't find any code that justifies it - and it would simplify some refactoring if it needed less. | 13:49 |
| alf__ | alan_g: I guess it depends on how generic we would want to make OverlayRenderer. For example an overlay could need to render to an offscreen buffer first (=the display buffer would lose its "current" rendering target status) and then the overlay would need to make the display buffer current again, so it needs some access to the display buffer (or perhaps we could provide it with a std::function<> make_display_buffer). | 13:57 |
| alf__ | alan_g: but these are only assumptions... For now I don't think anything but the software cursor uses the overlay | 13:58 |
| alf__ | alan_g: Also I would argue that we don't the overlay at all: whoever needs a special compositing strategy with overlays or whatever, should just create their own new strategy... | 13:59 |
| alan_g | alf__: I was wondering what was special about overlays. I didn't find any code using them - where's the software cursor stuff? | 14:00 |
| alf__ | alan_g: probably hidden in one of racarr's branches :) | 14:02 |
| * alan_g thinks "if it isn't on trunk I can break it" | 14:03 | |
| kgunn | alan_g: alf__ at least on the phone, the hwc api is supposed to be the support mechanism | 14:04 |
| kgunn | for overlays | 14:04 |
| kgunn | because, everyones hw is a bit weird | 14:04 |
| kgunn | e.g. caveats | 14:04 |
| kgunn | on things like i can't support bgr mixed with rgb formats | 14:05 |
| kgunn | at any rate, overlays are there | 14:05 |
| alf__ | kgunn: If the OverlayRenderer was indeed meant as an abstraction for the HW overlay, it makes more sense. But I always thought it was just a mechanism to provide an easy way for examples or the shell to draw over the display. | 14:10 |
| alan_g | kgunn: you're saying that we need overlay support separately from other surfaces because they don't even go via the DisplayBuffer (and don't need it) | 14:11 |
| alf__ | alan_g: kgunn: Let's hear what racarr's intention was for it | 14:11 |
| kgunn | alf__: ack on that | 14:12 |
| alan_g | yep, sorry. (I optimistically hoped for someone that's around would know.) | 14:13 |
| kgunn | alf__: not sure i think about it correctly...but yeah, overlays head for a "specialized" piece of hw | 14:14 |
| kgunn | and that special hw is really a composition engine | 14:14 |
| kgunn | of 2d nature | 14:15 |
| kgunn | that's why hwc is attempted to be used....but can result in the "overlay stack" being sent back to the gpu | 14:16 |
| kgunn | in order to get composed | 14:16 |
| alf__ | kgunn: sure, I am just not sure if the particular OverlayRenderer we are talking about was meant for this, or the term "overlay" was used in the more general sense. | 14:17 |
| kgunn | alf__: right...i'm tracking, may or may not have been intended for this | 14:18 |
| * alan_g sees that he's right: in lp:~robertcarr/mir/demo-software-cursor-junk SoftwareCursorOverlayRenderer just uses the DisplayBuffer to get the size of the view area. | 14:18 | |
| alan_g | kgunn: alf__ : as far as trunk goes OverlayRenderer is pointless. FWIW SoftwareCursorOverlayRenderer doesn't use hwc. | 14:22 |
| kgunn | alan_g: right...i would think so too because of the name "sw cursor" | 14:23 |
| kgunn | whereas a "hw cursor" might try to get an overlay | 14:23 |
| alan_g | The implication being that OverlayRenderer is not intended for hardware overlays. Anyway, I feel confident I can make my changes and we can figure out if there is anything we need OverlayRenderer for later. | 14:26 |
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| kgunn | alan_g: sure...still a qood ques for racarr later | 14:29 |
| === seb128_ is now known as seb128 | ||
| kgunn | hikiko: ping | 14:53 |
| === alan_g is now known as alan_g|tea | ||
| kdub | good morning, status, updating my android builds, working on getting glmark to run on mir under android drivers | 14:57 |
| kdub | if we wanted to add some graphics performance benchmarks that are runnable on both mir and say... surfaceflinger, seems benchmarks/graphics would be a good place for that | 15:06 |
| kdub | but we might have to put an Android.mk makefile in there... | 15:06 |
| kgunn | kdub: +1 | 15:08 |
| kgunn | oem's will like that | 15:08 |
| kdub | yeah, not super pumped about the Android.mk in there though... the other option is to have a separate project | 15:09 |
| kgunn | right....but seems overkill | 15:10 |
| kgunn | ah...maybe a seperate proj is the right thing tho | 15:10 |
| kgunn | its for sure the most sanitary | 15:10 |
| === alan_g|tea is now known as alan_g | ||
| kdub | i somewhat am leaning towards a separate project... that way we can instruct 'download the ndk...' without re-polluting lp:mir with that | 15:12 |
| kgunn | yeah...let's do that | 15:13 |
| kgunn | kdub: the main thing is having a nice pointer for the oem's to see | 15:13 |
| kgunn | & play with | 15:14 |
| alf__ | status: debugging lttng issues (also see: https://bugs.lttng.org/issues/538) | 15:15 |
| alf__ | status: ... and trying to make our lttng reporting work despite those issues | 15:16 |
| alan_g | status: refactoring code that's in the way of composition bypass. | 15:16 |
| alf__ | alan_g: s/refactoring/deleting/ ;) ? | 15:16 |
| kdub | alan_g, anything i can help with? | 15:16 |
| alan_g | alf__: no | 15:16 |
| alan_g | kdub: not for now - I've the next few steps planned out | 15:17 |
| alf__ | alan_g: too bad, I was in a mood for deletions today :) | 15:18 |
| kdub | i might have a deletion! :) there's a class i want to get rid of in src/server/graphics/android | 15:18 |
| * alf__ will be right back | 15:19 | |
| === mmrazik is now known as mmrazik|afk | ||
| kgunn | alan_g: kdub racarr any of you on saucy? | 16:21 |
| alan_g | kgunn: not yet | 16:21 |
| kdub | raring for me | 16:21 |
| === mmrazik|afk is now known as mmrazik | ||
| racarr | morning | 16:36 |
| racarr | lept in a little late because I am always super tired for the 11 pm weekly :p | 16:36 |
| racarr | still on raring...hould be in saucy probably | 16:36 |
| alan_g | afternoon | 16:36 |
| racarr | alan_g: Reading one of your emails. I think SurfaceCreationParameters belongs in shell | 16:37 |
| racarr | or mf::SurfaceCreationRequest (does not feature a top_left) | 16:37 |
| racarr | and msh::SurfaceCreationParameters (features a top left) | 16:37 |
| racarr | placement strategy takes Request->Parameters | 16:37 |
| alan_g | Make it so Mr Carr | 16:37 |
| racarr | :) | 16:42 |
| === robotfuel is now known as ChrisGagnon | ||
| === ChrisGagnon is now known as robotfuel | ||
| kgunn | racarr: was chatting with gerry earlier, as to platform-api changes we're "waiting" on | 16:59 |
| kgunn | is it just these 2? | 16:59 |
| kgunn | https://code.launchpad.net/~ricmm/platform-api/new_api_with_lifecycle/+merge/160691 | 16:59 |
| kgunn | https://code.launchpad.net/~robertcarr/platform-api/mir-client-and-server/+merge/163616 | 16:59 |
| === alan_g is now known as alan_g|life | ||
| racarr | kgunn: Yes. I am syncing up with ricmm today | 17:10 |
| racarr | at 1:30 to figure out how to land them | 17:10 |
| kgunn | racarr: great! let me know if you need review "volunteers" (mmwwhaahaha) | 17:11 |
| racarr | :) Thanks. I think it's mostly just a matter of everything lining up right | 17:12 |
| racarr | i.e. to land my changes we need to introduce some more modularity | 17:12 |
| racarr | so it's possible to have say, mirclient for implementing ubuntu_application_ui_* | 17:12 |
| racarr | but still get at the GPS via hybris | 17:12 |
| kgunn | right | 17:12 |
| racarr | and I think some of riccm's refactoring involves this | 17:12 |
| racarr | god the amount of time I spend renaming classes... | 17:13 |
| racarr | why can't clang do this yet | 17:14 |
| racarr | moved surface creation parameters to shell in enable-surface-placement | 17:17 |
| kdub | racarr, yeah.. seems something automagical should exist for renaming classes | 17:19 |
| racarr | Sometimes deep in the caves of refactoring | 17:19 |
| racarr | I wonder if it is worth righting a tool that does common tasks, even if say it only worked on our code tree haha | 17:19 |
| racarr | then I tell myself if it were someone would have already done it and to focus | 17:20 |
| racarr | then I look at pictures of cats on the internet. | 17:20 |
| racarr | writing a tool* | 17:20 |
| kdub | we should probably have a FindMirClient.cmake module... | 17:24 |
| kgunn | racarr: cracking me up | 17:27 |
| === mmrazik is now known as mmrazik|afk | ||
| racarr | about...30% through getting rid of setInputWindows and having the dispatcher controller use the surface model directly | 17:47 |
| racarr | has the nice side effect of enabling input for more than one urface at a time | 17:48 |
| racarr | out for 20 minute to take a walk, back soon | 18:40 |
| kdub | kgunn, have some numbers for startup cost on the meeting doc | 19:23 |
| * kgunn scurries away to read | 19:24 | |
| kgunn | kdub: well that's interesting, altho double, the value is so small...it shouldn't bother us | 19:26 |
| kdub | yeah, thats what i thought too... | 19:26 |
| kdub | the cost is probably that we fire off more threads | 19:27 |
| kgunn | kdub: its kind of just on the edge of nuisance | 19:27 |
| racarr | the most interesting cost-effect for startup time is probably | 19:27 |
| racarr | recovering when mir crashes | 19:27 |
| racarr | on boot we are drowned in a giant mess of things that take forever to start | 19:27 |
| racarr | and I doubt we really show up as a blip | 19:27 |
| kgunn | racarr: even on phone? | 19:27 |
| kgunn | also....this should be new client, post startup | 19:28 |
| racarr | I dunno | 19:28 |
| racarr | on the desktop qml-phone-shell for example noticeably takes a second or so to load | 19:28 |
| racarr | after the hardware cursor appears | 19:28 |
| racarr | we dont do much disk IO is the thing | 19:29 |
| racarr | we do start a lot of threads though XD | 19:29 |
| kdub | well, firing up qml-phone-shell is more akin to starting a Launcher.apk than it is to starting /system/bin/surfaceflinger | 19:52 |
| kgunn | kdub: and i think racarr is talking about system start...not client start | 19:54 |
| kgunn | altho i might be wrong | 19:54 |
| === kdub is now known as kdub^lunch | ||
| thomi | morning all | 20:07 |
| thomi | I see nobody was brave enough to reply to my email on mir-devel? | 20:07 |
| kgunn | thomi: alf did actually | 20:07 |
| kgunn | ( i thot) | 20:07 |
| thomi | hmmmm, maybe my mail client is bring dumb then | 20:08 |
| * thomi restarts thunderbird | 20:08 | |
| kgunn | thomi: answer was...yes, it should be thread safe | 20:08 |
| kgunn | and he was able to repro | 20:08 |
| kgunn | so...hooray....plan worked! we found a bug | 20:09 |
| kgunn | we = you :) | 20:09 |
| kgunn | so thank you | 20:09 |
| thomi | he == ? | 20:09 |
| thomi | kgunn: ^ | 20:11 |
| kgunn | thomi: he == alf | 20:12 |
| thomi | ahhh | 20:12 |
| kgunn | thomi: i spoke with him earlier...he said not as frequent, but definitely seeing race cond of some sort | 20:12 |
| thomi | kgunn: it could be because I have a pretty beefy laptop perhaps. | 20:12 |
| kgunn | thomi: yep | 20:13 |
| thomi | kgunn: any idea when a fix is in the works? I'm wondering if it's worth postponing further development on mir-stress until this first issue is fixed | 20:13 |
| thomi | since I can't really exercise the mir erndering stuff until I can reliably connect... | 20:13 |
| kgunn | thomi: if he shows to the team meeting you might ask him | 20:14 |
| kgunn | otherwise i'll ping him in the morning | 20:14 |
| thomi | good point | 20:14 |
| kgunn | thomi: btw, are you on saucy or raring | 20:15 |
| thomi | kgunn: both :) | 20:15 |
| thomi | kgunn: my main laptop is on raring, I have a test laptop that's running saucy + mit-team staging PPA | 20:15 |
| thomi | since the PPA sometimes breaks the desktop | 20:16 |
| kgunn | thomi: yeah, i was curious....how is the saucy + mir ? | 20:16 |
| thomi | kgunn: seems fine to me | 20:16 |
| kgunn | thomi: cool | 20:17 |
| thomi | kgunn: it builds fine, tests all pass | 20:17 |
| thomi | we need to get to the point where it's easy to start unity8 + mir though | 20:17 |
| kgunn | yeah, hopefully racarr can push some key platform-api changes through...then he & gerry can create their unity-mir project | 20:18 |
| === kdub^lunch is now known as kdub | ||
| racarr | Lunnnch! | 20:46 |
| thomi | brrrreakfast! | 20:59 |
| racarr | and back | 21:27 |
| racarr | Effective C++ said to provide raw access functions in your resource management classes so there can't be an ything dangerous about adding a .get()/.surface() to msh::Surface right? ;) | 23:14 |
| kdub | better cast to void and XOR it with a known constant first :P | 23:16 |
| kdub | just kidding :) | 23:16 |
| racarr | error: ‘void {anonymous}::FocusNotifyingInputTargeter::focus_changed(const std::shared_ptr<mir::input::SurfaceTarget>&)’ marked override, but does not override | 23:30 |
| racarr | god I love that kekyword | 23:30 |
| racarr | keyword* | 23:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!