#ubuntu-mir 2013-10-14
<RAOF> Damnit, mir_demo_client_eglplasma! Why can't you find the socket?
<duflu> RAOF: Cos we moved it in the server but failed to update libmirclient, I think
<duflu> I would have pointed that out if the MP didn't fly by and land without me noticing
<duflu> RAOF: If that's right, can you log a bug?
<RAOF> duflu: I don't think it's a new change. This *should* be all code that worked on another laptop.
 * RAOF is not running this from trunk, but from nested-spike.
<duflu> Sounds pointy
<tvoss_> good morning :)
<RAOF> Dear gdb: plz learn to C++.
<RAOF> No love, Chris.
<tvoss_> RAOF, for printing values?
<RAOF> tvoss_: Indeed.
 * tvoss_ always forgets the package that adds pretty printing of stl containers
<RAOF> To gdb?
<tvoss_> RAOF, yup
<duflu> tvoss_: When you remember, do tell
<duflu> Cos I've tried dropping the STL from a great height and it just won't die. So being able to debug would be next best thing
<RAOF> Hm.
<RAOF> Looks like it might be in libstdc++-4.8-dbg?
<tvoss_> RAOF, just pinged doko
<duflu> Surely pretty-printing is a generic template thing? Should be...
<duflu> i.e. Not STL-specific
<tvoss_> duflu, it relies on python to do the pretty printing
<duflu> Hah
<tvoss_> RAOF, that would  be libstdc++6-4.8-dbg, correct?
<RAOF> tvoss_: Yeah. Just trying to get it to actually work :)
<tvoss_> RAOF, likewise
<RAOF> duflu: But you'd really really like STL-specific pretty printers, so that your std::map<foo, bar> doesn't expand to 200 characters of entirely impenetrable implementation details.
<duflu> RAOF: No, I'd like pretty printing for any template. Not just the STL. Just like clang does
<RAOF> I'd like that too.
<RAOF> I'd like both less stupid template expansions, *and* std::map<int, string> = [{1, "one"}, {2, "two"}, â¦]
<tvoss_> RAOF, duflu this mail also helps: http://lists.kde.org/?l=kdevelop&m=125326438617051&w=2
<tvoss_> although I would have thought that we have packaged that functionality, too
<RAOF> tvoss_: I can only get python syntax errors out of that. :(
<RAOF> Sadness â¹
<RAOF> tvoss_: Ah. The pretty printers aren't python3 code.
<tvoss_> ah
<RAOF> And since gdb links to the 3.3 runtime...
<tvoss_> RAOF, now that's a bit annoying then
<RAOF> tvoss_: Ah, but running 2to3 on it appears to work.
<tvoss_> RAOF, got a nice pastebin?
 * tvoss_ wonders whether having pretty printers in our retracing-infrastructure would result in more easily readable stacktraces
<RAOF> tvoss_: sudo 2to3 --write /usr/share/gcc-4.8/python/libstdcxx/v6/printers.py
<tvoss_> RAOF, that's easy :)
<tvoss_> RAOF, I get http://paste.ubuntu.com/6234780/
<RAOF> tvoss_: Oh, you do 2. from http://sourceware.org/gdb/wiki/STLSupport, but with /usr/share/gcc-4.8/python
<tvoss_> RAOF, nope, that's from libstdc++-4.8-dbg
<RAOF> tvoss_: Yeah, but the python path is wrong (specifically, /usr/lib/debug/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.18-gdb.py appears to not add the sys path correctly)
<RAOF> Hm. Do we build without rtti? The pretty-printer is an ugly-printer without it :)
<tvoss_> RAOF, nope, we never disabled rtti
<RAOF> Sayeth the pretty-printer: std::shared_ptr (count 2, weak 0) 0x60dbd8, surface_map = warning: RTTI symbol not found for class 'std::_Sp_counted_ptr_inplace<mir::client::ConnectionSurfaceMap, std::allocator<mir::client::ConnectionSurfaceMap>, (__gnu_cxx::_Lock_policy)2>'
<om26er> duflu, re: bug 1227739 I assume that work will go in after 13.10 release ?
<ubot5> bug 1227739 in Mir "Mir continues to render background application surfaces even when they're not visible" [High,In progress] https://launchpad.net/bugs/1227739
<duflu> om26er: Unclear. I'm told the current work is exceptional to the freeze. But really I can't even get the prereq branches landed yet
<duflu> ... everyone's too busy to review them one way or the other
<tvoss_> RAOF, https://sourceware.org/bugzilla/show_bug.cgi?id=14235
<ubot5> sourceware.org bug 14235 in python "verbose RTTI message polluting traces" [Normal,New]
<om26er> duflu, right. there is still work in unity-mir needed after your branches get merged?
<om26er> or any other component
<duflu> om26er: Yeah, *maybe*. Would be unpredictable as to whether the fix works otherwise.
<duflu> The unity-mir fix is trivial. I'm just not familiar with building/testing that project
<duflu> Umm, I mean platform-api?
<Saviq> hey folks, is anyone looking at https://bugs.launchpad.net/ubuntu/+source/maliit-framework/+bug/1238107 - it's the most visible hang/crash at the moment for me - since it happens almost every time you stop unity8
<ubot5> Ubuntu bug 1238107 in maliit-framework (Ubuntu) "maliit-server crashed with SIGSEGV in __GI___pthread_mutex_lock()" [Medium,Confirmed]
<tvoss_> Saviq, alf_ was looking into a similar issue
<alf_> Saviq: I was planning to look into at after updating the phone
<alf_> s/at/it/
<Saviq> alf_, great thanks, let me know if you need help!
<alf_> Saviq: will do
<alf_> Saviq: so, just 'stop unity8' to reproduce?
<jibel> I got a webbrowser crash with the same trace on build 95 this morning bug 1239522
<ubot5> bug 1239522 in webbrowser-app (Ubuntu) "webbrowser-app crashed with SIGSEGV in __GI___pthread_mutex_lock()" [Medium,New] https://launchpad.net/bugs/1239522
<Saviq> alf_, yeah
<Saviq> jibel, yeah, it's something in mirclient most probably
<alf_> jibel: @1239522, is the webbrowser-app reproducible consistently?
<alf_> jibel: the crash I mean
<jibel> alf_, no, I was trying all the apps to verify none of them was completely trashed. I'm searching a way to reproduce.
<Saviq> duflu, re: bug #1238107 I believe alf_ said bug #1233988 was slightly different
<ubot5> bug 1233988 in maliit-framework (Ubuntu) "duplicate for #1238107 With Mir enabled: platform-api apps crash with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::client::DisplayConfiguration::copy_to_client()" [High,Fix committed] https://launchpad.net/bugs/1233988
<ubot5> bug 1233988 in maliit-framework (Ubuntu) "With Mir enabled: platform-api apps crash with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::client::DisplayConfiguration::copy_to_client()" [High,Fix committed] https://launchpad.net/bugs/1233988
<Saviq> actually
 * Saviq builds platform-api
<alf_> Saviq: ah, so the fix for 1233988 is not yet in?
<duflu> Saviq: I'm not convinced. But I'm also not convinced we fixed it properly first time. We should at least get to the stage where the known fixes are released, then re-assess if there's still a problem
<Saviq> alf_, it's Fix committed everywhere
<Saviq> duflu, +1
<alf_> Saviq: but not released...
<Saviq> alf_, yup
<duflu> alf_: I assume you verified the platform-api was smart enough to at least check for connect failure?
<duflu> .. i.e. returning false is not in vain
<Saviq> alf_, actually it's released in platform-api https://code.launchpad.net/~phablet-team/platform-api/trunk
<alf_> duflu: Saviq: yes, it fails an assertion... but now that I think about it, I think I tried it in debug mode, not sure if the assertion is fired in the package version too
<Saviq> on Thursday
<duflu> Right, but the bug may still exist. Only as an error now rather than a crash
<duflu> Although platform-api could still be abusing libmirclient and cause it to crash elsewhere
<duflu> Perhaps we should strengthen libmirclient so it doesn't get blamed for bad parms...
<Saviq> alf_, duflu, I'm still getting that crash reliably in maliit-server when stopping unity8
<alf_> Saviq: what about 1233988 ?
<Saviq> somewhat reliably at least
<Saviq> bug #1233988
<ubot5> bug 1233988 in maliit-framework (Ubuntu) "With Mir enabled: platform-api apps crash with SIGABRT in __gnu_cxx::__verbose_terminate_handler(), thrown from mir::client::DisplayConfiguration::copy_to_client()" [High,Fix committed] https://launchpad.net/bugs/1233988
<Saviq> alf_, I never knew how to reproduce it... the trace seems exactly the same..
<duflu> Saviq: I'm not confident the fixes so far are sufficient so maybe just reopen instead of duplicating in new bugs
<Saviq> duflu, sure - your call
<alf_> duflu: Let me investigate a bit further today, and I will merge as needed
<duflu> Saviq: Most importantly I just want to prevent people from working on duplicates. They're unaware of duplicating effort etc
<Saviq> duflu, I understand
<Saviq> duflu, works for me
<duflu> alf_: Should we be looking up valid_connections for all libmirclient API calls?
<duflu> Probably wouldn't hurt
<duflu> And it would stop crash reports from landing in Mir
<duflu> Hmm, actually it wouldn't. But it would allow us to instantly say "not a Mir bug"
<Saviq> duflu, alf_ I still get the maliit-crash on reboot
<Saviq> so sounds like not fixed indeed
<duflu> Saviq: No problem, just reopen
<alf_> Saviq: at least my part of the fix was not about not getting a crash, but getting a better crash (and not in Mir ;))
<Saviq> alf_, ok ;)
<Saviq> alf_, http://pastebin.ubuntu.com/6234953/
<alf_> Saviq: so is this with the default platform-api package, or something you built?
<Saviq> alf_, default papi, my mir trunk + https://code.launchpad.net/~kdub/mir/android-buffer-syncfence/+merge/189717
<Saviq> alf_, can downgrade mir if you think it matters
<alf_> Saviq: Can you try with a custom built platform-api? Just the package version but with -DCMAKE_BUILD_TYPE=Debug, to ensure the assertion for invalid connections is actually compiled in.
<Saviq> alf_, will do
<alf_> Saviq: hmm, just a moment to check something
<Saviq> alf_, holding
<alf_> Saviq: ok, please continue :) You may want to add a debug message for 'connect_suceeded' in u_application_instance_new_from_description_with_options src/ubuntu/mirclient/ubuntu_application_api_mirclient.cpp (that's where the assertion should fire, but no harm in having an extra message there)
<duflu> alf_: One of the duplicates today clearly showed MirConnection's this==NULL
<alf_> duflu: ok, so the problem probably is that platform-api should handle connection failures better. I wonder... is u_application_instance_new_from_description_with_options supposed to return NULL if the call fails?
<alf_> tvoss_: ^^ ?
<alf_> right now it just asserts
<tvoss_> alf_, yes, returning null would be correct
<tvoss_> alf_, admittedly, error handling should be better, but right now, NULL indicates error
<duflu> I think we need to protect libmirclient from false accusations and error-check the connection parameters
<alf_> duflu: +1
<tvoss_> alan_g, ping
<alan_g> tvoss_: hi
<tvoss_> alan_g, hey there, can I ask you to review https://code.launchpad.net/~kdub/mir/android-buffer-syncfence
<alan_g> tvoss_: it is on my list
<tvoss_> alan_g, ack, we would like to land the mp asap, so would be great if you could bump priority
<alan_g> tvoss_: OK. Do you know the best place to ask about network problems? (I'm a bit distracted by: my desktop stopped connecting to wired or wireless after I crashed X on Friday. Even installing a fresh image didn't fix - even though it works fine off the memory stick image)
<tvoss_> alan_g, #ubuntu-desktop
<alan_g> tvoss_: ta
 * duflu sees clipping bugs on iOS 7 and feels better about life
<alf_> duflu: :)
<duflu> It's kind of nice generally that Apple has lowered the bar/standard for UIs :)
<alan_g> My wire dislikes iOS7 nearly as much as Windows8
<duflu> -r +f?
<duflu> I'm not convinced Win8 was a step backwards compared to Win7. But Apple have killed a large chunk of their distinctiveness and competitive advantage with iOS7. And that's good for Ubuntu.
<alan_g> duflu: she's comparing Win8 with WinXP (but IMO win8 introduced a lot of silly traps for the user - e.g. two independent IE installs)
<duflu> To Microsoft's credit, at least with Win8 you generally don't need to install drivers any more. And the compositing feels nice and smooth
<duflu> alan_g: I've got to run, but would you be able to check this out and see why it's hanging in integration-tests?...
<duflu> lp:~mir-team/mir/verify-MirConnection
<alan_g> duflu: Sure, I'll have a look later
<alf_> Saviq: https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-more/+merge/190908 and
<alf_> Saviq: https://code.launchpad.net/~afrantzis/qtubuntu/fix-1233988-more/+merge/190907
<duflu> alan_g: Cool, ta
<Saviq> alf_, cool!
<Saviq> alf_, will test asap
<alf_> Saviq: note: this is not a fix of why maliit-server can't connect to the mir server, but at least now you should be getting a clear FATAL message from Qt (which is what the xcb backend does when it fails to connect)
<Saviq> alf_, so a better message at least
<Saviq> alf_, and no crash
<Saviq> alf_, well, I *know* why it can't connect - it's being shut down :)
<alf_> Saviq: There will be a crash == qFatal() == abort(). But we can change this to just print a message and exit cleanly... although the right solution here is to find why maliit is trying to connect to a server that is shutting down.
<Saviq> alf_, indeed
<alf_> Saviq: the problem is that I can't reproduce the maliit crash with 'stop unity8'. Of course, the maliit crash is very easy to recreate in general: just run maliit-server manually after 'stop unity8'.
<alf_> Saviq: some kind of race perhaps? How does upstart now when unity8 has started, so it can start maliit-server?
<Saviq> alf_, they stop "in concert" and indeed it's not 100% reproducible
<Saviq> alf_, but you can run the unity8 ap tests suite - should get you some .crash files
<alf_> Saviq: In upstart unity8.conf, we call 'exec unity8'. How does upstart know when unity8 has *really* started (i.e. it's ready to accept client connections?), so it can start maliit-server (maliit-server.conf: 'start on started unity8')?
<Saviq> ogra_, â can you shed some light there?
<ogra_> it waits until the PID it got returns something ...
<ogra_> Saviq, alf_ http://upstart.ubuntu.com/cookbook/#expect
<alf_> ogra_: thanks
<alf_> Saviq: "If your daemon has a "don't daemonize" or "run in the foreground" mode, then it's much simpler to use that and not run with fork following. One issue with that though, is that Upstart will emit the started JOB=yourjob event as soon as it has executed your daemon, which may be before it has had time to listen for incoming connections or fully initialize."
<Saviq> alf_, yeah, I know
<alf_> Saviq: does unity8 daemonize?
<Saviq> alf_, nope
<ogra_> so tracking the first PID should be fine then
<ogra_> (i.e no need to set "exepect")
<alf_> ogra_: yes, but we fall into the "Upstart will emit the started JOB=yourjob event as soon as it has executed your daemon, which may be before it has had time to listen for incoming connections or fully initialize." case
<ogra_> (except if you fork more than once)
<ogra_> i know slangesek is on a querst to look through all ubuntu touch upstart session jobs, you probably want to wait for his input
<ogra_> *quest
<ogra_> is teher a sprecific socket or file maliit should wait for ?
<ogra_> upstart has ways to make it do that
<ogra_> (you could drop "on started unity8" and make it ie "start on created socket file")
<ogra_> (and stop on removed ...)
<Saviq> alf_, arguably, since mir clients are not supposed to die when mir dies, shouldn't it also just wait for it to be ready and reconnect?
<alan_g> Saviq: alf_ we're a long way from that scenario working. (I'm currently fixing a client-side hang in the API when the server dies)
<Saviq> alan_g, got it
<tvoss_> alan_g, for kdub's branch: could you give it a more detailed review before kdub fixes the tests?
<alan_g> tvoss_: that was my plan
<tvoss_> alan_g, thx, would help a lot
<Saviq> tvoss_, btw, https://bugs.launchpad.net/unity8/+bug/1238645 is apparently valid for mir/qtubuntu/somewhere
<ubot5> Ubuntu bug 1238645 in Unity 8 "Shell does not get autopilot keyboard input if maliit isn't running" [Undecided,In progress]
<tvoss_> Saviq, looking
<Saviq> tvoss_, and I think we're seeing the result of it https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-maguro/2412/?#showFailuresLink
<Saviq> even with the workaround that we have
<Saviq> or workaround--, but upstart++ starting maliit-server for us
<tvoss_> hmmm, so key events are sent via uinput?
<ogra_> just add an env var check to maliits upstart job
<ogra_> make it a no-op if the var is set ... export it from AP
<tvoss_> Saviq, what ogra_ said ^?
<Saviq> tvoss_, yes they are
<Saviq> ogra_, it's not about maliit not being started
<Saviq> ogra_, it should be unrelated
<ogra_> ah, k
<ogra_> i thought maliit blocks uinput
<tvoss_> ogra_, that's actually an interesting idea. Saviq, didn't we see the permissions on /dev/uinput change recently?
<Saviq> tvoss_, well, yeah, it changes to "bluetooth" for me
<Saviq> tvoss_, but works regardless of that
<Saviq> i.e. perms no perms, if maliit is working - input is delivered (generally - as we can see there are still failures) - if not - no
<tvoss_> Saviq, ack, looking into it
<ogra_> root@ubuntu-phablet:/# grep uinput /lib/udev/rules.d/*
<ogra_> /lib/udev/rules.d/61-autopilot-uinput.rules:# Creates autopilot group specific access to /dev/uinput
<ogra_> /lib/udev/rules.d/61-autopilot-uinput.rules:KERNEL=="uinput", SUBSYSTEM=="misc", SYMLINK="autopilot-uinput", GROUP="autopilot", MODE="0660"
<ogra_> /lib/udev/rules.d/70-android.rules:ACTION=="add", KERNEL=="uinput", OWNER="system", GROUP="bluetooth", MODE="0660"
<ogra_> Saviq, tvoss|dentist ^^^
<ogra_> i guess we should drop it from the android rules :)
<ogra_> (and if GROUP=autopilot is wrong adjust thios too)
<alf_> Saviq: I wonder if what's happening with maliit etc is that the server crashes, maliit aborts, it's respawn and then fails to connect to the non-existent mir server.
<alf_> Saviq: because, all the backtraces we have for this issue point to this happening during application (Qt platform) setup
<alf_> Saviq: in any case, the new MPs for platform-api and qtubuntu should make this clearer
<Saviq> alf_, might be indeed, am building them now
<alf_> Saviq: Unfortunately, I am not able to get maliit to crash with 'stop unity8' (tried about 20 times now). I do get https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1238116 all the time though...
<ubot5> Ubuntu bug 1238116 in unity8 (Ubuntu) "unity8 crashed with SIGSEGV in QIcon::~QIcon()" [Medium,Confirmed]
<Saviq> alf_, right, that one's solved with https://code.launchpad.net/~aacid/unity-mir/waitforme/+merge/190716
<Saviq> alf_, and it uncovered a few other bugs now indeed
<Saviq> alf_, since we're destroying stuff proper now
<Saviq> alf_, I'm just building qtubuntu now and will let you know of what changed asap
<alf_> Saviq: thanks (note you need both the MPs to see the effect)
<Saviq> alf_, yup, papi already built
<tvoss> Saviq, I do see events getting into mir with autopilot and maliit not running
<Saviq> tvoss, yeah, we need to track them up the stack
<jibel> greyback, I added a video to bug 1234538
<ubot5> bug 1234538 in unity8 (Ubuntu) "With Mir enabled - Applications randomly failed to start" [High,Confirmed] https://launchpad.net/bugs/1234538
<tvoss> Saviq, I have a gut feeling that maliit goes away and the focus chain in unity is not correctly restored or something
<greyback> jibel: thanks. That video I guess with a recent image?
<jibel> greyback, 96
<greyback> jibel: perfect, thanks. Will look
<Saviq> tvoss, if maliit is stopped *before* unity8 starts
<Saviq> tvoss, it doesn't work either
<tvoss> Saviq, hmmm ... which would then mean, that qt/qml somewhere checks if an input-method is available
<greyback> jibel: last question: that a galaxy nexus or nexus4?
<jibel> greyback, mako/nexus4
<greyback> jibel: Ok, I'll try it there.
<greyback> mzanetti: that one new to me, thanks for that
<greyback> mzanetti: is it logged? I can't find it?
<mzanetti> greyback: noticed when developing the Ubuntu Authenticator on the weekend
<mzanetti> greyback: no, didn't report it yet
<mzanetti> greyback: it doesn't really hit users, but it
<mzanetti> is annoying for app developers
<greyback> mzanetti: every fix is a good fix
<davmor2> mzanetti: what issue is that?
<mzanetti> davmor2: run an app from the command line, lock the screen, press ctrl+c to stop the app, unlock the screen -> Boom!
<tvoss> Saviq, got it
<Saviq> alf_, so yeah, "FATAL: QUbuntu: Could not create application instance", but still getting crashes
<Saviq> alf_, and/or unity8 locking up
<Saviq> collecting .crashes now
<alf_> Saviq: ok, so if the hypothesis is correct, the "FATAL: QUbuntu: Could not create application instance" should be from the second (respawned) run of maliit-server. Can we verify this, e.g., by getting the stack trace of the first run if it crashed, or some kind of upstart log?
<Saviq> alf_, I can get you both, yeah
<Saviq> alf_, I can also get you packages I'm seeing that in, if you want them
<alf_> Saviq: yes, a cross check with what I have would be good, since I can't get the crash...
<Saviq> alf_, so... http://people.canonical.com/~msawicz/repo.tar.gz  - still uploading
<Saviq> alf_, that is:
<Saviq> mir + https://code.launchpad.net/~kdub/mir/android-buffer-syncfence/+merge/189717
<Saviq> platform-api + https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-more/+merge/190908
<Saviq> qtubuntu + https://code.launchpad.net/~afrantzis/qtubuntu/fix-1233988-more/+merge/190907
<Saviq> unity8 + https://code.launchpad.net/~unity-team/unity8/ap_launch_unity_with_upstart/+merge/190886
<Saviq> session-manager-touch + https://code.launchpad.net/~saviq/session-manager-touch/drop-unity8
<Saviq> Friday's unity-api + https://code.launchpad.net/~aacid/unity-mir/waitforme/+merge/190716
<Saviq> alf_, you can just add it as a repo in sources.list and upgrade from it
<Saviq> alf_, you can disregard unity8 and session updates, though
<Saviq> alf_, will ping you when it uploads
<Saviq> alf_, https://bugs.launchpad.net/ubuntu/+source/maliit-framework/+bug/1239712 here is the current trace
<ubot5> Ubuntu bug 1239712 in maliit-framework (Ubuntu) "maliit-server crashed with SIGABRT in raise()" [Undecided,New]
<Saviq> alf_, uploaded
<mlankhorst> hm
<mlankhorst> I think I understand the gbm fail
<mlankhorst> this makes it a bit harder though
<alf_> mlankhorst: what's the cause for the gbm fail?
<mlankhorst> the gbm piping expects a gbm surface type
<mlankhorst> but I think it can be workarounded..
<mlankhorst> hold on
<mlankhorst> in particular the createNewDrawable call, I'm writing a workaround atm..
<mlankhorst> well that was easy
<mlankhorst> now both work
<mlankhorst> http://paste.debian.net/57430/ gg hf kthxbye
<mlankhorst> the #if 0 code can be removed or kept, it works either way
<mlankhorst> alf_/RAOF: ^
<alf_> mlankhorst: \o/, so this fixes the nested mir case totally?
<mlankhorst> it fixed eglflash unnested for me, so I would assume so
<alf_> mlankhorst: awesome, I will try when the phone drops in priority, probably near EOW
<mlankhorst> the code inside #if 0 was the former default, the #if 0 simply allowed me to test any client without starting nested mir
<alf_> mlankhorst: is the diff against egl-platform-mir-egl-image-i965-experiment ?
<mlankhorst> hm no it's a diff against my previous diff :P
<mlankhorst> I think I had some changes on top
<mlankhorst> alf_: yeah, apply this one first http://paste.debian.net/57441/
<alf_> Saviq: with your packages what I am seeing is that the maliit-server crash is happening when starting up 'start unity8' not when stopping, reinforcing that maliit tries to connect too soon, fails/aborts, gets respawned and manages to connect
<alf_> Saviq: can you verify that you get a maliit crash after 'start unity8' and not after 'stop unity8'?
<Saviq> alf_, trying
<Saviq> alf_, it'd make sense indeed
<tvoss> kdub, hey there :)
<kdub> hello tvoss
<tvoss> kdub, so you are the most wanted person today :)
<tvoss> kdub, would be great if you could jump on fixing the test failures on https://code.launchpad.net/~kdub/mir/android-buffer-syncfence
<tvoss> kdub, if that is fixed, we could land the branch
<kdub> yep, #1 on the list for today
<tvoss> kdub, cool
<tvoss> kdub, let me know if I can help
<Saviq> alf_, confirmed
<Saviq> alf_, /me adds "sleep 2" to maliit job...
<Saviq> damn
<Saviq> alf_, yeah, confirmed
<Saviq> alf_, could we not SIGABRT when can't connect to server?
<Saviq> ogra_, can we add "sleep 2" to maliit-server before starting?
<ogra_> ergh, why is that
<ogra_> that adds 2 secs to the session startup, can you solve it in any other way ?
<ogra_> (i just spent two weeks to get the boot below 30sec again)
<Saviq> ogra_, maliit starts too early
<Saviq> ogra_, Mir in unity8 isn't yet ready
<ogra_> Saviq, then fix unity to not tell upstart it is started when it is notz
<Saviq> ogra_, how?
<ogra_> make it wait ? dunno
<ogra_> did you try different expect lines for the upstart job (and did you check the double fork stuff etc as explained in the upstart cookbook)
<Saviq> ogra_, nope
<Saviq> ogra_, we're not forking at all, though
<Saviq> ogra_, we're not daemonizing
<Saviq> ogra_, but will look through upstart cbook
<ogra_> please ask slangasek how to do it right then
<ogra_> i think he can help here
<ogra_> (or if slangasek isnt around, probably xnox or stgraber can help they are both upstart aces :) )
<ogra_> (or even jodh as upstart upstream)
<xnox> hm?
<ogra_> xnox, the unity8 upstart job seems to return before unity8 is actualyl ready ... causing dependent jobs to start to early
<xnox> ogra_: invoke tedg =) unity8 should emit started unity8, until ready =)
<xnox> ogra_: if there is a dbus known-name that unity8 exports, jobs can start on started that.
<xnox> ogra_: thanks to the dbus bridge.
<tedg> Or we could ask unity8 to emit sigstop when ready and have the job wait on that.
<tedg> I believe upstart has a mode for that.
<ogra_> well, any kind of landmark will do i guess
<tvoss> xnox, would initctl emit --no-wait unity8_ready (in unity) with a corresponding start on unity8_ready in maliit upstart conf work?
<tvoss> Saviq, ^
<ogra_> i'm just opposed to add sleeps back into upstart jobs
<tedg> Yup, here it is: http://upstart.ubuntu.com/cookbook/#expect-stop
<xnox> tvoss: sure, but also ugly. And please add "emits unity8_ready" in the unity8.conf, for documentation purposes to know which job is expected to emit that event.
<xnox> tvoss: tedg: expect stop is far better.
<ogra_> tvoss, seriously, unity8 should just DTRT :)
<tvoss> ogra_, we are trying to find out what the right thing is :)
<ogra_> before we write 100 line upstart jobs
<tvoss> ogra_, *you* might know, but simple question: how does a process signal "I'm ready" back to upstart?
<tedg> tvoss, There seems to be three idioms used here: 1) be fast, 2) sigstop, 3) fork but not until you're ready
<ogra_> right
<tvoss> tedg, why not emit an expicit signal? sounds like the best solution in an event-based job control system? ;)
<tvoss> tedg, s/signal/event
<ogra_> tvoss, thats the sigstop ...
<tvoss> ogra_, yeah, I meant event then
<tedg> tvoss, I think it depends on the case, if it's just "when it starts" there's no reason to have anything other than the "started" signal, and we should make that better.
<ogra_> from where ?
<tedg> tvoss, For indicators I added one, and my logic there was that Unity8 may start and do other stuff before it wants the indicator services.
<tvoss> ogra_, from unity8, just calling "initctl emit --no-wait unity8_ready"
<tvoss> whenever that is the case
<ogra_> ugh
<tedg> tvoss, Then what would people use the "started unity8" event for?  It seems like we'd be wasting that one.
<ogra_> just make your binary DTRT ... if there is no expect mode for your binary behavior, ask jodh to add one
<ogra_> tvoss, i think tedg's sigstop suggestion is the best we can do as a quick solution
<Saviq> sounds clean enough, yeah
<tvoss> Saviq, if you are happy, I'm too
 * Saviq wonders when to emit it ;D
<tvoss> Saviq, whenever qtguiapplication is constructed I would think
<kdub> alan_g, alf_, pushed fixes for the unit tests... they were just test problems, no code change
<alf_> kdub: ok
<tedg> tvoss, Throw in an idle event, then the first time you hit the mainloop without events...
<Saviq> tvoss, don't we need to spin the loop?
<alan_g> kdub: @ServerShutdown/OnSignal.* - can you confirm that test works fine when run on its own? (I've seen similar problems on the desktop - https://code.launchpad.net/~alan-griffiths/mir/fix-client-hang-on-server-death/+merge/190935/comments/438530)
<kdub> testing... one minute
<tvoss> Saviq, not sure ...
<kdub> alan_g, yes, with running the test on its own, I see it pass in 2-3 seconds, when ran with the group, it appears to hang
<alan_g> kdub: thanks (I'm trying to track down the interaction - at least this should require the same fix)
<tvoss> ogra_, can upstart check if a file exists?
<ogra_> tvoss, yes, with the file bridge
<ogra_> (as long as it is a regular file)
<tvoss> ogra_, yup, we just need to check if we are running on mir
<Saviq> ogra_, can we check if file && socket exist?
<ogra_> Saviq, socket is tricky
<ogra_> file is easy
<Saviq> ogra_, basically, if [ -e ~/.display-mir ] wait_for(/run/user/32011/mir_socket)
<ogra_> Saviq, and on my tablet where i have two users ? :)
<tvoss> ogra_, I don't think that's a valid use-case right now
<ogra_> tvoss, Saviq is adding the SIGSTOP in the code right after the file creation not an option ?
<tvoss> ogra_, I think Saviq is looking for a way to live without the sigstop for now
<ogra_> :(
<Saviq> no I'm not
<Saviq> I'm just looking for a good way to do it
<Saviq> and asking *when* to safely emit the sigstop
<Saviq> I'm fine with emitting it wherever - but someone knowing Mir needs to tell me when is it safe already
<alf_> tvoss: Saviq: (async ping for a review of https://code.launchpad.net/~afrantzis/qtubuntu/fix-1233988-more/+merge/190907 and https://code.launchpad.net/~afrantzis/platform-api/fix-1233988-more/+merge/190908)
<Saviq> alf_, is this ping cancellable?
<Saviq> alf_, you got a +1 from me 30s ago :)
<alf_> Saviq: the .wait() will just return immediately, no need to cancel :)
<Saviq> :)
<tvoss> alan_g, alf_ do we signal back to mir if the communicator is ready to take connections?
<tvoss> alf_, approved and top-approved
<alan_g> tvoss: Who is this "mir" you refer to
<tvoss> alan_g, the "rest" of the system, and the shell sitting on top
<alan_g> tvoss: the connector is ready as soon as "start()" returns - what other signal do you want?
<tvoss> alan_g, ack. Saviq, would that help?
 * Saviq looks
<Saviq> greyback, help
<greyback> Saviq: whassup?
<Saviq> greyback, in unity-mir, are we calling start() anywhere explicitly?
<alan_g> tvoss: Saviq connector->start() is called in DisplayServer::run() before main_loop->run()
<greyback> Saviq: no
<Saviq> greyback, we're trying to find a place to emit a SIGSTOP for upstart to know we're ready
<Saviq> to accept client connections
<Saviq> greyback, any ideas where to put it?
<greyback> run_mir ?
<Saviq> greyback, and that is called where?
<greyback> Saviq: called by unity-mir, in QMirServer::runWithClient
<Saviq> greyback, mhm, so basically just before returning from main()_
<greyback> Saviq: yeah. That too late?
<Saviq> greyback, no, not unless it's unity-mir that emits the SIGSTOP
<Saviq> greyback, since we can't do it in unity8's main, as we're looping there
<greyback> Saviq: it /could/
<greyback> but seems to be something that Mir should do, no?
<ogra_> greyback, mir isnt started by upstart
<Saviq> ogra_, it is ;) unity8 == mir
<Saviq> greyback, we'd need it for sflinger, too
<ogra_> greyback, the prob we try to solve is that upstart needs to know when unity is ready to only then start all the depending jobs
<greyback> ogra_: yep, that's understood. I'm trying to decide if it's Mir's job to send that signal, or instead the user of Mir (i.e. unity8) does it
<Saviq> greor well
<Saviq> greyback, that means we should be able to emit it in startShell, no?
<greyback> Saviq: yes
<Saviq> greyback, since by that time mir will be running already
<Saviq> orks
<greyback> yep, that'll work
<greyback> and yeah, I'm fine with that
<ogra_> greyback, the PID that upstart fired up needs to return the info
<Saviq> ogra_, it's the same PID
<Saviq> ogra_, there is no separate process for Mir
<ogra_> greyback, (i dont care about internals the SIGSTOP needs to come from unity itself)
<ogra_> oh, ok
<ogra_> well then whatever :)
<greyback> ogra_: mir is just a library, unity8 loads it.
<greyback> :)
<Saviq> ok, /me emits in startShell()
<Saviq> but first - food
<tvoss> Saviq, enjoy :)
<ogra_> yay
<ogra_> :)
<alf_> Saviq: greyback: Reading the code I don't think startShell will do
<alf_> Saviq: greyback: the startShell is invoked through a thread which is called in the *init_server* callback of run_mir
<Saviq> alf_, ;(
<alf_> Saviq: greyback: the server object will have been created at the point, but not run
<alf_> Saviq: greyback: server objects
<Saviq> ok, you guys talk, me really food
<alf_> Saviq: greyback: I think the sanest way is for the shell server configuration to subclass the Connector class and override start() to emit the signal after calling the parent start()
<greyback> alf_: well I expected the server to be running, as startShell creates a mir client which connects ok
<Saviq> greyback, yeah, but only when we exec(), no?
<Saviq> greyback, so it might be sheer luck
<alf_> greyback: Isn't that an inprocess client? It doesn't go through the socket I think.
<greyback> alf_: aha
<alan_g> alf_: there are probably saner ways
<greyback> ok yes I see startShell will be called before server.run()
<racarr> Morning
<alan_g> Evening
<greyback> alf_: yes your suggestion would work. alan_g what's a better way?
<alf_> alan_g: probably, but without changing the mir code?
<alf_> greyback: alan_g: ideally, we could emit some kind of event when the server starts up fully, e.g., by injecting an event in our main_loop?
<alan_g> alf_: The thing is that implementing Connector (as a proxy for the_connector()?) only tells about part of the initialization
<alan_g> I'd imagine implementing MainLoop would be better - as everything is started by the time run() is called.
<alan_g> But really I think there should be some sort of status notification (and also for pause/resume)
<tvoss> alan_g, +1
<greyback> +1
<alf_> alan_g: so extending pause_resume_listener I guess
<alan_g> alf start_pause_resume_stop_listener?
<alf_> alan_g: server_status_listener?
<alan_g> alf_: lgtm
<alf_> alan_g: ok, tomorrow then :)
<kgunn> alf_: you approve kdub's fence improvements now too ?
<alf_> kgunn: yeap, thanks for reminding me
<alf_> kgunn: done
<kgunn> alf_: efharisto
<tvoss> kgunn, wow, I'm impressed
<alan_g> "ÎÏÏÎ±ÏÎ¹ÏÏÏ" would be impressive
<kgunn> :) ...i'll let that merge...gonna run, then i'll do the all the prep to get it in
<racarr> tvoss: So was there practice ont he static initialization dealio
<racarr> progress&
<racarr> *
<tvoss> racarr, nope, I think we need to transition papi over to gcc 4.8
<tvoss> racarr, post v1, though
<racarr> tvoss: Hmm ok
<om26er> is there a ppa for Mir development branch somewhere ?
<thomi> morning
<racarr> Morning thomi
<kgunn> racarr: would you mind a review & hopefully approve of https://code.launchpad.net/~mir-team/mir/bump-deb-changelog14-mirserver6/+merge/189990
<kgunn> racarr: oops
<kgunn> sorry...wrong link
<kgunn> racarr: i meant this one https://code.launchpad.net/~mir-team/mir/bump-deb-changelog15-mirserver7/+merge/191029
<racarr> kgunn: oi
<racarr> kgunn:  looks ok to me
<kgunn> racarr: gracias
<racarr> thomi: How can I use autopilot and a python console
<racarr> to make key events :D
<thomi> racarr: like this:
<thomi> from autopilot.input import Keyboard; kbd = Keyboard.create(); kbd.type("some text")
<thomi> or: kbd.press_and_release("Delete")
<thomi> ... for "special" keys etc
<racarr> thomi: Perfect. Thanks
<kgunn> racarr: ok...one more...merging from dev to trunk...mind approving https://code.launchpad.net/~mir-team/mir/development-branch/+merge/191055
<kgunn> robert_ancell: hey...was just merging to trunk, how did duflu know there were merge conflicts that one time ?
<robert_ancell> kgunn, the MP in Launchpad showed errors
<robert_ancell> that one does not
<kgunn> robert_ancell: that's what i thot....was just double checking
<kgunn> what does it look like ?? yellow or something in the diff ?
<kgunn> robert_ancell:
<robert_ancell> kgunn, there are errors in the diff, i.e. "===" "<<<" type things
<kgunn> robert_ancell: ah!! thanks...
<robert_ancell> but also the list of files with conflicts is at the top under the "Merge Into" heading
<kgunn> robert_ancell: same as when you do merge on bzr
<robert_ancell> or somewhere nearby that
<robert_ancell> yes
<racarr> kgunn: mergemergemerge
<kgunn> racarr: thanks dude
<racarr> kgunn: Do you know of a bug # for the thing where autopilot tests and sometimes apps
<racarr> are getting
<racarr> extra key events?
<kgunn> racarr: let me dig one moment
<kgunn> racarr: i don't see a bug like that...was it reported against a specific app ?
<racarr> kgunn: I'm not sure it ever was
<racarr> its just shown up in a bunch of autopilot tests failures
<racarr> somewhat intermittently it seems
<racarr> and apparently riccm ses it on real usage sometimes
<racarr> ill sync with him when he gets back
<kgunn> racarr: cool...do you have a fix ? or you're just aware of it as a legit problem ?
<kgunn> racarr: maybe log a bug to track ?
<racarr> kgunn:  https://code.launchpad.net/~robertcarr/platform-api/fix-event-translation/+merge/191059 hopefully a fix :)
<racarr> kgunn: I think the remaining half of the autopilot keyboard issues
<racarr> is just key repeat...
<racarr> since the OSK doesn't use this code path
<racarr> or X mir -.-
<racarr> I am trying to decide
<racarr> if it's ok to just turn off key repeat
<racarr> for now
<racarr> basically autopilot presses, releases key, maybe that takes a long time to run
<racarr> you get repeats
<kgunn> racarr: ok...you're saying turn off key repeat only for AP's ?
<kgunn> i would think folks would probably wig out if you turned it off all the time
<racarr> well the thing is, then we would have to add it as an option, etc which is more stuff
<racarr> but really
<racarr> xmir uses it's own input, so it doesnt change xmir
<racarr> the osk uses the seperate codepath so it doesn't change the osk
<racarr> Is there actually any using
<racarr> mir input with physical keyboards
<racarr> for 13.10?
<racarr> I guess it doesn't hurt to just make it an option...
<racarr> thomi: IF we make a mir option for disabling key repeat, can things be set up so all the autopilot runs configure mir this way?
<racarr> press("K") release("K") is always a race with key repeat enabled
<thomi> racarr: but aren't key repeats at that level handled by separate key repeat events?
<thomi> racarr: also, I'm not sure what the key repeat timeout is set to in mir, but if you look at the autopilot logs, the press & release events are pretty close together.
<racarr> thomi: In cases where we get extra events I mean?
<racarr> thomi: No what the timeout is set to, there is always a case
<racarr> press("K")
<racarr> autopilot gets preempted
<racarr> stuff happens
<racarr> release("K) happens after the timeout
<racarr> you get repeat.
<thomi> racarr: right, but I'm saying that the AP logs look like the press and release happens pretty close together.
<thomi> hmmmm
<thomi> veebers: perhaps we should just turn on the OSK backend by default?
<thomi> oh, right - he went to the gym
<racarr> thomi: I guess it's a half second
<racarr> I don't know if it's really key repeat causing this...there was also this other bug that the fix-event-translation bug above is about that could be pretty related
<thomi> racarr: so... can you actually reproduce this, or are you guessing that this is the cause?
<veebers> thomi: I'm just out the door now, right now the OSK backend won't work until this MR is merged: https://code.launchpad.net/~veebers/ubuntu-keyboard/update_autopilot_emulators/+merge/190319
<racarr> so unless we have some logs of test failures with the duplicated events and key press differences greater than .5 second (where can I find such detailed logs/produce them myself?)
<veebers> thomi: so I'm gonig to approve it now
<veebers> going*
<racarr> thomi: No! Just guessing. I can't reproduce it at all
<thomi> racarr: ahh, ok
<thomi> racarr: I'd be surprised if we saw > 500ms lag between press and release
<thomi> not saying it can't happen, but...
<thomi> I think something else is at fault here
<racarr> mm
<racarr> maybe it was fix-event-translation *Crosses fingers*
<racarr> i need to find a test I can trigger it on and
<racarr> dig down
<racarr> it seems like it can show up in ubuntu-ui-toolkit so ill try that over and over again :p
<racarr> out for some excercise brb
<racarr> perhaps really more of a bbiab situation :p
<lool> mir building in PPA
#ubuntu-mir 2013-10-15
<lool> /!\ Mir FTBFS in PPA
<lool> racarr: https://launchpadlibrarian.net/153780284/buildlog_ubuntu-saucy-amd64.mir_0.0.15%2B13.10.20131014-0ubuntu1_FAILEDTOBUILD.txt.gz
<lool> it's this flaky new test
<lool>  10/155 Test  #10: acceptance-tests.ServerShutdown/OnSignal.* .............................***Failed    0.02 sec
<lool> I've retried the builds
<lool> but this is no good
<lool> kgunn: ^
<kdub> lool, alan_g was looking into that towards the end of euro-day
<lool> failed again
<lool> it's kind of unfortunate because it built on armhf
<lool> and that will block other builds like the platform-api fix
<lool> ok, succeeded on 3rd try
<racarr> lool: Yay. Thanks
<lool> racarr: would still be good to fix this  :-/
<racarr> lool: I know I think Alang is working on it
<lool> unity-system-compositor and platform-api now in PPA
<racarr> lool: I think we should get some good autopilot runs when it runs :D
<lool> yeah
<lool> especially with the keyboard fix
<racarr> Mm :D
<RAOF> mlankhorst: What ended up being the problem with nested? I'm trying to rework it to remove the bonghits involved in mystically passing around a gbm_device *.
 * duflu wonders what said "bonghit" looks like in code
<tvoss> good morning
<RAOF> tvoss: Good morning!
<tvoss> RAOF, hey there :) how goes?
<RAOF> Acceptably.
<RAOF> Thinking about foreign surfaces, still trying to figure out precisely what mlankhorst's patches for nested-gbm actually *do*, so we can make the nested code less maniacal, the usual.
<duflu> Maniacal is fun, in small portions
<RAOF> I'm a fan of not doing http://bazaar.launchpad.net/~afrantzis/mir/spike-nested-gbm-egl-image-hack/view/head:/src/server/graphics/nested/nested_platform.cpp#L59 and http://bazaar.launchpad.net/~afrantzis/mir/spike-nested-gbm-egl-image-hack/view/head:/src/server/graphics/gbm/native_gbm_platform.cpp#L37
<tsdgeos> guys
<tsdgeos> what's calling mir::graphics::android::MirNativeWindow::dequeueBuffer ?
<tsdgeos> i can't seem to grep-find what calls it
<tsdgeos> but i have a thread here that is doing it
<tsdgeos> so someone is :D
<tsdgeos> #25 0x42aad0c4 in mir::graphics::android::MirNativeWindow::dequeueBuffer (this=<optimized out>, buffer_to_driver=0x5219b970) at /build/buildd/mir-0.0.14+13.10.20131011/src/shared/graphics/android/mir_native_window.cpp:165
<tsdgeos> #26 0x4468ab0e in ?? ()
<tsdgeos> #27 0x4468ab0e in ?? ()
<alf_> tsdgeos: AFAIK, it's called only by the driver. We pass this to the android drivers, as part of our custom native window implementation.
<om26er> duflu, hello! when your second branch lands re: bug 1227739 is someone working on using those changes in unity-mir or platform-api ?
<ubot5> bug 1227739 in Mir "Mir continues to render background application surfaces even when they're not visible" [High,In progress] https://launchpad.net/bugs/1227739
<tsdgeos> alf_: i see
<duflu> om26er: The main fix for Mir isn't even proposed yet. Those awaiting review are just prereq enhancements. But no, no one is assigned the platform-api task.
<om26er> duflu, that means you have another branch inprogress ?
<tsdgeos> alf_: thing is, if i shutdown unity+mir when nothing is moving, it's all fine, if i shut it down while some animation is going on (i.e. there's painting) this is one of the threads that seems to be kept alive
<duflu> om26er: Yes. It's blocked by the one still awaiting review (because I fear it could be rejected so don't want to complete the fix based on that)
<tsdgeos> can't totally blame on it, but i wonder who is supposed to tear it down
<om26er> duflu, ok, thanks.
<tsdgeos> btw, if the comment in https://code.launchpad.net/~aacid/mir/fix_mismatched_delete/+merge/190885 is true shouldn't the CI job be fixed so that it merges the target before running CI?
<alf_> tsdgeos: Mir should be tearing the graphics subsystem down. A couple of things could be going wrong here: 1. Mir is not tearing down correctly 2. Mir is not tearing down at all, because e.g. the shell is still holding a shared_ptr to a Mir resource/subsystem
<tsdgeos> alf_: mir is teared down
<tsdgeos> or looks like it to me
<tsdgeos> at least mir::run_mir has returned
<tsdgeos> of course that doesn't mean it has tearned down properly or much i guess :D
<alf_> tsdgeos: what I mean is that if e.g. the shell is holding a strong pointer to Mir's graphics subsystem, the server will be torn down, but the graphics subystem will not be uninitialized
<alf_> tsdgeos: at least not at the right time
<tsdgeos> alf_: but that "not tearing down" problem only happens when there's an animation running
<tsdgeos> if all is static it works
<tsdgeos> i don't see us holding an extra resource when animating
<tsdgeos> which may be of course :D
<tsdgeos> maybe just still haven't found that bit of code
<alf_> tsdgeos: yeah, I am not sure either, just guessing, trying to give some leads :)
<tsdgeos> sure :-)
<alf_> tsdgeos: I know that unity-mir is holding a shared_ptr to a MirSurface, which may be related to this problem. So one possible scenario is: mir server is torn down, graphics torn down, but the MirSurface (which is backed by a "native window" used by the driver) is not destroyed because shell/qt/qml is still trying to use it
<tsdgeos> may be
<alf_> tsdgeos: valgrind may give you more hints about what is going on there
<tsdgeos> i does actually hang/deadlock while we are deleting the window
<tsdgeos> i.e. i successfully leave qt's event loop
<tsdgeos> and when i try to delete the window
<tsdgeos> it goes deep in somewhere
<alan_g> duflu: I didn't get a chance to look at lp:~mir-team/mir/verify-MirConnection - is it still a problem?
<duflu> alan_g: Not really. I'm now questioning the whole exercise. Might be best to reconsider all libmirclient error handling semantics post-saucy
<duflu> Because we need to halt broken clients and show them where they're broken... but that conflicts with the existing design of allowing invalid connection handles to many functions. And in many cases silently ignoring them
<alan_g> duflu: OK. What we've implemented isn't self-consistent
<duflu> alan_g: Correct
<duflu> alan_g: I think we need to detect bad parameters and crash the client immediately. But that's enough of a semantic change I'm struggling to call it a "fix" we could squeeze into saucy
<alan_g> duflu: I think it is too big a discussion for this week. But I agree the broad principle
<duflu> alan_g: https://bugs.launchpad.net/mir/+bug/1239978
<ubot5> Ubuntu bug 1239978 in Mir "libmirclient does not validate/verify parameters to API calls" [High,New]
<alf_> Saviq: Do you also need a "stopped" event from mir? Returning from run_mir is essentially a "stopped" event.
<Saviq> alf_, not right now, but dunno if it'll be needed later by something
<alf_> Saviq: My plan is to add "started" for now. If we need it it can be trivially added.
<alf_> Saviq: (stopped)
<Saviq> alf_, +1
<tjaalton> the xorg packages keep getting xmir related crashes all the time, and I doubt those will get fixed as sru?
<duflu> tjaalton: True. It would only be a big problem if the crashes can't be easily de-duplicated though... ?
<tjaalton> de-duplicated? i've no idea which ones are related to which
<duflu> tjaalton: I mean we can deal with it so long as there's sufficient stack info for you to know it's a Mir bug... and then for us to recognize which Mir bug
<tjaalton> i mean, shouldn't there be a word sent out that anyone sticking to saucy should just disable xmir?
<tjaalton> oh I can recognize xmir from ProcCmdline
<duflu> tjaalton: That's a nice thought but in the world of Ubuntu, users will constantly customize and experiment even when we suggest not to
<tjaalton> so that's fine, but the bug view is getting cluttered with all these bugs with '[xmir]..' :)
<duflu> tjaalton: Is it? Are they correctly assigned to the xmir project?
<tjaalton> no
<tjaalton> crashers are sent to xorg-server
<tjaalton> it's a manual process after that
<duflu> tjaalton: I know how that is. Spent most of the past could of years dealing with Unity crashes landing in Compiz :/
<tjaalton> although xdiagnose could be smarter..
<tjaalton> now that I think of it
<duflu> tjaalton: If you could automagically bump them to the xmir project then we'd see them and help with the triage
<tjaalton> yeah I'll see if it can be done
<tjaalton> depends on apport I think
<asac> it would be nice if Mir team could run apt-get install ubuntu-ui-toolkit-autopilot + phablet-test-run ubuntuuitoolkit and see what happens
<asac> (something bad, in short, after a couple of minutes)
<asac> err
<asac> "it would be nice if Mir team could run apt-get install ubuntu-ui-toolkit-autopilot + phablet-test-run ubuntuuitoolkit and see what happens
<asac> (something bad, in short, after a couple of minutes)"
<asac> kgunn: ^^
<asac> thats again uncovered/triggered by MIR landing still
<tvoss> asac, do we have any more detail on what is going wrong?
<asac> tvoss: no its misty dark
<asac> tvoss: you run the APs one by one its kind of working... but if it runs all in one shot it will stall completely
<tvoss> asac, okay
<tvoss> asac, any reason we suspect mir and not u8?
<asac> tvoss: so unity8 could be the candidate, but since mir landing started regressing all the tests
<asac> its the first stop for every issue until we have managed to get the rest to green once
<asac> then we can more easily blame the right folks again
<asac> tvoss: if you feel its u8 from the looks, lets have Saviq also check
<asac> Saviq: sdk team tests:
<asac> 11:04 < asac> "it would be nice if Mir team could run apt-get install ubuntu-ui-toolkit-autopilot +  phablet-test-run ubuntuuitoolkit and see what happens
<tvoss> asac, reflashed phone, testing now
<tvoss> asac, just saying that both the Mir team and the U8 team should look into regressions to be more efficient
 * Saviq checks
<asac> tvoss: yeah. good news is that mir team is in the same team as unity8 :)
<asac> so... :)
<Saviq> asac, except we're not ;)
<asac> we put them organizationally close to each other for such cases
<asac> Saviq: both report to kgunn ... who spans this bigger team
<alf_> greyback: https://code.launchpad.net/~afrantzis/mir/server-started-notification/+merge/191134 , let me know if this is enough for you
<greyback> alf_: looks reasonable, will test it out in ~1 hour
<alf_> greyback: ok
<alan_g> duflu: shall we move the "privatize" and "tidy-up" branches to WIP for the time being?
<duflu> alan_g : Yeah "Resubmit" for when we have a T-series branch
<tvoss> alf_, got an eta on https://code.launchpad.net/~afrantzis/mir/server-started-notification/+merge/191134
<tvoss> ?
<tvoss> alan_g, ping
<alan_g> tvoss: ?
<tvoss> alan_g, hey, so we are seeing slowdown of rendering after multiple app starts/stops in autopilot test scenarios
<tvoss> alan_g, as I have seen some mp's for ensuring correct session deconstruction recently, could you check if we actually clean up sessions, their surfaces and buffers?
<tvoss> alan_g, I have a gut feeling that we somehow have closed sessions alive in mir/unity8
<alan_g> tvoss: you mean like the one I wasn't convinced cleaned sessions up?
<tvoss> alan_g, yup :)
<tvoss> alan_g, perhaps we can prove with a simple cout in the session/surface d'tor?
<alan_g> tvoss: have you tried enabling the session mediator report?
<tvoss> alan_g, nope, not yet
<tvoss> Mirv, didrocks again, to establish a baseline: how do we run the uitk testsuite?
 * alan_g realizes that won't prove anything
<didrocks> phablet-test-run ubuntuuitoolkit
<Mirv> tvoss: flash, apt-get install ubuntu-ui-toolkit-autopilot on device, run phablet-test-run ubuntuuitoolkit
<tvoss> Mirv, didrocks thx
<alan_g> tvoss: is is probably ms::surfaces that need to be cleaned up - and it is entirely possible that unity hangs onto them after the session closes. (We need a surface manager report)
 * alan_g hasn't looked at the unity code for a long time - "possible" is not an accusation
<tvoss> alan_g, can you help me and look into that?
<alan_g> tvoss: I'm going to knock up a quick report from surface manager and first try a basic mir server. If that's clean I'll try dropping it into u8
<tvoss> alan_g, +1, and many thanks
 * alan_g hates interruptions
<alan_g> tvoss: the ownership of surfaces is such a mess that I can't spot an effective place to report on it. Digging...
<alf_> tvoss: I am the submitter, you should ask the reviewers :)
<alf_> tvoss: ah, you mean about the fix, working on it
<tvoss> alf_, sorry, ENOCONTEXT ;)
<alf_> tvoss: @eta for server-started-notification
<tvoss> alf_, ah, thanks
<dandrader> alf_, Since you have a recent fix in qtubuntu I suppose you've also built it in your device recently. I'm trying to build it myself but I'm getting these errors: http://paste.ubuntu.com/6240031/  I should have all the needed  libraries installed as I've run "apt-get build-dep qtubuntu"
<dandrader> any ideas?
<alf_> dandrader: the build command is not linking against -lEGL, but I don't know why that is, I didn't have any problems with it
<dandrader> alf_, so it's not "-lGLESv2"?
<alf_> dandrader: that is only GLES 2, you also need to link against EGL
<dandrader> alf_, ah, ok. "EGL", "GLES", they look so similar. :)    thanks for the hint!
<Mirv> congrats on the performance improvements (the situation after a fresh boot), extremely nice. scrolling not hitch free yet, but that's probably a combination of many factors.
<Mirv> but it's night-and-day difference in swiping between lenses or indicators with the new mir
<tvoss> Mirv, thanks :) all credit to kdub :)
<alf_> kdub: ^^ \o/
<om26er> racarr, ping
<tvoss> Mirv, which image will have the performance fix?
<Mirv> tvoss: it's now in release pocket (since 0.5h), so the next one. I assume the number is #98.
<mlankhorst> RAOF: see the patch I wrote
<mlankhorst> RAOF: basically the GBM allocator expected a gbm_surface
<mlankhorst> and then it passed gbm_surface->dri_private to the mir call
<mlankhorst> RAOF: look at the forwarding calls defined in src/gbm/backends/dri/ for dri2_loader_extension
<mlankhorst> dri_get_buffers_with_format  dri_flush_front_buffer dri_get_buffers
<om26er> Mirv, when do we spin a new build ?
<Mirv> om26er: ask ogra_ or didrocks
<ogra_> om26er, once everything planned is in the archive
<om26er> <<<answered>>>
<alf_> greyback: did you get a chance to try the server-started-notification branch with unity(-mir)?
<greyback> alf_: just compiling now
<alf_> greyback: ok
<greyback> alf_: well I've tried your branch, I get a started() call, but I'll have to trust you that it happens when mir is ready to get client connections
<alf_> greyback: Trust me, I know what I am doing https://www.youtube.com/watch?v=nnwWKkNau4I
<greyback> alf_: :D
<Saviq> ogra_, https://code.launchpad.net/~saviq/unity8/raise-sigstop/+merge/191212 looking sane for the SIGSTOP?
<ogra_> Saviq, awesome !
<alan_g> tvoss: The mir code doesn't leak surfaces. I'll have to update my phone image to investigate further - here's the code if it helps you: https://code.launchpad.net/~alan-griffiths/mir/draft-surfaces-report/+merge/191215
<Saviq> ogra_, so... that makes us pause when ran by hand... any way we can detect we're running under upstart?
<Saviq> ogra_, to only emit it if we are?
<Saviq> hmm we could set an env var
<ogra_> Saviq, one sec ... meeting ...
<Saviq> ogra_, we went for $UPSTART_JOB == "unity8"
<ogra_> Saviq, i dont really get what you are referring to
<ogra_> the above patch looks just fine
<Saviq> ogra_, if we just "$ unity8" in bash
<Saviq> ogra_, the process will pause
<ogra_> yeah you should never do that
<Saviq> ogra_, and we need to SIGCONT it (or well, "$ fg")
<Saviq> ogra_, for testing
<ogra_> use upstart to start and stop it
<Saviq> ogra_, we often need console output and stuff
<ogra_> ah, k
<Saviq> ogra_, and it's just easier to not have to go through upstart
<ogra_> yeah then add stuff to the unity8 job that reacts to an env var
<ogra_> and sets debug options etc
<Saviq> ogra_, we have that
<Saviq> ogra_, it's still easier to just ./unity8
<Saviq> ogra_, I just did if ($UPSTART_JOB == "unity8") raise(SIGSTOP);
<ogra_> well, but that wont give you the same env that the user has
<Saviq> ogra_, that seriously wrong?
<ogra_> i dont think so
<ogra_> but i think testing stuff without upstzart involved will taint your results
<Saviq> ogra_, we obviously will
<Saviq> ogra_, autopilot does, if nothing else
<Saviq> ogra_, it's just for day-to-day dev
<ogra_> right
<ogra_> ship a developer start script ;)
<Saviq> ogra_, we do ;D
<ogra_> start-unity8
<Saviq> ./run
<ogra_> ah,, good
<Saviq> ogra_, and that we'll make to use upstart
<ogra_> ok
<Saviq> ogra_, but we don't want to break the "./unity8" case unnecessarily
<ogra_> right
<kgunn> racarr, hey did you happen to look into why unwanted characters show up in text fields sometimes ? e.g. * when you hit the power button ?
<tvoss> alan_g, thanks, are you looking further
<tvoss> ?
<alan_g> tvoss: Am updating my phone image as we chat
<tvoss> alan_g, ack
 * alan_g thinks it weird the instructions haven't changed since last time
<alf_> Saviq: +1 for not breaking './unity8' case
<alf_> Saviq: if the $UPSTART_JOB scheme doesn't work, we could make unity8 read e.g. UNITY8_SIGSTOP_ON_STARTED env. variable, and set that in unity8.conf
<alf_> Saviq: when invoking unity8
<tvoss> greyback, for my mp: unity-mir already uses mir, which uses exceptions
<tvoss> greyback, also: how do you handle cases where creation of an object would result in an invalid object? with an isValid() accessor?
<greyback> tvoss: true, we can't avoid that, but it's why if mir throws an exception, unity-mir doesn't try to catch it, nor does unity8, so unity8 quits
<greyback> tvoss: yes
<tvoss> greyback, well, that's the opposite of exception safety
<tvoss> greyback, just saying :)
<greyback> tvoss: I'm not arguing, I'm just saying what we do with Qt
<tvoss> greyback, ack, I will adjust the mp. Still saying we should revisit how we consider exception safety :)
 * alan_g wonders why mir exceptions are propagating to unity on a thread Mir doesn't own
<greyback> tvoss: no objection here, as long as Qt's particulars are considered. It was written before exceptions were commonplace, so it wasn't designed to use exceptions itself. I'd love a primer on safe exception usage with Qt
<tvoss> greyback, ack
<tvoss> greyback, I left the static functions, they are at least as good as const static members
<tvoss> greyback, addressed your other comments
<greyback> tvoss: thank you
<racarr> Morning
<racarr> kgunn: I am not sure * whn you hit the powe button was a real thing...I could never reproduce it I think we fixed the other unwanted characters though, that's the thing I was pinging you about it yesterday
<racarr> reworded: We fixed some kind of unwanted character bug
<racarr> not sure about the power button
<racarr> are you sure thats a thing?
<davmor2> racarr: open terminal hit the power button you got a ? in the terminal and then a second when you powered it back on
<davmor2> racarr: let me see if it is still in place on 97
<davmor2> racarr: Ah is a * now
<davmor2> racarr: I forgot open terminal and tap it so the keyboard it up then press the power button
<davmor2> racarr: although it might be fixed by the fix you are talking about
<davmor2> racarr: does that help?
<racarr> davmor2: Yes thanks I am checking now
<racarr> it could be the bug from yesterday actually...
<racarr> as the surface loses focus
<racarr> davmor2: kgunn: Ok. it's a thing. its not the thing from yesterday actually just the key event really is going through
<racarr> and getting mapped incorrectly
<racarr> the shell needs to grab it...need to figure out how to do that with the monitor situation
<davmor2> racarr: \o/
<racarr> I really thought  I tried that last week
<racarr> wonder if I did something silly or there really is some sort of
<racarr> inconsistency to the mismapping
<racarr> *shrug*
<kgunn> racarr: thanks (sorry late response, i had an early lunch)
<racarr> s'ok
<kgunn> racarr: so the "thing" yesterday...does it potentially fix this one https://bugs.launchpad.net/ubuntu/+source/unity-mir/+bug/1238098
<ubot5> Ubuntu bug 1238098 in unity-mir (Ubuntu) "Autopilot test fails because of extra inserted characters" [Undecided,New]
<racarr> kgunn: Yes
<kgunn> sweet
<racarr> kgunn: Very hopefully...shouldn't we have new AP runs very soon
<racarr> or do we have them *checks*
<kgunn> racarr: yeah...Saviq was saying we should be down to like 1 failure on unity8 AP run
<kgunn> racarr: which means they should turn almost everything back on
<racarr> http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/mako/97:20131015:20131015/4732/
<racarr> unity8 and ubuntu-ui-toolkit finally succeeded
<racarr> which is nice
<racarr> I think the extra characters really are gone because that was killing
<racarr> ui toolkit
<racarr> filemanager and rssreader got worse?
<kgunn> racarr: cool...i'm gonna mark that fixed, was that fix in unity-mir or mir or ubuntu-keyboard
<racarr> kgunn: platform-api
<kgunn> racarr: thanks...the only one i didn't guess :)
<kgunn> wow...its getting creepy dark here in dallas....
<kgunn> storm movin' in
<racarr> kgunn: lol, and my initial guess for where it would be was
<racarr> qtubuntu
<racarr> its like some sort of bug wheel of fortune
<kgunn> :))
<kgunn> ubuntu-roullette
<racarr> kgunn: No, that's the adult themed free software chat roulette alternative
<kgunn> lol
<racarr> I want to write a phone app.
<racarr> kgunn: ricmm had a fix in the pipe for the power key stuff https://code.launchpad.net/~ricmm/unity-mir/add-keyfilter-interface/+merge/189727 we are testing, coordinating, etc :)
<kgunn> racarr: thanks
<lool> guys, just tested latest mir from image that was just published and it's *flying* much better performance with the locking changes   \o/
<tvoss> kdub, ^ \\o//
<tvoss> lool, thx
<kdub> :D
<racarr> It actually feels really smooth now :) except for the occasional
<racarr> pause
<racarr> kgunn: I think you were right with that idea you had last week that
<racarr> something happens to the animation curve when you lift
<racarr> your finger up
<kgunn> racarr: yeah..the numbers from qml timing seem to indicate that also....
<kgunn> and gerry was pretty sure there's a decelration in qt somewhere
<kgunn> which we've selected by default
<racarr> I'm not sure it's exactly that (lifting the finger actually)
<racarr> I've just been sitting here for like 5 minutes flipping the dash trying to figure out why it doesnt look right lol
<racarr> I think the thing is
<racarr> it's quite slow to accelerate, you notice just
<racarr> put your finger around an icon and quickly drag
<racarr> and the icon falls far behind your finger
<racarr> quite a bit...
<racarr> and I think
<racarr> the finger jerks in response to this haha
<racarr> i.e. my physical finger
<racarr> because if I really focus on making a smooth motion with my finger and not look at the screen as much it seems pretty smooth
<racarr> *shrug*
<racarr> it seems also like if you go really fast it will keep up
<racarr> so there must be some sort of deacceleration or some acceleration with a weird curve
<racarr> there's also something that looks strange when you
<racarr> flick fast and focus on white blocks
<racarr> like the top bar text...
<racarr> but I think that might just be...a weird effect from when the white passes over the light part of the background
<racarr> it definitely doesnt look right though
<racarr> On the other hand. It works well enough that you can investigate minor issues like this without being distracted by general system failure. Huzzah :D
<racarr> kgunn: If nothing critical comes up can I spend some time investigating the animation model? or do I need to dig in to autopilot more
<racarr> http://reports.qa.ubuntu.com/smokeng/saucy/
<racarr> build 98 is running I guess?
<racarr> ricmms branch fixes the power key thing :) just need gerry and saviq to review I guess
<Saviq> racarr, ricmm, do we know where the asterisk come from in any case?
<Saviq> like who translates PowerKey to * ?
<racarr> Saviq: Probably a combination of xkbcommon and qtubuntu...
<racarr> probably mostly qtubuntu
<racarr> by that I mean we probably have errors in both our xkbcommon mapping and the interpretation in qtubuntu
<racarr> though. it does in fact come out of xkbcommon
<racarr> mapped to volume up
<racarr> and we added that to the qt key table mapping
<racarr> so it's a little hard to say
<racarr> *thinks*
<RAOF> mlankhorst: Where's the canonical location of your patch? I don't think I've got the whole context of your changes.
<mlankhorst> RAOF: shrug I merged ubuntu debian packaging, upstream/9.2 branch
<mlankhorst> sec :P
<mlankhorst> real changes were 2 pastebins I posted here before
<mlankhorst> http://paste.debian.net/58054/ git show + git diff appended
<mlankhorst> probably applies against the egl-image*-i965 branch
<RAOF> Oh, right.
<RAOF> Because we were populating gbm_dri.
<RAOF> So that's a perfectly good fix, just one that doesn't allow me to stop passing the gbm_dri_device * through the platform.
<mlankhorst> :P
<mlankhorst> well the #if 0'd code still works
<mlankhorst> but yeah needs gbm if available
<mlankhorst> lookup extension probably sitll fails, dno if there is one or not
<mlankhorst> but it expects a gbm something
<mlankhorst> I if 0'd it for debugging, mostly
<mlankhorst> that way i can test nested mir path with a demo client
<RAOF> mlankhorst: I mean I'd prefer to do something like http://paste.ubuntu.com/6242735/ , which doesn't work, but I don't really see why not.
#ubuntu-mir 2013-10-16
<rsalveti> one interesting issue when checking mir with nexus 10
<rsalveti> bug 1203268
<ubot5> bug 1203268 in Mir "Mir fails to start on Nexus 10 as display is already unblanked" [Medium,Triaged] https://launchpad.net/bugs/1203268
<rsalveti> mir_demo_server_basic fails because unblank returns an error (already unblanked)
<rsalveti> which shouldn't be fatal
<RAOF> Mmm. 21s latency to google.com. My internet really knows how to party recently.
<RAOF> This bodes excellently for the upcoming hangout!
<tvoss> RAOF, ping
<RAOF> tvoss: Pong
<duflu> Perhaps the copper is jealous of the approaching fibre?
<RAOF> Mayhap
<duflu> Whereas my copper now needs to last till the next Labour government.
<duflu> Or something
<duflu> RAOF, hikiko hangout?
<duflu> racarr?
 * duflu assumes no kdub this time of day
<RAOF> Hm. missed the hangout?
<duflu> RAOF: just cancelled
<duflu> My audio is dead and no one other than alf turned up
<Saviq> hey guys
<Saviq> alf_, for https://code.launchpad.net/~afrantzis/mir/server-started-notification/+merge/191134
<Saviq> alf_, should we not have ABI / version bump there? so that we can depend on it?
<alf_> Saviq: no, we bump the ABI once when we merge from development-branch into lp:mir, to avoid ABI bump races (e.g. two branches increasing the ABI to the same value etc)
<mlankhorst> RAOF: have you looked at my patch? :P
<Saviq> alf_, yeah that's fine, I'm not asking straight away, but there will be a bump, yeah :)
<Saviq> alf_, any idea what can we put in Build-Depends: libmirserver-dev (>= ???) then?
<Saviq> alf_, we've >= 0.0.14 now
<mlankhorst> RAOF: but yeah using gbm as 'native' backend would be preferred for create pixmap/lookup image
<mlankhorst> makes life easiser
<mlankhorst> -s
<mlankhorst> my patch simply makes gbm creating screen not run into weird pointer issues
<alf_> Saviq: my guess is that we will go to 0.0.16 and libmirserver8, but kgunn should have a definitive answer
<Saviq> alf_, k thanks
<alf_> duflu: btw, we could reduce coupling by using a NiceMock, so that we could just expect glEnable(GL_BLEND) = 0 times glDisable(GL_BLEND) = 1 time (and perhaps expect glDrawArrays() to ensure we Disable before drawing)
<duflu> alf_: Umm, redesign the GLRenderer tests to be nicer, separately? It's done now
<alf_> duflu: ok
<tvoss> alan_g, ping
<alan_g> tvoss: hi
<tvoss> alan_g, hey there, do you keep on digging into why mir/u8 becomes slow after the uitk tests?
<alan_g> tvoss: yes, getting back to that
<tvoss> alan_g, thx
 * alan_g has broadband problems again :(
<mlankhorst> alf_: oh btw finally got around to testing nested mir, works unsurprisingly
<alf_> mlankhorst: \o/, excellent, thanks!
<RAOF> mlankhorst: I have indeed looked at your patch.
<mlankhorst> RAOF: well any work done should be on top of that as base, because it's the minimum to get gbm working ;)
<RAOF> mlankhorst: Yeah.
<RAOF> mlankhorst: I just still not convinced that getting gbm working is the appropriate goal :)
<mlankhorst> RAOF: well not sure how you want to get nested mir working otherwise..
<RAOF> You pass in a gbm_bo to create_image_pixmap_khr, you pull the __DRIImage out of it, and you dupImage() it?
<mlankhorst> RAOF: and hit the intel bug again?
<mlankhorst> or maybe similar bugs in radeon/nouveau
<RAOF> Of course, that doesn't actually *work*, but I don't see a good reason why it *shouldn't* work âº
<mlankhorst> because you create 2 instances of screen
<mlankhorst> which each have separate tracking
<mlankhorst> for the same drm fd
<mlankhorst> and there is no refcounting for gem, it's create/destroy only
<RAOF> Right, but there *is* refcounting for __DRIImage
<mlankhorst> ok fine
<RAOF> I've traced it down, and the appropriate intel_region is reffed.
<mlankhorst> libdrm/intel/intel_bufmgr_gem.c
<mlankhorst> that is where the problem was
<mlankhorst> sec
<mlankhorst> you create 2 separate drm_intel_bufmgr_gems for the same fd
<mlankhorst> create a bo against one, and validate it in the other
<RAOF> Aaaah.
<mlankhorst> this breaks down in drm_intel_add_validate_buffer2
<RAOF> *That* makes more sense.
<mlankhorst> specifically the line drm_intel_bufmgr_gem *bufmgr_gem = (drm_intel_bufmgr_gem *)bo->bufmgr;
<mlankhorst> and drm_intel_bufmgr_gem has its own dirty etc tracking that a your solution wouldn't cover, but i guess you get the point ;)
<RAOF> Boo.
<RAOF> Passing in the gbm_device is annoyingly ugly :(
<mlankhorst> it's the only solution :P
<mlankhorst> RAOF: or we could make a gbm mir backend and use platform_drm? :P
<RAOF> I was actually thinking about that.
<RAOF> Although, you know what would be easier?
<mlankhorst> dno?
<RAOF> An EGL extension inverting the problem!
<mlankhorst> creating a gbm from egl?
<RAOF> ie: rather than trying to import foreign buffers, export a buffer.
<mlankhorst> erm you still hit the same issue
<mlankhorst> same fd, can't validate it
<RAOF> No, you'd end up with it imported on a different fd.
<mlankhorst> meh just don't make life even harder, go with the solution I wrote. :S
<RAOF> Yeah.
<RAOF> Actually... isn't there already an "Export EGL image to dma-buf fd" jobby?
<mlankhorst> i thought only importing
<alf_> tvoss: alan_g: another data point about unity8 slowness after AP tests: it seems that the whole system has become slower, especially I/O. For example, apt-get install progresses awfully slowly when "Reading package lists". Stopping unity8 restores performance. So my guess is something IO related is going on.
<RAOF> Yeah.
<RAOF> You're right.
<tvoss> alf_, interesting. can you strace unity8? I think we will see some waits/polls there that shouldn't be there
<alan_g> alf_: checked the memory footprint?
<mlankhorst> fix XMir to work seamlessly first. ;)
<alf_> tvoss: I will, that what the apt-get install was for :)
<RAOF> mlankhorst: Yeah, yeah... :)
<tvoss> alf_, ;)
<mlankhorst> You still have 4 months or so. ;D
 * RAOF really really EODs
<tvoss> RAOF, bye
<mlankhorst> and good night ;)
<alf_> alan_g: tvoss:good idea, and you are probably right... I see: 980m 624m 581m
<tvoss> alf_, of unity8?
<alf_> tvoss: yes
<tvoss> wow
<tvoss> hmmm, valgrinding on the phone? :)
<alf_> tvoss: normal usage (before AP tests) is 425m  83m  48m
<tvoss> aha
<tvoss> alf_, mako or maguro?
<alf_> tvoss: mako
<alan_g> tvoss: I've played around with unity8 for a while without seeing any surfaces leaked. (Now to work out how to run the tests)
<tvoss> alan_g, ack, thx
<alf_> alan_g: tvoss: the memory piles up as new tests are being run. However, opening/closing apps manually seems to release memory normally (looking at top output). So perhaps there is something in the way that autopilot works that is causing the leaks?
<tvoss> alf_, normal = opening/closing apps from the launcher ?
<alf_> tvoss: alan_g: Yes. Although, arguably, unity8 should not allow autopilot to cause leaks even if it misbehaves.
<tvoss> alf_, it might be due to the upstart based app launching
<tvoss> alf_, can you try invoking apps from the cmdline, please?
<alf_> tvoss: through upstart?
<tvoss> alf_, yup, we start applications via the user upstart session nowadays
<tvoss> alf_, that's how ap starts apps
<alf_> tvoss: hmm, so how do you actually start an app with upstart? 'start <appname>' doesn't work
<tvoss> popey, can you help alf_ real quick?^
 * popey arrives
<popey> you need APP_ID
<alf_> popey: ok, where do I get that from?
<popey> start application APP_ID=music-app
<popey> something like that I think
<popey> it's the bit of the .desktop file
<popey> often found in /usr/share/applications or ~/.local/share/applications
<alf_> popey: great, thanks
<alf_> popey: can I use upstart to also stop an application?
<popey> never tried â»
<alf_> popey: well, 'stop ...' doesn't work so I guess not
<alf_> alan_g: tvoss: aha, when killing (i.e. SIGTERM) an app, memory in unity8 is not released!
<popey> oof
<tvoss> alf_, that is, the friendly: please kill yourself SIGTERM is not registered by unity?
<alan_g> alf_: does the server see the client has died? (connector report ought to say)
<Saviq> tvoss, alf_, did memory usage increase enough to cause the slow down? i.e. are we swapping or somethng?
<alf_> alan_g: haven't checked yet, will start unity8 with MIR logging...
<tvoss> Saviq, pre-test 425MB, post: 980MB
<Saviq> tvoss, ok, yeah, that's bad
<alf_> tvoss: that's just virtual, resident was: 83m -> 624m
<alan_g> alf_: and does the app actually exit?
<tvoss> alf_, okay, that's even worse :)
<alf_> alan_g: yes
<alf_> alan_g: tvoss: http://paste.ubuntu.com/6244872/ (ignore UbuntuKeyboardInfo - socket error, I am starting unity8 manually without maliit)
<alf_> alan_g: tvoss: the app drops the connection abruptly, so perhaps we are not cleaning up resources properly in this case?
<alf_> tvoss: So if autopilot stops apps like this, it would explain the leak. Can we find out how autopilot stops the test apps?
<tvoss> alf_, good question. asac, can you help here?
<tvoss> asac, alf_ I would assume first SIGTERM and SIGKILL if nothing happens
<asac> would go for #qa
<asac> and check with folks if anyone with autopilot know how is around... also you can check with osmonon
<asac> and Saviq ... those have used autopilot a lot as well
<asac> (and would at leaast have an idea how to find out)
<asac> tvoss: alf_: ^^
<Saviq> tvoss, alf_, asac, it doesn't SIGKILL them
<Saviq> tvoss, alf_, if the app under test is hanging, it will go "Killing app blah..." indefinitely
<alf_> Saviq: does it SIGTERM, thought?
<alf_> -t
<Saviq> alf_, I imagine so, yes, how else?
<asac> alf_: i think this might be the code: http://paste.ubuntu.com/6244898/
<asac> hmm. or not
<asac> check out lp:autopilot ... testcase.py
<asac> autopilot/testcase.py
<Saviq> ok, so it never SIGKILLed for me...
<asac> http://bazaar.launchpad.net/~autopilot/autopilot/trunk/view/head:/autopilot/testcase.py
<asac> Saviq: did you see processes not getting TERM'ed?
<tvoss> SIGTERM
<asac> and it didnt KILL? feels like a bug then
<jibel> tvoss, AP does a SIGTERM/SIGKILL to terminate applications
<asac> but i dont think this is what we see here?
<tvoss> jibel, so sigterm first, then sigkill?
<asac> see the code. seems like it ... yes
<asac> after 9 seconds :)
<Saviq> asac, yeah, unity8 has an issue on TERM when it gets stuck if still animating
<jibel> tvoss, yes, that's in the code asac found
<asac> Saviq: so the kill code didnt work?
<Saviq> asac, it didn't seem to indeed
<asac> err ... never happened?
<asac> Saviq: sure it was autopilot that was hanging and not unity?
<asac> err ignore
<Saviq> asac, with upstart it's working (assume upstart is SIGKILLing)
<asac> well. hard to say without being able to reproduce
<Saviq> asac, yeah, had to kill -9 unity8
<asac> maybe this is not the code that is getting run though
<Saviq> asac, I expect it is - I saw the "Killing process..." indefinitely when unity8 hung
<asac> there is also one hit for TERM in autopilot code here:
<asac> bin/autopilot-sandbox-run:trap on_exit EXIT INT QUIT ABRT PIPE TERM
<asac> err ignore
<asac> not sure what that sandbox is and when its used though
<alf_> tvoss: asac: ok, so we have found when the unity8/mir leaks happen. Now to find out why unity8/mir doesn't clean up if a connection is terminated abruptly... on it...
<tvoss> alf_, +1
<alf_> after lunch :)
<tvoss> alf_, enjoy
<jibel> asac, that's for developer to run their code locally, not for production use
<jibel> asac, it runs AP test inside xvfb or xephyr instead of using the active session
<asac> ic ... thanks
<asac> alf|lunch: what is exactly leaking?
<asac> some resources related to maliit i figure?
<alf|lunch> asac: no idea yet
<Saviq> t1mp, alf|lunch and tvoss are looking into the uitk ap failures
<t1mp> great, thanks
<Saviq> and overall system slowdown after it
<t1mp> alf|lunch, tvoss, Saviq so now it seems that individual tests pass if we run them after a reboot
<t1mp> but if we run all the tests, or if we run a single test a lot of times (like 10-20), then they start to fail
<t1mp> and after they fail, also qmlscene segfaults
<t1mp> so it seems like an issue with cleaning up processes
<kalikiana> ^^ I cannot always see them, but sometimes I see the dash filling up with thumbnails after those test runs
<kalikiana> I'm guessing apparmor prevents me from "seeing" it in ps
<tvoss> t1mp, yup, alf|lunch is tracking that down
<t1mp> tvoss: great. please keep us informed also :)
<t1mp> and let us know if we can help
<tvoss> t1mp, please stay around here :)
<t1mp> sure
<t1mp> alf_: hello. I hope you enjoyed your lunch :) as you can see, SDK people are invading this channel so we can bug/help you with the UITK autopilot failures
<alf_> t1mp: ok, I am currently investigating the mir part of it, will let you know
<t1mp> alf_: ok, great.
<t1mp> alf_: are there other parts to it besides the mir part?
<alf_> t1mp: I am not sure yet. It seems that if an app is SIGTERMinated, not all resources are released properly, looking into what exactly is happening there.
<alf_> t1mp: => resources in the server, causing leaks
<t1mp> alf_: ok
<alan_g> alf_: I've been playing - Mir doesn't see (e.g. terminal) drop the connection if I send it a SIGTERM.
 * alan_g was looking at this sort of issue in the client side comms before interrupt (and planning to look at same on the server next)
<alf_> alan_g|lunch: I am getting server messages like "connection dropped without disconnect
<alf_> alan_g|lunch: aren't you getting any messages at all?
<alan_g> alf_: I'm getting the connection messages, but nothing about disconnect - but maybe I've a slightly different scenario.
<alf_> alan_g: (Have you enabled all the REPORTS properly?) In my case, investigation shows that the shell::ApplicationSession is never destroyed, because unity-mir is keeping a strong handle to it, keeping the 'application' alive...
<alan_g> alf_: (I'm starting the terminal from the u8 GUI and killing it from an adb shell)
<alan_g> alf_: I've got DebugSurfaces report and connector report
<alf_> alan_g: FWIW, "connection dropped without disconnect" is a SessionMediatior report message
<alan_g> alf_: adding it now
<alf_> alan_g: btw, we should change the connector report to use "Connector" instead of "SessionMediator"
<alan_g> alf_: True
<alan_g> alf_:  I still don't see the server noticing the disconnect...
<alan_g> alf_: my bad - it was on stderr, not stdout
<alan_g> alf_: You're ahead of me here. (I'll go fix the report. )
<alf_> alan_g: ok
<alf_> greyback: could you please explaing the logic of ApplicationManager::onSessionStopping() in unity-mir/src/modules/Unity/Application/application_manager.cpp ?
<didrocks> tvoss: did you get any progress on the slowdown that we can trigger easily after running the ubuntuuitoolkit AP tests?
<tvoss> didrocks, see backlog, alf_ and alan_g are looking into the issue and it seems to be a memory leak
<didrocks> any ETA?
<tvoss> alf_, alan_g ^
<alan_g> didrocks: tvoss: alf_ is the man
<alf_> didrocks: tomorrow for sure, maybe today but no promises
<didrocks> alf_: ok, to be in finale, we need to avoid an ABI break though FYI (we just rejected the sigstop one because of that)
<kalikiana> just keep in mind that this has been preventing uitk releases for days, no fix isn't exactly an option
<tvoss> kalikiana, strong words don't help here, let alf_ keep on working
<kalikiana> if didrocks talks about rejecting fixes those are strong words for me
<tvoss> kalikiana, well, that's didrocks department and decision in the end. I'm pretty sure alf_ will try to avoid an ABI break
<didrocks> (hence why I prefer to warn in advance)
<greyback> alf_: If Mir reports an application has stopped, but shell/upstart wasn't one to stop it, we assume the lifecycle management killed it, so set the application state as "Stopped" - keeping the app in the list of running apps
<greyback> alf_: that what you wanted to know?
<tvoss> greyback, why would the lifecycle mgmt do something without unity/mir knowing?
<tvoss> greyback, the point is: how do you distinguish from autopilot sigterm'ing a test app?
<greyback> tvoss: well nothing is telling unity/mir that the OOM has  killed an app
<greyback> tvoss: yep that's a problem. AP should really be using upstart, not relying on the desktop_file_hint hack
<tvoss> greyback, what would need to be changed?
<greyback> tvoss: well first, is this really a problem? Is it breaking anything?
<tvoss> greyback, it causes u8 to slow down to a crawl
<greyback> tvoss: second, AP would need to launch apps using upstart-app-launch
<alan_g> tvoss: @"how do you distinguish from autopilot sigterm'ing a test app?" why would you need to?
<alan_g> tvoss: nm - I just understood the context
<tvoss> alan_g, killed by lifecycle is a valid reason to keep the app as "running" around in the shell, killed by autopilot is not a valid reason
<alan_g> tvoss: yeah. But the Mir resources still need to be cleaned up
<alan_g> *session resources
<tvoss> alan_g, yup, alf_ and greyback are on it
 * alan_g thinks that is should be as simple as using a weak_ptr to the sh::Session instead of a shared_ptr
<alan_g> (From 50.000m)
<tvoss> alf_, ^
<tvoss> ;)
<alf_> alan_g: possibly, although I think this may be too risky a change at this point for unity-mir (but I am not very familiar with the unity-mir internals).
<alf_> greyback: ^^?
<greyback> alf_: yep, that's too big a change right now. I'm keeping it simple
<alf_> hikiko: kgunn: racarr: stand up
<kgunn> alf_: gonna miss today...let me know if you got any questions
<greyback> alf_: care to have a look? https://code.launchpad.net/~gerboland/unity-mir/fix-leaks/+merge/191449
<alf_> greyback: looking
<tvoss> greyback, did you try that patch with the uitk testsuite?
<greyback> tvoss: no, I ran through the steps in the bug.
<greyback> tvoss: but I'll do that, just to check
<tvoss> greyback, yup
<alan_g> greyback: I lack the surrounding context - but why is the delete only when "application == m_focusedApplication"?
<alf_> greyback: tested successfully on phone, now running uitk too
<alf_> greyback: (phone == single app case)
<greyback> alan_g: if app not in forefront, and it dies, we are pretending the app is still alive. If the user then requests that app, we will launch it again, hopefully restore its state, and give that to the user
<greyback> alan_g: so ideally they'll not realise the app was dead
<alf_> greyback: would it make sense to also add application->setSession(nullptr); to some cases in ApplicationManager::onProcessStopped() ?
<alan_g> greyback: Is there another line that releases the sh::Session pointer? setSession()?
<greyback> alf_: actually yeah, there's one place, nice spot
<greyback> alan_g: is it the Application object that's holding the sh::Session pointer. Calling setSession(nullptr) deletes that shared pointer
<alan_g> greyback: I get it
<alf_> greyback: tvoss: verified ubuntuuitoolkit tests run fine, system fluid after tests
<greyback> alf_: yep here too
<asac> alf_: fixed?
<greyback> alf_: pushed one other fix
<alf_> asac: yes, with greyback's MP: https://code.launchpad.net/~gerboland/unity-mir/fix-leaks/+merge/191449
<asac> alf_: do you feel the issue is fully understood now?
<asac> and this is a clean fix?
<asac> or rather a hack in the hope of ... :)?
<didrocks> and is it the only fix?
<asac> right :)
<asac> also that
<asac> alf_: greyback: ^^
<alf_> asac: didrocks: clean fix, plugging a memory leak
<alf_> asac: didrocks: what do you mean by only fix?
<asac> alf_: is this the only patch we need to take?
<didrocks> alf_: like this is the cause of all the slowliness we see after launching ubuntuuitoolkit AP tests?
<asac> compared to 99
<greyback> asac: was my bug, problem clear, fix is correct
<greyback> asac: my bug as in I introduced the bug :)
<alf_> asac: yes, slowness was because unity8 process ended up taking up 700MB resident memory, including graphics surfaces
<asac> greyback: well, so what else was committed to mir branch after 99 image content
<asac> err unity-mir
<asac> didrocks: maybe check and make a call :)
<didrocks> I'm checking
<asac> the patch looks good
<didrocks> yeah
<greyback> asac: an OOM value setter by tvoss
<asac> didrocks: we would take the OOM anyway?
<asac> i remember seeing it on landing
<didrocks> asac: yeah, but unity-mir wasn't part of the landing ask
<didrocks> so not that part
 * didrocks looks at the code
<didrocks> hum, I don't like it
<didrocks> (rev 127)
<didrocks> greyback: did you test with that one?
<greyback> didrocks: yes, it works
<didrocks> greyback: trusting you on rev 127 then (the OOM one) :)
<greyback> didrocks: ack
<asac> didrocks: check with tvoss
<asac> tvoss: http://bazaar.launchpad.net/~mir-team/unity-mir/trunk/revision/127
<tvoss> asac, didrocks waiting for lool to revisit https://code.launchpad.net/~thomas-voss/unity-mir/less-aggressive-scores/+merge/191440
<tvoss> asac, didrocks making the oom score adjustments more conservative
<lool> tvoss: So do we want to test this too?
<lool> tvoss: I started looking, but to land this we'd also want to test the OOM again
<didrocks> lool: is this really wanted for finale? ^
<lool> didrocks: well mu
<lool> didrocks: I personally think it can come in an update
<didrocks> I don't want pushing the finale cut forever
<didrocks> ok, let's get that tomorrow, once we are happy with the image
<lool> we have tested OOM, it has a small bug
<lool> this version will be cleaner, but it can land in a couple of days
<asac> didrocks: we could ask folks for the performance fix isolated
<asac> backing out the oom commit
<asac> so we can take it
<asac> ... just saying that that is an option
<asac> (not saying we should do that... leave that to you)
<didrocks> asac: greyback tested with the oom commit
<didrocks> asac: I have full trust on him :)
<lool> tvoss: Hmm why file.open(QIODevice::WriteOnly | QIODevice::Text) on the adjuster's oom file?
<didrocks> asac: otherwise, I would have ask for a revert TBH
<lool> tvoss: dont we want ReadOnly?
<tvoss> lool, oh, good point
<lool> tvoss: let's not rush this in; we could even take the time to write tests along side, the way you've split the functions is very nice for testability actually
<tvoss> lool, yup, happy to iterate
<tvoss> lool, that said, I will look into it tomorrow again
<tvoss> lool, fine for you?
<lool> tvoss: Not being very good on the C++ side, I dont understand whether int * float to int will be nice
<lool> tvoss: Sure, I can review tomorrow, dont think we will land tomorrow though
<lool> friday rather
<tvoss> lool, ack
<tvoss> greyback, alan_g, alf_ thanks for the fix :)
<lool> tvoss: so I would have written * 80 / 100 rather than * 0.8
<lool> but perhaps that's ridiculous given what the compiler already knows
<tvoss> lool, yup
 * tvoss grabs dinner
<tvoss> back in ~30 mintues
<lool> I will slowly walk away
<lool> might take a sneak peek to see if last landings come in nicely
<lool> but everything for image #100 is set
<tvoss> lool, thanks :)
 * greyback eod
<tvoss> greyback, o/
<t1mp> alf_: any news for the uitk autopilot tests?
<kalikiana> t1mp: https://code.launchpad.net/~gerboland/unity-mir/fix-leaks/+merge/191449
<kalikiana> but haven't tested it myself yet
<kalikiana> (eod for me)
<t1mp> kalikiana: at least the name of the branch sounds good :D
<t1mp> if it fixes our issues that's awesome :)
<t1mp> but yeah, I'll also see tomorrow. eod time
<alf_> t1mp: yes, tested it fixes the slowness after uitk
<t1mp> alf_: and the uitk autopilot tests run then?
<alf_> t1mp: I have run the full uitk twice without problems with this branch
<alf_> t1mp: (60 tests)
<t1mp> wow. super :D
<t1mp> alf_: thanks!
<t1mp> ah greyback is offline, I'll thank him tomorrow :)
<davmor2> tvoss, kgunn: http://ubuntuone.com/0Vem5WU2FOKaY5QVVnnmcC  sorry for the sideways view bit of weirdness with android videoing, but you should at least be able to tell that it is much snappier now :)
<racarr> I'm concerned that the ui toolkit tests
<racarr> passed yesterday? and failed today :*
<racarr> :(*
<t1mp> racarr: passed yesterday? they are failing since last week.
<racarr> t1mp: You mean the autopilot tests?
<davmor2> tvoss, kgunn: that is image 99 by the way :)  feels a much nicer place to be :)
<racarr> I think I looked
<racarr> at the wrong report yesterday a bit :p ignore me
<t1mp> racarr: yes
<t1mp> racarr: ok :)
<tvoss> davmor2, thx :)
<t1mp> racarr: I was talking about this https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1239646
<ubot5> Ubuntu bug 1239646 in Ubuntu UI Toolkit "CI fails most tests on UITK trunk" [Critical,In progress]
<racarr> I don't understand the failures up there though....
<t1mp> racarr: might be fixed in mir now
<tvoss> racarr, I'm pretty sure things are fixed now
<tvoss> t1mp, in unity-mir
<racarr> Ok
<racarr> how to interpret test failures like http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/99:20131015.2:20131015/4749/ubuntu-ui-toolkit-autopilot/491077/
<racarr> though
<racarr> oh is it the OOM killer
<tvoss> yup
<racarr> fun
<t1mp> tvoss: yeah that's great. I'll try the tests tomorrow :)
<tvoss> racarr, not :)
<tvoss> there he is
<tvoss> greyback, o/
<greyback> yes?
<tvoss> you rock :)
<greyback> alf_ deserves the credit, he tracked down the issue
<tvoss> well, you guys just worked together really well, thanks :)
<kgunn> kdub:  do you consider "support for bypassing unity8 surface" to the be the same thing as what I call "android bypass" ?? if its different...let me know how
<thomi> morning
<kdub> kgunn, both are 'bypass' but the path they will take in the code is different
<kdub> unity 8 is internal, so there's less plumbing to hash out when compared to a bypassed IPC client
<kdub> morning thomi
<thomi> o/
<kgunn> kdub: hmmm....not sure i follow, are you caling unity8 bypass really just the shell ? whereas IPC client bypass would be apps ?
<kgunn> thomi: \o
<kdub> kgunn, right
<kgunn> kdub: are both tied to android ?
<kgunn> wondering how it differs from what we already have
<kgunn> ...i guess what we have is closer to ipc bypass...just on gbm
<kdub> right, xmir (an ipc client) is bypassed
<racarr> kdub: Wait so are you doing unity8 bypass?
<kdub> not right now, i think we're just organizing the future
<racarr> Ok
<racarr> I have an idea for a simple fix for
<racarr> https://bugs.launchpad.net/mir/+bug/1227739
<ubot5> Ubuntu bug 1227739 in Mir "Mir continues to render background application surfaces even when they're not visible" [High,In progress]
#ubuntu-mir 2013-10-17
<RAOF> Uuuh, launchpad? Why did you just silently eat my workitems?
<duflu> Uuuk, google? Why did you just silently eat my personal account and force me to retry for an hour to prove my identity?
<duflu> Seriously though... I have plenty of two-factor mechanisms and instead of asking for them, Google asks me questions that no reasonable person would be able to answer. Like the month I opened my account, or the month/year I first used Calendar.
<RAOF> Woah.
<kgunn> RAOF: duflu ...could one of you review/approve https://code.launchpad.net/~mir-team/mir/bump-deb-changelog16-mirserver8/+merge/191548
<duflu> kgunn: Done, but needs a minor fix
<duflu> kgunn: Also, I assume we've given up on keeping milestones up to date with each 0.0.N ?
<RAOF> duflu, kgunn: Do we need dates in the changelog *at all*?
<RAOF> s/changelog/version/c
<duflu> RAOF, kgunn: Yeah if we're bumping the version this much then there's no need for a date in there too
<duflu> So long as it *increases* each time
<kgunn> duflu: robert_ancell used to set milestones...altho, i'm not enlightened as to its usefulness...other than maybe trying to target bugs to be done (e.g. phone-v1-freeze)
<duflu> kgunn: I've been maintaining them much of the time, but they're not useful if the milestone moves this often. You need less frequent point releases.
<duflu> kgunn: If we're not using them then we should have even just one milestone for the release and target that
<kgunn> RAOF: duflu ...as to date, dunno, i thot there was some esoteric reason it was needed
<duflu> kgunn: I think we're free with version strings. So long as they increase and also end with -NubuntuN. The prefix is our own choice
<duflu> ... the prefix being the upstream project version without -NubuntuN
<kgunn> duflu: so you guys are saying instead of this 0.0.16+13.10.20131011-0ubuntu1....we should just make it 0.0.16-0ubuntu1
<duflu> kgunn: I think so
<RAOF> Yup.
<kgunn> robert_ancell: ^ what you say even tho you no workie on mir anymore
<robert_ancell> the only reason I was stamping versions was so we could mark bugs as closed against that version
<robert_ancell> recently the version is useful for bumping build dependencies
<duflu> Although the "16" is meaningless. It would have more meaning if we replaced "16" with "<bzr rev number>"
<robert_ancell> I'd agree with duflu using the bzr revision number is more useful
<robert_ancell> and having some sort of major version number for telling the difference between versions in Ubuntu
<duflu> Then the "0.0" is a placeholder for real project versioning (in future)
<duflu> Yeah, the major.minor needs to change, somehow, for each cycle at least
<kgunn> duflu: ok...can we go with this for this time, let me coordinate with didrocks tomorrow.....i don't want to switch it up and have a reason for grinding everything to a halt
<duflu> Fair point. My experience with versions and didrocks that anything which increases is fine. And anything with meaning is better
<duflu> *is that
<duflu> Argh. Although in using revision numbers you have to remember *only* the development-branch has useful history now. So it would have to be the revision of development-branch
<duflu> And similarly, when branching post-saucy, that has to branch from development-branch. Or else we lose the history. Because lp:mir presently has no useful history
<kgunn> duflu: now ? https://code.launchpad.net/~mir-team/mir/bump-deb-changelog16-mirserver8/+merge/191548
<duflu> kgunn: Needs fixing still :(
<duflu> Really, we're not using milestones and the "16" is meaningless. So we should go to upstream version "0.1" or higher. And let ubuntu saucy versions be "0.1-0ubuntuN".
<duflu> or "13.10..." :)
<kgunn> ok strange...i remerged from trunk, that went fine, dch -i and did all the updates...all seemed fine...
<kgunn> but now, when i try to push...is says error "These branches have diverged."
<kgunn> but when i do bzr missing it just shows my one commit...
<kgunn> and a merge from dev-branch results in "nothing to do"
<RAOF> Where are you pushing to?
<duflu> kgunn: bzr info to see where you're pushing to. Verify it's your own and not a shared branch. Then explicitly: bzr push --overwrite lp:~kgunn/mir/somewhere
<kgunn> duflu: ok...now?
<duflu> kgunn: All approved. But then again... I'm not sure if and where we actually broke the server ABI :)
<duflu> ... hence it might not have needed incremening
<duflu> +t
<om26er> duflu, hey!
<om26er> duflu, got an opinion on bug 1240841 ?
<ubot5> bug 1240841 in mir (Ubuntu) "[Mir]In-App scrolling is lagging much" [High,New] https://launchpad.net/bugs/1240841
<duflu> om26er: Hi
 * duflu looks
<tvoss> om26er, which image?
<tvoss> om26er, maguro?
<om26er> tvoss, 100 mako
<tvoss> om26er, was it present yesterday?
<om26er> tvoss, yes it was
<duflu> om26er: Probably not Mir at least. Since native Mir demo clients are perfectly smooth
<duflu> But maybe...
<tvoss> om26er, can you please verify with a less complex client than the browser?
<om26er> tvoss, ok, let me try the contacts app
<tvoss> om26er, ideally, something without too much interaction with the underlying system would be helpful
<tvoss> om26er, to isolate variables
<duflu> That's fun. The Mir branches appear to have had Compiz tags imported into them at some point. How useless. Now deleting them
<om26er> tvoss, its visible in address-book as well
<om26er> with only 38 contacts in the list
<duflu> om26er: On startup too (not many surfaces running in the background)?
<om26er> just rebooted. lets see
<duflu> om26er: P.S. occlusion optimizations just landed, but don't do anything on mako because --> bug 1240833
<ubot5> bug 1240833 in Mir "[feature] Expose at least one non-alpha pixel format for Nexus 4" [Medium,Triaged] https://launchpad.net/bugs/1240833
<om26er> duflu, will it help on nexus 7 ?
 * ogra_ sees it on maguro with the browser and all webapps (though i was blaming the browser initially)
<duflu> om26er: Haven't looked yet
<duflu> Yeah it seems the browser is naturally slower than other apps anyway
<ogra_> (lagging and horrible jumpiness when scrolling that it)
<duflu> It has a lot to do
<ogra_> well it didnt do that a week ago or so
<om26er> duflu, facebook.com or omgubuntu are really smooth in the browser under Mir. there are other sites that can be slow but these 2 are super smooth
<ogra_> and indeed i dont see that on mako
<om26er> *under SF
<duflu> om26er, ogra_, Yeah I think we know our Android rendering is sub-optimal. I don't know what is planned to fix there next. Best ask kdub.
<om26er> duflu, just rebooted. visible right after phone starts in contacts app
<tvoss> om26er, just augment the bug with your findings. Ideally add a video, we will look at it
<ogra_> duflu, well, maguro has other more low level probs too with Mir ... like exposing a uevent for *each* vsync, seems that doesnt happen on SF
<duflu> ogra_: Sounds bad. But I'm no Android expert
<ogra_> yeah
<tvoss> ogra_, do we have a bug report for that?
<ogra_> tvoss, yes, pitti is just working with om26er on one of the fallout bugs in #ubuntu-touch
<ogra_> (one is that udevd eats constantly 10%+ on maguro, the other is that upstart picks up these events and collects ram like crazy)
<ogra_> tvoss, we dont really have a bug against Mir for it, but i think somewhere in Mir lies the root of this
<ogra_> seems SF somehow tells the driver to stop the event spam (probably through a special arch specific switch)
<tvoss> ogra_, digging
<om26er> tvoss, ok. will do
<tvoss> om26er, did you upload the video, yet?
<om26er> tvoss, i was helping pitti with some udev debugging
<tvoss> om26er, ack
<om26er> tvoss, will upload in a few minutes
<om26er> duflu, so who is going to work on bug 1240833 ?
<ubot5> bug 1240833 in Mir "[feature] Expose at least one non-alpha pixel format for Nexus 4" [Medium,Triaged] https://launchpad.net/bugs/1240833
<om26er> Kevin ?
<duflu> om26er: Don't know. But it's next cycle :(
<om26er> duflu, next cycle starts in a few days ;)
<om26er> well actually tomorrow :p
<duflu> om26er: Hah. Yeah fair point. Still don't know. It's a simple concept, but potentially tricky to implement
<om26er> tvoss, I don't think video camera are able to capture the lag. I have been trying to record a few videos but none seems to show the problem. perhaps I need a better camera
<tvoss> om26er, ack
<davmor2> om26er: what's the issue I have a pretty good camera I can setup
<om26er> davmor2, on Mir open contacts app with ~50 contacts, try flick from bottom towards top and see if the scrolling lags. try the same on SF. make a video for both
<om26er> its even more visible in the webbrowser.. in sites like omgubuntu or facebook
<davmor2> om26er: I was going to say open planet.ubuntu.com and you get it
<om26er> yeah
<davmor2> tvoss: ^ this is what I said yesterday, If you open planet.ubuntu.com on a maguro because of the length of the site page you can really see the glitchy effect on mir.  Not so much lag for me more that is seems to bounce forever and a day
<tvoss> davmor2, again, maguro is not really the reference here, but I will look at it as soon as I have some time on my hands
<om26er> davmor2, confirm this bug 1240841
<ubot5> bug 1240841 in mir (Ubuntu) "[Mir]In-App scrolling is lagging much" [High,New] https://launchpad.net/bugs/1240841
<tvoss> davmor2, until then, please make sure that we have bugs logged with as much information as possible
<om26er> I see that on mako Sir!
<tvoss> om26er, sure. One other thing: *much* is not really helpful, either we have hard numbers to quantify the slowdown, or it lags. I would rather model qualitative attributes in the bug importance
<tvoss> davmor2, om26er that being said: bug reports with attached videos or as usual, detailed steps to reproduce would help the most
<om26er> ok, we'll improve the title and attach a video if I get my hands on a better camera
<davmor2> tvoss: I can video the glitch effect I'll add it to the bug, I'll give you a ping once it is done
<tvoss> davmor2, thx
<tvoss> om26er, thx
<ogra_> tvoss, i find it funny that maguro isnt really the reference anymore since we were told we need to focus exactly on this device class
<ogra_> instead of the beefy arch
<ogra_> (though that seems to have shifted a little)
<tvoss> ogra_, fair point, and we will get to optimizing for it, too. However, the PowerVR SGX 540 is *known* to be full of issues, and we don't have drivers with proper hardware compositor support for it
<tvoss> ogra_, that's the main reason it does not benefit as much of the performance improvements
<ogra_> yeah, i understand whats the issue indeed
<mlankhorst> everything powervr has issues :P
 * ogra_ fights with PVR since nearly 4 years already :)
<tvoss> mlankhorst, but there are particular bad chips in that series ;)
<ogra_> maguro is just a different pandaboard ;)
<tvoss> mlankhorst, ogra_ specifically, touching the fb stalls rendering pipelines and rendering contexts in wild and wonderful ways
<tvoss> ogra_, that's one of the reasons just catting the fb can lead to "interesting" behavior on maguro
<tvoss> ogra_, but yes, I'm talking in technical terms here. In general I do agree that we should not only consider super-phones
<ogra_> theyshould be second focus instead
<davmor2> tvoss: video added to bug
<tvoss> davmor2, +1, thx
<davmor2> om26er: can you confirm that is what you see too
<davmor2> tvoss: is that alright for you?
<tvoss> davmor2, yup, helps a lot, thx
<davmor2> tvoss: same thing happens on contacts as with the slow scroll on the browser page you get that bouncy glitchy effect
<tvoss> davmor2, ack
<davmor2> tvoss: the only really odd thing if you do the same scroll in unity8 itself you don't get the glitch it's nice and smooth :)
<om26er> davmor2, try opeing three apps and scroll in unity then ;)
<tvoss> davmor2, that's indeed interesting
<tvoss> om26er, please add that information to the bug report
<om26er> davmor2, yeah, I can confirm your video
<om26er> tvoss, ok
<davmor2> om26er: I've confirmed the bug then now I know it is the same thing :)
<om26er> davmor2, btw opening omgubuntu.co.uk is also an easy way to reproduce that bug. since that a mobile optimized app
<davmor2> om26er, tvoss: I'm assuming that the slow scroll in unity8 with apps open is mostly just down to lack of memory so it's possibly hitting the swap
<tvoss> davmor2, might well be. However, we have optimization potential in Mir, too
<om26er> davmor2, memory is not much of a problem on mako. its because the apps that are running in the background are still being rendered by Mir
<om26er> davmor2, bug 1227739
<ubot5> bug 1227739 in unity-mir "Mir continues to render background application surfaces even when they're not visible" [High,Triaged] https://launchpad.net/bugs/1227739
<tvoss> om26er, only for a certain amount of time, after that, the processes are sigstopped
<davmor2> om26er: right yeah I see it when you open an app and you get that initial stall sometimes and another app appears till the new one is fully loaded
<lool> Hey folks
<lool> wanted to ask, is there some kind of xvfb for mir?  some kind of fake mir backend in memory
<lool> no specific GPU connected
<alf_> lool: no, we do have a dummy display backend in the tests (no drawing done at all)
<alf_> lool: why do you need the memory backend?
<alf_> lool: also see https://bugs.launchpad.net/mir/+bug/1118903
<ubot5> Ubuntu bug 1118903 in Mir "[feature] Mir lacks a software rendering backend" [High,Triaged]
<lool> alf_: something inbetween emulator virtual machine, and real hardware basically
<lool> alf_: I think this is indeed related; thanks for the pointer
<lool> alf_: I guess there is probably a fake fb driver we could use with this support for fbdev
<lool> I'll check with kgunn how far this is in the mir roadmap
<lool> (with other work such as performance work upcoming)
<kgunn> lool: why the query ? e.g. what's your proposed need ?
<lool> kgunn: I'm chatting with vila on evolutions of CI stuff, and this came up as one of the things that might help running some of the tests on vms
<lool> kgunn: So was just tring to get status
<lool> kgunn: maybe we will need this sooner rather than later, depends how far this is
<kgunn> lool: ok, right now its nowhere (...unless duflu has been sneaky and spent time on it)
<lool> kgunn: Ok; thanks
<kgunn> lool: but thanks for this...i will
<kgunn> make sure to create a bp for some general mir testability items (this is 1 of handful)
<alf_> lool: don't the VMs we have support KMS/DRM?
<kgunn> alf_: true...but, isn't the fb is just a phoney...its really a sw fb that gets redirected to a window right?
<kgunn> alf_: oh i get your point
<kgunn> alf_: you might  use a sw buffer as fb, but that doesn't mean there is no fb
<kgunn> oops, meant gpu...
<kgunn> you might  use a sw buffer as fb, but that doesn't mean there is no gpu
<lool> alf_: I'm not sure; I think where there are cases where we dont want this relayed to real hardware, but rather have fake fbs
<alf_> lool: do you mean the final display, or the rendering?
<lool> alf_: I guess it depends; on one side we want to exercize Mir itself, on the other side sometimes we just want a solid hardware independent output for higher level tests which are not dependent on GPU specific behaviors
<lool> Perhaps something we might want to do for instance is simulating cloning or extending of displays, or rotating the screen
<lool> or different DPIs
<alf_> lool: (if it's just for the final display, we could just draw to an off-screen buffer instead of the real framebuffer)
<tvoss> lool, so you want a vesa backend?
<alf_> lool: so ideally you want a pure software pipeline, e.g. what the bug describes
<alf_> lool: GPU not involved in neither display nor rendering
<lool> alf_: Yes, in regular memory buffers is what I had in mind rather than real framebuffer
<lool> much like Xvfb
<lool> tvoss: vesa still goes to hardware via bios?
<lool> alf_: yes pure software
<lool> alf_: exactly
<alf_> lool: the rendering part may be a bit tricky, but we could probably just use mesa software rendering for this
<alf_> lool: btw, I am not sure that xvfb doesn't use the GPU at all, I think it does so for rendering
<alf_> lool: perhaps you just want mir in an X window? :)
<lool> alf_: Actually I care to be able to say "Run these commands that would usually output things to a real screen on a fake screen and let me be able to poke at it"
<lool> alf_: typically, take screenshots, get events about what's going on, influence it
<lool> alf_: e.g. did the display output get "turned off"
<tvoss> lool, so you want a state-observable mock? I think that's best done in the project-internal tests
<lool> alf_: the main use case is running tests in a reproducible manner and simulating / listening to events; e.g. I can run a "rotate unity8" test on intel or nvidia hardware without testing the intel and nvidia specific behaviors, and then do integration testing on real hardware
<lool> tvoss: but right now when we're actually displaying something it goes to real hardware and might behave differently on this or that hardware
<lool> also, hardware sucks
<lool> if you see what I mean
<lool> we'll always need testing on real GPUs
<lool> but if we could run most of the pre-integration test steps in vms / reproducible + controlled environments, that would be more reliable, scalable
<tvoss> lool, sure, I'm not argueing against your point, only saying that I think what you want is a mockable and obversable backend, as independent of HW as possible
<tvoss> lool, what are preintegration tests from your pov?
<lool> tvoss: Ah Mir backend, yes
<lool> tvoss: typically testsuites of our components
<lool> one class is unity8 itself, another class is anything running in unity8
<lool> but in all cases, we're rarely writing GPU specific code and we could run all tests first on a virtual backend, then on a GPU in the last integration steps
<tvoss> as in-process?
<lool> hmm not sure
<tvoss> lool, sure, we would need graphics drivers for the vm's then
<lool> Frankly, I dont fully grasp how the technical implementation would look like yet  :-)
<lool> but in the end, I feel I shoudl be able to land an unity8 change by running the tests on a reproducible / fast / scalable environment before I even try it on a real GPU
<lool> with more tooling too
<lool> like, rotating the screen
<tvoss> lool, so what we would need are graphics drivers for the virtual machines we want to consider
<tvoss> lool, those drivers typically allow for injecting events like "rotate screen", too
<lool> tvoss: hmmm
<lool> tvoss: virtual machine we are working on
<lool> goldfish
<lool> but it has GL passthrough
<lool> so it's not really hardware independnet
<lool> also, vms are a bit heavy
<lool> when you compare to Xvfb
<tvoss> lool, xvfb is not hardware independent either
<lool> is it not?
<lool> how so?
<lool> I thought it was creating a fake in memory surface; that it worked without a hardware GPU
<tvoss> well, it depends
<tvoss> however, I do not see the advantage of a "pure" software solution in small-scale integration testing. What we have right now is a way to run Mir without real-hw backend in integratoin and acceptance testing scenarios. Unity (or unity-mir) could use that knob, too
<lool> tvoss: can we take screenshots from it?
<lool> I guess we could live without screenshots
<tvoss> lool, nope, it's state observable though
<tvoss> lool, that's what we use to mock out things for our CI runs
<lool> maybe fake non-rendering backend + goldfish are enough to cover our needs
<lool> the xvfb like solutoin would be a bit in between I guess
<lool> where's the fake non-rendering backend?  I looked into mir/src/server/graphics/ but I'm not sure I can tell how it's named
<tvoss> lool, searching
<alf_> lool: tvoss: there no dedicated "null" backend at the moment, it's just dummy classes inside our test framework (e.g. see in tests/mir_test_framework/testing_server_options.cpp)
<lool> ok
<kgunn> alan_g: alf_ anyone?....https://code.launchpad.net/~mir-team/mir/development-branch/+merge/191652
<alan_g> kgunn: looking
<alf_> alan_g: is this going into a phone release?
<alf_> kgunn: ^^
<kgunn> alf_: alan_g nope, won't make phone release
 * alan_g thought so
<alf_> kgunn: so, when are we going to be working directly on trunk again?
<kgunn> alf_: i spoke to didrocks about it, and seems the api control we have in place is working good...
<kgunn> alf_: so until we get our api distilled down
<kgunn> alf_: we'll have to stay on the dev branch
<alf_> :/
<kgunn> alf_: what's the complaint besides speed (of which...i am probably 1/2 that problem :)
<alan_g> kgunn: the problem is tracking the source of problems - think about "bisecting" trunk changes
<kgunn> alan_g: yeah...true
<kgunn> racarr: can you resume the api distillation activity ?? ^ this will help us return to trunk
<alf_> alan_g|tea: that was a quick lunch ;)
<alf_> kgunn: I think our API will begin to stabilize only after the scenegraph/model rework
<kgunn> alf_: that makes a lot of sense....so really, should we just forego the distillation process with what we have today & prioritize the scenegraph work ?
<kgunn> alf_: altho...doing some gross distillation wouldn't hurt
<kgunn> we could bump api/abi slightly less
<kgunn> today i see a header in include/server....by technical rights...i need to bump (even tho i know the likelihood is really low)
<kgunn> i suppose tackling scenegraph will depend on greyback's availability ....and i know he may be sidelined for about 3 weeks doing the right-edge navigation proto
<kgunn> greyback: could someone else do the proto ?
<kgunn> albert maybe ?
<alf_> kgunn: I think that the upcoming changes will drastically alter what we expose to the shell, so much of the distillation work will be wasted. We also need to decide what  privatization scheme we are going to use.
<alan_g> ^ +1
<kgunn> alf_: "which scheme"....can you elaborate ? i'm kind of simple minded...i was thinking you got  abunch of headers wit pv func's and some needed enums/structs in them
<alf_> kgunn: I am referring to the discussion in the the "privatize" MP series email thread
<kgunn> btw, gonna miss stand up..i have to sit in for olli at some meeting
<kgunn> alf_: ah...again, am i missing something ? but isn't it a rather simple argument to conclude which directories (feel free to educate me)
 * kgunn realizes there were some responses to my mail...i meant to go back and read :)
<greyback> an accidental "make -j44" brought my machine to its knees
<greyback> kgunn: fastest way to do the prototype is probably to use the app-screenshot hack we're using for app switching. Disadvantage of that is previews will not be live. But that task will require the screenshot-save-to-disk work we need anyway
<greyback> kgunn: yes someone else could certainly take that on
<greyback> kgunn: that prototype could be educated to use live previews when available, as the scenegraph task progresses a bit
<greyback> kgunn: I need to write up a doc with what scenegraph works I think needs to be done, and what I think Mir might need. I need to spend time understanding how the two can work together tho
 * greyback quite needy at the moment :)
<greyback> I'll also need a volunteer from the Mir team who is happy to discuss the Mir-side compositor with me, to explain hardware compositing drawbacks to me, and so I can bounce ideas off
<kdub> greyback, i might be able to help there
<greyback> kdub: great, thanks! Prepare for a barrage of idiotic questions and sky-high ideas :D
<kdub>  :D
<alf_> greyback: 'make -j' is also fun :)
<greyback> alf_: that it is, but for some reason my Ctrl+C reflex kicks in for that immediately.. :)
<kgunn> greyback: was busy, and thanks for the responses....great minds think alike....i wanted to ask you to write up some thots....maybe you and kdub (and whomever else) could spend some quality time early next week on it
<greyback> kgunn: sure
<greyback> kdub: as a first question, I'd like to learn more about what various hardware compositors can do, just to get a grip on the basics. Would you know of any docs that I could start out on?
<kdub> docs, not really
<greyback> kdub: even an API of some hardware compositor would give me something. I've found a little on the hardware compositor in the raspberry pi, but mot much
<kdub> oh, let me point to the api
<kdub> greyback, https://android.googlesource.com/platform/hardware/libhardware/+/android-4.3.1_r1/include/hardware/hwcomposer.h
<greyback> kdub: are there similar for nvidia/intel/amd chips? Or is it quite chip specific?
<kdub> the whirlwind tour is that you can set various transforms you want to do in composition (basic ones) certain alpha modes, 90-degree rotation, cropping, blits, scaling
<kdub> then you ask the hardware, and it tells you 'i can do that' or 'i can't'
<kdub> if the hardware can't do it, you have to do that in opengl
<kdub> greyback, only talking about android at the moment
<greyback> kdub: sure, I'm just thinking about desktop further down the road
<kdub> right, with desktop... i think? there's just the cursor that's an overlay
<kdub> alf_, is that right, or wrong? :)
<alf_> kdub: KMS has the concept of planes (=hardware overlay), but we are not using them at the moment, not even sure how well they are actually supported by the drivers
<kdub> oh yeah... i don't hear about them very often, i'd guess the support is hit-or-miss
<greyback> so sounds like there's little to no hardware compositing abilities on desktop chips
<kdub> i guess.... i mean, there are some different tricks we might want to try
<kdub> like, composition happens on the 2nd gpu core (for laptops with an integrated and discrete core)
<greyback> cool
 * greyback eod
<w-flo> are there any known issues with mir and android hwc11 (whatever that is)? mir 0.14 used to work after some patching, mir 0.15 crashes in hwcomposer.so after a call from mir in commit_frame() in HWC11Device. Now I'm wondering if the special qcom/display for my phone is broken, or if there's something wrong with mir 0.15 and "hwc11" :)
<kdub> uhoh
<kdub> nexus 4?
<w-flo> nope
<w-flo> HTC Desire Z
<w-flo> nexus4 uses that hwc11 code, too? then it must be something in the hwcomposer code for my phone I guess...
<kdub> w-flo, haven't tried it... but i am doing improvements around that area currently
<kdub> i'd expect them to be different
<kdub> but is there a backtrace or something? might be a difficult issue to debug w/o a device though
<w-flo> kdub, http://pastebin.ubuntu.com/6252062/ is the backtrace. The code for libhwcomposer is not the same as in ubuntu/cyanogenmod, so no need to fix anything :)
<kdub> w-flo, still would be good to fix... maybe i'll have a branch or two to try over the next week (or two :) )
<kdub> i'll keep you posted
<w-flo> kdub, well, don't waste your time with it. might be a bug in the inofficial cyanogenmod port for the device, this is the repo: https://github.com/Andromadus/android_hardware_qcom_display/blob/cm10.1/libhwcomposer/hwc.cpp
<w-flo> anyway, thanks a lot kdub, I'll let you know if I get it to work somehow :)
<tvoss> kdub, hey there  :) happy release day
<kdub> happy release day tvoss :D
 * kdub start refactoring
<tvoss> kdub, thanks :) so I commented on the uevent spam bug
<tvoss> kdub, seems like we miss a call to the android poewr HAL that is a no-op on mako, but should help on maguro
<tvoss> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1234743/comments/37
<ubot5> Ubuntu bug 1234743 in systemd (Ubuntu) "omapfb module floods system with udev events on samsung galaxy nexus" [High,Fix committed]
<kdub> ah, hmm
<kdub> okay, i guess we should add that hal to mir
<kdub> we can add that to a bp somewhere
<tvoss> kdub, yup :) kgunn, can you help here?
<tvoss> not sure which bp is approprate
<kgunn> alan_g|EOD: dang...i did not realize you were unavailable...but the sprint timing was kind of tied to strehl's team as well
<kgunn> alan_g|EOD: that ended up being a really good week for his team too
<racarr> Lonnnn....don?
<racarr> I'm glad we are getting an architecture sprint even if it's going to be cold
<ogra_> could be worse ...
<ogra_> oslo in january for example
<kgunn> alan_g|EOD: i'm gonna poke strehel and see if we could change to that nov 18-22 week...but i'm doubting it
<racarr> kgunn: *deep breath and exhale* I guess I should go back to ABI now?
<kgunn> racarr: so alf_ and i discussed earlier....he was suggesting that changes may come wrt api/abi from scenegraph as well ...he was thinking drastic
<kgunn> racarr: question is how long that may take, and even if that's the case i was wondering...isn't some
<kgunn> kgunn: kind of coarse api distillation still useful ? (e.g. at least limit the number of headers out there in public)
<racarr> hmm
<racarr> yes that's true. wrt scenegraph
<racarr> kgunn: Ok I guess, so let's actually split the issue in to two
<kgunn> racarr: in other words, alf_ was sort of questioning whether its worth distilling the api right now priori to that
<racarr> 1. ABI is hard to maintain. 2. API is hard to maintain
<kgunn> racarr: whereas i was thinking...some effort would be good
<kgunn> racarr: yep
<racarr> the ABI is hard to maintain because we have unity8 using concrete classes, and the sheer number of things we expose (which could be internal)
<racarr> the API is hard to maintain, because of it's shape, i.e. the way we require unity8 to implement many many interfaces
<racarr> hmm
<racarr> alf may be right depending on when we really
<racarr> crack down on the scene graph
<kgunn> racarr: right, i'd like to dive in and try to make headway asap, i think greyback is going to spend some time working with kudb and you to put toghether a vision of what really needs to get done to incorporate qtscenegraph
<racarr> ok yeah my thoughts kind of trailed off this way...
<racarr> we really need to think about that
<racarr> I think maybe
<racarr> I need to do a deeper dive in to Qt/QML
<greyback> racarr: if you have a little patience, I'll write up a doc explaining the internal workings of the Qt SG
<greyback> as that's pretty important for you guys to have a decent understanding of, before we get anywhere
<racarr> Ok.
<kgunn> ug...i everytime i start thinking about it then i think...oh crap, we're gonna need parent-child relations, modality....calgon take me away
<greyback> washing machines live longer with..calgon. *bing*
<greyback> Now I remember why I don't have a TV
<racarr> I feel like I need to understand the QML side more perhaps though...
<racarr> because I still don't understand the objective outside of
<racarr> tautologically, i.e. "use the QT scene graph"
 * kgunn now on a mission to over-use the word tautologically
<greyback> racarr: the benefit for us is to be able to position/size and apply transformations/rotations to Mir's surfaces using QML's syntax
<greyback> racarr: that then means we can easily animate too
<greyback> racarr: so ideally a mir surface will be a Surface{} type, with properties like a Rectangle{}
<racarr> greyback: This is what I don't understand though
<racarr> can't a surface be a Surface{} type and have properties like
<racarr> width and height and support transformations and such
<racarr> and even be a QQuickItem (we reach the boundaries of me knowing what I am talking about)
<greyback> for simple properties yes
<racarr> and does Qt "scene graph" even have to be
<racarr> part of that?
<greyback> but transformations and clipping can depend on their parent's transformations & clipping
<kgunn> racarr: i think part of the point is....something on the qt/qml side will need that just for the qml portion to "talk" in those terms
<kgunn> before it "knows" about mir
<racarr> greyback: That's true
<racarr> Isn't it kind of a small number of things though?
<greyback> racarr: so what I need to determine is if I can calculate the total transformation
<greyback> and clipping
<greyback> it could be, but during a complex animation like the proposed right-edge swipe to show all windows animation, it could also be non-trivial
<racarr> ?
<racarr> I lost a thread
<racarr> hmm, yes I mean there can be a lot of stuff going on
<racarr> but it's a quite simple language of stuff
<racarr> there are items that can be rendered, they have transformations, clips, shaders, a few visual properties (width, height, opacity, position, etc...)
<greyback> we can also write shaders in qml to appy to elements, but yeah, that's a good chunk of the list
<racarr> My thought is that improving the mir data model to support the needed things (like parent child relationships with cumulative transformations)
<racarr> and then binding that out to QML
<racarr> is going to be much easier and more fruitful than trying to change the mir data model to be the Qt scene graph
<racarr> + the whole rendering set of questions
<greyback> That's not what I am asking for
<racarr> ?
<greyback> I want to give Mir a list of surfaces, plus their transforamtions, positions etc
<greyback> I just need Mir to support the surface properties that QML will demand
<greyback> then Mir can composite away
<racarr> *can sort of see it*
<racarr> I still have some concern over thinking about it like "want to give mir a list of surfaces though"
<greyback> On the QML side, I want to be able to manipulate a QQuickItem, which represents a mirsurface. Then I want to be able to extract the correct information about that QQuichItem from the scenegraph to give to mir
<racarr> because if you are always giving mir a list of surfaces, then you are the mir data model, it's just you are protected by a cache that you atomically update
<racarr> so then you have to worry about synchronization between what you have and everything
<racarr> on the other side
<greyback> What will be in Qt/QML will only represent the Mir surface. Qt won't be owning it, Mir will
<racarr> Ok so it's more like an adapter scene graph
<greyback> so let me rephrase, I want to set all the properties of Mir's list of surfaces
<racarr> XD
<racarr> Ok now we are getting somewhere
<greyback> but there are things I am worried about with this approach.
<greyback> One is, I'd like to draw a window shadow in QML. I can do that by surrounding the Surface{} element with something which draws the shadow - so Qt draws the shadow
<racarr> one thing that concerns me slightly is your ability to just like
<racarr> right
<greyback> but if a partly-transparent window is above another window with a shadow, how can I draw the "covered" shadows?
<racarr> I thinkkkk
<kgunn> meaning shadow (of the underneath) blended with the window on top
<kgunn> right
<racarr> ok so the most immediately correct, but
<greyback> yep
<racarr> obviously not satisfactory solution
<greyback> same with window decorations
<racarr> is
<racarr> that creating this element around the Surface{} element
<racarr> makes a new 'surface' (let's call this new thing, a layer actually, and say that a surface is also a layer)
<racarr> and it gets rendered by QML, then the compositor composites it, etc
<racarr> but this is way too horribly
<racarr> ineffecient
<greyback> right, so now Qt is rendering an extra surface for every non-opaque mir surface
<racarr> i.e. a full window sized buffer which is mostly empty for each shadow
<greyback> which it can probably do... but yeah
<racarr> right, it's no good.
<racarr> so, if we could trick QML in to sharing OpenGL contexts in a friendly fashion
<greyback> oh
<racarr> we could do this without the memory overhead right, i.e. the 'layer'
<racarr> isnt backed by a memory buffer
<greyback> that could be do-able
<racarr> and we just have QML draw in
<racarr> the compositors context
<greyback> interesting
<racarr> i.e. mir invokes layer->render()
<racarr> and layer is a MirQMLQtQuickAdapterBridgePRoxyItem
<racarr> :p
<greyback> lol
<greyback> but that is an idea
<racarr> I think this would be pretty cool, but I knwo people looked at sharing the opengl contexts in the past and it was deemed
<racarr> non trivial but maybe with the new
<racarr> renderer
<racarr> it's a more reasonable task
<racarr> or maybe it's just, a non trivial task that we should undertake
<racarr> I think if we can share opengl contexts, like that, this all becomes way easier
<greyback> people do this when mixing qml with things like vtk and other viz toolkits. Qt even addded api in 5.2 to let it reset its own context so it can continue
<racarr> ok
<racarr> I have a feeling we can probably make this approach work then.
<greyback> me too
<racarr> the other idea I had is that with things like
<racarr> shadows, etc.
<greyback> that works around one of my main concerns
<racarr> you could probably use some sort of accumulation buffer and
<racarr> a front to back
<racarr> rendering trick...
<racarr> and just always QML draws on top
<racarr> but I dunno
<racarr> lol
<greyback> I prefer the first idea :)
<greyback> well, every idea is worth thinking about before dismissing anyway
<racarr> yeah, first idea is way better. XD
<greyback> yep
<racarr> um...hmm, yeah, I feel better about this.
<racarr> one thing I don't understand is how
<racarr> like, this idea that when you surround the Surface{} element with a ShadowBox{} element
<kgunn> greyback: racarr so i think i follow in the shadow example...you avoid creating another seperate surface...but the original underneath window(surface) would need to be larger thatn it thinks right? in order to accomodate the extra shadow content
<racarr> kgunn: No, the shadow will be drawn during compositing
<racarr> directly on to the framebuffer
<racarr> or whatever buffer you are compositing too I guess
<racarr> greyback: What...um...
<racarr> greyback: I need to understand what the C++ side of QML looks like more I guess
<racarr> I don't understand how the actual mechanism will line up here, but it can't be too bad.
<greyback> racarr: start with QQuickItem then, as that represents the Item{} type
<greyback> qtdeclarative/src/quick/items/ in the qt5 source tree
<racarr> ok
<racarr> this still isn't ideal from a rendering perspective :(
<racarr> ideally the window and it's shadow would be part of the same
<greyback> qtdeclarative/src/quick/scenegraph/ for renderer
<racarr> larger than window size buffer
<racarr> like kgunn is talking about
<racarr> so that you can still use
<racarr> hardware composer/overlays
<racarr> well, you can still use sommmme overlays this way
<racarr> but not full out hardware composition
<greyback> for shadows/window decoration, why care about hardware compositing/overlay? They don't change much
<racarr> which is probably fine because on mobile we don't have most of these things all the time
<racarr> greyback: But I mean, as soon as one window has a shadow
<racarr> then we have tos witch to drawing the whole framebuffer with GL
<greyback> gotcha
<racarr> instead of using the hardware compositor
<greyback> well we'll have shadows only on desktop (maybe)
<racarr> but, I guess on mobile this is really only the path for when effects are happening
<racarr> and stuff
<racarr> right
<racarr> and on desktop
<greyback> in which case, only overlays really, right?
<racarr> ...*shrug*
<racarr> yeah. I guess. we can still use some kinds of video overlays, etc
<racarr> and it should be fine
<racarr> not sure we even care that much on desktop
<greyback> I don't want to add shadows to all Mir surfaces, as then every mir surface is not opaque, so compositing will not be that efficient
<greyback> and I like this approach as then we'd have server side decoration, and Mir wouldn't have to care about it
<racarr> its going to be really hard
<racarr> to squeeze the last drops
<racarr> of effeciency out this way...
<racarr> thinking like.
<racarr> well, our ideal shadow rendering path
<racarr> is probably
<racarr> the window texture, is the same size as the window
<racarr> and it's drawn on a slightly larger than normal quad
<racarr> and a shader
<racarr> procedurally draws the shadow/places the window texture in the center of the quad
<racarr> but all of a sudden the shadow is no no longer a qt item in the scene graph with nice properties, etc...all the details are hidden inside the shader
<racarr> not sure about how to express those sorts of things...
<greyback> which would be a pity, but not end of world either. It's a optimization...
<racarr> yes
<racarr> there are some appealing optimizations though
<racarr> like in the case of a desktop with a few non transformed windows
<racarr> but, can have some things like shadows (perhaps even decorations)
<greyback> well we can always create a custom QML element that could maybe encompass that?
<racarr> we could get away with rendering the whole desktop in a single call out to the GPU
<racarr> on a single quad
<racarr> yeah. that's what I am thinking now
<racarr> we can probably do it anyway
<greyback> sure
<racarr> we are a long way out from that I guess :p
<greyback> Well when you're in the gutter, it's good to look up at the stars
<racarr> greyback: Ah, in the US we say "When you're in the gutter, curl up in a ball and cry"
<racarr> yours is nice too though
<kgunn> racarr: greyback (distracted as usual) wrt overlay / using a shared gl context to render direct to the comp layer....
<kgunn> you would still be ok, right...i mean whatever buffer you might directly render into
<kgunn> would just be an input buffer to the overlay/hwcomposer layer
<tvoss> kgunn, if we are fine with compositing the main image with gles, and only use the hwc to blit to screen, correct?
 * tvoss wonders if we could be clever and move the indicator surface to its own hwc layer
<kgunn> tvoss: right...and most of the overlays subsystems are driven by true 2d blitting activity (can't do 3d effect...like a shadow that you might want to do with a shader)
<greyback> tvoss: we do plan to have  the launcher/dash/indicators will all have their own surfaces. Think that work almost ready. So moving one to hwc layer will do-able
<kgunn> tvoss: yes...very interesting idea
<kgunn> android panel is exactly done this way from the main view
<tvoss> racarr, greyback, kgunn ^, why don't we just move panel/indicator to its own hwc layer? with that, we could be way more aggressive in terms of composite bypassing on the main layer, too
<tvoss> kgunn, yup ;)
<racarr> tvoss: Ideally we could
<greyback> kgunn: Yes, just want input buffer to the overlay/hwc layer.
<racarr> I mean that's the thing, we could render everything in to an input buffer, then hand it off to hwcomposer
<racarr> but actually in many situations mir shouldn't have to use OpenGL at all
<tvoss> racarr, let's keep it simple in the beginning
<tvoss> I think we will get the biggest bang for the buck with 2 or 3 hwc layers
<greyback> tvoss: my lack on knowedge on hwc poking up here. Are we limited to the number of hwc layers? On desktop, I thought there were 4
<tvoss> greyback, there are definitely limits
<kgunn> racarr: greyback tvoss ...no matter what, you have to keep the gl fallback 100% of the time....its concevable altho unlikely  hw might not have an overlay
<tvoss> greyback, but I don't know the exact number off the top of my head
<greyback> kgunn: indeed
<racarr> Oh definitely
<racarr> you need the GL fallback, and many times need to switch
<tvoss> kgunn, yup, graceful fallback has to be possible
<racarr> i.e. all of a sudden there is a lot visible
<racarr> or, all of a sudden we are using
<racarr> the dash blur
<kgunn> right...you must in the instance where you do true 3d (perspective) transitions
<kgunn> right
<kgunn> actually dash blur might be ok
<tvoss> to me, it's just an implementation of surface, whether it is associated to an hwc layer
<tvoss> +detail
<tvoss> it's actually 0..* from the hwclayer perspective
<kgunn> tvoss: right...i was going to say...to the android comment, its "that way" because of how they implemented the ui
<racarr> tvoss: Well, the bit that is coming up though, is 'surfaces' (say layers) which are not backed
<greyback> racarr: mad idea you'll probably hate, for case when the hwc says no, how about having QtSG does the whole render (i.e. grabs texture ids from Mir) itself?
<racarr> by a hardware buffer, much less an HWC layer
<tvoss> racarr, sure, but that should be handled by the impl without hte consumer of the surface api having to know
<tvoss> greyback, valid
<racarr> but instead, involve Qt rendering directly in to the compositor context
<tvoss> greyback, I think we want a custom renderer for the scenegraph though
<tvoss> greyback, one that knows about mir
<racarr> tvoss: I know, but I am saying if rendering with OpenGL directly in to the framebuffer
<tvoss> racarr, the custom qt scenegraph renderer should take over the compositor
<racarr> becomes the 'common' case, i.e. say
<racarr> well all the time
<racarr> then you effectively lose your ability to use the HWC effectively
<racarr> because you always have to composite things with GL first
<tvoss> racarr, the renderer could just be clever enough, I wouldn't invest too much time in special casing
<kgunn> right but we talked about this....it might need to check with some hw/overlay first
<tvoss> racarr, I know what you mean, just saying that we can easily have hwc-awareness in a custom qt scenegraph renderer that we implement, too
<tvoss> kgunn, yup, ^ :)
<kgunn> tvoss: precisely!
<racarr> Ok but now I am confused again
<kgunn> :))
<racarr> because I thought we weren't actually using Qt scene graph, and just mir was exposing things out so QML could manipulate the mir data model in terms of QQuickItems
<greyback> tvoss: well that involves teaching QtSG renderer about HWC. I had expected that Mir would isolate that from me. I was more thinking: QtSG sets a bunch of properties on Mir's Surfaces. Mir sees if HWC will do it. If not, QtSG can render whole scene with GL directly to the framebuffer, so Mir's compositor doesn't have to
<racarr> if not, is the Qt scene graph actually the mir data model? Or is it a copy of the mir data model.
<kgunn> greyback: sure...mir could hide hwc/overlays....with an interface like "hey try this"...if it can't then you go do gl
<kgunn> that's effectively what sf is doing in dorid
<kgunn> or droid even
<kgunn> racarr: i guess as i have been watching you guys chat & think about it....i would think it could be the mir data model (e.g. its just a common data model)
<greyback> it reduces the 2 step: "Qt doing some rendering, then Mir doing compositing" into single step "Qt composites"
<greyback> is idea I want to think about more tho
<racarr> kgunn: But the mir data model also has all these synchronization responsibilities between other partso
<racarr> of mir right
<racarr> which are totally outside the scope of Qt
<racarr> so I guess I have some doubts that the Qt scene graph will work as the mir data model.
<kgunn> racarr: are we lumping control/execution in with data modeling ?
<kgunn> ...or maybe you guys see some  tightcoupling concerns i don't get
<racarr> kgunn: Well, I mean only as much as you have to
<racarr> execution is based on state right
<kgunn> racarr: totally....and from a composition pov that should be a one way street (e.g. what is executed won't effect the state/model)
<racarr> Right but we have to present different synchronized views out of the data model
<racarr> i.e. one to the compositor (in this case it's a scene graph)
<kgunn> well...at least the only info back is timing of avialability of the fb
<racarr> one to input, one to shell surface control, one to the frontend
<racarr> so the data model is kind of a larger thing
<racarr> than a scene graph you see?
 * kgunn reads over and over trying to see
<kgunn> racarr: i guess i see that you mean the data model might be used in a lot of diff places...but would it really be "different synch'd views"....meaning, wouldn't they all be looking at the same data model at any one instance in time ?
<racarr> well, they really are different views right even if it's the same data
<tvoss> greyback, will follow up tomorrow
<racarr> but they need to be in synchronization, and I think our experiences so far
<racarr> with...difficulty in synchronization XD
<racarr> kind of indicate that we are going to need some sort of smarter
<kgunn> racarr: ok, i see what you mean by view...
<racarr> data model with support for some sort of transactional idea or
<racarr> well, some sort of smart synchronization, to take all the commands and control over a given frame and present
<racarr> consistent views to all the consumers
<kgunn> racarr: mmmm....transactions like "input available/input handle", "app surf changed", "composition run", "fb avail /vsync"
<racarr> well, or maybe you need to do a series of things
<racarr> atomically
<racarr> i.e., get the main surface of a session and then deliver it focus
<racarr> or
<racarr> query things to conclude which rendering technique you need to use, or
<racarr> select the targets of touch events
<racarr> and, I mean, qt scene graph (for example) can select targets of touch events inside the scene graph, etc
<racarr> but the rules for input dispatch inside Qt, are not the same at all as the rules for input dispatch in mir
<racarr> At this point about 50% of what I am saying is nonsense though because it's just way too abstract
<racarr> greyback and I are going to work on some first steps :)
<kgunn> no worries...its fun to think about
<racarr> Haha yesi
<racarr> it's pleasant to think lofty thoughts about ideal rendering paths
<racarr> after a long bit of thinking not so lofty thoughts about
<racarr> autopilot tests and power buttons and launching applications
<racarr> lol
<racarr> and phones
<racarr> I finally switched my SIM card last night :)
 * greyback eod properly this time
<racarr> *waves*
<racarr> kgunn: Despite the rampant confusion greyback and I had a good talk elsewhere and I think we have at least a high level plan and some first steps.
<racarr> and I understand the goal now lol
<kgunn> racarr: awesome
<kgunn> thomi: hey...so i'm collecting work items, and i remembered at least 2 ...i added them here....do you have more? https://blueprints.launchpad.net/ubuntu/+spec/client-1404-unity-ui-windowmanager
<thomi> kgunn: we (meaning QA) actually have a list - we were gonna talk to you about it in Oakland
<kgunn> thomi: ack..so you wanna wait :)
<thomi> kgunn: I assume most of the planning stuff will happen at Oakland, so I figured it made sense to wait till then...
<thomi> I mean, unless you have people twiddling their thumbs right now :)
<kgunn> thomi: more like recovery via inebriation
<thomi> yeah, I'd rather have sober developers work on this stuff, if it's all the same to you :P
<racarr> I was thinking about that, one of the worst things about this distributed working is I feel like on a day like today
<racarr> the whole team should be in the bar with a licensed psychologist
<racarr> but it's just not feasible
<kgunn> no doubt
<thomi> should all fly to NZ, we'll go hiking in the hills :)
<kgunn> racarr: fwiw...i sat in for olli today on rick's meeting
<kgunn> even he looked & acted exhausted
<racarr> yeaaah :)
#ubuntu-mir 2013-10-18
<duflu> Morning didrocks. I just did a project cleanup (with branch from where saucy was released). Any thoughts? https://launchpad.net/mir/+series
<didrocks> duflu: hum, looking good but please don't push anything to saucy release anymore
<didrocks> duflu: we don't support it for touch-only components
<didrocks> and good evening ;)
<duflu> didrocks: I only pushed the changelog, as the tagged version didn't match the ubuntu release. Now it's identical
<didrocks> duflu: perfect then :)
<tvoss> katie, on my way
<katie> tvoss, ok
<w-flo> kdub, remember my mir crash (Desire Z) from yesterday? I think the problem is on line 89 in https://github.com/Andromadus/android_hardware_qcom_display/blob/cm10.1/libhwcomposer/hwc.cpp , "MAX_DISPLAYS" is (HWC_NUM_DISPLAY_TYPES+1)   .. so it's 3, and the display list passed by mir only has length 2. I haven't tested this yet, but something seems to be wrong there. is that a possible mir bug or hwcomposer bug? :)
<kgunn> greyback: do you feel the work around scenegraph is something that could be achieved by jan ?
<greyback> kgunn: until we've fully defined the task, I really can't say for sure. Would estimate by mid-next week be ok?
<kgunn> greyback: yeah...
<kgunn> greyback: just trying to line stuff up...
<greyback> kgunn: it'll be a good 2 month effort, most likely. Is that enough to help you, then I can be more specific later
<kgunn> greyback: yeah, looking for gross estimates
<alan_g> kgunn: reminder: the work around scenegraph is intimately connected to the work around the Mir data model - but they are not the same thing.
<kgunn> alan_g: is your reminder a warning about knock-on impacts to mir ...and the effort there? or rather one of architectural-vigilance ?
<alan_g> kgunn: more about ensuring that you don't conflate them in planning workload
<kgunn> alan_g: meaning we don't really have a "mir data model" at the moment ? :)
<alan_g> kgunn: meaning our data model is spread across several components and that is causing problems
<kgunn> alan_g: lol....worse than not having one
<tvoss> kgunn, what alan_g is saying that we first need to cleanup our internal data model before we can start thinking about punching in the qt scenegraph
<tvoss> alan_g, correct?
<kgunn> tvoss: even worse...its not "cleanup"...to me that's extraction-to-create a mir data model
<alan_g> tvoss: kgunn meaning we need to think about both
<tvoss> kgunn, well, that's the same to me ... but feel free :)
<tvoss> alan_g, +1
<kgunn> tvoss: sure...i will hair split on that one....cleanup would imply we have some centralized component representation already
<tvoss> kgunn, well, if you look at the very first architectural diagram, we have ;)
<kgunn> tvoss: if i look at the code tho ?
<tvoss> kgunn, obviously not
<kgunn> ;)
<kgunn> tvoss: just worried about load...and time to get there
<tvoss> kgunn, not sure what you mean? this is a must have from my pov
<kgunn> tvoss: we're in violent agreement....
<tvoss> true
<kgunn> tvoss: i would like to say we could get it preJan...but
<kgunn> complexity of it will likely push it
<alan_g> kgunn: The complexity isn't really in the implementation - more in the agreeing of requirements
<kgunn> alan_g: sure...let's let gerry have a chance to publish his thoughts from investigating & chatting with racarr/kdub a bit more
<kgunn> then we'll be able to come together to discuss more intelligently
<alan_g> kgunn: I think we should be first  factoring the current data model into a single component. (i.e. moving the misplaced bits from input and shell to surfaces).
<alan_g> kgunn: second we should be addressing the synchronization issues we have by designing a proper threading strategy in the data model
<alan_g> kgunn: Only then does it make sense to look into changing the implementation to incorporate the qt scenegraph
<kgunn> alan_g: hmmm, so you think it would _not_ be premature to refactor the current data-model bits into a single component before hearing greyback 's need/vision ?
<tvoss> kgunn, ultimately, when we are talking about a centralized component, a scenegraph will be an (admittedly) important implementation detail
<tvoss> but that's it
<alan_g> kgunn: unity is only one client of the data model. Input, compositor and shell are also clients. But it is hard to pull out the requirements from input or shell as they implement parts of the de-facto data model
<kgunn> alan_g: so you see some dup'ing of implementation (at least conceptually) between unity-mir & mir
<alan_g> kgunn: no. I'm not sure why you say that.
<kgunn> alan_g: "unity is only one client of the data model." ....& "shell as they implement parts of the de-facto data model"
<kgunn> alan_g: that's how i was reading that...
<alan_g> At present we have parts of what should be the data model in surfaces, parts in input, parts in shell and parts in unity8. That is wrong. Implementation that support communal data access should be in surfaces and nowhere else.
<alan_g> kgunn: clients of the data model do not implement the data model, they use it.
<greyback> alan_g: I agree that per-surface data should be in one place. I don't see how fixing that blocks the SG task (whatever we decide that to be)
<greyback> but right now, until we're clear on what the SG task actually is, I don't want to start discussing potential work items
<alan_g> greyback: I just doubt that deciding how (or whether) to use a SG and how to fix the data model can be done independently.
<alan_g> And like tvoss says "a scenegraph will be an (admittedly) important implementation detail"
<greyback> alan_g: ok. While I cannot contribute to the Mir-side discussion, I can discuss my proposal(s) with you, and see what overall is the best solution for both of the projects
<greyback> but I need to get the proposals clear first
<alan_g> greyback: for sure. Similarly, cleaning up the existing model will make clear what it is and how it is being (ab)used.
<greyback> alan_g: most likely yes
<blead> hello, anyone know where to get the mir multi boot installer for N7
<slangasek> kgunn: hi!  so xnox is working on the goldfish emulator bring-up, and he's at the stage now where he needs to get graphics output working... is there somebody who could help him from the Mir side to get this wired up correctly?
<alf_> alan_g: @mir_connect_impl shouldn't throw, ok I didn't see try/catch in the impl we use in the tests (tests/mir_test_framework/testing_process_manager.cpp) and thought there wasn't any guarantee. I will fix the test _impl and remove the try/catch from the client library
<alan_g> alf_: I'm not blocking on it
<alf_> alan_g: hmm, now that I check again,  mir_default_connection_release doesn't try/catch either. OK, I will leave it for now then, and we can clean up in the future...
<alan_g> alf_: "it shouldn't throw" unfortunately doesn't mean "it can't" - we should probably abort or something (or at least have the option to)
<kdub> sometimes, i wish std::shared_ptr was just std::sp
<alan_g> kdub: "using sp = std::shared_ptr;"
<kdub> yeah, but not mir style :)
<alan_g> kdub: put the case for a change in style?
<kdub> maybe...
<mlankhorst> please please dont, I only touch mir code when debugging stuff you blame mesa about, and renaming things like that make it harder for me to understand it
<alan_g> ;)
<kdub> yeah, probably easier all around not to
<kdub> i should just rewire F8 to spit out "std::shared_ptr" :)
<kgunn> slangasek: just have him ping here...if u.s. time, kdub or racarr
<slangasek> kgunn: ok - and if he's UK time? :)
<slangasek> (since he is :)
<slangasek> xnox: ^^
<kgunn> slangasek: then alf_ or alan_g
<slangasek> ok, perfect - thanks
<kdub> emulator stuff should find its way into a bp or something
<kdub> from my perspective, its about the same amount (or more)  effort as a new physical device
<xnox> kdub: was mir ported to each nexus device separately? emulator suppose to behave similarish to android...
<kdub> it should, but i'm sure there's some kinks to work out
<xnox> ok.
<kdub> we're still transitioning to pick up all devices, some don't work just yet
<kdub> so, from an architectural viewpoint, they should be the same
<kdub> but i'm sure there will be some bugs that stop it from working at first that we'll have to work through
<w-flo> kdub, BTW, I've posted a bug + patch for my latest HTC Desire Z issue with mir (we talked about that yesterday): https://bugs.launchpad.net/mir/+bug/1241683
<ubot5> Ubuntu bug 1241683 in Mir "[Desire Z Port] Mir segfault in libhwcomposer.so; display array too short" [Undecided,New]
<kdub> w-flo, i'll take a look
<kdub> w-flo, its a hwc bug, iirc
<kdub> that we patched on the official builds
<w-flo> kdub, okay, I can change my hwc to handle it. but that same code appears to be on phablet.ubuntu.com
<w-flo> oh, wait. maybe I've looked in the wrong place then
<w-flo> http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_hardware_qcom_display-caf.git;a=blob;f=libhwcomposer/hwc.cpp;h=75f62b6efd19768bfbddb4162d5f1c7cb952236a;hb=refs/heads/phablet-saucy <-- this looks similar to my and CyanogenMods (possibly buggy) libhwc
<kdub> w-flo, does it work after the patch? :)
<kdub> the device on the whole
<w-flo> uhm.. yeah, with flickering and keyboard  not showing up, etc
<w-flo> it's better, but still not good enough to actually use it
<kdub> yeah, good to hear though
<w-flo> It's nice to see mir working on that rather old device, I agree :)
<kdub> w-flo, trying to find the patch we use in nex4...
<kdub> w-flo, i'm working on better hwc fencing support at the moment (should help with that flicker on your device)
<w-flo> I guess I could simply replace that MAX_DISPLAYS with the old HWC_NUM_DISPLAY_TYPES, I just wasn't sure if it's a bug in HWC or actually intended behaviour
<w-flo> since it seems they changed that for loop recently so it's 3 iterations instead of 2
<kdub> i think with this function, its supposed to be sorta like the attributes eglChooseConfig, you have an array terminated by a value
<kdub> and it looks like qcom just copied the array that surfaceflinger submits and assumes nothing other than SF would ever use the function
<w-flo> ah, so.. just stop on encountering a NULL pointer
<w-flo> well, qcom is amazing %)
<slangasek> kdub: yes, I expect it will be a non-trivial amount of work to get Mir working on goldfish; but this needs to happen ASAP, we are hurting badly by being dependent on hardware for all of our testing.  If making it a blueprint is what needs to happen to get this made a priority, then I'm happy to make a blueprint...
<kdub> kgunn^^
#ubuntu-mir 2013-10-19
<pfifo> Im going to give mir a shot, going to build from source.
<wolter> Are there any foreshadows of Mir working with proprietary drivers (or nVidia helping nouveau further)?
<pfifo> The following tests FAILED: 4 - acceptance-tests.ClientPidTestFixture.* (Failed)
<pfifo> but it worked on a second try :)
<pfifo> I had to 'make doc' in order to get 'make install
<pfifo> I had to 'make doc' in order to get 'make install' to work, the tutorial didnt say anything about that
<pfifo> I had to edit my ld.so.conf so that mir could find libmirserver.so.8
<pfifo> but mir is running nativly now
#ubuntu-mir 2013-10-20
<pfifo> ok now im running into a real problem, I am trying to build unity-system-compisitor, but I cannot find the file 'mir/pause_resume_listener.h' well technically >I< can find it, its at '/usr/include/mirserver/mir/pause_resume_listener.h' it looks like it was installed into the wrong location, or perhaps the install locations changed and unity-system-compisitor hasnt updated their code yet? What should I do?
<pfifo> well I gave up on trying to build it myself, and installed the binary package, but that created all sorts of problems :( I think im going to have to hold off on mir hacking til it gets a bit more
#ubuntu-mir 2014-10-13
<alan_g> DOes anyone know what this amd64 "virtual memory exhausted: Cannot allocate memory" error is?
<anpok_> strange and unpleasent are two adjectives ..
<anpok_> it started to happen last week
<anpok_> never had a closer look
<greyback> alan_g: had chat with ricmm about https://code.launchpad.net/~alan-griffiths/platform-api/delete-dead-code-that-uses-Mir-PrivateProtobuf-API/+merge/237265 - our views are in the comment
<anpok_> alan_g: alf__ kdub: made two versions
<anpok_> cannot decide between home grown type info or type info :)
<alf__> anpok_: ENOCONTEXT
<anpok_> the abi stable server_configuration thing...
<anpok_> the two mps i just proposed
<alan_g> greyback: I see. Should the bodies be empty or "throw std::logic_error("Not implemented");"
<greyback> alan_g: empty please
<anpok_> alf__: regarding those proposals.. and alans Server MP..
<anpok_> the benefit of having boths..
<anpok_> the remaining ABI breaker in mir::Server will be the addition, rearrangement or removal of interfaces in the interface of mir::Server itself..
<anpok_> by interfaces I meant
<anpok_> wrap_...() or the_...() methods
<alf__> anpok_: addition and rearrangement of these function are not ABI breaks (since they are not virtual)
<anpok_> ok havent noticed.. i blindly assumed them being virtual
<anpok_> then you are right .. we wont need both then
<alan_g> What is the point of mir_demo_server_translucent?
<anpok_> alan_g: demonstrate how to enforce a transparent or opaque buffer for a nested server
<alan_g> anpok_: does it need to be a separate executable? Or can it be a switch on basic?
<anpok_> hmm
<anpok_> switch would be a lot better
<anpok_> alan_g: i even think it would be nice to have it inside default config?
<alan_g> anpok_: I'll just make it a "basic" switch for now - into default is more disruptive.
#ubuntu-mir 2014-10-14
<alan_g> greyback_: does this work for you? https://code.launchpad.net/~alan-griffiths/platform-api/delete-dead-code-that-uses-Mir-PrivateProtobuf-API-without-ABI-break/+merge/238194
<greyback_> alan_g: looks like it's good. Will test it shortly
<alan_g> alf__: do you need to review this or may I TA? https://code.launchpad.net/~andreas-pokorny/mir/drop-input-configuration/+merge/237751
<alf__> alan_g: please go ahead
<alan_g> done
<alan_g> alf__: anpok - your comments addressed, care to re-review? https://code.launchpad.net/~alan-griffiths/mir/a-simpler-server-setup/+merge/237990
<anpok> alan_g: yeah already on it..
<kdub> -ETOOMANYREVIEWS
<greyback_> alan_g: https://code.launchpad.net/~alan-griffiths/platform-api/delete-dead-code-that-uses-Mir-PrivateProtobuf-API-without-ABI-break/+merge/238194 - one small comment, works fine though
<alan_g> greyback_: ack, looks...
<alan_g> greyback_: looks like dandrader beat me too it
<greyback_> alan_g: oh feck, I'd no idea. Sorry about that
<alan_g> greyback_: np - what I care about is that Mir doesn't need to support that API
<racarr> Morning
<anpok> hi
<anpok> racarr: some time ago you mumbled something about resampling input.. will that have impact on MirEvent or the android input stack event structures?
<racarr> anpok: No its just in the client
<anpok> so within or around the input reader?
<racarr> doing linear interpolation and or extrapolation of motion events (with tool-type=finger)
<racarr> anpok: Actually on the client
<racarr> so far
<racarr> in the receiver
<racarr> I question that decision lol...but thats where android put it
<anpok> hmm
<anpok> it could be in the kernel :)
<racarr> lol
<racarr> tbh most of it should be in the touchscreen
<racarr> 90% of it is just
<racarr> an attempt to match up the refresh rate
<racarr> of the display and the touchscreen
<racarr> so you can get a uniform number of input frames per
<racarr> video frame
<anpok> yeah the devies should have a sync option
<racarr> which to me seems like it could be done by
<racarr> yeah
<racarr> hooking up the clocks lol
<racarr> on krillin we have
<racarr> 57hz v 100 hz
<racarr> lol
<anpok> racarr: i was thinking today about moving input channel out of surface.. and look at inputdispatcher again..
<racarr> anpok: Oh?
<anpok> racarr: we have two code paths there right now
<anpok> to get input events to clients
<anpok> brb
<kdub> camako, is the needs info addressed? https://code.launchpad.net/~kdub/mir/fix-1378326/+merge/237827
<camako> kdub, I'll put some concerns in the review but approve... we can always change it..
<kdub> thanks!
<anpok> hm why would we ever need a different clear color than 0,0,0,0?
<tedg> I'm trying to rebuild this silo that Saviq made and it's getting a qtmir error.
<tedg> Can someone give me a hand with that?
<tedg> https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-006-1-build/46/console
<racarr> tedg: I am not an expert on this particular issue but I
<racarr> if I was rebuilding a silo and ran in to a qtmir-gles error I would toggle the little box on the build form
<racarr> about "twin packages" :p
<tedg> racarr, Yeah, I tried that, it didn't seem to fix it :-/
<racarr> ;(
<tedg> It had the gles example there.
<racarr> tedg:  I dont really know then sorry, I've yet to find an explanation for the whole twin packaging setup in CI
<racarr> camako: "bzr: ERROR: Unable to find the needed upstream tarball for package qtmir-gles, version 0.4.3+14.10.20141014.1." in silo build...familiar to you?
<tedg> np, thanks for looking racarr!
<racarr> anpoks typeinfo branch is so cool
<racarr> but it does seem that a-simpler-server-setup is...a lot simpler :p
<anpok> racarr: thx
#ubuntu-mir 2014-10-15
<duflu> Wow, platform-api needs some love. It has merge proposals untouched going back 18 months
<anpok_> duflu: you misunderstood the mp.. though we already settled with the other.. the instantiation is pushed to the code using the configuration.. and in case of internal code will not be exposed as a symbol and in case of somebody outside of mirserver using it.. it will reside there
<anpok_> so it is not part of the abi
<duflu> anpok_: Isn't that still DefaultServerConfiguration? That's the leaf of the class hierarchy
<duflu> Using templates still means just as many real functions get created. If they're that easily moved then we probably could have done it without templates
<anpok_> hmm people could just interact with serverconfiguration and insert or query whatever they need
<duflu> Maybe we have already -- I'm not going to start looking at the other branch
<anpok_> and thats kind of the ugly side
<anpok_> as it is harder to figure out what is provided and who pushes inside..
<anpok_> hmm
<anpok_> i added the templates to have it type safe
<anpok_> otherwise i would have to expose the shared_ptr<void> based interface
<duflu> anpok_: Doesn't matter now if something else has been chosen. And for my own sanity I need to not look at it any more till the sprint at least
<anpok_> well I am not entirely convinced of both solutions..
<duflu> Too many MPs
<anpok_> but alans one is the better one for now
<anpok_> untill we get wiser..
<anpok_> and maybe still then
<duflu> anpok_: Wiser still to stay out of it all ;)
<anpok_> alf__: alan_g: WrappingBuilder instead of Wrapper?
<alan_g> Why? It uses more words to convey the same concept.
<anpok_> because it is only the function returning a wrapper.
<alan_g> wrapper: 1. a person or thing that wraps.
<alan_g> (You're thinking "2. something in which a thing is wrapped.")
<alan_g> BuildingFunctor/WrappingFunctor :^)
<anpok_> alan_g: you mean it wrapps the functor that builds the type
<alan_g> no. There's a functor that builds and a functor that wraps
<anpok_> ok
<anpok_> brb
<kdub_> AlbertA2, with thte frameskipping/krillin issue, that doesn't occur with overlays on correct?
<alan_g> kdub_: does render_overlays do anything useful on desktop (I get an exception "trying to createGBM buffer with unsupported pixel format")
<kdub_> alan_g, it could be used to try out bypass, but in the current form thats not easy to do
<kdub_> and that issue would be something else to figure out what's going on
<kdub_> it needs some sprucing up, mostly to render more interesting things, and perhaps have more indicative output of what's going on
<kdub_> in terms of accepting/rejecting an optimization
<alan_g> kdub_: OK (I wanted to check I hadn't broken - but if it seems already broken)
<alan_g> thanks
<kdub_> yep, no problem
<kdub_> https://bugs.launchpad.net/mir/+bug/1381552
<ubot5> Ubuntu bug 1381552 in Mir "mir_demo_standalone_render_overlays should be more useful" [Wishlist,New]
<kdub_> seems it needed a wishlist bug
<AlbertA2> kdub_: right I have not seen it happen with overlays
<kdub_> AlbertA2, i've been watching for a while with overlays disabled, and I havent seen it
<AlbertA2> kdub_: egltriangle?
<kdub_> yes
<AlbertA2> I wonder if we got a new vendor binary blob
<kdub_> possible
<robotfuel> greyback_: I have a better stacktrace in https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1377332
<ubot5> Ubuntu bug 1377332 in unity8 (Ubuntu) "UI randomly freezes" [High,Confirmed]
<greyback_> robotfuel: thanks
<greyback_> robotfuel: the spinner was animating?
<robotfuel> greyback_: yes there is a link to video on my chinstrap account
<greyback_> robotfuel: yep I saw that from the video
<greyback_> just wnated to confirm
<greyback_> robotfuel: is it still hung, or have you rebooted it?
<robotfuel> greyback_: I've re-imaged with todays image :/
<robotfuel> greyback_: I think I still have log files
<greyback_> robotfuel: nah, I would have asked for you to install a few more debug packages, as there's some symbols missing which could help
<robotfuel> greyback_: I can do it next time, which packages?
<greyback_> I'm just about to set off some more random testing myself, so with luck I'll get it
<greyback_> robotfuel: dandrader mentioned them in comment 22: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1377332/comments/22
<ubot5> Ubuntu bug 1377332 in unity8 (Ubuntu) "UI randomly freezes" [High,Confirmed]
<robotfuel> greyback_: ah I didn't install those, just the qt dbg packages, I'll make sure to install those on the next one.
<greyback_> robotfuel: thanks. If you get another hang, please ping me
<robotfuel> greyback_: actually the phone hasn't been imaged yet, I can still install those.
<greyback_> robotfuel: well if you get hang, we cna attach gdb, try generating stacktrace, see what debug symbols we need, install them and try gdb again
<kdub_> tricky to see the best place to put the fd size description
<kdub_> in the ipc layer
<kdub_> the header, the wire protocol, or the mir protocol...
<kdub_> we currently have it in the mir protocol, which seems wrong
<robotfuel> greyback_: are you still around? I have another ui freeze
<greyback_> robotfuel: yep
<greyback_> robotfuel: please attach gdb to the frozen unity8 process, and do a backtrace
<robotfuel> greyback_: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1377332/+attachment/4237481/+files/gdb.txt
<ubot5> Ubuntu bug 1377332 in unity8 (Ubuntu) "UI randomly freezes" [High,Confirmed]
<robotfuel> greyback_: done :D
<robotfuel> greyback_: this one is on mako instead of krillin like before
<greyback_> robotfuel: ok. In gdb, would you mind entering "info threads" and pasting the output to me
<robotfuel> greyback_: the backtrace unlocked the freeze
<greyback_> robotfuel: that isn't possible, but more likely something timed out and unblocked the rendering
#ubuntu-mir 2014-10-16
<alan_g> alf__: duflu anpok_ is BufferInitializer a feature we intend to support? https://code.launchpad.net/~alan-griffiths/mir/render-examples-using-a-simpler-server-setup/+merge/238469/comments/585656
<alan_g> We don't - for example - have an acceptance test
<duflu> alan_g: From memory I wanted to kill it. There's no realistic use case outside the examples
<anpok_> hmm you get the buffer
<anpok_> but you have no other context
<alan_g> duflu: I suspected as much. There's no security concern requiring steps to initialize a buffer before handing it out?
<duflu> alan_g: I think we could replace it more elegantly using software buffers where the examples use it
<duflu> alan_g: If so then that might be a GBM/Mesa bug. Not sure if we have a requirement to clear new buffers
<alan_g> "the examples" == render_surfaces?
<duflu> alan_g: Yeah whatever it was. There may only be one
<anpok_> hm i doubt mesa or drm driver will clear it
<duflu> I'm not sure that's relevant... if we don't already clear buffers in the server lib
<alf__> duflu: alan_g: anpok: Yeah, there is no guarantee that we get a cleared buffer
<anpok_> but should we use that interface to implement clearing then?
<alan_g> But if the only conceivable requirement is to clear it we don't need a customization point
<anpok_> yes
<alf__> alan_g: anpok_: BufferInitializer was mostly a convinience, we could probably implement the same functionality differently in render_surfaces, e.g., wrap the display and the buffer allocator, but I am not sure if that's much better in terms of hiding/exposing API.
<alf__> anpok_: alan_g: ... (which I guess is the driving concern here)
<seb128> did Mir changed in a way that made the GTK backend stop working? does anyone know if that's a known issue?
<seb128> starting e.g gedit used to work and now hit "Gdk:ERROR:/build/buildd/gtk+3.0-3.12.2/./gdk/mir/gdkmireventsource.c:417:gdk_mir_event_source_queue_event: code should not be reached"
<seb128> I guess that's more one for robert_ancell but he's not around anymore for today
<alan_g> seb128: it isn't known to me anyway
<seb128> was there any recent change in Mir that could lead to such issues?
<seb128> we need some automated tests to make sure Mir updates don't make GTK stop working
<alan_g> Or at least to tell us about it
<seb128> yeah
 * alan_g wonders where the gtk code is
<seb128> alan_g, you don't want to know ;-)
<seb128> alan_g, http://bazaar.launchpad.net/~ubuntu-desktop/gtk/ubuntugtk3/view/head:/debian/patches/mir-backend.patch
<alf__> alan_g: seb128: Yeah, probably apt-get source is the best way to get it :)
<seb128> alan_g, I think the vcs is https://git.gnome.org/browse/gtk+/log/?h=wip/mir
<seb128> alf__, ^
 * alan_g doesn't want to know
<alf__> seb128: A quick look indicates that we probably added some mir event that the code is not handling
<seb128> ok
<seb128> I'm going to let robert_ancell know, thanks
<alf__> seb128: btw, I think the event switch statement in question is too strict, it should ignore unexpected events (and perhaps log a warning) instead of aborting
<alf__> seb128: np
<alan_g> +1
 * alan_g thinks a compile time warning would be better than a run time error.
<alan_g> (Not that C makes it easy.)
<seb128> alan_g, alf__: thanks
<alf__> anpok: Hi! In test_asio_main_loop why do we need "evaluate_clock_alarm" in AdvanceableClock ?
<alf__> anpok: Is it to guarantee that all time dependent actions for which the timeout has been reached will have been triggered?
<alan_g> alf__: @"green background" that's been gone a while - but I didn't notice when it happened
<anpok> alf__: thats to make the code that handles timers look for the current time again
<anpok> alf__: the code advances time and believes that if a new alarm is created the system will look for current time and calculate diffs..
<anpok> alf__: thats the poor mans solution that does not involve duplicating asios timer functionality
<alan_g> camako: kdub_ anpok - anyone want to express an opinion? https://code.launchpad.net/~alan-griffiths/mir/basic_server-using-a-simpler-server-setup/+merge/238184
<kdub_> alan_g, +1 from me, i don't mind taking things one step at a time
<alan_g> kdub_: thanks (I think that discussion was off the point of the MP anyway)
#ubuntu-mir 2014-10-17
<slvn_> Hi, I have posted a feature request on libmirclient
<slvn_> https://bugs.launchpad.net/mir/+bug/1382209
<ubot5> Ubuntu bug 1382209 in Mir "[Enhancement] Add an API to lock surface orientation" [Undecided,New]
<slvn_> It would be nice if someone could consider it !
<slvn_> This is my last blocker to submit application for ubuntu touch
<tvoss> slvn_, thanks for the bug report :)
<slvn_> tvoss, you're welcome ! I need this feature, to publish my SDL application ! I need anyone porting an SDL game, or any native application will need this feature !
<slvn_> I  think anyone porting an SDL game, or any native application will need this feature !
<tvoss> slvn_, yup, I think I know what you are after. Out of curiosity: did you use our sdl 2 backend for porting purposes?
<slvn_> tvoss,  yes of course !   I have had any talks and help with bschaefer about it ! and I also a reported a few minors fixes
<tvoss> slvn_, awesome, thank you
<slvn_> (and I got help from many people here ! for cross-compiling and making think works)
<tvoss> slvn_, great,thanks for the feedback :)
<slvn_> s/think/thing
<slvn_> from my point of view. Developing native app on ios/android/winrt/nacl/macox/linux
<slvn_> the main blocker remaining to develop native app
<slvn_> is this orientation issue !
<kdub_> alan_g, are you working on https://code.launchpad.net/~alan-griffiths/mir/spike-making-render_surfaces-an-example/+merge/238562/comments/586081 ? If not I'll take it up
<alan_g> kdub_: I'm not - what are you thinking of doing with it?
<kdub_> alan_g, just seeing if its possible to just override the DisplayBufferCompositor, and get rid of the factory
<alan_g> That would be good to establish
<kdub_> its looking easier to use so far
<kdub_> we don't have to make the overriding code fiddle with our funny compositor id system
<alf__> kdub_: Note that the factory is there so that the implementation could: 1. Provide customized/optimized DisplayBufferCompositors for maximum performance (e.g. with a gl renderer tailor-made for each display buffer)
<alf__> kdub_: 2. Easily handle dynamic construction/destruction of DisplayBufferCompositors as display configurations change
<kdub_> alf__, but as it is, one DisplayBufferCompositor is made for each displaybuffer
<kdub_> and, as things change, it seems easier to just adjust the existing gl program than construct a new one
<kdub_> but its good to keep in mind
<alf__> kdub_: right, that was the point, create a DisplayBufferCompositor tailor-made for each displaybuffer
<kdub_> I'm still missing some part of the argument
<kdub_> alf__, ^^
<alf__> kdub_: ok, so, what is the plan for handling multiple display buffers internally in the new version of DBC? (e.g. two different calls from different threads for dbc.composite(db1,...) dbc.composite(db2,...) ?
<kdub_> the gl program adjusts
<kdub_> I guess the real win in terms of ease of use is moving the SceneElementSequence
<alf__> kdub_: note that dbc.composite() calls could be concurrent, we can't have a single gl program, we need one for each displaybuffer
<kdub_> well right, one dbc per displaybuffer
<alf__> kdub_: One dbc per displaybuffer? I am confused, I thought that you were suggesting a single dbc for all?
<kdub_> no, just shifting how the DisplayBufferCompositor gets the DisplayBuffer
<kdub_> right now, we force the implementers of DisplayBuffer to go through the DisplayBufferCompositorFactory and their own constructors to get the DisplayBuffer to use
<alf__> kdub_: ok, without a factory how do we create new DisplayBuffers in MultiThreadedCompositor when the configuration changes?
<kdub_> I'm a bit more focused on making the DisplayBufferCompositor::composite easier to use
<kdub_> still not sure if getting rid of the factory is doable
<kdub_> still exploring
<alf__> kdub_: sure, I am trying to use the socratic method (on both of us :)) to bring to the surface all the parameters that may affect the decision.
<kdub_> socratic method... the true greek way :D
#ubuntu-mir 2015-10-12
<duflu> RAOF: Thanks for fixing Mesa
<duflu> It's like nothing was ever broken...
<duflu> RAOF: Was it actually a Mesa bug or Mir+Weston doing the same bad things?
<RAOF> duflu: Mesa bug.
<RAOF> It was incorrectly rejecting BGRA8888 textures.
<duflu> RAOF: Oh _the_ Mesa bug?... http://lists.freedesktop.org/archives/mesa-announce/2015-October/000179.html
<RAOF> Yeah, that mesa bug.
 * duflu pulls out the big guns (240FPS camera)
<zzarr> hello lovely people! how is the MIR display server coming along?
<alan_g> pretty good. Thanks for asking.
<zzarr> :)
<zzarr> I read that MIR will support the Vulkan API :D
<zzarr> is there MIR (Android/libhybris I assume) drivers for for RockChip RK 3288?
<zzarr> -is + are
<alan_g> As you surmise we don't have specific drivers for individual chips. I don't know if that one's been tested.
<zzarr> okey, thanks for you reply
<zzarr> I hope to install Ubuntu with MIR/Unity8 on my ASUS ChromeBook Flip in the future
<zzarr> does anyone know how long until XMIR will be installed in a default Ubuntu?
<zzarr> Is it likely in the next LTS?
<anpok_> as long as it is needed I supposed.. and it is neeaded to support X applications, I doubt that we can already estimate when those might disappear from the default install image
<anpok_> -d
<zzarr> so what does that mean in a time perspective?
<alan_g> No-one can know. It is matter of where Canonical chooses to put its effort - and that can change as market conditions change.
<zzarr> okey, thanks for clearing that up :)
<alan_g> yw ;)
<zzarr> I long for MIR/Unity8 ;)
<alan_g> is there a specific reason?
<zzarr> I love it :)
<zzarr> I have it on my phone (Meizu MX4 Ubuntu Edition)
<Guest42341> what happened to mx4?
<zzarr> have anything happened to it?
<zzarr> my works fine
<Guest42341> you can't buy one now
<alan_g> they sold out
<Guest42341> and closed the store :))
<Guest42341> Dear customer, this page (Meizumart.com) is now closed.
<Guest42341> http://www.meizumart.com/
<zzarr> ohh, to bad :(
<zzarr> will I be able to use a USB/HDMI converter any time soon? (MX4)
<ogra_> no
<ogra_> i mean, the USB part might work ... but HDMI wont
<zzarr> ogra_, I know I have asked the same thing before, but it was a long time ago
<zzarr> thanks for your reply
<anpok_> Guest42341: the models flashed with ubuntu touch were sold out afaik.
<Guest42341> anpok_, all 4?
<Guest42341> joking
<Guest42341> i hope they'll sell more mx4 or mx5  :(
<Guest42341> mx4 is a really nice phone
<anpok_> well the future will have nicer and hopefully more phones..
<anpok_> robert_ancell: not necessarily in wily..
<anpok_> but in the current phone overlay
<robert_ancell> anpok_, ok, cool. Will leave that until x-series then.
<anpok_> hm when will the x-series be opened/
<anpok_> it will be relevant for mir-0.18
<anpok_> but in the worst case we would just land it with it..
<robert_ancell> In a few days I think.
<anpok_> oh fine
<greyback> alan_g: I'm still mystified why your CI job fails. I can't repro locally, no matter what I try
<alan_g> greyback: nor I.  I'm narrowing things down by experimenting in CI
<greyback> pete-woods: have you any tips on debugging qtdbusmock? We get dbus failes on one particular MR, for no obvious reason I can see: https://jenkins.qa.ubuntu.com/job/qtmir-vivid-amd64-ci/194/console
<greyback> "Connection Timeout: disconnecting client after 300.0 seconds"  <- never seen that error before in CI
<pete-woods> greyback: I have, on occasion seen that error
<pete-woods> but I don't know what the problem is
<greyback> odd it's stuck to that MR
<pete-woods> is dbusmock really not starting?
<pete-woods> (i.e. check the process list)
<pete-woods> if it is starting, then it must be some race type thing in the service init waiting code
<pete-woods> okay, read the output now
<pete-woods> greyback: the dbus daemon itself doesn't seem to be starting...
<pete-woods> greyback: I could only suggest gradually reverting bits of the MR until you get something that passes?
<greyback> alan_g: ^
<pete-woods> let me check how libqtdbustest handles dbus failing to start
<greyback> pete-woods: it's a python script which implements the mock dbus interface, right?
<pete-woods> greyback: yeah, libqtdbusmock tells libqtdbustest to start a python process with the right command line args
<greyback> could that be failing to start?
<pete-woods> doesn't look like it
<greyback> ok
<pete-woods> libqtdbustest starts a private instance of dbus before any of thing
<pete-woods> *this
<pete-woods> dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
<pete-woods> says that python reckons there's no system dbus
<pete-woods> then libqtdbustest says:
<pete-woods> C++ exception with description "Process [python3] for service [com.canonical.powerd] failed to appear on bus" thrown in the test fixture's constructor.
<pete-woods> which means that the python process started, but never successfully connected to the system bus
<pete-woods> presumably because it's not there
<pete-woods> so either the system bus isn't starting for some reason (weird environment?)
<pete-woods> or there's some security / confinement type policy that is stopping comms with dbus
<greyback> pete-woods: understood. Can I ask you to consult on #ubuntu-ci-eng if I get someone to look into it?
<pete-woods> greyback: sure
<greyback> thanks
<alan_g> greyback: still waiting on the final CI confirmation, but it seems that the same changes in a new MP don't have the problem. Bizarre!
<greyback> alan_g: absolutely. Is one of those can't print on Tuesdays bugs
<alan_g> I'll check findings and tidy up first thing tomorrow.
<greyback> thank you
#ubuntu-mir 2015-10-13
<RAOF> Ok. I want a new Dell XPS 15.
<anpok> those are nice
<RAOF> In a shocking twist, that took longer than I expected :)
<RAOF> But there's a kinda-sorta-working multistream demo.
<RAOF> ...and then when you realise that MirGraphicsRegion.stride is in bytes rather than pixels, everything even looks approximately right!
<alan_g> greyback_: fixed: https://code.launchpad.net/~alan-griffiths/qtmir/test-harness-for-MirWindowManager/+merge/274221
<greyback_> alan_g: just a different MP?
<alan_g> I couldn't reproduce, but I *think* LP got the prerequisites in a tangle.
<alan_g> In the end I overwrote the branch with an identical head and recreated the MP.
<greyback_> strange, but glad that issue has gone away
 * alan_g wishes he could have reproduced but can't justify investing more time into understanding.
<Saviq> anpok, pmcgowan has the "screen doesn't go off" issue right now, can you find him and provide any guidance as to how to debug?
<Saviq> anpok, unping, alf's helping already
<seb128> kgunn, do you know what's the status to land a mir version that builds in wily?
<alan_g> seb128: waiting on QA I think. alf ^?
<alf> seb128: Mir 0.17 is in "Ready for QA" state in ci-train, if that's what you mean
<alan_g> alf: seb128 actually, that's the "dual" landing to overlay. We also need to copy across to wily.
<seb128> alan_g, do you need somebody to do the copy for you?
<seb128> alf, unsure, train landing don't go to distro by default anymore, so maybe the answer is that we need to land that and pocket copy then
<alf> seb128: alan_g: ah, you mean the real wily, yes we would need to copy after release to the overlays
<alan_g> seb128: yes, we will.
<seb128> great
<kgunn> ack, will help keep an eye on as well
<dandrader> anpok, do you happen to know what's the usual value range for the pressure axis?
<dandrader> anpok, is it something like [0,1]?
<anpok> hm
<anpok> i think we might not have normalized the values in the past..
<anpok> but with the new input stat it will be [0,1]
<anpok> *stack
#ubuntu-mir 2015-10-14
<RAOF> Oh.
<RAOF> / TODO support surface modifications
<RAOF> Well, that's why m_surface->generate_renderables only ever returns one renderable, then.
<RAOF> We should be handling set_streams calls before handing the request on to the shell.
<RAOF> Yeeees!
<RAOF> I win the subsurface award!
<RAOF> Hm.
<RAOF> Positioning is not quite right.
<RAOF> SHIP IT ANYWAY!
<greyback_> alan_g: hey, I was porting qtmir to the WindowManagement API (removing SessionListener) last night, and noticed that the WM has no notion of prompt sessions. Is that intentional?
<greyback_> also, are you planning on removing mir::shell::Shell, as it duplicates much of WindowManager
<alan_g> greyback_: I've "not needed" prompt sessions for any of the window management work I've done in Mir (yet)
<alan_g> I've shown you this before: https://code.launchpad.net/~alan-griffiths/qtmir/window-management/+merge/274241
<alan_g> It's been waiting on the simpler stuff to land
<greyback_> alan_g: yep, you have. I just wanted to remove SessionListener and make more use of WM. Hopefully doesn't conflict too much
<alan_g> greyback_: sure, all part of the same migration. are prompt sessions a blocker?
<greyback_> alan_g: not at all. Just curious about the direction
<alan_g> Well, for direction, I'd like to "internalize" Shell and "publish" BasicWindowManager - but the latter needs more work.
<greyback_> ok
<alan_g> greyback_: any more thoughts? https://code.launchpad.net/~alan-griffiths/qtmir/test-harness-for-MirWindowManager/+merge/274221
<greyback_> alan_g: I don't think I had.
<greyback_> approved
<alan_g> thanks
 * alan_g wishes he could mount an sd card with a useful filesystem
<anpok> vogons: should we use the dso versioning guide also for loadable modules?
<anpok> ... modules as in platforms.. /me doesnt see the need as the most part of the abi is not inside the set of symbols.. but the vtables..
<alan_g> anpok: There's clearly a need for some versioning. I've not thought about whether the guide covers it.
<anpok> i have to bump input platform abi right now.. so I would have to either go to '4' or 0.18.0
 * alan_g decides to read what the guide says today....
<anpok> :)
<popey> robert_ancell: bug 1421575
<ubot5`> bug 1421575 in xserver-xorg-video-intel (Ubuntu) "Desktop corruption when changing monitor config" [High,Triaged] https://launchpad.net/bugs/1421575
<alan_g> anpok: so your only question is about "_4" vs "_0.18"?
<anpok> yes
<alan_g> "_0.18" makes sense to me
<anpok> i mean the motivation for that naming for client comman and server .. and platform dso versioning does not seem to apply here. So I wasnt sure to use that naming for platforms
<anpok> *common
<alan_g> Well, the argument that having a name related to the release is easier to get right still applies
<anpok> for the package and shared library name.. yes
<alan_g> anpok: It would be more consistent with "horizontal_scroll_scale" to have "cursor_acceleration_bias".
<anpok> right
<alan_g> anpok: As it was merged and reverted you need to rebase this for it to have any effect: lp:~andreas-pokorny/mir/load-all-supported-input-platforms
<anpok> oh right
<alan_g> alf: have you looked into lp:1502782 at all?
<alf> alan_g: no
#ubuntu-mir 2015-10-15
 * alan_g reproduces something that looks like lp:1502782 \o/
<alan_g> ...and the stack is complete @!"$Â£
<anpok_> without any library unloading?
<alan_g> anpok_: not sure yet. Only just found a formula for reproducing.
<anpok_> we do keep the platform alive within server settings
<anpok_> +library
<anpok_> and the platform is also stored in display_server..
<anpok_> (maybe a problem of the driver shutting down..)
<alan_g> Ah, but AndroidHardwareSanity plays "silly bugger" with SetUpTestCase() and a static member variable.
<anpok_> alan_g: btw, can you reproduce it only on krillin?
<alan_g> anpok_: only tried on krillin so far
<anpok_> me couldnt on mx4
<anpok_> ok
<alan_g> FWIW: $ gdb --args bin/mir_integration_tests --gtest_filter=AndroidHardwareSanity.* --gtest_repeat=2
<alf> robert_ancell: Hi!
<robert_ancell> alf, hi!
<alf> robert_ancell: I filed a bug (enhancement really) for lightdm https://bugs.launchpad.net/lightdm/+bug/1506426
<ubot5`> Ubuntu bug 1506426 in Light Display Manager "LightDM needs better log file rotation" [Medium,Triaged]
<alf> robert_ancell: Looking at some other packages, I guess this should be handled at the packaging level
<alf> robert_ancell: (if we use logrotate)
<alf> robert_ancell: but I wanted to hear what your thoughts are on it
<robert_ancell> alf, I don't know the best way to do this but we should probably match other packages. Being done in the packaging sounds good to me.
<robert_ancell> I don't think LightDM wants to grow a super-sophisticated logging system
<robert_ancell> What does Xorg do?
<alf> robert_ancell: I agree. I took a look at upstart, it ships upstart.logrotate file with some rules. I don't know how well logrotate would interact with lightdm moving old log files to *.old.
<robert_ancell> alf, we can look at disabling that if it's not necessary with logrotate
<robert_ancell> It was just a cheap method of keeping the previous log
<alan_g> kdub: is there something about what AndroidHardwareSanity.display_can_post_overlay uses that is dubious (seen on krillin)?
<alan_g> Works: $ gdb --args bin/mir_integration_tests --gtest_repeat=8 --gtest_filter=AndroidHardwareSanity.*:-AndroidHardwareSanity.display_can_post_overlay
<alan_g> Fails: $ gdb --args bin/mir_integration_tests --gtest_repeat=2 --gtest_filter=AndroidHardwareSanity.display_can_post_overlay
<alan_g> probably bug 1502782
<ubot5`> bug 1502782 in Mir "CI segfault in mir-mediumtests-runner-mako after AndroidHardwareSanity tests" [Medium,Confirmed] https://launchpad.net/bugs/1502782
<kdub> alan_g, right, it pulls in the drivers, and trying to tear down and start up the drivers in the same process tends to be problematic in the driver code
<alf> robert_ancell: do you have time to take a look, or should I?
<robert_ancell> alf, if you have the time please do
<alan_g> So you think this may be unrelated to the bug and just an effect of --gtest_repeat?
<alf> robert_ancell: ok, and I should propose all changes (including packagin) against lp:lightdm?
<robert_ancell> alf, yes please
<alf> robert_ancell: ack
<kdub> alan_g, right, last time I looked, it was the repeating that was the problem
 * alan_g wonders if AndroidHardwareSanity is the only integration test case that loads drivers...
<alan_g> kdub: Curious that it is triggered by that one test (when repeating the rest of the test case seems to work)
<kdub> It should be the only integration test that loads the drivers
<alan_g> Confirmed
<anpok_> hm interesting .. is also that it only happens with basic .. here.
<anpok_> nm, client in use does not matter
<anpok_> it is just more easier to reproduce with it
<zzarr> hello! will XMIR be implemented in OTA-7? (if not will it in OTA-8?)
<alan_g> zzarr: Xmir won't be usable in OTA-7. I doubt it will be working well for OTA-8, but there is some progress happening.
<zzarr> okey, alan_g, I wondered because a developer (don't remember a name) showed an image of a Nexus 4 running Firefox and GIMP
 * alan_g left the AndroidHardwareSanity.* in a loop script over lunch and came back to a core file.
<alan_g> zzarr: that's a WIP, not ready for general use. Most of the work there missed OTA-7 and not all of it is finished. There's a couple of weeks to land stuff for OTA-8 and IMO not everything will be ready in that timeframe.
<zzarr> okey, thanks alan_g, but there's always a OTA-9 after OTA-8 and the hope is still there ;)
<alan_g> zzarr: yes, it will certainly come but there's a lot of issues to trace through the software stack and only a few hands with time to spend on it. And depending on your intended usage there are other solutions (like gtk-mir).
<zzarr> I have a ASUS ChromeBook Flip, is it possible to install MIR/Unity8 and XMIR if I install Ubuntu 15:10 and libhybris in a dualboot with the help of a android driver for the RK3288 SoC
<zzarr> I know there's a gtk Java version, how do I install it on my MX4?
<alan_g> zzarr: I've no idea about support for Chromebook hardware. Installing stuff on a phone is problematic. Maybe this is some help? http://accu.org/index.php/journals/2158
<zzarr> many questions... but I really would like a Unity8 environment on the ChromeBook (since it can fold like a tablet)
<zzarr> okey
<zzarr> thanks
<zzarr> alan_g, do you know how they will make the convergence work? I mean in a more technical aspect, will the desktop be a lxc inside the Phone system (lika an system app) and run desktop applications within that lxc? (in order to maintain OTA support)
<alan_g> zzarr: I'm able to answer that.
<alan_g> zzarr: I'm *not* able to answer that.
<zzarr> okey, alan_g, thanks in any way :D
<alan_g> kdub: anything spring to mind? https://bugs.launchpad.net/mir/+bug/1502782/comments/5
<ubot5`> Ubuntu bug 1502782 in Mir "CI segfault in mir-mediumtests-runner-mako after AndroidHardwareSanity tests" [Medium,Confirmed]
<kdub> alan_g, maybe check dmesg and /system/bin/logcat to see if there are any complaints?
<alan_g> kdub: http://paste.ubuntu.com/12789072/
<kdub> that "failed to close ion client" is some sort of driver problem, probably what's going on
<kdub> *probably related to the error
<alan_g> Is the (EGL_NOT_INITIALIZED) likely to be something
<alan_g> kdub: *something* is racy - I've hacked in a small sleep at the end of the test and it runs nicely.
<kdub> alan_g, the not initialized message doesnt concern me, although hard to rule it out completely
<kdub> alan_g, we've had some problems in this area with this device only (quirk in mga::DeviceQuirks)
<kdub> iirc, repeatedly opening and closing that module had some problems that we couldn't fix from the mir's side... and running it repeatedly within the same process like that will still try to open() and close() the module
<alan_g> kdub: I'm restarting the process (while loop in the shell)
<kdub> i guess though that I don't trust the synchronization of this module around open() and close() with the kernel
<kdub> we could have an "if" dependent on that quirk that will introduce a sleep there
<kdub> a bit of a workaround, but we don't have the sources for the module to try a root-cause/proper fix
<alan_g> duflu added a "mako" tag, so I'm not sure it is krillin only
<alan_g> ...although every instance I've seen in CI is krillin. So I think that's wrong
<kdub> let me see if I can reproduce on mako
<kdub> eh, there is a problem there too
<alan_g> :(
<alan_g> +    test_buffer.reset();
<alan_g> +    std::this_thread::sleep_for(std::chrono::milliseconds(10));
<anpok_> alan_g: that helps?
<anpok_> quit
<anpok_> wrong terminal
<alan_g> anpok_: yes
 * alan_g doesn't find it a very satisfying solution. kdub does it help mako too? (https://code.launchpad.net/~alan-griffiths/mir/workaround-1502782/+merge/274564)
 * kdub is mid upgrade of the build, so wont know for a bit yet
<kdub> build system
<alan_g> np just hoped you were set up
 * alan_g plugs in mako
<anpok_> alan_g: I am tinkering with that on the mir_demo_server shutdown issue..
<alan_g> anpok_: does any of it help with the  mir_demo_server shutdown?
 * alan_g wishes mako was faster
<anpok_> alan_g: that didnt help for the mir_demo_client_basic issue..
<anpok_> alan_g: i wrapped the buffer allocator and added an object that will add a sleep after the allocator destruction..
<alan_g> anpok_: thanks.
<anpok_> didnt help.. but I also removed our global static ShardLibrary that currently keeps the graphics platform alive to not have the segfault on application exit.. but still no further clues..
#ubuntu-mir 2015-10-16
<duflu> Ha. Not a bug.
 * duflu throws out broken mouse
 * alan_g discovers that "sudo unity-system-compositor --debug-without-dm" crashes horribly
<anpok> duflu: get a cat!
<anpok> I can make the seg fault on the krillin ci runs go away
<duflu> Don't need one. Have the internet full of cats.
<anpok> it seems that.. if we dont load the mesa/kms platform unloading the android platform does not crash the driver
<alan_g> anpok: that is likely the "horrible hack"
<anpok> so..
<anpok> there are various ways
<alan_g> The mesa driver code reloads itself with RTLD_GLOBAL
<anpok> oh
<anpok> i thought some tls related problems..
<anpok> another option might be to never unload the android platform if quirk->cannot_survive_unloading()..
<anpok> or change the ci script to handle krillins runners differently.. disabling the probe .. removing the mesa modules .. all of which harms the effectifness of ci
<alan_g> It is just on krillin?
<anpok> yes
<alan_g> A thought: what if you probe the android drivers before the mesa ones?
<anpok> hm that is happening
<alan_g> Rats!
<anpok> brb
<alan_g> anpok: for differential diagnosis, could you try the effect of commenting out the reload code - ensure_loaded_with_rtld_global() - in the mesa drivers?
<anpok> alan_g: bingo
<anpok> when do we need that?
<anpok> could we delay that until we know this will be the platform to use?
<anpok> arg thats in the init code of the library
<alan_g> anpok: somewhere in the mesa code there's an attempt to find some symbol. (I think alf knows the details.)
<anpok> oh or we might be able to split the mesa driver into pieces..
<anpok> since probing only needs udev..
<alan_g> anpok: RAOF promised to have a go at fixing mesa (eventually) as it also pulls in the X stack and other rubbish
<alan_g> So delaying the hack is a possibility - depending on when mesa needs to find ... mir_server_mesa_egl_native_display_is_valid()
 * alan_g wonders if there's a way to just publish that one symbol...
<anpok> alan_g: we only need that in nested, right?
<alan_g> anpok: no for any mesa graphics (AIUI)
<anpok> vogons: https://code.launchpad.net/~andreas-pokorny/mir/fix-1506137/+merge/274708
<anpok> alan_g: it seems to work for the guest platform only - which makes sense since the drm-egl is builtin mesa and needs no mir interaction
<alan_g> anpok: if that's true then great. (Not as good as getting rid of the hack, but at least it reduces the cases where it messes us up).
<anpok> i still have vt switching issues.. so I tried it via two times cascaded launch-client... and it seemed to work
<anpok> oh
<anpok> thats not the right use case..
<anpok> I should have tried it with unity8 instead?
<anpok> but still it should be true..
<alf> robert_ancell: Hi!
#ubuntu-mir 2016-10-17
<brunch875> /var/log/auth.log:
<brunch875>  http://paste.ubuntu.com/23338207/
<brunch875> /var/log/lightdm/unity-system-compositor.log:
<brunch875> http://paste.ubuntu.com/23338209/
<brunch875> I installed 16.10, but I can't get to unity8 :(
<brunch875> I'll be glad to walkthrough / turn my laptop into a guinea pig to help bugfixing!
#ubuntu-mir 2016-10-19
<mterry> RAOF: you there?  Did you ever dig into Mir and VT switching?
<RAOF> mterry: Yes; we want you to enable a Mir report and reproduce the bug.
<mterry> RAOF: can do
<mterry> RAOF: which report?
<mterry> RAOF: you think it's Mir's fault after all then?
<RAOF> mterry: No.
<RAOF> mterry: MIR_SERVER_DISPLAY_REPORT=log is your winner, I belive.
<mterry> Dang it, it would have been easier if it was Mir's fault
<mterry> RAOF: ok will do that
<RAOF> mterry: The hypothesis is that Mir fails to drop master for whatever reason, which results in it (correctly) NAKing the VT switch.
<RAOF> (We call drmDropMaster, but that can fail; if it does, we throw an exception, (silently) catch it, and NAK the VT switch)
<mterry> RAOF: http://paste.ubuntu.com/23348320 -- I set the env, but don't see much about display output, doesn't seem like a useful log
<mterry> RAOF: I assigned this bug to you (but just as a point of contact, please re-assign or unassign as you see fit): https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1634888
<ubot5`> Ubuntu bug 1634888 in mir (Ubuntu) "Problems switching VTs" [Undecided,New]
<RAOF> mterry: OK.
<mterry> RAOF: if it is drmDropMaster mysteriously failing, is that a driver bug?
<RAOF> mterry: So, that shows that Mir is successfully calling drmDropMaster(), which means that it's probably someone else's bug.
<mterry> RAOF: you mean there's a lack of an error message?  :)
<RAOF> Yes :)
<RAOF> It would say failed to drop master :)
<mterry> I guess I'll go back to robert and see if he thinks lightdm could be botching the hand off
#ubuntu-mir 2017-10-19
<RAOF> Oh, yeah. FindGTest.cmake is much more likely to work if you actually have gtest-devel installed.
#ubuntu-mir 2017-10-21
<Son_Goku> can someone publish tarballs of new tagged releases of mir?
<Son_Goku> since I know 0.28 was tagged, it'd be nice if the tarball was available for download
