#ubuntu-mir 2013-11-18
<duflu> Gah. Summer must be coming. Everything has a spider living in it already :P
<RAOF> :)
<RAOF> Dear lord, upstairs is hot.
<RAOF> Also, why must Qt have crappy font rendering?
<RAOF> (Alternately, where do I tell Qt to render fonts non-crappily?)
<RAOF> Hm. Hang on to shared_ptrs, or increment other people's reference counting?
<Mirv> filed bug #1252144 on a test failure on builders
<ubot5> bug 1252144 in Mir "A test failing on builders with mir 0.1.1" [Critical,New] https://launchpad.net/bugs/1252144
<duflu> Mirv: Also, is the "UNRELEASED" a problem? mir (0.1.1-0ubuntu1) UNRELEASED; urgency=low
<Mirv> duflu: no, it's fine and gets changed by cu2d as seen at https://launchpadlibrarian.net/156699885/mir_0.1.1%2B14.04.20131116-0ubuntu1.diff.gz
<duflu> Mirv: If I propose a fix to lp:mir can we test it quickly? I can't reproduce the bug either...
<RAOF> Does it fail on the PPA builders, too?
<duflu> Looks like a silly-short timeout which will fail on a busy server. Proposing now...
<duflu> Oh. Wait, no. It fails after 1ms
<Mirv> duflu: yeah I can push to some PPA as well if needed
<duflu> Mirv: We don't use PPAs in Mir any more. But proposing now...
<Mirv> ok, seeing the branch
<Mirv> building soon at https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-daily/+sourcepub/3666854/+listing-archive-extra
<duflu> RAOF: When is an appropriate time to add resize support to Mesa? There are prerequisite changes in Mir 0.1.2 that it will need, but can we update git immediately?
<RAOF> We can update git any time you want.
<duflu> RAOF: In that case, may I ask you to look at my two lines of logic and update the buffer acquire/release stuff to suit?
<duflu> two-ish
<RAOF> :)
<RAOF> Certainly. Where are they?
<duflu> RAOF: https://launchpadlibrarian.net/156390351/mesa-mir-resize-support.patch
<duflu> It works now... but of course we don't have any demo clients using non-colour buffers yet
<RAOF> How do clients know to change their rendering, by the way?
<duflu> RAOF: They presently query EGL. Events are coming soon
<duflu> For example: https://code.launchpad.net/~vanvugt/mir/resize-examples/+merge/194833
<RAOF> Added to git.
<duflu> RAOF: Ta muchly
<RAOF> Oh, also; why is there a check for buffer.width and buffer.height?
<duflu> RAOF: So it falls back to the existing (working) behaviour if you accidentally run it against an older Mir
<RAOF> Ah, ABI.
<duflu> ... where they are zeroed fields
<RAOF> Yeah, fair call.
<duflu> It's both sad and exciting that resizing surfaces is one of the most dramatic things you will see on demo_server* right now
<duflu> RAOF: Were you referring to jaggies on touch earlier? I see them now :P
<duflu> Mirv: Jenkins is reporting CI failures which are actually problems with the build machine and not the code :(
<duflu> https://code.launchpad.net/~vanvugt/mir/fix-1252144.trunk/+merge/195547
<Mirv> duflu: yep, retrying in case it helps
<duflu> alf_: Do we ensure xbgr is listed before abgr so dumb clients like unity-mir will grab the first (fastest) pixel format?
<alf_> duflu: no, on the contrary, we return pixel formats in descending "active" bits order (abgr = 32, xbgr = 24)
<duflu> alf_: Is that a good idea
<duflu> ?
<alf_> duflu: It's a more predictable ordering (and helps a bit when searching for particular formats), sorting by "fastest" is not. In any case, if unity-mir, or any other app needs a particular surface type they should search for it, not rely on formats[0] being what they want.
<duflu> alf_: Yeah I was trying to avoid fixing and rebuilding unity-mir
<alf_> duflu: (because we may indeed decide to change the ordering in the future)
<duflu> alf_: OK. I think we need to improve on format lookups in future. Perhaps like bug 1236254
<ubot5> bug 1236254 in Mir "[enhancement] MirPixelFormat should encode details of the pixel format" [Medium,New] https://launchpad.net/bugs/1236254
<alf_> duflu: yeah, I was looking at the DRM fourcc format, but it's a bit arbitrary unfortunately
<alf_> duflu: (/usr/include/drm/drm_fourcc.h)
<duflu> alf_: Yeah I know it, but it does not solve the problem
<alf_> duflu: alan_g: @offscreen-platform, are you happy with renaming to OffscreenDisplayContext or OffscreenNativeDisplay or ...
<duflu> alf_: I think I prefer OffscreenPlatform more :S
<alan_g> alf_: reminding myself...
<alf_> duflu: alan_g: Unless we go with one of the other methods (e.g. adding egl_native_display() to platform directly and having an independent OffscreenPlatform interface)
<duflu> alf_: Or just make OffscreenPlatform a real platform and drop the pure virtual requirement :)
<alan_g> alf_: the name doesn't bother me much - but I would suggest BasicPlatform/MinimalPlatform would be a better base for Platform than OffscreenPlatform
<duflu> Yeah that would be better
<duflu> BarePlatform?
<alf_> alan_g: duflu: EGLPlatform?
<duflu> alf_: That's slightly better, but it's going to confuse people for that to be the base of "Platform"
<duflu> I think any good solution is going to involve rethinking "Platform" which is a job for another day.
 * duflu abstains
<alf_> alan_g: duflu: OK, I will go with BasicPlatform
<alan_g> alf_: the last suggested revised name for "surfaces" I can find is "core" - how do you feel about that?
<alf_> alan_g: thinking...
<alf_> alan_g: I am not convinced that core is a better name than surfaces (or something else), it's surely is less descriptive
<alf_> alan_g: after all mir::surfaces is all about the creation and management of surfaces
<alf_> alan_g: mir::scene ?
<alan_g> alf_: maybe - although I've been trying to get away from "scenegraph" which tends to be taken too specifically
<alan_g> alf_: mir::model?
<alf_> alan_g: It depends on how literally we want to use "model" (in the MVC sense), since the component contains the controller too.
<alan_g> tvoss_: I think the time is ripe to change the name of mir::surfaces. Do you have any thoughts on a good name? (Also ^^)
<alan_g> alf_: yeah, but mir::model_controller is a bit long winded
<alan_g> mm or mmc is easy to type though...
<Stskeeps> g 63
<Mirv> weird, weird, the test duflu fixed still failing in the daily-build PPA, while when I build in another PPA (granted probably slightly different PPA) it succeeded: https://launchpad.net/~ubuntu-unity/+archive/daily-build/+sourcepub/3667324/+listing-archive-extra
<Mirv> this is the bug #1252144 still
<ubot5> bug 1252144 in mir (Ubuntu) "A test failing on builders with mir 0.1.1: PublishedSocketConnector.drm_auth_magic_is_processed_by_the_server" [Critical,In progress] https://launchpad.net/bugs/1252144
<kgunn> didrocks: ok...what's up ? u-s-c FTBFS ?
<didrocks> kgunn: see what Mir posted an hour ago ^
<didrocks> bug #1252144
<ubot5> bug 1252144 in mir (Ubuntu) "A test failing on builders with mir 0.1.1: PublishedSocketConnector.drm_auth_magic_is_processed_by_the_server" [Critical,In progress] https://launchpad.net/bugs/1252144
<kgunn> didrocks: sorry...got on later than that
<didrocks> kgunn: also, it seems platform-api doesn't have the bump build-dep merged
<didrocks> that's the 2 things now that we can slowly try to land things again :)
<didrocks> and doing Mir in priority
<didrocks> seems to work on virtualized ppa, but not on real hardware one
<didrocks> (the latter beeing used for distro)
<didrocks> (comments #4 and #5)
<kgunn> didrocks: do we know the fundamental differences between  qt5-daily PPA vs. daily-build PPA  ??
<didrocks> kgunn: I have this virtualized vs non virtualized in mind, but that's it
<didrocks> kgunn: the other possibility is a timing issue, but it's weird we have consistent failures (we did several retries)
<didrocks> and virtualized would be "faster"
<kgunn> mlankhorst: alf_ ....any ideas, this is strange ^ almost wonder, did mesa change ??
<mlankhorst> gah why always blame mesa
<mlankhorst> :P
<kgunn> didrocks: is the mir-patched xserver stuff in archive for trusty ?
<didrocks> kgunn: well, both are built on trusty, right?
<didrocks> so I guess that mlankhorst didn't remove the patch, right mlankhorst?
<kgunn> mlankhorst: only because no one's touched u-s-c/xmir in a good while :)
<robotfuel> alf_: ping
<didrocks> kgunn: let me look for the content of the ppa
<kgunn> this is why /me doesn't like xserver/mesa sitting outside bzr
<robotfuel> I was testing your --offscreen branch and get this error when I try to run offscreen http://pastebin.ubuntu.com/6437847/
<alf_> kgunn: mlankhorst: that particular test doesn't interact with any external components, its a unit test using mocks
<alf_> it's
<didrocks> kgunn: +1 for not liking that ;)
<mlankhorst> didrocks: I'm tempted to do so, but no
<kgunn> mlankhorst: sorry...i'll keep it to myself :)
<kgunn> alf_: ok...so just a failing mock...sounds like you're familiar enough, could you take a look on the trunk ?
<alf_> kgunn: ok
<mlankhorst> kgunn: we haven't touched mesa in trusty much, only uploaded 9.2.2 afaik
<kgunn> alf_: thank you...this is an item that's holding up our mir update to the archive (going on 3 weeks :)
<kgunn> mlankhorst: sorry dude...i'll try not to be so mesa-blame-happy :)
<alf_> robotfuel: (will get back to you in a bit)
<kgunn> robotfuel: sorry...i swiped alf_
<robotfuel> alf_: ack I see you have your hands full :)
<didrocks> kgunn: no, all the same for both
<didrocks> apart from this virtualized vs non virtualizeds
<kgunn> didrocks: ack, we got someone looking
<didrocks> kgunn: thanks!
<didrocks> keep us posted
<kgunn> didrocks: at least hope it fails on their local machine....it should since its the non-virt failing
<didrocks> kgunn: cyphermox/robru/ken when I'm not around
<kgunn> thank you sir
<didrocks> kgunn: let's cross fingers (they should try building the package to have the same config: bzr bd)
<kgunn> alf_: ^ see didrock's last statement
<greyback> alf_: alan_g: would either of you be able to make sense of this: http://pastebin.ubuntu.com/6422376/ What I'm trying to do is use a qt application in Mir. So running mir_demo_server_shell, and then qmlscene (using the qtubuntu plugin so behaves as mir client)
<kgunn> didrocks: one thing on the platform-api bump... https://code.launchpad.net/~kgunn72/platform-api/bump-mir-dep-0.1.1/+merge/193519
<alan_g> greyback: looking...
<greyback> alf_: alan_g: it would appear that mesa imports x11. Do we have patch to stop that?
<kgunn> didrocks: it looks like it won't autoland due to mir build dep itself...(or do i not understand ?)
<kgunn> e.g. does mir have to land first before that will actually merge ?
<alan_g> greyback: that doesn't look familiar to me. Sorry
<greyback> alan_g: np, thanks for looking
<alf_> greyback: When you create an egl display from an egl native display (MirConnection etc), the patched mesa checks Mir first so it shouldn't be a problem. Is this desktop or phone?
<greyback> alf_: desktop
<didrocks> kgunn: yeah, for those kind of trivial change, you can force it to trunk (merge manually)
<didrocks> kgunn: to not wait mir to land in the ppa
<kgunn> didrocks: ack, so pull, merge, push quickly ?
<didrocks> (well, mir is in the ppa, but failed tobuild, as we discussed)
<didrocks> kgunn: sounds good to me
<kgunn> ricmm: ^ just beware of what i'm about to do :)
<alf_> greyback: can you please also install libegl1-mesa-dbg so we can get the missing functions in the trace
<greyback> alf_: ack
<alf_> greyback: are you able to run an example mir application?
<greyback> alf_: yes, demo mir clients are fine
<alf_> greyback: also use MESA_DEBUG=1 EGL_LOG_LEVEL=debug when running the qt app
<greyback> ok
<ricmm> kgunn: sec
 * ricmm reads back
<ricmm> go for it
<kgunn> ricmm didrocks: & done...platform-api trunk now dep on 0.1.1 mir
<didrocks> kgunn: thanks!
<didrocks> "just" the FTBFS now ;)
<didrocks> and then we can build/test/deliver Mir
<greyback> alf_: http://pastebin.ubuntu.com/6437996/ <- egl seems to decide x11, not mir.
<greyback> how does it decide? is there an env var maybe that could force it?
<greyback> FYI  I am running X11 on VT7. Am trying to run mir on VT1.
<alf_> greyback: on the same machine?
<greyback> alf_: yes
<kgunn> greyback: just curious...can you run a mir demo client per the instructions http://unity.ubuntu.com/mir/using_mir_on_pc.html
<kgunn> under "runing mir natively"
<kgunn> ...sorry if this is deja vu
<greyback> kgunn: that's exactly what I'm doing. Demo mir clients work fine
<alf_> greyback: just to be clear, you mean the mir server is running on VT1 but you want to start an app from VT7 under X11?
<greyback> alf_: nope. I'm starting app from VT2
<greyback> for running under mir
<alf_> greyback: ok, FWIW, running it from VT7/X11 should work too
<greyback> alf_: yes that makes sense :)
 * greyback stops using VT2
<alf_> greyback: are you using qtubuntu trunk or some other branch (I want to take a look at the code there)
<kgunn> alf_: please...can you do that after the drm_auth_magic test failure
<alf_> kgunn: I am doing it in parallel, the package is building (which is slow)
<kgunn> :) thanks
<greyback> alf_: heh, this is where things get annoying. I'm using Qt5.2, and made a branch of qtubuntu to support it, and also hack around depending on hybris: alf_: I made a branch so it wouldn't depend on hybris. lp:~gerboland/qtubuntu/qt5.2-on-desktop/
<greyback> alf_: but please you try using standard qtubuntu, just to test please
<alf_> greyback: as a first step I want to take a look at the code
<greyback> alf_: sure
<greyback> alf_: src/platforms/base/context.cc will be of interest to you
<racarr> Happy monday!
<alf_> kgunn: I can't recreate the problem building the package locally :/
<kgunn> alf_: thanks...hmmm.... didrocks thots to proceed ?
<didrocks> kgunn: did you ask on #webops?
<kgunn> didrocks: so sorry...was otp...why webops ?
<didrocks> kgunn: they will be able to help to debug why the test segfault on devirtualized ppas (meaning, distro builders)
<didrocks> even getting you chroot access I guess
<kgunn> racarr: mornin'
<racarr> Morning kgunn!
<racarr> alan_g: My branch actually does conflict with yours a little...I want to just straight up remove the session container
<racarr> maybe we can talk about it tomorrow?
<alan_g> racarr: I've no problem with it being removed
<racarr> alan_g: The thing is we only use it internally for the system compositor focus tracking (i.e. finding hwich session to give focus to when another closes)
<racarr> so rather than make it a customizable component, I am just going to fold it in to
<racarr> msh::DefaultShell
<racarr> which is the new SessionManager
<racarr>  / implementor of mf::Shell
<alan_g> Hmm. But the "Controller" part of SessionManager belongs in surfaces
<alan_g> As does the "Model" part
<racarr> hmmmaybe, I mean it wont be the same manager, I am changing
<racarr> the mf::Shell interface as well
<alan_g> So, I'm not convinced by "msh::DefaultShell"
<racarr> to basically mirror the mf::SessionMediator interface
<racarr> except in terms of Mir server types instead of IPC types
<racarr> to the DefaultShell, takes the fully interpreted IPC requests, and decides which controller components to use
<racarr> to update the model
<racarr> s/to the DefaultShell/so the mf::Shell/
<alan_g> I guess I should look at what you're doing. (But my head is full ATM)
<racarr> I will propose it todayhopefully
<alan_g> OK will look in morning
<kgunn> robotfuel: since some services are back to working....have you had a chance to test out the demo clients as part of ci ?
<robotfuel> kgunn: I am working on that now
<alf_> robotfuel: please check latest lp:~afrantzis/mir/offscreen-display
<robotfuel> alf_: will do thanks
<kdub> android clients? :)
<robotfuel> kgunn: I am still waiting for this a MP to land before we can add demos to CI, I've talk to the phablet team and it's on their list to review today, they have a bunch of reviews to do. https://code.launchpad.net/~chris.gagnon/phablet-tools/run-test-without-autopilot/+merge/194920
<robotfuel> racarr: https://code.launchpad.net/~robertcarr/mir/cbranch-can-not-be-named-fix-1247718/+merge/195629 has problems I got this failure:  /tmp/buildd/mir-0.1.1/tests/unit-tests/input/android/test_android_input_manager.cpp:158:83: error: template argument 1 is invalid
<greyback> alf_: just FYI, I did a little digging, found if I set EGL_PLATFORM=mir, then I get further. Failure now with EGL_BAD_CONTEXT...
<robotfuel> alf_: your new offscreen branch crashes my X session, but otherwise seems to work.
<alf_> robotfuel: it's not ready to be run under X11 yet, you still need to be in a VT
<robotfuel> alf_: I am running it in a vt with sudo mir_demo_server_basic --offscreen --vt 3, yet it still crashes my X session
<alf_> robotfuel: ok
<alf_> greyback: if you don't solve this today, please send me an email with quick instructions so that I can try tomorrow morning
<greyback> alf_: ok
<alf_> robotfuel: btw, you can't switch back to X while the offscreen server is running yet (I guess that's what you meant by killing the X session)
<robotfuel> alf_: ah ok, maybe that is the issue? I've added the crash part of the X log to the MP
<robotfuel> alf_: X restarts in fallback mode on tty8 after running --offscreen
<alf_> robotfuel: only when switching to X while offscreen is running, though, right?
<robotfuel> alf_: I did try to switch back to tty7 I'll retry
<robotfuel> alf_: yeah If I don't switch back X does not crash.
<alf_> robotfuel: ok, thanks
<robotfuel> alf_: I also updated the comment in the MP.
<bschaefer> racarr, ping
<racarr> bschaefer: pongalong
<bschaefer> racarr, hello! So, i was digging around in the motion event, and it doesnt seem to expose the type of device being used
<bschaefer> ie: http://paste.ubuntu.com/6438929/
<bschaefer> with out exposing the ToolType, you don't know if it the event is a mouse/finger/etc..
<racarr> bschaefer: Seems correct
<bschaefer> racarr, i can test it out some more, but was just wondering if you knew of any other way :)
<bschaefer> without having to use an unused var
<racarr> No. sorry.
<bschaefer> racarr, alright, well i can make a bug, and get some tests then I can get an MP up
<bschaefer> thanks!
<racarr> Thankyou !
 * kdub forgot to restart xchat after x locked up
<racarr> timefor awalk
<racarr> at thatpoint in refactoring where its like
<racarr> ahahgashgahsga
<racarr> also its really time for a new space key
<kdub> racarr, c++ doesn't need the space key :P
<kdub> just tabs
#ubuntu-mir 2013-11-19
<duflu> RAOF: After my comment yesterday, I arrived to find a dead spider on the desk today :)
<RAOF> duflu_: Ominous!
<RAOF> Hm. How do you tell QtCreator to run a parallel make?
<Mirv> duflu: did you see me and cyphermo_x's comments at bug #1252144? the test still seems to fail in the build environment of the daily-build PPA, plus it was spotted that after the patch it's a segfault, not a test fail
<ubot5> bug 1252144 in Mir "A test failing on builders with mir 0.1.1: PublishedSocketConnector.drm_auth_magic_is_processed_by_the_server" [Critical,In progress] https://launchpad.net/bugs/1252144
 * duflu looks
<duflu> Mirv: OK, thanks. The logs yesterday were hinting it wasn't a timeout anyway
<duflu> I did run it against helgrind, but we've lagged behind in our helgrind testing and there's much noise
<Mirv> what is strange to me in terms of reproducing is that I thought both PPA:s had similar kind of non-virtualized builders, but apparently not
<RAOF> Hm. I wonder how often acceptance-tests.ServerDisconect.* hangs...
<duflu> No idea. It's not in the list (?) ... https://bugs.launchpad.net/mir/+bugs?field.tag=testsfail
 * duflu was worried for a moment... 
<duflu> [==========] 666 tests from 123 test cases ran. (7692 ms total)
<tvoss_> duflu, :)
<duflu> That's fun. Our tests run faster if pinned to a single CPU core (taskset)
<tvoss_> duflu, under valgrind? might well be
<duflu> Yep
<duflu> Mirv: OK I now have a good explanation of why just that test is failing, and have synthesized a similar failure + segfault. Another MP coming
<alf_> duflu: \o/
<didrocks> awesome! :)
<alf_> duflu: didrocks: FWIW, I tried to reproduce the issue by ssh-ing and building the package in a devirtualized builder yesterday, but couldn't get the error...
<duflu> Why valgrind can't see that uninitialized value, I don't know. But the C++11 docs seem to say it should and will be uninitialized. And it's surrounded by variables that are explicitly initialized
<didrocks> alf_: argh, let's see duflu's explanation once he will get the MP up thenâ¦ That was the only common sense diff between the 2 ppas I could have come up with
<duflu> https://code.launchpad.net/~vanvugt/mir/fix-1252144-v2.trunk/+merge/195718
<didrocks> it's interesting that it only happen in one ppa, and reliably thereâ¦
<duflu> didrocks: Yes, something different about the default memory layout/contents. Possibly due to a different library or kernel
<duflu> I notice the logs say it's failing on kernel 3.2
<didrocks> oh, devirtualized should use a precise kernel
<didrocks> juts weird that alf_ didn't reproduce
<alf_> didrocks: hmm, the devirtualized builder I used has 2.6.32 (10.04)
<didrocks> oh, maybe different ones ;)
<alf_> greyback: Hi! Any luck with the EGL issues?
<greyback> alf_: hey. No, I didn't get much further (sorry, forgot to send you mail). Setting EGL_PLATFORM manually helped a bit
<tsdgeos> you guys that know much more *gl than me
<tsdgeos> is EGL+regularOpenGL something that works on the desktop?
<mlankhorst> no idea
<xnox> tsdgeos: the question is weather hardware/drivers expose EGL, e.g. AMD drivers on the desktop do expose EGL, but no others.
<xnox> http://www.g-truc.net/post-0457.html is a good read.
<alf_> greyback: Can I just install qtubuntu etc on the desktop? It brings in hybris which usually messes up desktop EGL
<greyback> alf_: the hybris dependency is actually build-time
<alf_> greyback: however the qtubuntu-android binary package depends on hybris
<greyback> alf_: but I don't think the package dependencies reflect that
<greyback> right
<greyback> easiest would be to check out lp:qtubuntu, install libhybris-dev, run "qmake CONFIG+=mirserver CONFIG+=mirclient CONFIG+=debug", make && make install
<greyback> then remove libhybris
<alf_> greyback: ok
<kgunn> read scrollback, that's kinda scary that there are so many different kernels we're using on validation systems (...on desktop)
<kgunn> isn't there supposed to be 1 kernel ver/cfg to be used (period)
<alf_> greyback: reproduced problem, looking into it...
<greyback> alf_: cool. Let me know if you need anything.
<alf_> greyback: FYI, using "sudo update-alternatives --config x86_64-linux-gnu_egl_conf" and then "sudo ldconfig" allows us to select mesa even in the presence of libhybris
<greyback> alf_: nice, thanks
<greyback> info like this should really be in a wiki page somewhere
<kgunn> didrocks: Mirv we all good with mir update now ?
<didrocks> kgunn: there is a patch from duflu
<didrocks> kgunn: but it seems the CI system doesn't want from it
<kgunn> didrocks: crap...will go check
<didrocks> kgunn: I asked kenvandine to start where Mirv left, but it's about pushing the CI guys to look/act on it
<alan_g> kgunn: looks like fginther is on it
<kgunn> thanks guys....if fginther is on it...i'll rest easy :)
<Mirv> yeah francis now hopefully found the cause
 * alan_g wishes for a C++11 aware mocking framework
<olli> kdub, congrats for making it onto phoronix ;)
<rsalveti> would be nice if we could have someone from the mir team also joining http://summit.ubuntu.com/uds-1311/meeting/22107/core-1311-early-boot-animation/
<rsalveti> as that might bring back the discussion of having some part of mir already running in the initrd itself
<kgunn> mterry: ^ could you join that one ?
<mterry> kgunn, I'm in the encrypted home dir one
<kgunn> mterry: np
<kgunn> alan_g: ^ could you ?
<alan_g> kgunn: I could - but have no idea what's happening
<kgunn> alan_g: no prob...i think they just want some mir representation
<alan_g> kgunn: what do I do? Just follow that link?
<kgunn> alan_g: http://summit.ubuntu.com/uds-1311/meeting/22107/core-1311-early-boot-animation/
<kdub> thanks olli
 * alan_g tries to register...
<alan_g> ..."wait a few minutes and reload this page."
<kgunn> alf_: thanks for merging trunk back in....was just going to do that
<alf_> kgunn: ? I didn't do anything, but I can do it if you like :)
<kgunn> alf_: no you did.... 4 hrs ago :)
<kgunn> oh wait...misread it...it was duflu i think
<alf_> kgunn: yes, although it was not exactly a merge back, it was the same commit retargeted at devel
<kgunn> right
<kgunn> just didn't want it to not make it back to dev branch...all good
<DieMumiee> hm i had no audio on the hangout video, do I need to register/login to hear the voices
<mterry> jono, how would one edit http://unity.ubuntu.com/mir/using_mir_on_pc.html ?
<mterry> Or point me maybe at who would know  :)
<robotfuel> mterry: I that's part of the doc's in the source code.
<mterry> robotfuel, interesting
<jono> mterry, yep, it is in the source, and synced to unity.u.c
<mterry> jono, robotfuel; thanks!
<jono> np
<kgunn> mterry: right, you mod the doc in the src tree and then it automagically updates on the web
<kgunn> nvmd i see jono now said that :P
<DieMumiee> i have issues setting up the build environment for mir. cmake/FindGtest.cmake declares that gtest.a is in <builddir>/gmock/libs/gtest/libgtest.a
<DieMumiee> but it is never created there nor do I find a clue which cmake project creates it there
<kdub> DieMumiee, not sure why... maybe you don't have gtest or gmock installed?
<RAOF> I presume you've run âapt-get build-dep mirâ?
<DieMumiee> yes
<DieMumiee> ah thats an issue of ninja it works with makefiles
<racarr> Submitted a first step of refactoring that I think gets across my idea with msh:: :) going to wait for some discussion on the rest
<kgunn> mterry: so...curious...how's the greeter split going now that mir-on-mir AP test is solved? i know you were going to mp a lightdm to keep sf enabled...but outside of that, any other issues?
<mterry> kgunn, so today the last piece of the puzzle got filed, I believe.  everything is in appropriate trunks except for the lightdm branches and the top-level config changes which will be last
<mterry> kgunn, this is for nested mode switch
<mterry> kgunn, not split greeter
<mterry> kgunn, this is step 1 to split greete
<mterry> kgunn, after this, will be actually splitting greeter out
<mterry> kgunn, then enabling locking
<mterry> kgunn, but for the actual splitting out, there will likely be more yaks to shave around receiving calls and such in the greeter.  I'm going to dive into some of those issues now that nested mode is mostly solved
<mterry> also visual look of the greeter on top of session
<kgunn> mterry: ok...this is kind of sounding daunting...do you need a hand from anyone?
<kgunn> mterry: you can pick who you want as this is a key item we need to nail
<mterry> kgunn, for next step of splitting greeter, I have to catalog remaining issues.  Then I'd know who to get help from.  I suspect if we want to avoid a regression in unlocking animation, I might need some help from a low-level graphical point of view...
<kgunn> RAOF: racarr kdub ...any of you mind if i move the meeting out 30 minutes? i gotta personal commit tonight and i just know it'll run over
<RAOF> Fine by me.
<kgunn> oh wow...that'd be nice if i had put repeat on the invite
<kgunn> doh
<RAOF> Heh
#ubuntu-mir 2013-11-20
<racarr> kgunn: Wait so whattimeisitnow? Not sure ifitupdated in my calendar
<racarr> i.e. dont remember when it was last week
<kgunn> racarr: hey...so...i forgot to make it a repeat anyway...so i had to just send a new invite
<kgunn> racarr: so its, 3hr 15 min from now
<racarr> kgunn: Ok
<racarr> depending on how my soon to start bus bound adventure goes I may be a little late.
<kgunn> racarr: np
<duflu> kgunn: Make it earlier perhaps? As in 90 minutes?
<kdub> duflu, good job on the resizing work :) all my devices seem to work with it
<duflu> kdub: Thanks, but it's still laggy without events
<duflu> kdub: BTW, even Nexus7? I've found Mir on N7 hasn't responded to touch properly (if at all) for some time
<duflu> --> bug 1239501
<ubot5> bug 1239501 in Mir "Nexus 7 does not respond to touch" [High,Triaged] https://launchpad.net/bugs/1239501
<duflu> Hmm, hanging the server with a broken client is bad, right?
<alan_g> yep
<duflu> Argh. So. Many. Deadlocks
<duflu> .
<alan_g> Want to talk about it?
<duflu> alan_g: If I had the words to describe them I would have logged bugs. But for now it's easy to blame myself, since they only happen on my branch
<duflu> Although me finding deadlocks is different to me causing deadlocks :/
<alan_g> so true
<duflu> One of the major problems I have encountered is our client event callbacks coming in on their own thread. That's quite a problem for simple single-threaded clients.
<alan_g> Hmm. We don't have control of the single tread to execute callbacks on it - so what would you do instead?
<duflu> alan_g: I presently have to use pthreads in the single threaded client to signal the primary rendering thread from the event thread. That's not ideal
<alan_g> Why does the simple single-threaded client need to use callbacks? Doesn't the ..._sync API cover it?
<duflu> alan_g: How else do you get immediate notification of resizing?
<duflu> ... or input etc
<duflu> Or do you mean we need a mir_wait_for(mir_next_event(&e)) ? :)
<alan_g> So, you'd want to poll an event queue?
 * alan_g bad memories of the Windows event loop
<duflu> alan_g: Not poll. I'm happy to have everything event driven and sleeping nicely. But whatever it takes to get clients back to one thread would be excellent
<duflu> or perhaps:  what = mir_wait_for_either(mir_sleep(n), mir_next_event(&e))
<alan_g> mir_get_event_sync(...)?
<duflu> alan_g: You really need support for waiting on multiple handles simultaneously to do it properly. Like Win32's WaitForMultipleObjects
<duflu> mir_wait_for_any(a, b, c, NULL)
<alan_g> Perhaps - but doesn't that go further than the "simple" single-threaded client case needs?
<alan_g> BTW How does this hang the server?
<duflu> alan_g: I have the server hung in send() sending a trivial resize notification, while the client is somehow deadlocked.
<duflu> I'll just avoid that path for now and if I can describe the problem in terms of existing logic, then log a bug
<alan_g> duflu: that's clearly a server side bug - I can look at that later
<alan_g> duflu: if the default event callback were to push events into a queue and we provided an optionally blocking  call to pull off the queue doesn't that cover the simple case?
<duflu> alan_g: Essentially yes. I would want to fuss over the client-side API we expose though. In the least you need to be able to wait for any-and-all Mir things that could be happening, including a timeout/sleep to animate the client
<duflu> Even more weird... it's safe for an event callback to swap_buffers on motion events, but not on resize events which originated from motion events
<alan_g> Does "safe" mean guaranteed by a standard? Or just "doesn't break on my machine"?
<mlankhorst> What if the standard is doesn't break on my machine? ;)
<duflu> alan_g: Doesn't *seem* to break and has worked for most of the year
<duflu> (as in fingerpaint)
<alan_g> Ah
<duflu> alan_g: It appears my hanging send() contains a TODO :)  [mfd::SocketMessenger::send()]
<alan_g> That TODO is a typical comment - it disagrees with the code
<alan_g> the send_fds it refers to is now part of that function
<duflu> alan_g: I mean that I need it to be async. It's not.
<duflu> What are the "fds" we're passing around all the time??
<alan_g> duflu: It shouldn't block anyway - so being async would be at best an optimization
<duflu> alan_g: It seems a broken client can block it :)
<alan_g> the fds are handles from gbm or android
<duflu> alan_g: Why do we use them on every message? That's weird
<alan_g> They're optional on all messages. Only a few send them
<alan_g> The wire protocol is blob+optional fds
<duflu> alan_g: Oh, I see. Empty if not provided
<alan_g> ack
<alan_g> So you think we're writing bytes to a socket and get throttled because the client isn't reading the other end?
<duflu> alan_g: Yes, I think so. Another (probably different) problem I have now is that the surface events come in on a different thread to input events. Yet they share the same callback so it's very confusing
<duflu> I suspect we'll need to solve this before resize events can be usefully demonstrated. Unless I instrument all the examples with pthread magic, but that's bad
<alan_g> @"on a different thread" - that's weird. I though there was just the comms thread (and any threads the client code has)
<duflu> alan_g: Weird, but I just remembered I documented that when I discovered it -- http://unity.ubuntu.com/mir/group__mir__toolkit.html#ga171267b0c507a17b2d76a8e927f2d959
<duflu> "and locking" should say "any locking"
 * duflu closes the can of worms and wanders off
<alan_g> alf_: How strong is your preference for references? gmock is throwing up a bunch of errors when I set expectations on a mock of fill_ipc_package(BufferIPCPacker& packer, Buffer const& buffer) - it can't check anything for equality and doesn't like incomplete types.
 * alan_g thinks pointers are fine anyway
<alf_> alan_g: My preference is strong, but if references are causing problems I am OK with pointers.
<alan_g> pointers it is then.
<alan_g> tvoss_: when you have a moment: https://code.launchpad.net/~alan-griffiths/unity-system-compositor/dont-use-ApplicationSession/+merge/193070
<tvoss_> alan_g, looking
<didrocks> kgunn: Mir in -proposed! (thanks to the restless Mirv)
<didrocks> let me cry of joy for a minute :)
<Mirv> :)
<tvoss_> didrocks, :)
<greyback> could someone please check that Mir in daily-proposed works on the Nexus10? It's failing for me with http://pastebin.ubuntu.com/6448151/
<Mirv> addition to above, Mir almost in -release pocket as well (visible in LP that it's already accepted, waiting for publisher run)
<alan_g> Must be time to try landing another batch of updates. ;)
<Mirv> :) rmadison now tells it's in archives for real
<fginther> kgunn, are https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1252933 and https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1252857 duplicates?
<ubot5> Ubuntu bug 1252933 in Ubuntu CI Services "Mir performance testing as a merge requirement" [Undecided,New]
<ubot5> Ubuntu bug 1252857 in Ubuntu CI Services "mir performance baseline, tracking, & blocking" [Undecided,New]
<fginther> kgunn, I received 1252933 from thomi
<kgunn> Mirv: didrocks ...thanks both!
 * kgunn will be laughing all day imagining didrocks crying tears of joy
<kgunn> fginther: lemme look
<didrocks> kgunn: rohhhh! you have no idea about the pain we endure ;)
<kgunn> fginther: yes...those seem to be duplicates, i guess thomi thot mine sucked :)
<fginther> kgunn, I filed the second bug, didn't think to look for one first :-)
<kgunn> fginther: np
<alan_g> greyback: I don't have one to test - but I think you need -r 1228 of dev branch for N10. trunk is based on r1192
<greyback> alan_g: okay
<alan_g> greyback: and to use dev-branch we need to land https://code.launchpad.net/~alan-griffiths/unity-mir/dont-use-ApplicationSession/+merge/195242 (hint hint)
<greyback> alan_g: sure. I'm trying to test it as I type, just bad luck I chose nexus10 to test it on
<greyback> alan_g: I've added 2 little comments to that MR just now
<alan_g> greyback: fixing...
<alan_g> tvoss_: when you have a moment: https://code.launchpad.net/~alan-griffiths/unity-system-compositor/dont-use-ApplicationSession/+merge/193070
<tvoss_> alan_g, yup, still looking
<Mirv> kgunn: you're welcome
<alan_g> greyback: ...pushd
<greyback> alan_g: thanks
<greyback> alan_g|tea: https://code.launchpad.net/~alan-griffiths/unity-mir/dont-use-ApplicationSession/+merge/195242? approved, top approve at your desire
<alan_g> greyback: top-approved. Thanks
<tvoss_> alan_g, can I just use your branch of usc, latest Mir and whatever X drivers we have and give it a spin?
<alan_g> tvoss_: I would hope so.
<tvoss_> alan_g, building right now, just wanted to check before I kill my local setup :)
 * alan_g assumes that the trunk usc is working (hasn't tried it yet)
<tvoss_> alan_g, can you give it a spin, too?
<alan_g> tvoss_: I'm not really set up for it right now. Too many versions in flight
<tvoss_> alan_g, ack, I will give it a spin on two machines then. I'm hesitant to approve as usc has no no tests in place
<alan_g> that's something I'd like to get fixed. But only one set of hands
<tvoss_> alan_g, sure, not saying it's your fault :) just explaining high latency for the review here
<alan_g> tvoss_: I know.
<mterry> Heyo!  Can someone help me with a nested-mir issue?  "Nested Mir failed to find an opaque surface format"
<mterry> I can reproduce with just mir-demos
<racarr> mterry: Oh this is the transparentstuff
<racarr> mterry: https://code.launchpad.net/~robertcarr/mir/alpha-for-nested-servers/+merge/193162 will unblock you for nowbut it wont land
<mterry> racarr, yeah.  I realized today I've been testing all this time with that branch in place
<mterry> racarr, assumed it would have landed by now.  But I see that feedback is needed on that branch
<mterry> racarr, what can I do to move that branch (or something like it) along?
<mterry> racarr, at this point, it's not even what the greeter needs.  This error is just preventing nested Mir at all
<racarr> I guess I need to redo it to expose an option or something
<racarr> oratleast pick a transparent format if there is an opaque one in plac
<racarr> eerr
<racarr> if there is no opaque one
<mterry> racarr, also...  is there not an automated test involving nested Mir?  I would have expected such a test to hit this, although maybe this is android specific
<racarr> no automated testing on actual android devices
<mterry> racarr, well, once we land nested, I guess it will get tested all the time
<mterry> racarr, well, if this could get highish priority, I'd give you a hug
<mterry> racarr, I'm *so* close to landing nested mode
<mterry> racarr, so why can't a nested Mir find an opaque surface format anyway?  Why would that change in nested mode?
<racarr> mterry: Oh it's just that nothing else insists on having an opaque surface.
<mterry> racarr, oh
<mterry> racarr, and android can't provide one?
<racarr> mterry: Apparently not that seems like it must be abug though
<mterry> racarr, OK, well if there's anything I can do to help, let me know
<racarr> mterry: Ok thanks. I will get on it in like
<racarr> 30mins
<racarr> I forgot about the underlying bug when the branch was abandoned because we dont need alpha anymore
 * kdub wades into composition options
<mterry> racarr, me too  :)
<mterry> racarr, and we do need alpha...  just not immediately
<mterry> racarr, greeter will still want to be semi-transparent
<kdub> i don't really know why we even have that error
<kdub> maybe gbm can't bypass buffers with alpha?
<racarr> kdub: Ithink it was
<racarr> "optimization"
<racarr> and a weird strategy ;)
<rsalveti> kdub: so, one more device, the emulator :-)
<rsalveti> 5 "android"-based devices
<kdub> rsalveti, yeah
<kdub> is that working with mir?
<rsalveti> kdub: yup
<kdub> oh :) thats good news
<racarr> Just had a fun idea...trying to figure out how to make the focus mechanism make sense,the idea of customizing behavior doesn't make so much sense anymore, but it's nice for testing the default shell/system compositor, i.e. EXPECT(focus_setter, set_focus), v. EXPECT(surface_controller,raise) EXPECT(input_targeter, target)
<racarr> so I had the idea that maybe there is a 'FocusTracker' which handles the bit of defocusing the focused surface (i.e. updating the attribute) when we focus a new surface
<racarr> but rather than a 'FocusTracker' it could just be a callback
<racarr> i.e. mf::Shell::create_surface(Session, SurfaceParameters, std::function<void(FocusState)> track_focus)
<racarr> the more I type the less im sure :p
<racarr> You can test instead with an integration test by acting on the event sink...
<racarr> and thats probably more clear
<racarr> mterry: https://code.launchpad.net/~robertcarr/mir/nested-dont-require-opaque-surface/+merge/196026
<racarr> should have just dont that right away :p its tiny
<racarr> sorry
<mterry> racarr, heh.  why does nested mode want an opaque surface anyway?
<mterry> racarr, the performance aspect?
<mterry> racarr, oh, just noticed that you want me to review that branch.  I can test on my device, sure.  But should probably have an actual mir dev actually review
 * mterry goes to test
<mterry> racarr, btw, I'm a little confused by the issues of performance around the alpha branch.   If the background is alpha, but opaque things cover that background (like would happen in unity8), why would there be a performance hit?  I figured that alpha bg would be optimized out
<kdub> rsalveti, how does the emulator work?
<kdub> kinda a vague question
<kdub> but is it using a software egl for the android platform?
<xnox> kdub: emulator is the same one as for android. there are egl libraries in android-container, which do pass-through to hypervisor, where a traslation from egl -> host gl is done, host's drivers are used to process gl, and it gets fed back into the emulator.
<kdub> hmm, interesting
<kdub> and the host is X...
<kdub> xnox, how about the display?
<xnox> kdub: there is no host X involved at all.
<xnox> kdub: it's a virtual machine, based on goldfish kernel. so there is goldfish framebuffer which is what mir paints on.
<xnox> to the user it is magically projected over vnc.
<xnox> and that's how humans look at it =)
<xnox> the egl -> gl -> egl translator is very cunning.
<xnox> you can run emulator head-less, as in without projecting the vnc window anywhere.
<kdub> so the emulator does the translation from android platform egl to the host platform's egl?
<kdub> and the other curiosity is that mir only paints the fb via the android HAL surrounding the fb.... so there must be some goldfish friendly hwc somewhere
<kdub> neat...
 * kdub pokes around android code in this area
<kdub> okay, i see how this all works from a high level then.. very cool
#ubuntu-mir 2013-11-21
<robotfuel> racarr: ping
<robotfuel> kdub: ping are you still around?
<kdub> indeed
<robotfuel> kdub: I have failing tests are arm due to memory leaks, do you know who I should ping about it? https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-armhf-ci/139/console
<robotfuel> er I have failing tests on arm due to...
<kdub> ooo, are we running tests on arm? :)
<kdub> robotfuel, i'll take a quick look
<robotfuel> kdub: the tests pass when I don't use valgrind.
<kdub> robotfuel, right
<kdub> robotfuel, i see it too, could you file a bug against mir?
<robotfuel> kdub: will do
<kdub> robotfuel, thanks
<cpatrick08> i am trying to build mir from source on trusty and I get following error http://pastebin.com/zeRYuQiB
<cpatrick08> cmake-gui options for builf http://tinypic.com/r/11b1bsz/5
<robotfuel> kdub: https://bugs.launchpad.net/mir/+bug/1253486
<ubot5> Ubuntu bug 1253486 in Mir "memory leaks in unit tests on android" [Undecided,New]
<kdub> cpatrick08, you could just disable building the unit tests, if thats the only thing failing
<kdub> although, it is strange it can't find eglCreateImageKHR, as nothing should link to that directly anyways
<RAOF> cpatrick08: Hm, difference with my successful builds might be âuse debflagsâ
<cpatrick08> will take that away and try to build again will let you know if that works
<kdub> i retract my statement about 'nothing should link to that'... :) long day
<kdub> sigh, i retract my retraction :)
<robotfuel> cpatrick08: did you try dpkg-buildpackage?
<cpatrick08> no i have not will try it if this does not work
<kdub> morning duflu
<kdub> i made a comment on the bug, but I don't see input problems on my n7
<duflu> kdub: Hi. OK, thanks
<kdub> oh, and resizing was okay too :)
<duflu> kdub: Yeah, that's what confused me. I had demo-shell getting input a week or two ago, but not clients. Now nothing
<duflu> It's only the N7 that's an issue
<cpatrick08> kdub, i removed the unit tests and the make worked but when i ran ctest i got error only on test 23 	 23 - integration-tests.GBMBufferIntegration.* (SEGFAULT)
<cpatrick08> i kept the debflags on btw
<cpatrick08> i am trying it again with the debflags off
<duflu_> RAOF: What am I missing?... https://bugs.launchpad.net/mir/+bug/1253507
<ubot5> Ubuntu bug 1253507 in Mir "The following tests FAILED: 134 - unit-tests.UdevWrapperTest.* (OTHER_FAULT)" [High,Triaged]
<RAOF> duflu: We should really spit out the actual test output when it fails :)
<duflu> RAOF: It's way too long :/
<RAOF> Not for the bit that fails.
<RAOF> Anyway, what *is* the output?
<duflu> RAOF: Yes, the bit that fails is massive...
<duflu> But mostly they say C++ exception with description "Udev device does not exist" thrown in the test body.
<RAOF> Iinteresting.
<RAOF> Pastebin?
<duflu> RAOF: Attached to the bug
<duflu> RAOF: Weird cos my saucy and trusty machines seem to have identical udev packages
<RAOF> Ah, but probably have different umockdev packages?
<duflu> Oh, wait, no. The Ubuntu revisions differ
<duflu> RAOF: Yeah fails on umockdev 0.4.6-2, works on 0.4.7-1
<RAOF> umockdev is just being totally screwy there; it's not providing a mock udev environment at all.
<duflu> RAOF: But it worked a few days ago(?)
<RAOF> Not on those tests it didn't?
<duflu> RAOF: Well, everything we had worked a few days ago
<RAOF> Because those tests are shiny and new!
<duflu> I assume we used umockdev to some extent even before, when it worked
<RAOF> Yeah, we did.
<RAOF> Is there some good reason why lp:mir doesn't resolve to lp:~mir-team/mir/development-branch?
<duflu> RAOF: Not by our own choice. I tried pointing lp:mir to development-branch at the start of the cycle. But distro have a *requirement* that lp:mir be more stable than they perceive development-branch to be
<duflu> So now lp:mir is the Ubuntu branch
<RAOF> I am going to *keep* hitting that, aren't I â¹
<duflu> RAOF: Mainly it's about ABI stability and how any break in Mir affects a string of other projects. So it's good we can batch and control the timing of ABI breaks into lp:mir
<duflu> tvoss_: Morgen
<duflu> RAOF: Apparently the "ubuntu" project branches for Mir can't be used for Ubuntu packaging work. So they need to own lp:mir
<tvoss> duflu, hey there :)
<mlankhorst> morning
<duflu> Ping alan_g
<alan_g> duflu: morning
<duflu> alan_g: Hello. I have spiked that event queue idea. I think it's looking very attractive now, but needs some serious testing yet. So just FYI... please don't duplicate effort for now. I'll get it up for review by Friday in the latest
<alan_g> duflu: that's great. Thanks.
<alf_> duflu: alan_g: Do unit-tests.UdevWrapperTest.* tests fail for you locally with the latest development-branch?
<duflu> alf_: Yes. But only on saucy
<alan_g> no
<alf_> duflu: I am on trusty...
<duflu> alf_: Me too, half the time
<alf_> duflu: I mean they fail for me on trusty
<duflu> alf_: That's odd, but means it's more serious than first thought
<duflu> alf_: There's a bug already BTW: 1253507
<duflu> bug 1253507
<ubot5> bug 1253507 in Mir "The following tests FAILED: 134 - unit-tests.UdevWrapperTest.* (OTHER_FAULT)" [High,Triaged] https://launchpad.net/bugs/1253507
<alf_> duflu: thanks, assigning to myself
<duflu> alf_: If you get that bug on trusty then it's probably Critical :/
 * duflu goes to make dinner
<alan_g> alf_: update - running without ctest I too see the problem
<alan_g> alf_: and something similar in GBMDisplayTest.drm_device_change_event_triggers_handler
<alf_> alan_g: right, the umockdev framework needs an LD_PRELOAD to work properly
 * alan_g leaves it to alf_ who's already on it
<alf_> alan_g: I don't think there is a solution to it. When running manually we need to use the preload (or the related umockdev-wrapper script)
<alan_g> That sucks
 * alan_g wonders if any tests needing this preload should be put in a separate executable
<alf_> tvoss: Please take a look at https://code.launchpad.net/~afrantzis/mir/mir-client-ensure-global-symbol-resolution/+merge/196110 , especially the discussion about the options, since it involves multiple components in our stack
<tvoss> alf_, yup, put it on my list
<alan_g> Any experts on booting with USC about? I tried following the instructions - http://unity.ubuntu.com/mir/using_mir_on_pc.html - although I had to create the .conf file after installing USC. But when I restart I see "/usr/lib/xorg/modules/drivers/intel_drv.so: undefined symbol: xmir_get_drm_fd" in /var/log/lightdm/x-0.log.old. Does anyone know how to fix?
<alf_> alan_g: I haven't seen that before (but it has been a while since I tried USC)
<alan_g> alf_: thanks. (This is my first time with USC.)
<kgunn> alan_g: i can try in a moment...
<kgunn> alan_g: are you on trusty or saucy ?
 * kgunn knows alan_g :)
<alan_g> kgunn: that laptop is on trusty
 * kgunn does _not_ know alan_g  :)
<kgunn> alan_g: ok...i'm on trusty...just looking at your output...sure looks like packaging shenanigans
<alan_g> kgunn: ack
<alan_g> kgunn: What I was really trying to do was test this: https://code.launchpad.net/~alan-griffiths/unity-system-compositor/dont-use-ApplicationSession/+merge/193070
<alan_g> kgunn: If this problem will go away by itself then I don't want to waste too much time
<kgunn> alan_g: so, i already had u-s-c installed, so just had to comment back in type=unity, rebooted...u-s-c/xmir came up fine for me
<kgunn> alan_g: would you like me to rebuild u-s-c from that branch to test?
<alan_g> kgunn: please. I'm going to wait and see if the packages come into alignment over the next few days
<kgunn> alan_g: yeah...something doesn't seem quite right wrt packaging in trusty
<kgunn> based on some previous stuff i've seen
<alan_g> hmm, my netbook just refused to upgrade to trusty as it can't find some of the repos.
<mterry> Did y'all remove the mir::surfaces namespace?  Compiling unity-mir against mir devel-branch gives an error to that effect
<kdub>   mterry it is now mir::scene
<mterry> kdub, thanks, btw
<racarr> mterry: I guess you aren't cool enough to keep up with the hip new scene.
<racarr> *drum crash*
<mterry> racarr, whatever, I'll just hang out with libmirserver7 at my house.  I don't need this mir scene
<racarr> lol
<racarr> welcome
<racarr> to my life
<mterry> :)
<ricmm> kdub_: ping
<ricmm> kdub: ping
<kdub> pong
#ubuntu-mir 2013-11-22
<duflu_> RAOF: Bug 1253507 is now on trusty too :(
<ubot5> bug 1253507 in Mir "The following tests FAILED: 134 - unit-tests.UdevWrapperTest.* (OTHER_FAULT)" [Critical,Triaged] https://launchpad.net/bugs/1253507
<RAOF> duflu: You can't run the unit-tests bare.
<duflu> RAOF: Yes you can. Always have. How else do you run a specific test you're working on? Or under valgrind?
<RAOF> duflu: If you don't want to run âmake testâ, you'll need to run âumockdev-run bin/unit-testsâ
<RAOF> Or export LD_PRELOAD, of course.
<duflu> RAOF: We need to fix that then. All the tests binaries need to be self-contained
<RAOF> This has been - or *should* have been - the case for some time. We've had umockdev tests in tree for ages.
<duflu> Hmm. Although I see the problem :S
<duflu> RAOF: Perhaps make the tests smarter so they don't try stuff that will fail if the environment is wrong
<RAOF> I could do that, yes.
<duflu> Because tests "expected to fail" is just going to trip people up, repeatedly
<RAOF> They're not expected to fail; they're expected to succeed, and do in the correct environment.
<RAOF> Hm. Looks like you can't programatically skip gtest tests.
<racarr> Wow I just heard that all australlians that develop an opinion on https://code.launchpad.net/~robertcarr/mir/consolidate-default-shell-part-1/+merge/195870 get a cookie at the sprint
<racarr> Everyone is talking about it.
<sarnold> oh man wish I could a cookie. but I'm not australian :(
<racarr> Yeahhhh...sorry
<racarr> I don't make the rules
<sarnold> rules are important. but I bet there's some lucky australian who'll get a cookie!
<racarr> and just maybe his wildest IPC fantasies will come true.
<racarr> Good afternoon RAOF :p
<RAOF> racarr: :)
<duflu> racarr: Can't eat cookies :S
<racarr> duflu: Hmm I don't know what your IPC fantasies are either.
<RAOF> racarr: The description makes sense to me; bonus points are available for proceedurally generating the DefaultShell, of course :)
<RAOF> racarr: I'll form a more informed opinion over time :)
<RAOF> duflu: Would you accept tests that fail with a more-correct error message when the environment is wrong?
<duflu> RAOF: Not really. It would be a significant loss to not be able to run "unit-tests" any more. But if you can do an error message then you can if(){} around the failing tests too. Although instructing gtest to disable them would be nicer
<RAOF> duflu: You *can* still run unit-tests.
<RAOF> You just need to run âumockdev-run bin/unit-testsâ
<RAOF> Unless you restrict the tests you run to tests which don't need umockdev, in which case you should still be able to run unadorned bin/unit-tests
<duflu> RAOF: There are solutions out there. I'm really just asking that it not be me who implements one because I'm the only person who cares right now
<RAOF> duflu: I'm just trying to get a sense of what parameters you think a solution must have.
<RAOF> Hm. I wonder if we could just link the unittests to the umockdev SO rather than libudev...
<duflu> Sounds like another option.
<duflu> And so is lunch...
<racarr> RAOF: I think any discussionsabout the IPC,etc will have to wait for the sprint so in the mean time I am just trying to change the way we think about "shell"
<RAOF> racarr: Oh, yeah. Absolutely.
<RAOF> duflu: https://code.launchpad.net/~raof/mir/fix-1253876/+merge/196222 is first part of fix.
<RAOF> duflu: GAH! Does lp-propose not work? I ran bzr lp-propose lp:~mir-team/mir/development-branch, which should target the right thing?
<duflu> RAOF: Apparently not (?!)
 * RAOF should really learn more OpenGL
<duflu> RAOF: It's actually much more fun leanring OpenGL than ES :P
<duflu> *learning
<RAOF> More fixed function, less shaders for everything? :)
<duflu> RAOF: Yes... as in OpenGL complements your C algorithm. You just write C and emit vertices etc when it suits you
<duflu> Also there's much less setup and voodoo that ES necessitates with shaders
<duflu> Whoever designed GL was clever. Whoever designed ES was so desperate to solve hardware-specific performance issues that they forgot to keep the awesomeness of GL
<duflu> Umm, I mean OpenGL. Technically "GL" is an SGI thing that predates it
<alf_> Why is cmake so stupid? It's building the executable before a library that the executable depends on! https://jenkins.qa.ubuntu.com/job/mir-android-trusty-i386-build/258/console
 * duflu reconsiders the wisdom of the past few days work. Maybe it's the wrong approach.
<duflu> And now I have to host dinner :S
<alan_g> alf_: Can you confirm that I've not missed something? The call to frame_posted() would work just as well after secure_client_buffer()  wouldn't it?
<alf_> alan_g: looking
<alf_> alan_g: From what I can see it shouldn't make any difference.
<alf_> alan_g: Are you seeing anything strange?
<alan_g> alf_: thanks
<alan_g> No, just wanted to shuffle stuff and wanted to double check
<alf_> alan_g: hmm, on second though, it will change the timings a bit, since we won't necessarilly recomposite until after the client has got its buffer (will may block for a bit)
<alf_> thought
<alf_> will->which
<alf_> alan_g: thinking whether this could actually block the system completely
<alan_g> alf_: it does change ordering slightly, but I *can't see* that it can cause blocking.
<alf_> alan_g: (after some thought) yes, it seems it would be ok
<greyback> alan_g: alf_: hi folks, can you remind me of something: when using run_mir(config, clientInit) - is Mir server ready to accept incoming connections when clientInit is called? Or it only works as clientInit is an internal client, and so I must use the ServerStatusListener for when external clients can reliably connect?
<alf_> greyback: you need to use ServerStatusListener
<greyback> alf_: ok
<alan_g> greyback: Mir is initialized, but run() hasn't been called
<greyback> alan_g: alf_: thanks!
 * alan_g wonders whether to build on start-cleanup-of-ownership-of-client-buffers when it has a "Disapprove" vote
<greyback> alan_g: +1 on SIGSTOP being a strange choice. Made it particularly annoying to test, run it and it stopped itself
<kgunn> alan_g: alf_ i'm gonna eat bkfst real quick...but this morning, i suppose its time to queue up dev-branch merge to trunk ?? just checking make sure there's nothing to wait on ...
<alan_g> kgunn: nothing essential. Anything "in flight" is a nice to have though. ;)
<alf_> kgunn: nothing special on my side... shmem buffers are getting close, but are not urgent
<dandrader> what's the easiest way for unity8-mir to grab a screen shot (ie. which mirserver API it should use)?
<alf_> dandrader: I would say override the renderer, and read from the framebuffer (glReadPixels) after rendering is done
<alf_> dandrader: override => decorate
<dandrader> alf_, ok. thanks. should I lock any resource explicitly or will it just work?
<alf_> dandrader: no, during rendering the renderer is in complete control of the framebuffer (well, the back buffer to be exact, since we are double buffering)
<dandrader> ok
<alf_> dandrader: hmm, actually now that I think about it this won't work with the current compositor structure
<dandrader> alf_, oh, what should I do then?
<alf_> dandrader: you could implement/override the overlay renderer, which is called after all normal rendering is done and do glReadPixels from there
<alf_> dandrader: but I am not sure what the future holds for the overlay renderer, it seems it's not needed in general
<kgunn> alan_g: alf_ ...was just about to do the version update...noticed this https://code.launchpad.net/~vanvugt/mir/version-0.1.2/+merge/196050
<kgunn> mind approving ?
<alan_g> kgunn: no objection
<kgunn> or...guess i can...sorry to bother..
<kgunn> was thinking something else....
<alan_g> There are worse wastes of time
<kgunn> he just confused me with the todo in changelog...but i totally get it now....epiphany
<ricmm> dandrader|lunch: ping
<ricmm> racarr: ping
<dandrader> ricmm, pong
<ricmm> dandrader: I see you as the author of http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/1193#3rd_party/android-input/android/frameworks/base/services/input/InputReader.cpp
<ricmm> racarr and duflu as reviewers
<ricmm> that branch breaks input on all devices after 16 touches on the screen
<dandrader> ricmm, you need newest qtubuntu
<ricmm> sure it could be patched in qtubuntu
<ricmm> but is there a reason for the count not to reset?
<ricmm> why not hold an internal count for your tracking purposes, instead of changing the android API
<ricmm> just trying to understand the reason of the pointer id increasing across gesture boundaries
<dandrader> ricmm, "Have touch ids remain valid for some time after its touches have physically ended, so one can still refer to a touch that has already ended."
<dandrader> ricmm, and qtubuntu was making wrong assumptions about touch id values
<ricmm> in what way?
<dandrader> ricmm, check the patch there
<dandrader> ricmm, is has an explanation
<dandrader> ricmm, besides, we forked android-input code so that we could modify it to fit our needs
<ricmm> thats not an explanation, thats you saying you are changing the android API
<ricmm> but sure
<ricmm> does this qtubuntu change work with the SF plugin?
<dandrader> ricmm, yes
<ricmm> alright
<ricmm> dandrader: for my own awareness, what are they being used for after the touch ends?
<dandrader> a tap near the edge of a screen
<dandrader> ricmm,  the edge gesture recognition won't know it's not an edge gesture until the touch has already ended
<dandrader> ricmm, and so it has to reject a touch after its end
<ricmm> got it
<greyback> anyone around be able to tell me is mir::graphics::Buffer::id() simply the gl texture id?
<alan_g> greyback: It used to be a generated number - I doubt it changed
<greyback> alan_g: ok, thanks
<kgunn> alan_g: good togo
<alan_g> kgunn: I assume that means "Approve"? ;)
<kgunn> alan_g: yep...i can do that too
<kgunn> uno momento
<alan_g> kgunn: just vote (no need to top-approve yet)
<kdub> alan_g, with the surface/scene cleanup, have you given any thought yet to ms::SurfaceStack?
<kdub> i'm trying to come up with a good interface for overlays, and if SurfaceStack is changing, I might hit conflicts
<alan_g> kdub: only to the extent that the interfaces it needs to support are getting clearer
<alan_g> kdub: I'm fiddling with client buffers for the next couple of days
<kdub> ah, okay
<kdub> the system of filters and iterating over the stack seems pretty okay for the purposes of sorting out overlays
<alan_g> kdub: maybe but it is wrong beyond that
<alan_g> let me sketch why...
<alan_g> we should only be locking the stuff composited by the current compositing pass (think multiple concurrent monitors and hidden surfaces)
<alan_g> So there ought to be a filter pass that selects what will be composited and leaves it locked
<alan_g> And then a compositing pass over the locked stuff
<alan_g> And we should get rid of the lock()/unlock() of everything
<alan_g> So if there's any of that which fits well with your needs...
<kdub> yes, that makes sense
<kdub> so the first filter would trim away surfaces that we know won't appear on the screen, and secures them for render
<kdub> and then the 'overlay filter' would go through and sort out which of those need GL composition
<kdub> and then we would do a composition pass, (GL + overlay), and then post
<kdub> okay, sounds good
<greyback> fuck yeah, I finally have Qt SG compositing Mir surfaces
<alan_g> kdub: yes. I've not thought through all the details. (Was chatting to duflu about it a couple of weeks back)
<alan_g> greyback: sounds interesting
<kdub> i think too that the bypass logic should be buried deeper than the compositor
<kdub> all the compositor needs to know for bypass AND overlays is which layers need GL composition
<kdub> in the bypass case, no gl composition at all, in the overlay case, some gl composition
<alan_g> kdub: I have the feeling that it becomes a special case of ... yeah exactly
<alan_g> bypass is really just using any suitable surface as the fb
<kdub> cool, sounds like we're on the same page
<kdub> and then though, the hardware cursor becomes an overlay that gbm can do
<kdub> and mc:: doesn't know 'this is the cursor'
<alan_g> I hadn't though that through, but it sounds plausible
<kdub> yeah
<kdub> i get an hour of overlap with duflu, will chat with him about it on monday
<kdub> since its already tomorrow in australia
<alan_g> ack
<alan_g> It is already weekend here. ;)
<kdub> i know, every friday, i'm like 'i'm the last one that gets a weekend :('
<kdub> but every sunday, i'm like 'i'm the last one still on the weekend :)'
<kdub> racarr can probably relate
<Kaleo> greyback, well done!
<alan_g|EOW> But the last to get up on a Monday morning
<greyback> Kaleo: ta
<kdub> greyback, with the gnex or nexus4?
<alan_g|EOW> greyback: I'll be very interested in how and any issues you ran into. (But not until next week)
<greyback> kdub: working on nexus4, framerate bad, but same with mir_demo_server_shell, so think it a problem
<greyback> alan_g|EOW: a few things I had to hack into Mir, but not much to get it working
<alan_g|EOW> Bye all! Have a good one.
<kdub> greyback, ah, okay...  i don't really know why you're seeing that
<greyback> kdub: yep, weird alright
<kdub> greyback, but i was spiking on overlays
<greyback> kdub: as I said in the mail, I'm not asking for help, was just an FYI
<kdub> greyback, right
<greyback> it's just weird tho :)
<kdub> greyback, so does that use mir's ms::SurfaceStack? or does it do something else
<kdub> really, I think we can boil the communication we need with the GL compositor down to
<greyback> kdub: it doesn't rely on SurfaceStack - but this is just iteration 1. I get the surfaces from the SessionListener events
<kdub> greyback, ah, okay
<greyback> kdub: this is an early prototype, so that's not a permanent decision or anything. Was just most convenient
<kdub> greyback, right
<kdub> greyback, i think as long as qt's renderer can skip some surfaces, we can work bypass and overlays into the render pass
<greyback> kdub: when a surface is created by Mir, I wrap it with a QQuickItem (so that it can be used in QML). That QQuickItem then can specify the texture to be used in the scenegraph engine
<kdub> without the compositor having to know about bypass or overlays
<greyback> +1 that's my thinking too
<greyback> and not hard to do
<kdub> okay, cool
<greyback> what I think will be most tricky is deciding /when/ can use bypass/overlays
<kdub> greyback, right, but as long as mir can understand the intended composition
<kdub> it can decide, based on the hardware, and the platform, what would be best
<greyback> right
<mhall119> hey guys, I know there's a screenshot script for some of the nexus devices running Mir, but are there plans to build in a more reliable way of getting screenshots and screenrecordings from Mir?
<dandrader> mhall119, well, I just started on a task for providing a way for autopilot to get screenshots
<dandrader> mhall119, something along the lines of unity8 exposing a d-bus method to be called for that.
<mhall119> could that be extended to do recordings too?
<sarnold> .. or vnc?
<dandrader> mhall119, the task is about just screenshots. Which is what autopilot folks are asking for
<mhall119> does it return the screenshot over dbus, or just trigger it with dbus and then access it via the filesystem (or some other method)?
<dandrader> mhall119, I think it will just a filename will be exchanged...
<mhall119> ok, so in theory it could do something similar for video
<dandrader> mhall119, I don't know. I have absolutely no experience with screencasts
<mhall119> ok
<dandrader> eow
<kgunn> alf_: you still on  ?
<kgunn> kdub: or racarr could one of you sanity review https://code.launchpad.net/~mir-team/mir/v0.1.2/+merge/196359
<mhall119> kgunn: being able to record an app in-use on a device with Mir is something app developers are going to want, what do I need to do to get this on your radar/roadmap?
<kdub> okay
<kdub> kgunn, what do you mean by sanity review? :)
<kgunn> kdub: meaning...review and approve...it should just be dev going to trunk
<kgunn> kdub: so mainly the debian bits
<kgunn> version
<kgunn> s
<kdub> okay
<kgunn> mhall119: well...its interesting
<kgunn> mhall119: trouble is
<kgunn> mhall119: we don't want to just let apps read from the fb
<kgunn> its kinda anti-security
<kgunn> an app could certainly read from its own back buffer before it gets composited
<sarnold> kgunn: users are going to want vnc or nx or something similar
<kgunn> sarnold: mhall119 please bring up monday when tvoss is back..i'm well aware but we need something that's cohesive with our security story...and things like "my random remote desktop app" just might not work..we might have to have a signing process or something....
<kgunn> mdeslaur: ^ thots ?
<kgunn> bbiab
<mdeslaur> capturing a video or a screenshot is definitely a privileged operation
<mdeslaur> we want to make sure that the user is able to control that, not confined applications
<mdeslaur> having it live in unity is the right place
<mdeslaur> and we can enforce both access to the dbus call to trigger it, and to the file storage location once it's written out
<sarnold> heh, I _do_ want to confine the vncd .. :)
<mdeslaur> sarnold: yes, the design should allow for trusted apps, such as a vnc daemon, or an alternative keyboard
<mdeslaur> by "confined applications", I meant "arbitrary untrusted confined application"
<sarnold> okay, good :)
<mdeslaur> ie: not stuff from the app store
<mhall119> kgunn: will so
<mhall119> kgunn: my assumption is that an app would need permission to request a screen recording, or use the content hub to request it without app permissions, then it will be given access to read from a local socket or something
<mhall119> or what mdeslaur said, if I had bothered to finish reading the scrollback before commenting :)
<mhall119> but yes, no arbitrary access to the FB
<ricmm> rafalm_: ping
<ricmm> crap, wrong person
<ricmm> racarr: ping
<racarr> ricmm: Pong
<ricmm> racarr: is the msh::Session for the server expected to be null?
<ricmm> you set it to null when creating the surface for the shell in papi
<ricmm> just wondering if thats expected
<racarr> Yes.
<ricmm> ok
<racarr> though maybe its an abuse of API so its possible not everyone knew about this
<racarr> and some code might expect it
<ricmm> I wrote some code expecting it and it blew up in my face
<ricmm> but I went around it
<ricmm> heh
<racarr> Thanks for bringing that up actually its a good point to consider in the shell refactoring thread
<racarr> its weird that a session is the sort of the only way to create a fully functioning surface but the shell doesn't have one
<ricmm> yup
#ubuntu-mir 2013-11-23
<kdub> generic grumble about the surfacestack
<racarr> kdub: Generic response about data models.
<kdub> generic comment
<kdub> haha
<racarr> kdub: Generic drift off in to friday evening :p
<racarr> have a good weekend!
#ubuntu-mir 2013-11-24
<truebattleaxe> morning all
#ubuntu-mir 2014-11-17
<Stskeeps> n
<kgunn> ...and one more time
<kgunn> desrt: hey, curious, we've been talking about disallowing reparenting of surfaces/windows...someone pointed out that gtk permits this
<kgunn>  desrt: just wondering, is this really used ? or do you know of examples ?
<greyback> Qt's API could allow reparenting support, but I don't see it used much at all, probably can live without it
<greyback> https://qt-project.org/doc/qt-5/qwindow.html#setTransientParent
<alan_g> kdub: examples/testdraw/android_graphics_region_factory.cpp uses mir/graphics/android/native_buffer.h (which got privatized with the secrecy drive). Do you think reasonable clients might want access to this header?
<kdub> no, I don't think so
<kdub> there might be a reason in the future, but for the moment, it can stay hidden
 * alan_g decides that testdraw/android_graphics_region_factory.cpp needs fixing
<kdub> yeah, needs some update, its a very old file
<racarr> Morning!
<racarr> Good morning even
<alan_g> kdub: is reworking graphic_region_from_handle() a quick thing for you? (I'm not sure of the right approach - its all unfamiliar)
<kdub> alan_g, rework how? (i'm guessing it depends on some header that's inconvenient)
<alan_g> It uses NatriveBuffer from mir/graphics/android/native_buffer.h
<alan_g> NativeBuffer even
<kdub> hmm, I think I see a way to get rid of it
<kdub> hopefully won't take long
<alan_g> kdub: it is not currently worth spending long on - but would help clean up.
<kdub> alright
<kdub> I'll let you know if I've given up :)
<attente_> hi, i'm having trouble running mir from trunk
<attente_> i keep getting a File already exists in database: mir_protobuf_wire.proto warning
<alan_g> attente_: could that be bug 1391976
<ubot5> bug 1391976 in Mir "Loading libmircommon.so twice leads to a segfault in protobuf code" [High,New] https://launchpad.net/bugs/1391976
<alan_g> ?
<alan_g> Which executable are you using? Which platform?
<attente_> alan_g: yeah, it sounds like it. i'm just trying to run a unity8 session against mir trunk
<alan_g> attente_: you've built U8 against your build of Mir? There are ABI breaks
<attente_> alan_g: i have as well as u-s-c, but i get a different exception
<attente_> alan_g: Warning: ignoring unrecognised arguments: --vt 8
<alan_g> Ignoring things isn't an exception
<attente_> alan_g: http://paste.ubuntu.com/9058242/
<attente_> sorry, i didn't want to paste in the channel
<alan_g> "std::exception::what: Could not open hardware module" - not running as root? Already running a USC instance?
<attente_> alan_g: just trying to run it from lightdm
<attente_> as a desktop session
<alan_g> We're still talking USC?
<attente_> the session is lightdm-unity8-session
<alan_g> You pasted an exception "std::exception::what: Could not open hardware module" - that was from USC? I'm guessing it wasn't run as a privileged user?
<attente_> alan_g: i'm not sure, that paste is from the /var/log/u-s-c.log though
<anpok> attente_: on x86 with mesa drivers?
<attente_> anpok: amd64 with mesa drivers
<anpok> then why does it load the android drivers
<attente_> anpok: no idea
<attente_> anpok: i don't have either of the android platform driver packages installed
<attente_> anpok: argh. thanks, apparently i had the libmirplatform4driver installed
<anpok> you need at least the -mesa one ..
<Trevinho> does MirDisplayOutput provides the subpixel order of that output in some way?
<racarr> Trevinho: Not yet! Looks like there is subpixel info in DRM since feb though.
<racarr> feburary
<Trevinho> racarr: cool, thanks
<racarr> Thank you :)
 * kdub goes cross-eyed trying to think of the proper nested abstraction
<kdub> i'm becoming convinced that nested and offscreen
<kdub> are just different display modes
<kdub> not really platforms of the same par as android/mesa/etc
<racarr> kdub: Sounds like display mode/platform is onto something
<racarr> maybe the offending noun is platform right
<racarr> so broad....
<kdub> yeah, but its okay when used with mesa and android imho
<kdub> because those can provide all thats needed
<racarr> mm I guess I just mean contrasting against it is hard.
<racarr> like its hard to say what is a display mode and what is a platform
<racarr> because
<racarr> platform is so vague
<kdub> sure
<kdub> I'm favoring just having the display server override the display creation for our two 'interesting' modes (offscreen and nested)
<kdub> and also telling the platforms if they're the one server instance to rule them all when we create the platform
<kdub> because there's also some confusion in our libplatform C functions about that
<kdub> which, has a massive negative diff :) and makes it less confusing when some other driver comes along
<kdub> such as llvm
<kdub> I guess we'll see what it looks like once I get through tgetting things to compile
<racarr> mm
<racarr> seems like a promising path :)
<kgunn> robert_ancell: hey, curious... i tried to ask ryan this earlier, not sure if he's out or something
<kgunn> but, we were talking about reparenting surfaces/windows
<kgunn> and i heard gtk supports it, but is it really employed ?
<robert_ancell> kgunn, when we discussed it with RAOF Ryan said he'd look at putting a warning into GTK+ to discourage apps from doing it. We couldn't think of a reason why they would need to
<kgunn> it's been something we didn't want to support, but if there's cases etc
<kgunn> ah...ok
<robert_ancell> I think it's mostly just a hangover from X
<kgunn> yeah, i was just curious if we were being draconian
<kgunn> robert_ancell: thanks...and good to know you guys expected it as well
<robert_ancell> kgunn, http://irclogs.ubuntu.com/2014/11/05/%23ubuntu-desktop.html#t23:55
<robert_ancell> found it
<kgunn> ta
<robert_ancell> https://bugzilla.gnome.org/show_bug.cgi?id=739697
<ubot5> Gnome bug 739697 in .General "GTK should warn when reparenting a shown window" [Normal,Unconfirmed]
#ubuntu-mir 2014-11-18
<duflu> RAOF: EOD merge proposals then? :)
<duflu> All the proposals
<mlankhorst> duflu: you know the mesa side better right?
<duflu> mlankhorst: Better than Android at least
<mlankhorst> I'm playing around with XMir, and I have sw rendering working
<mlankhorst> but my egl knowledge is lacking, how can I get glamor working, possibly with multiple windows? (in case of rootless xmir)
<duflu> mlankhorst: I'm not sure it ever did. RAOF would know what's missing. I think something was
<mlankhorst> was thinking of using some egl calls instead of raw mir in a couple of places
<duflu> mlankhorst: Yes, Mir likes you to use egl
<mlankhorst> oh.. some interacting with eglCreateWindowSurface might work
<duflu> mlankhorst: Yeah see mir's examples/
<anpok_> alan_g: are you currently working on exposing something like the fake-event-hub, for acceptance testing?
<alan_g> anpok_: not currently - I was hoping you or racarr would get to it first.
<duflu> alan_g: Is it intentional that Server does not have virtual methods? That's not what I thought it would be...
<anpok_> duflu: for abi stability .. to have those as symbols
<alan_g> duflu: it is intentional
<anpok_> instead of table entries
<duflu> alan_g: So a "Shell" would contain a "Server" then?
<anpok_> ok.. just rememberd your recent change there and thought you might be starting something
<duflu> I'm confused because Server has shell methods...
<anpok_> alan_g: I am about to form a mir replacement of what EventHub does using the stuff RAOF added there
<alan_g> duflu: yes, there's a spike here: https://code.launchpad.net/~alan-griffiths/qtmir/migrate-to-mir-Server-API/+merge/240451
<alan_g> and here: https://code.launchpad.net/~alan-griffiths/unity-system-compositor/migrate-to-mir-Server-API/+merge/240566
<duflu> alan_g: It might be more instructive for me to see how you convert demo-shell...?
<duflu> If I wait for that instead of trying myself
<alan_g> duflu: basic shell has been converted if that's of use
<duflu> I think basic shell was too basic to answer my questions but will look again
<alan_g> (And minimal, but that's not useful for this)
<duflu> alan_g: I think I need to learn how your design protects the ABI first
<alan_g> No vtab index changes, no implementation changes, fewer customization points
<duflu> I do wonder if it's helpful that we distinguish between "shell" and "server". I think "shell" is just a server with customized behaviour
<alan_g> Mir handles a number of concerns that are of no direct interest to the shell (IPC, graphics and input drivers, ...)
<duflu> alan_g: Yeah I can see some line...
<duflu> alan_g: Consider however Server.override_the_placement_strategy() -- it's a shell feature so if Shell can't inherit from Server then functions like that need to move into some generic Shell class instead
<alan_g> I'm not following, can you give an example?
<duflu> alan_g: "placement strategy" is a shell feature. It changes according to which shell you're using. So in the end I think placement behaviour needs to be a feature of a shell class, somewhere. The issue is you can't make a shell class that inherits from Server so it would have to contain a Server. But then you still have "placement strategy" in the server and not the shell
<duflu> I think that feature is misplaced, and it's something I'm working on directly right now... so need to figure it out
<duflu> Agreed however that most of Server is indeed server stuff and not shell
<alan_g> You just have to tell the server which placement class to use
<duflu> alan_g: I think you will find when there exists a Shell class separate to Server then the server no longer cares about placement strategy. It's entirely a shell concern
<duflu> The server should send all policy queries (e.g. placement) to the shell to decide
<duflu> alan_g: Maybe we need a function of Server to "set_shell(Shell ..)" to begin with?
<alan_g> duflu: your saying all queries should be answered by one shell interface, what I see is have is specific queries being answered by specific shell interfaces.
<duflu> alan_g: Absolutely, it scales better and fits peoples' mental models. Instantiating N different policy classes is a nightmare
<duflu> I'm trying to improve on it
<duflu> Also, what you think is PolicyX might need to talk to PolicyY and PolicyZ (e.g. state settings depend on current type)
<duflu> So, one class can do that trivially with much less effort and coupling
<alan_g> I disagree, but you can define your interface simply by subclassing all the existing ones
<duflu> alan_g: I'm handwaiving again and it's after hours. I'll try and do a prototype and see if it improves things at all
 * alan_g waves goodbye
<alan_g> Have a good evening
<duflu> alan_g: I think a good example to think about is how to eliminate the poorly-named "WindowManager" in demo-shell. I think that should just become a more capable "DemoShell" class
<duflu> And then logical cleanups should follow
<alan_g> anpok_: if you have a design that plays nicely with mir::Server that will help my migration task
<anpok_> alan_g: not sure yet.. whether we want a testing-(input)platform with an interface to create fake devices and emit user input or just some sort of always available interface to inject devices and events..
<alan_g> anpok_: we have more-or-less the same question with the graphics. The existing stub graphics platform doesn't (yet) allow customization for testing scenarios
<mlankhorst> how much effort would be it to use client-side allocation for mir-mesa?
<anpok_> u need that for glamor?
<greyback> is there a mir_demo_client which prints out the frame rate any more?
<mlankhorst> anpok_: hm I just found a way around it using some internal glamor copy thing
<mlankhorst> but now I need the stride for the fd that was passed by mir
<mlankhorst> oh oops, it exists ;P
<mlankhorst> yay, glamory eyes that work
<alf_> greyback: You can set MIR_CLIENT_PERF_REPORT=log for any client now
<greyback> alf_: ah ok, thanks!
<mlankhorst> yay, xeyes on glamor working \o/
<alf_> mlankhorst: great!
<anpok_> mlankhorst: yay for xeyes!
<mlankhorst> I seem to get some minor visual glitches, not sure where they're coming from
<mlankhorst> and they're probably gone if I invalidate the entire screen each time, looks like some stale damage :/
<mlankhorst> alf_: you were the one that helped me debug nested mir right?
<alf_> mlankhorst: could be, I don't remember
<alf_> mlankhorst: Is there something I could help with?
<Trevinho> robert_ancell: hi
<robert_ancell> Trevinho, hi
<Trevinho> robert_ancell: today I gave a look at the new gdkgl thing... and I've made an implementation for gdkmir...
<robert_ancell> Trevinho, cool. I had a look yesterday too but it seemed non-trivial :)
<Trevinho> robert_ancell: I've pushed it at https://github.com/3v1n0/gtk/compare/wip/mir-gdkgl for now, but I might move that to a new branch in git.gnome if you prefer...
<Trevinho> robert_ancell: things work... *but*...
<robert_ancell> It would be better in git.gnome.org as a wip/mir-gl
<Trevinho> ok, cool
<Trevinho> robert_ancell: as you can see http://people.ubuntu.com/~3v1n0/gdkgl-mir-ok.avi
<Trevinho> it does the job
<robert_ancell> Trevinho, nice work!
<Trevinho> robert_ancell: thanks :).. but here (radeon) not when using eglSwapBuffersWithDamageEXT it has some problems
<Trevinho> robert_ancell: see http://people.ubuntu.com/~3v1n0/gdkgl-mir-bad1.avi
<Trevinho> robert_ancell: it's like there's a corruption somewhere
<robert_ancell> You'll have to ask the Mir guys about that one
<Trevinho> robert_ancell: yes, that's also why I'm here...
<robert_ancell> RAOF, hah, timing!
<Trevinho> RAOF: hi... (speaking of the devil...)
<Trevinho> :D
<robert_ancell> <robert_ancell> You'll have to ask the Mir guys about that one
<robert_ancell> <Trevinho> robert_ancell: yes, that's also why I'm here...
<robert_ancell> --> RAOF (~RAOF@ppp105-211.static.internode.on.net) has joined #ubuntu-mir
<Trevinho> or maybe not :P
<Trevinho> robert_ancell: anyway, how dow we want to track it? should I also open a bug on bugzilla?
<Trevinho> robert_ancell_: also I pushed a backend for cogl, that should then make also clutter working (not sure what will be the future of these, but we still need them I guess)
 * robert_ancell_ -> lunch, bbl
<RAOF> robert_ancell, Trevinho: You rang?
<Trevinho> RAOF: yep...
<Trevinho> it's for this https://www.youtube.com/watch?v=xQyfvEvQ_G0
<Trevinho> RAOF: that's gdkgl support in mir... I've been working on it few hours and got mostly working... But....
<Trevinho> all you see there happens when using an eglSwapBuffer call... when instead using eglSwapBuffersWithDamage, I get some corruption (like you can see at http://people.ubuntu.com/~3v1n0/gdkgl-mir-bad1.avi)
<Trevinho> RAOF: basically if this if: https://github.com/3v1n0/gtk/blob/wip/mir-gdkgl/gdk/mir/gdkmirglcontext.c#L146 is false it works, otherwise it seems that it swaps garbage...
<RAOF> Hm. That .avi quite effectively freezes my session.
<racarr> haha
<Trevinho> RAOF: ops... try with vlc, or mplayer... mencoder did it
 * RAOF suspects gstreamer's vaapi support; the intel drivers seem to be a bit flaky on Vivid.
<RAOF> Trevinho: Anyway, while I think we implement SwapBuffersWithDamage we don't actually do anything with the damage.
<RAOF> Ahem.
<RAOF> DANCING MENUBAR!
<RAOF> (Care of unity-panel-service bouncing, it seems)
 * Trevinho might be involved on that as well :P
<Trevinho> RAOF: mh, I'm not sure whether it's fully using it (it looked the case when I tried), but I've also made a cogl backend and it uses SwapBuffersWithDamage... And I didn't see these troubles
<RAOF> Hm. That crazy vid looks like you're only drawing every second frame.
<Trevinho> RAOF: yes,m it looks like that
<Trevinho> RAOF: if you see http://people.ubuntu.com/~3v1n0/gdkgl-mir-bad2.avi
<Trevinho> RAOF: there it's even different.. it only draws when something changes on the screen,
<Trevinho> RAOF: you can't see the mouse cursor, but I was just moving the cursor over the gtk widgets to make them change state
<Trevinho> and thus to make the ui redraw
<RAOF> Hm.
<Trevinho> RAOF: in some other cases it happens that the surface seems to swap between a the new state and a very old one... So, every few ms you see the old look of the window and then the new one... While the old one doesn't seem to update
<Trevinho> (it's like the very first frame swapping with the new ones)
<RAOF> Hm. Could you shoot me the code?
<RAOF> I can have a look.
<Trevinho> RAOF: ah you maybe misseed my link before... it's at https://github.com/3v1n0/gtk/blob/wip/mir-gdkgl/gdk/mir/gdkmirglcontext.c#L146
<RAOF> I probably did; thanks to unstable session :)
<Trevinho> no worries
<racarr> transition scheme in place for event 2.0...semantics worked out for pointer ev v. touch event implementation of key event finished
<racarr> think I am 4-5 hours of work from having the transition path to propose :)
<racarr> but not today :(
<Trevinho> RAOF: basically at the point I linked you, if using the simple eglBufferSwap works, but I'm not sure it's still perferct in terms of rendering
#ubuntu-mir 2014-11-19
<RAOF> Trevinho: I take it invalidate_for_new_frame isn't called by anything?
<Trevinho> RAOF: it's called by gtkwindow as it's used as function overrider in gtkmirwindowimpl
<RAOF> Ah, ok.
<Trevinho> RAOF: so at the end in gdkwindow.c at line 3653
<RAOF> Why does it bail early if not using GL? You still need to account for previous damage (unless you always do full-window repaints when not using GL?)
<Trevinho> RAOF: not sure I undestood what you mean...
<Trevinho> ah, the function...
<RAOF> https://github.com/3v1n0/gtk/blob/wip/mir-gdkgl/gdk/mir/gdkmirglcontext.c#L63
<Trevinho> well, when not using gl it shouldn't be called at all, in that case it uses a 2d surface
<Trevinho> RAOF: basically this function works only when a gdkgl area is used, which happens only when using a gtkglarea, not for all the rest of the widgets
<RAOF> Fair chop.
<duflu> Wow, src/server/ is 317 files now. No wonder I'm still getting lost
<mlankhorst> why so many?
<duflu> mlankhorst: Mir does more than you think
<duflu> Just not all that you want (yet)\
<duflu> alan_g: Any idea why C++ says you can't get to namespace local things in the parameter list, but can in the function body?
<alan_g> duflu: do you means something different to what I understand by "namespace local things"?
<duflu> alan_g: I mean a function parameter list must use full namespace spec, and can't implicitly get to the namespace the function is in
<duflu> I guess parameter list is different scope to the body
<alan_g> I don't believe that is true.
<alan_g> Give an example
<duflu> alan_g:   mir::shell::Something::doit(shell::Type x)
<alan_g> Like mir::logging::Logger::log(Severity, ...)?
<alan_g> That works
<duflu> alan_g: Maybe it's a different issue. No big deal.
<mlankhorst> duflu: yeah, I would really like to have support for multiple keyboard/etc
<duflu> mlankhorst: If that's your only complaint then we're doing well
<duflu> mlankhorst: Find the egl examples?
<duflu> We have a few
<mlankhorst> well, no
<mlankhorst> window management is lacking, makes rootless hard
<duflu> mlankhorst: Working on that right this moment
<duflu> mlankhorst: You know how to use mir_server_demo_shell?
<mlankhorst> no, not at all
<duflu> mlankhorst: Very primitive WM: http://unity.ubuntu.com/mir/demo_shell_controls.html
<mlankhorst> don't even know the differences between all those mir servers
<mlankhorst> oh and support for synaptics would b enice
<anpok_> working on it
<duflu> mlankhorst: I think anpok is working on libinput now
<anpok_> and the underlying libevdev is causing some trouble with umockdev
<mlankhorst> ah
<mlankhorst> what about support for dumping keymappings so I can tell X about them?
<duflu> alan_g: I didn't realise yesterday that "Shell" is a class already :)
<duflu> alan_g: So I'm side-stepping that and making a "WindowManager" to avoid changing too much at once
<alan_g> I don't know what your trying to solve. I thought I explained why there wasn't a problem yesterday
<duflu> alan_g: I'm avoiding large changes suggested yesterday
<duflu> These are less invasive
<duflu> Not final, but smaller steps
<mlankhorst> who knows more about the lifetime management of the buffers with mesa?
<duflu> mlankhorst: A client is guaranteed to own any buffer the server gives it till the next swap
<duflu> That's possibly all you need to know in the client
<mlankhorst> duflu: yes, but what happens if I cache the fd's, should that work?
<duflu> mlankhorst: Possibly not. The server might resize the surface once it gets it back. And I think that could mean the old one is gone
<duflu> Resize means delete buffers when it's safe and replace them with new ones of the new size
<mlankhorst> does it reset the buffer age in that case?
<duflu> mlankhorst: Don't know. It _should_ I guess but unsure
<mlankhorst> mm *checks how xorg-mir does it*
<mlankhorst> ok it just does the whole dance over and over
<mlankhorst> duflu: but is it really a good idea that the fastpath is gbm_bo_import, eglCreateImageKHR, glGenTextures, glEGLImageTargetTexture2DOES, glDeleteTextures, eglDestroyImageKHR, gbm_bo_destroy ?
<duflu> mlankhorst: *shrug*
<mlankhorst> bleh
<mlankhorst> duflu: what about the drm fd, is that a new one only used by the device?
<duflu> mlankhorst: I have lost context, sorry. Would have to dig through source to answer anything like that
<mlankhorst> oh oops
<mlankhorst> *checks if gbm closes the drm fd or not*
<mlankhorst> even dup'ing seems to be affected, great
<duflu> Woo, working on-the-fly WM policy
<duflu> Just needs a few days to make it nice
 * alan_g wonders if he's the only one to find the log messages now coming from the tests a PITA
<kdub> alan_g, I do too... was thinking of logging a bug :)
<kdub> https://bugs.launchpad.net/mir/+bug/1394221
<ubot5> Launchpad bug 1394221 in Mir "acceptance_tests are too chatty" [Medium,New]
<alan_g> camako: the AnonymousShmFile tests should pass on kernel 3.13 shouldn't they? https://code.launchpad.net/~alan-griffiths/mir/migrate-more-acceptances-tests/+merge/242094/comments/596315
<mlankhorst> ugh found my issue, I had to RTFM
<mlankhorst> "If the EGL rendering context context is not current to any thread, eglDestroyContext destroys it immediately. Otherwise, context is destroyed when it becomes not current to any
<mlankhorst>                     thread."
<mlankhorst> x11perf works again now, and I no longer get those weird issues I was having..
<mlankhorst> the basic functionality is now stable, on towards handling resizing events I guess. :P
<camako> alan_g, yes they should
<alan_g> camako: thanks
<anpok_> mlankhorst: cool
<attente_> hi, is there any progress on https://bugs.launchpad.net/mir/+bug/1391976? i can't seem to get unity8 running from trunk because of it
<ubot5> Launchpad bug 1391976 in Mir "Loading libmircommon.so twice leads to a segfault in protobuf code" [High,Confirmed]
#ubuntu-mir 2014-11-20
<Trevinho> RAOF: hey! You remember that buffer corruption? It happened because I forgot to filter out a surface buffer swap when using egl.... :/....
<Trevinho> RAOF: but.... after doing that, I don't get anything draw at all
<RAOF> Trevinho: So you were swapping twice?
<Trevinho> when using egl swap with damage (eglBufferSwap stul works)
<Trevinho> still^
<Trevinho> RAOF: yeh, i was...
<RAOF> Behind the back of EGL! Naughty!
<Trevinho> RAOF: but now I presume is something more driver related at this point...
<Trevinho> RAOF: like it says it supports swap with damage, while is not the case
<RAOF> Yeah, I'll just have a second look at what our WithDamage implementation does.
<RAOF> Trevinho: Ahem. We lie through our teeth about supporting SwapBuffersWithDamage
<Trevinho> RAOF: ah! :)
<RAOF> Likewise, buffer_age
<RAOF> But at least in that case we always return 0.
<RAOF> So it's harmless.
<RAOF> Our SwapBuffersWithDamage returns EGL_FALSE
<RAOF> And nothing else :)
<Trevinho> Ah, in fact I was getting an EGL_FALSE but then eglERrror didn't say anything about that, so I was wondering if I was wrong about it
<Trevinho> fair enough btw... RAOF any plan for supporting them?
<RAOF> Yes.
<RAOF> I could trivially fix the buffer_age now.
<RAOF> In fact, I shall.
<Trevinho> cool
<RAOF> But WithDamage requires that we actually implement some form of damage :)
<RAOF> I can fix that we say we support it, though :)
<Trevinho> RAOF: that's enough for us I think
<Trevinho> robert_ancell: ^^ so... it looks like that the at gdk level all is fine for supporting gl... .)
<Trevinho> robert_ancell: got any chance to check that branch?
<robert_ancell> Trevinho, I'll have a look now
<Trevinho> robert_ancell: thanks, as RAOF will fix the fact that egl says we've extensions we actually don't support, I guess I can also remove the hardcoded "return FALSE" on about supporting the buffer damage swap
<Trevinho> robert_ancell: and... Once you've done with that, give a look if doing this makes sense to you: https://git.gnome.org/browse/gtk+/commit/?h=wip/mir-async-swaps&id=4073caf3b47a9c847b30d9238860e9f16118337c
<robert_ancell> Trevinho, can you convert it into a patch and put it in bugzilla? It will be easier to review like that
<Trevinho> robert_ancell: sure
<robert_ancell> I immediately notice you've added gdk_mir_window_get_mir_surface which doesn't seem related or necessarily something we should be exposing
<Trevinho> robert_ancell: you meant the whole branch or this last patch
<robert_ancell> I'm looking at the wip/mir-gdkgl branch
<Trevinho> robert_ancell: yes, I added that because also other toolkits expose such stuff (x11 the xid, wayland the surface) and... we'd need it for clutter
<robert_ancell> Trevinho, right, but you need to just propose one change at a time
<Trevinho> robert_ancell: that was my plan, i just forgot to remove that patch from the branch :(
<robert_ancell> OK, I'll have a look when you have a cleaned up patch in bz
<Trevinho> robert_ancell: it's at https://bugzilla.gnome.org/review?bug=740346
<Trevinho> ops, no it seems I've squashed one patch that was out
<robert_ancell> RAOF, mir surfaces can change types?
<RAOF> robert_ancell: I believe so; I think we've got a design requirement for morphing windows.
<duflu_> Not clear if that ever changes parenthood. I think sabdfl was driving that idea
<RAOF> I believe it might unset parenthood; dialog â normal would.
<duflu> RAOF: Yeah that's one.
 * duflu likes the idea of morphing because it's beautiful and computationally really simple to implement
<RAOF> I don't think any morph would reassign parent, though.
<Trevinho> robert_ancell: I've removed the extra commit, patch updated at https://bugzilla.gnome.org/review?bug=740346&attachment=291049
<robert_ancell> yep
<robert_ancell> reading it now
<duflu> RAOF: Although to do it properly I think we might end up with separate src and dest surfaces
<duflu> Not sure
<RAOF> robert_ancell: Oh, by the way: http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/2074
<robert_ancell> RAOF, nice!
 * Trevinho seconds that!
<Trevinho> robert_ancell: about moving these functions to gdk_mir_window or gdk_mir_display... I wanted to do the same since the beginning but then I avoided to  do that not to expose privately the definition of GdkMirGLContext...
<Trevinho> robert_ancell: so I just followed what gdk was doing in other toolkits
<Trevinho> robert_ancell: but... I agree that it would be better to keep these functions in the place where they override.... Not sure if it's better for reading the whole gl code btw... (I mean, having all these inside gtkmirglcontext makes easy to see the whole gl engine in the same place)
<Trevinho> robert_ancell: let me know what you prefer... whether adding a gdkmirglcontex-private.h with the struct definition or the way it is
<robert_ancell> Trevinho, I'd prefer the private header
<Trevinho> robert_ancell: ok, doing it
<robert_ancell> Trevinho, note the other backends do it that way but I changed that for the Mir backend
<Trevinho> robert_ancell: yes, I noticed...
<Trevinho> robert_ancell: want a new private header, or should I use gdkmir-private?
<robert_ancell> Trevinho, just commit the gdk_mir_display_get_mir_connection change directly if it's just a trivial change
<Trevinho> k
<robert_ancell> Trevinho, use gdkmir-private
<Trevinho> robert_ancell: updated
<robert_ancell> Trevinho, ack
<robert_ancell> Trevinho, #include "gdkglcontextprivate.h"
<robert_ancell> Doesn't exist in patch
<robert_ancell> (in gdkmir-private.h)
<Trevinho> robert_ancell: it's provided by gdk..
<Trevinho> that's the genric
<robert_ancell> oh, duh
<Trevinho> robert_ancell: updated
<Trevinho> robert_ancell: ta
<alan_g> Rats! alf TA'd an MP I was updating in response to review comments. https://code.launchpad.net/~alan-griffiths/mir/restrict-access-to-private-headers/+merge/242097 - should I kill the updates?
<alf> alan_g: We can always switch to needs review again and cancel the autolanding job
<alan_g> alf: just doing that. ;)
<alf> When compiling with clang I get "multiple definition of `pthread_equal'" errors when linking the tests. Has anyone seen this? (vivid, clang 3.5.0)
<mlankhorst> hmm
<mlankhorst> I'm toying with enabling copy-less support on DRI2, but it seems to be more concerned about lifetime
<mlankhorst> RAOF: hmm... how do I allocate depth buffers?
<attente_> hi, is there any progress on https://bugs.launchpad.net/mir/+bug/1391976? i can't seem to get unity8 running from trunk because of it
<ubot5> Launchpad bug 1391976 in Mir "Loading libmircommon.so twice leads to a segfault in protobuf code" [High,Confirmed]
<alan_g> attente_: AFAIK that bug shouldn't be affecting unity8 - could you share why you think it does?
<attente_> alan_g: not sure, but i keep getting this in .cache/upstart/unity8.log: http://paste.ubuntu.com/9123860/
<attente_> alan_g: is it possible that i need to rebuild another dependency against mir? i'm building u-s-c and unity8
<alan_g> are you running on desktop or phone? Are you rebuilding qtmir?
<alan_g> does your u-s-c work?
<attente_> alan_g: on the desktop, haven't rebuilt qtmir
<alan_g> attente_: unity8 uses mir through qtmir, you'll need that
<alan_g> greyback: anything I'm missing? ^^
<attente_> alan_g: thanks, i'll try rebuilding qtmir to see if it helps
<mlankhorst> bleh.. I wish I knew someone who understood this crap better than me :P
<anpok> mlankhorst: hm depth buffers.. for that we should have an interface..
<anpok> but you are only using mir_client?
<anpok> or again, you mean .. you want to configure the depth of the depth buffer?
<mlankhorst> I want to figure out how I can create a depth buffer and pass that along for dri2 to use
<greyback> alan_g: nothing I can think of.
<attente_> alan_g: can't seem to build qtmir for the same reason: tests are failing because of the libprotobuf problem: File already exists in database: mir_protobuf_wire.proto
<alan_g> attente_: can't *build* qtmir?
<attente_> alan_g: yes
<attente_> tests are failing because of that segfault
<alan_g> attente_: you don't somehow have the libmirplatform*-android platform library installed do you?
<attente_> is there some special way of building/running them from trunk? i've just been trying to build using debuild and ccache, but wondering if there's an easier way to build and run from trunk
<attente_> alan_g: no, those aren't installed
<alan_g> attente_: I don't often build them but I just point pkgconfig at a local install.
<alan_g> greyback: any better suggestion? ^
<greyback> attente_: easiest way to build qtmir (after bzr clean-tree) is: qmake "QMAKE_CXX=arm-linux-gnueabihf-g++-4.9" "QMAKE_LINK=arm-linux-gnueabihf-g++-4.9" "QMAKE_LINK_SHLIB=arm-linux-gnueabihf-g++-4.9"
<greyback> then make & make install
<greyback> but try "make check" - those are the tests
<attente_> greyback: does this work for you on x86_64?
<greyback> attente_: ah, I thought you on arm
<greyback> attente_: qmake "QMAKE_CXX=g++-4.9" "QMAKE_LINK=g++-4.9" "QMAKE_LINK_SHLIB=g++-4.9"
<attente_> greyback: hmm.. i still seem to be getting the protobuf error after doing make check
<greyback> attente_: then it's something in Mir IMO
<greyback> attente_: are you using a custom build of Mir?
<greyback> do the mir-demos work for you?
<attente_> greyback: it's mir from the current trunk
<attente_> i built using debuild and ccache
<greyback> attente_: have you other copies of the mir libraries in /usr/lib by any chance?
<attente_> mir demo shell is working
<attente_> greyback: i have libmircommon2/libmircommon3, libmirplatform3/libmirplatform4, etc. installed
<greyback> attente_: you should only have 1 of each of those
<attente_> but there seems to be a bunch of things (including unity8) that are depending on the old ones
<greyback> as I'm not certain Mir is good at having multiple versions of itself installed at once
<attente_> greyback: ok, i'll remove them and try again. thank you!
<alan_g> I'm certain it was bad at it and it's getting fixed (but possibly not there yet)
<greyback> attente_: let us know if it helps
<attente_> greyback: alan_g: ok, qtmir tests are passing again now, i am hopeful for the rest. thank you!
<greyback> attente_: great!
<alan_g> attente_: :)
<alan_g> camako: are you working on bug 1394221? (If not I'll steal it)
<ubot5> bug 1394221 in Mir "acceptance_tests are too chatty" [Medium,Confirmed] https://launchpad.net/bugs/1394221
<camako> alan_g, yes I am
<alan_g> camako: the problem you mentioned - https://code.launchpad.net/~alan-griffiths/mir/fix-set_logger/+merge/242392
<camako> alan_g, oh sh*t... my fault... thx for the fix!
<alan_g> I just happened to look in the right place
 * alan_g suspects he wrote the offending expression in an untested spike and also shares the blame for not seeing it at review time.
<RAOF> mlankhorst: You allocate depth buffers yourself.
<RAOF> mlankhorst: Mir is only ever going to give you colour buffers. If you need any auxiliary buffers, you're free to allocate them however you want.
<mlankhorst> yeah I'll just implement it by ignoring it
<mlankhorst> I'm not sure anyone cares about sharing depth/stencil buffers
<RAOF> They manifestly do not; Intel at least has been ignoring that part of the spec for a number of years.
#ubuntu-mir 2014-11-21
<duflu_> Ugg. Another problem that apparently can't be solved without measuring time intervals
<duflu_> I hate those
<duflu> To the cookery
<duflu> Verb or noun, either way
 * alan_g wonders why running all the tests at once causes a consistent failure in the one he's hacking. But repeated solo runs don't cause trouble
<kdub> which test?
<kdub> alan_g,
<alan_g> kdub: MirSurfaceVisibilityEvent
 * kdub doesnt know much about that one
<alan_g> kdub: knows even less about my changes to it
<alan_g> alf: I'm trying to track down a race condition. What I need is a sync point where the DisplayBufferCompositor objects have been created - is it safe to add a barrier in MultiThreadedCompositor::start() so that it only returns once the compositing threads have completed initialization?
<alf> alan_g: It should be safe
<alf> alan_g: I guess it depends on what point you consider the compositing threads to have completed initialization
<alan_g> after the call to report->added_display()
<alf> alan_g: well, assuming that the code in the compositing thread until that point doesn't interact with the compositor in ways that can cause a deadlock, which is a perfectly reasonable expectation, it should be OK.
 * alan_g is trying it
<alf> alan_g: However, it is an added risk, since we can't control what other implementations of the involved will do.
<alf> alan_g: Plus the point is arbitrary, e.g., why not after scene->register_compositor ?
<alf> alan_g: It depends on what guarantee we want to provide for Compositor::start()
<alan_g> alf: actually that's probably better
 * alan_g breaks mir_unit_tests.MultiThreadedCompositor.*
 * alan_g hates MultiThreadedCompositor anyway
<alan_g> The test that is
<kdub> yeah,it runs too long
<alan_g> And that is because it relies on real time rather than synchronization
<alan_g> Hence it is broken
<alan_g> I could "fix" my race condition like that too.
 * alan_g is no longer sure he broke anything with his changes
<dandrader> are there -dbg packages for mir?
 * dandrader reads https://wiki.ubuntu.com/DebuggingProgramCrash#Debug_Symbol_Packages
<racarr> dandrader: Hi no rush (e.g. next week is fine)
<racarr> but would appreciate your feedback on https://code.launchpad.net/~mir-team/mir/introduce-mir-event-2.0/+merge/242443
<racarr> dandrader: I don't know if you've seen notes doc outlining the direction too?
<dandrader> racarr, no, I haven't
<dandrader> racarr, will take a look at this MP next week. nearing my EOD now
<racarr> dandrader: :) Happy weekend
<racarr> I will CC you the email with the notes so you have it
<dandrader> racarr, thanks :)
<dandrader> same to you
#ubuntu-mir 2015-11-16
<Mirv> RAOF: were you pinged already to copy mir 0.17.1 to xenial-proposed from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial ? (where it mistakenly was landed)
<Mirv> needs a core-dev, and copy-package from lp:ubuntu-archive-tools
<Mirv> that would be: ./copy-package --from=~ci-train-ppa-service/ubuntu/stable-phone-overlay --from-suite=xenial --to=ubuntu --to-suite=xenial-proposed -b mir
<RAOF> Mirv: Done. We build a lot of packages!
<Mirv> RAOF: thanks! yes I also noticed quite of lot of binaries for 6 archs :)
<alan_g> kdub: you've been looking at this area of code more than me - does the error message "<ERROR> MirBufferStream: Error processing incoming buffer error registering graphics buffer for client use" suggest a likely cause? https://bugs.launchpad.net/mir/+bug/1516670
<ubot5`> Ubuntu bug 1516670 in Mir "Nesting Mir servers with assorted display configs causes lockup" [Undecided,New]
<kdub> alan_g, it means that the client is having trouble mapping the buffer the first time its seen it, but other than that, unsure why that combo of branches would make more problems
<alan_g> The branches actually make fewer problems. But that means it runs long enough to see new ones. :(
<alan_g> I think something racy is happening with the rebuilding of display configs, nested "display buffers" etc. Just not figured out what yet.
<alan_g> kdub: don't worry about it - just hoped you'd have a good suggestion.
<alan_g> kdub: not urgent, but checking you noticed there's a special request for your input on this: https://code.launchpad.net/~alan-griffiths/mir/fix-1463873/+merge/277552
<kdub> alan_g, sure will try to look today
<alan_g> thanks
<kdub> why don't the client modules link to libmirplatform?
<kdub> I'm mostly just curious if this is actively-willed/designed or not
<kdub> ^vogons
<anpok> kdub: I believe just a lack of need? libmirplatform is mostly utilities for graphics server platforms that need to be lgpl..
<kdub> anpok, thanks... i think I've found a need, so we'll see what people say in review I guess
#ubuntu-mir 2015-11-17
<anpok_> alan_g: https://code.launchpad.net/~andreas-pokorny/mir/load-all-supported-input-platforms/+merge/274421/comments/702108 you mean the mouse cursor itself is not moving?
<alan_g> anpok_: right
<anpok_> with a touchpad or mose?.. do you have logs from the hosting server?
<alan_g> It's a lenovo - there's both a touchpad and a button in the keyboard. The latter is what works with the current input stack, but not with the MP
<alan_g> (It does move without the button presses)
<anpok_> alan_g: hm oh libinput might have defaulted to disable while typing
<anpok_> but that would be odd for modifier keys
<anpok_> i remember a change for that ..
<anpok_> whats your libinput version?
<alan_g> hold on, I have to grab the laptop...
<alan_g> libinput10
<anpok_> 0.10  was the last abi breaking release.. the source version should be higher
<anpok_> hm maybe I should finally make an MP that adds input configuration examplse and also one that makes disable while typing configureable
<alan_g> sorry, 0.21.0
<anpok_> thx will dig through logs
<alan_g> alf_: did you get a response from CI re mir-mediumtests-builder-vivid-armhf?
<alf_> alan_g: Yes, they fixed the infrastructure problem. The mir-mediumtests-runner-touch are now failing because of https://bugs.launchpad.net/mir/+bug/1515660 .
<ubot5> Ubuntu bug 1515660 in Mir "CI test failures in GLMark2Test" [High,New]
<alf_> alan_g: I'll take a look. I need a break from the Android stuff.
<alan_g> alf_: I thought it the same as I get 404 from https://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/4834/console and https://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/ ends on the 12th
<alf_> alan_g: That's yet another problem (something goes wrong when publishing the result to the public server), but it doesn't affect the job result. Logs are available in s-jenkins.
<alan_g> alf_: I can't access that since I have trouble with the VPN I've not been motivated to resolved.
<anpok_> hm this is also a vivid-clang problem .. "Failed to trigger thread shutdown"
<anpok_> *there
<anpok_> in several MPs during NestedServer acceptance tests
<anpok_>  NestedServer.display_configuration_reset_when_application_exits
<anpok_> the mako test runner failure is beause 0.17.1 landed
<anpok_> alf: we need to incorporate the changelog to lp:mir.. or even add an entry for 0.18.0
<alf_> anpok_: ack, will take a look
<anpok_> as a result of the newer version archive it only install some of the ci built packages..
<anpok_> odd
<anpok_> despite the complaints initially it does install the ci build
<alan_g> alf_: kdub - at the root of some of the display config problems is the way that nested::Display manages overlapping (in my case cloned) outputs. It makes a surface supposedly the size of the bounding rectangle but also fullscreen on the first output in the overlap group: the server resizes the surface and things get "inconsistent". Is it better to have fullscreen surfaces for all active outputs? Or not have it fullscre
<alan_g> en?
<greyback_> alan_g: I see no reason why a nested server would want a non-fullscreen surface
<alan_g> greyback_: in this case it wants one that covers all the overlapping outputs. Suppose your outputs are {{0, 0}, {100, 700}} and  {{0, 0}, {700, 100}} then the current logic wants  {{0, 0}, {700, 700}}
<greyback_> alan_g: ah, cloned mode
<anpok_> that may cause weird behavior for input too..
<greyback_> if you're cloning the nested server's surface on each display, why would arrange things so it is partly occluded? i.e. is too big for each display
<greyback_> either we choose size which is intersection of the display geometries, else we start scaling to fit
<alan_g> greyback_: ...or we pick "the biggest" monitor and window the others.
<alan_g> there are lots of options. But the current choice is broken.
<greyback_> desktop currently chooses the intersection of the display geometries, which is most reliable choice I guess
<alan_g> that also makes sense.
<alf_> alan_g: greyback_: The single surface for overlapping is an optimization that's, in theory at least, worth having, but it's not necessary. Are there any downsides to option 2, not making the surface fullscreen?
<alf_> greyback_: so for 0,0,100x700 0,0,700x100 it would show a 0,0,100x100 surface on both screens?
<alan_g> Currently, the system-compositor WM rejects non-fullscreen surfaces
<kdub> kgunn, I didn't see the mir packages installed from the silo...
<alan_g> So that affects USC
<kgunn> kdub: you have to pin the ppa
<kdub> ah, right
<kgunn> /etc/apt/preferences.d/extra-ppa.pref
<kgunn> just copy that entry
<kgunn> and modify one to be "landing-020"
<kdub> ack
<kgunn> kdub: so how did you get that thing to build without gles there ?
<kdub> I don't know how silos work :) :/
<kgunn> i was reading up on that....twins...and i guess it's always suppose to fail
<kgunn> :)
<alf_> alan_g: on the other hand, the single surface may interfere with overlay optimizations on the host server...
<kgunn> kdub: i'm trying to get qtmir force merged around the xenial mess
<kgunn> so we can add that back and rebuild more easily
<alan_g> alf_: yes, I'm not sure how to evaluate the trade-offs
<alf_> alan_g: We would need to measure unity8 FPS with the two approaches. For now I would say if (1) (one fullscreen surface per output) is simpler overall, go for that and we can revisit.
<alf_> alan_g: greyback_: What are our main clone mode scenarios (for phone)?
<anpok_> alf_, alan_g: would those two surface be overlapping on usc too?
<greyback_> alf_: none in my opinion
<greyback_> clone mode only makes sense for very limited situations - usually mirroring desktop onto projector for presentation
<anpok_> alf_, alan_g: or would usc always be neutral and.. assume them to be side by side?
<alf_> greyback_: then I guess the optimization isn't important anyway, so let's go for the simpler solution
<alf_> alan_g: ^^
<alan_g> anpok_: they are also overlapped in USC
<alf_> anpok_: hmm, actually that's a good point
<alan_g> alf_: ack. I just need to test that compositing isn't confused by overlapping display buffers.
<anpok_> alan_g, alf_: thinking about the cursor..
<anpok_> and enter exit events that we can probably filter out..
<kdub> kgunn, alright, so i'm seeing what you're seeing, so I guess we had 2 corruption issues
<kdub> because the demo_client_flicker one sure was a problem
<kdub> where's our xmir source?
<kgunn> kdub: one sec...lemme dig
<kgunn> kdub: https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir
<kdub> kgunn, thanks, let me see if there's anything in there that stands out
<tsdgeos> hi guys, i'm getting the "Failed to wait for event" exception of dispatch_loop in threaded_dispatcher.cpp
<tsdgeos> when starting unity8 in my laptop
<tsdgeos> any idea of what may be the culprit?
<alan_g> anpok_: did you need me to do anything on laptop? (yet?)
<anpok_> you would have to run evemu-describe and evemu-record as root
<anpok_> but but for all involved devices
<anpok_> so touchpad and touchpad button ... if those are exposed as separate
<dandrader> anpok_, are we tracking the lacking of mouse acceleration on the relative mouse axes in some bug already?
<dandrader> anpok_, if so this bug could be make a duplicate: https://bugs.launchpad.net/mir/+bug/1517133
<ubot5> Ubuntu bug 1517133 in unity8 (Ubuntu) "mouse speed is much lower than elsewhere (to the point of useless)" [Undecided,New]
<dandrader> s/make/made
#ubuntu-mir 2015-11-18
<Laney> hi, wondering if anyone is looking at mir blocked in xenial-proposed?
<Laney> (liburcu hangs on ppc64el)
<alan_g> Laney: I'm not aware of it. But I don't see how Mir can impact liburcu?
<Laney> it's one of Mir's dependencies
<seb128> alan_g, it doesn't impact it directly, it's the other way around
<seb128> MIR is blocked because one of the libs it's using needs to be fixed
<alan_g> seb128: ah, at least that makes sense.
<alan_g> So landing wouldn't break anything that isn't already broken?
<seb128> that's not how it works
<seb128> that library got an update
<seb128> and the new mir built/got linked to that new version
<seb128> so landing the mir update means landing the library update with it
<seb128> so if the lib has a regression mir might have a regression as well
<seb128> even if it's not mir's fault
<seb128> or said differently the library you are using needs to be cleared out or it's going to block mir
<Laney> And blocking mir means it blocks anything that depends on mir (in this case GTK)
<alan_g> alf_: is it AlbertA trying to release Mir to xenial?
<alan_g> seb128: I've no idea how to "clear out liburcu" - is this urgent? Or can it wait for the USA to wake up?
<seb128> alan_g, it can wait for them to wake up
<seb128> alan_g, the issue with liburcu is that the build/tests hang on ppc64el
<seb128> so somebody needs to debug why
<seb128> (likely an upstream issue, it's also happening in Debian)
<alf_> alan_g: Yes, 0.17.1
<alan_g> seb128: can't we just use the old version?
<alf_> seb128: problem with ppc64el is that we have no reasonable way to replicate the problems locally
<alan_g> Who can debug ppc64el?
<seb128> alan_g, we would need to delete the update and rebuild mir
<seb128> but that's not really constructive, we are going to need to update that lib one day
<seb128> so better to fix the issue and move forward
<alan_g> seb128: the first problem is the lack of any ppc64el kit on which to investigate.
<seb128> Laney guessed that would be an issue :-/
<Laney> there's the bos01 cloud
<Laney> I would hope that it's possible to get access there
<Laney> although... I just tested on an instance there (abusing my access through autopkgtest) and it actually built :(
<Laney> one second
<Laney> https://bugs.launchpad.net/ubuntu/+source/liburcu/+bug/1511458
<ubot5> Ubuntu bug 1511458 in linux (Ubuntu Vivid) "liburcu fails to build on ppc64el" [High,Confirmed]
<Laney> seems it might be a cloud/kernel bug
 * Laney asked
<pandatrone> what happened to mir?last update is 2015-11-13
<pandatrone> 5 days ago
<alan_g> pandatrone: MP landings have been backing up because of trouble in CI. Hoping that is now resolved.
<pandatrone> alan_g, phew :D thanks!
<alan_g> were you waiting on something?
<pandatrone> alan_g, nope. i just like to read the new mir updates :D
 * alan_g resolves to write interesting commit comments.
<pandatrone> :))
<anpok_> alan_g: evemu-record worked for me when I dont send it to background
<anpok_> but it just terminates otherwise
<alan_g> OK, you need both devices at the same time?
<anpok_> alan_g: hm I think so yes..
<anpok_> but there is also a slight chance that this will be fixed by: https://code.launchpad.net/~andreas-pokorny/mir/use-one-cursor-position-per-seat/+merge/277843
<anpok_> but I cannot remember the details
<tsdgeos> guys, i need this https://code.launchpad.net/~aacid/mir/eintr_dispatch_loop/+merge/277847 otherwise my unity8 aborts, can anyone with more knowledge of the code have a look and decide if it makes any sense?
<alan_g> anpok_: sent. I'll try your branch later
<alan_g> tsdgeos: looks weird to me too. I think RAOF wrote most of that code
<alan_g> Laney: is the problem with liburcu still needing help from Mir?
<anpok_> alan_g: hm ok but you are pressing alt while moving the trackpoint?
<alan_g> yes
<Laney> alan_g: not right now, hopefully lp will fix it
<Laney> https://portal.admin.canonical.com/85976 for those who can see that
<alan_g> anpok_: which set of your branches should I merge to test laptop?
<alan_g> anpok_: reapplied lp:~andreas-pokorny/mir/load-all-supported-input-platforms and lp:~andreas-pokorny/mir/use-one-cursor-position-per-seat - I still have a problem. The trackpoint controls the cursor unless the middle button is pressed. Alt+left button drags the triangle, Alt on its own or Alt+right just move the cursor. Just pressing the middle button (with or without Alt) and the cursor only responds to the touchpad (
<alan_g> but that has never worked with the "mouse" buttons).
<anpok_> oh
<anpok_> we do not unify the mouse buttons
<anpok_> for the input stack the trackpoint and the mouse buttons belong to one device and the touchpad is separate..
<anpok_> that means touchpad movement + trackpoint buttons are two separate streams of events hence.. if someone checks for button state on motion events all will be released..
<anpok_> but thats simple to combine .. just like we did with modifier..
<alan_g> I just don't want to break something that is already working (trackpoint+middle button)
<alan_g> I thought it might be diagnostic that the left and right buttons do work
<anpok_> hmm yes that is strange
<alan_g> is something misidentifying it as a *two* button mouse?
<anpok_> oh I have to make sure the server sees the first events too otherwise it will miss the middle button down press
<anpok_> yes I can reproduce .. it has nothing to do with any of my theories.
<alan_g> anpok_: reproduction is the first step towards diagnosis
<anpok_> hum.. and I believe we dont want to have a separate button state between pointing devices
#ubuntu-mir 2015-11-19
<pandatrone> hello Mir people
<pandatrone> i get 10-50% more FPS with glmark2 on OTA8 compared to OTA5
<pandatrone> on mx4
<pandatrone> good job
<alan_g> alf_: thanks for picking up the NestedServer test issue
<alf_> alan_g: np
<dandrader> alan_g, need your input https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1517615
<ubot5> Ubuntu bug 1517615 in lightdm (Ubuntu Vivid) "Need to disable "--enable-hardware-cursor=true" option in unity-system-compositor" [Undecided,Confirmed]
<alan_g> dandrader: looking...
<dandrader> alan_g, this solve https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1515921 for ChrisTownsend
<ubot5> Ubuntu bug 1517615 in lightdm (Ubuntu Vivid) "duplicate for #1515921 Need to disable "--enable-hardware-cursor=true" option in unity-system-compositor" [Undecided,Confirmed]
<dandrader> s/solve/solved
<ChrisTownsend> dandrader: After chatting w/ bregma about that, the "--enable-hardware-cursor" option was added back in the day as a hack to get a cursor in the Unity 8 desktop session until Unity 8 provided its own cursor.
<ChrisTownsend> dandrader: Since Unity 8 now provides its own cursor, I think the option can be safely removed.
<alan_g> dandrader: I think enable-hardware-cursor is a USC specific "feature"
<dandrader> ChrisTownsend, I commented on the bug with my understanding on the issue
<dandrader> alan_g, ah, so it's not about a switch for using a hardware cursor instead of a software one?
<alan_g>             // This is a workaround for u8 desktop preview in 14.04 for the lack of client cursor API.
<alan_g>             // We need to disable the cursor for XMir but leave it on for the desktop preview.
<alan_g>             // Luckily as it stands they run inside seperate instances of USC. ~racarr
<alan_g> dandrader: no, it enables a USC specific cursor
<dandrader> alan_g, ah, ok. great. then I think we can remove not only the parameter from the lightdm call but also its implementation in usc
<alan_g> Hmm. actually reading the code more carefully it is an option to enable the Mir cursor that defaults to disabling the cursor.
<alan_g> dandrader: ^ - so removing the parameter is likely best.
<dandrader> alan_g, ok
<bregma> really, I'd leave it in u-s-c for now, because we may want that when prototyping kiosk applications, but remove it as default in lightdm (and make it a config option there)
<alan_g> alf_: any progress on lp:1517781?
<alf_> alan_g: Yes, but I need to perform some more testing to ensure the fix doesn't have any side effects
<alan_g> Excellent!
<popey> bschaefer, do you know what causes the issue on nexus 4 where sdl2 apps show two copies of the screen side-by-side?
<bschaefer> popey, yup!
<popey> is it an SDL/Mir issue or something which can be fixed in the game?
<popey> good!
<bschaefer> SDL issue
<popey> awesome.
<bschaefer> popey, fix is here: https://code.launchpad.net/~brandontschaefer/+junk/SDL2-new-mir-ABI
<bschaefer> as well as the touch screen issue
<popey> ooooh
<popey> which issue is that?
<bschaefer> touch wouldnt work :)
<popey> hah
<popey> okay, good one to fix :)
<bschaefer> because i made.... up = down and down = up
<bschaefer> yeah
<popey> lulz
<popey> I'll build that and have a play, thanks!
<popey> it's fun playing doom on an e4.5 :)
<popey> http://people.canonical.com/~alan/screenshots/device-2015-11-19-184911.png
<popey> :)
<bschaefer> haha awesome!
<popey> bschaefer, out of interest what do you build armhf things on locally?
<popey> I'm building on a nexus 7, but feel I could probably benefit from maybe using a chromebook with more storage (and a screen and keyboard)
<bschaefer> popey, on my N4
<bschaefer> or cross build
<bschaefer> from pbuilder
<bschaefer> pbuilder-dist vivid armhf build *.dsc
<bschaefer> popey, that could work as well
<popey> good point
 * bschaefer always finds arm slow to compile no matter the device :)
<bschaefer> have to wait for the compiler to catch up
<popey> I keep running out of space
<popey> so thinking of a cheapo acer chromebook
<bschaefer> popey, yeah thats my issue on N4
<bschaefer> soo i just use the pbuilder-dist for now... copy over debs
<bschaefer> and install thought it sucks when you need to debug
<bschaefer> when i need to debug i've to build on a device
<popey> hmm bschaefer it's failing to build here - http://paste.ubuntu.com/13351541/
<bschaefer> popey, its not building mir :), hmm strange what version of mir do you have?
<popey> bschaefer, which package should I look for version of?
<bschaefer> mirclient-dev
<popey>   Installed: 0.17.1+15.04.20151105.1-0ubuntu1
<bschaefer> hmm that should be fine...
<bschaefer> popey, try --enable-video-mir
<bschaefer> but it should be default...
<popey> ok
<popey> Time passes... :)
<mcphail> bschaefer: you can det up a symbol server and use that for remote debugging
<mcphail> bschaefer: saves building on the device
<bschaefer> nice ill have to look into that
<mcphail> bschaefer: there's a good youtube vid from one of the valve developer conferences which explains it better than I could
<bschaefer> o nice ill have to take a look
<mcphail> https://www.youtube.com/watch?v=xTmAknUbpB0 - about half way through that one
<popey> bah, build failed again
<bschaefer> :(
<popey> http://paste.ubuntu.com/13351832/
<bschaefer> says mire support = no
<bschaefer> mir*
<bschaefer> popey, do you have libxkbcommon-dev?
<popey> yes, 0.4.3-2
<bschaefer> popey, you can ... try to manually edit the configure.in
<bschaefer> under CheckMir
<bschaefer> to force it to be enabled... as that doesnt make much sense... something is wrong
<bschaefer> you also have libegl1-mesa-dev?
<popey> i do
<bschaefer> :::(
<bschaefer> its only been a week since i've tried this on vivid + overlay
<bschaefer> and it worked...
<popey> :(
 * popey dist-upgrades
<popey> dunno how old this tablet has got
<popey> probably new crack since I last updated
<bschaefer> well ... you said mir was 0.17
<bschaefer> which is more then enough
<bschaefer> (i just changed to 0.14/0.15)
 * bschaefer checks again
<popey> :(
<mcphail> popey: can't you just cross-compile in a chroot?
<popey> probably could, yeah
<popey> will do if I can't get this working
<popey> don't understand what's going wrong
<bschaefer> checking for Mir support... yes
<bschaefer>   Installed: 0.17.0+15.10.20151008.2+r3103~daily1~ubuntu16.04.1
<bschaefer> hmm you have a newer version
 * bschaefer upgrades
<mcphail> popey: isn't it just looking for X and not finding it?
<mcphail> (which would be expected)
<popey> hmm
 * mcphail doesn't recommend debuild for this kind of thing
<mcphail> popey: the failure is on line 587
<bschaefer> huh ... im still at 0.17.0
<bschaefer> you can try (and it should be there?) --disable-video-x11
<bschaefer> but it builds it
<bschaefer> mcphail, theres the other issue of mir not building though
<mcphail> bschaefer: probably just pkg-config looking in the wrong place
<popey> we need an armhf ppa for your bleeding edge sdl :)
<bschaefer> haha... well you have a better version of mir then i do (still waiting on 0.17.1 to actually fix the color format issue
<bschaefer> popey, o wait... that clone issue *isnt* fixed in that branch
<mcphail> bschaefer: what's the link to your repo again? I'll try building in a chroot
<bschaefer> since im waiting for 0.17.1 :)
<popey> ooh!
<popey> good!
 * popey ctrl-cs the build
<bschaefer> (need to ask egl the pixel format is the issue)
<mcphail> ha!
<bschaefer> vs picking a supported one
<popey> I don't want to push my silly dosbox click to the store with this problem
<bschaefer> yeah
<popey> will get angry mail from nexus 4 owners :)
<bschaefer> i can imagine, unless they like that sort of thing
<bschaefer> (though input would be all wonky)
<mcphail> popey: tell them it is virtual reality
<popey> hah, need to buy a proprietary lens and cardboard from me
<popey> it's a shame we can't detect device in the store, and say "No to you!" for people with duff devices
<popey> bschaefer, is there no workaround for this?
<popey> in the app
<popey> neverball had this issue, and I think they worked around it in the app..
<bschaefer> popey, whats a duff device?
<popey> nexus 4, nexus 7
<popey> (devices where it doesn't render correctly)
<bschaefer> but as far as sdl2 cares ... its just weather its supports the rendering library or not
<bschaefer> hell, armhf thinks glx works because the headers exist :)
<bschaefer> soo theres nothing to fancy for checking rendering atm
<bschaefer> sdl2 armhf* thinks glx works because opengl installs those headers
<popey> wonder if I can tell dosbox to request some other mode from sdl
<popey> is there some other mode I could use maybe
<popey> lower colour depth maybe
 * popey is clutching at straws now
<popey> https://github.com/pseuudonym404/neverball-touch/commit/1f50b5f20d4eaa0d024379ca2363a4f2bae2f631 that's what the neverball person did
<mcphail> try it
 * popey rebuilds dosbox
<popey> didn't fix it :(
<bschaefer> popey, only way is to recompile with
<bschaefer> umm
<bschaefer> SDL_mirwindow.c:111:    surfaceparm.pixel_format = FindValidPixelFormat(mir_data);
<bschaefer> to
<bschaefer> SDL_mirwindow.c:111:    surfaceparm.pixel_format = mir_pixel_format_rgb_565;
<bschaefer> popey, but this will cause issues on other devices (maybae?)
<popey> hmmm
 * popey looks for a cheeky ppa to build it in
<bschaefer> ppas dont usually build for armf :(
<bschaefer> armhf*
<popey> I have one that does, on bare metal
<bschaefer> o nice
<popey> https://launchpad.net/~canonical-community/+archive/ubuntu/ppa/+build/8320572
<popey> lets see
<mcphail> bschaefer: any chance you can persuade them to release sdl2.0.4 soon? We've been on 2.0.3 for ages and we're never going to get the mir fixes in the repos if we don't get a new version
<popey> them being Sam?
<mcphail> Is it all down to Sam?
<mcphail> Looking at some of the 2.0.4 grubles on mailing lists I thought it was more complex than just going through Sam
<bschaefer> IIRC deb is still on 2.0.2
<bschaefer> mcphail, and i cant push upstream until the LTS is released
<bschaefer> since upstream follows the LTS
<mcphail> bschaefer: aah. OK
<popey> mcphail, worth taking a snapshot of 2.0.4 and putting in this ppa for fun and lulz?
<bschaefer> the plan is to get all the fixes merged into archive
<bschaefer> from a ubuntu patch
<bschaefer> but need to wait for 0.17.1 ...
<mcphail> popey: my old sdl build was a "2.0.4" snapshot, but, of course, won't have bschaefer's fixes
<popey> right
<mcphail> bschaefer: presumably that isn't in OTA8?
<bschaefer> OTA8?
<popey> whats on the phone today
<mcphail> bschaefer: current release on the phone
<bschaefer> yeah its not
<bschaefer> trying to get the patch done but got side tracked on something i have to finish for mir
<bschaefer> before 0.18 :)
<mcphail> :)
<popey> hm, failed to build in the same way
<popey> https://launchpadlibrarian.net/227045641/buildlog_ubuntu-vivid-armhf.libsdl2_2.0.3~ppa1~vivid1_BUILDING.txt.gz
<popey> bah
 * popey gives up for tonight
<popey> mcphail, is it worth (for fun) taking your 2.0.4 snapshot and integrating bschaefer's patches?
<popey> or not worth it until 0.17.1 of mir?
<bschaefer> it doesnt have any video drivers :(
<bschaefer> not sure what causing the failure at the end, but even if it worked, nothing would work :)
<mcphail> popey: don't hink it is worth it, tbh. I'm sure bschaefer's branch will be better in every way
<popey> yeah
<popey> I'll just play with stuff on my bq for now and not upload anything till it's working
<mcphail> Shame
<popey> appreciate the help chaps, this is one of the more fun parts of hacking
<bschaefer> haha
 * bschaefer enjoys the programming bits more
<mcphail> A device isn't viable until it has run doom
<bschaefer> haha
#ubuntu-mir 2015-11-20
<alan_g> Hmm. Mako started reporting spurious "plug/unplug" of external display making me think my changes broke something. But reverting didn't fix. So I powered off. Now it says it hasn't enough juice to start up again. I hate hardware!
<alan_g> and now it reports a full charge!
<dandrader> AlbertA, where do the server gets the size hints (min max size, size increment) set by the client in that MirSurfaceSpec?
<dandrader> AlbertA, found it. it's in include/server/mir/shell/window_manager.h
<AlbertA> dandrader: right it should be in the SurfaceCreationParameters if creating surface or in SurfaceSpecification if modifying one
#ubuntu-mir 2016-11-23
<duflu> RAOF: Can you help me out with a review here? https://code.launchpad.net/~vanvugt/mir/fix-1642504/+merge/311363
<duflu> It's rather annoying not having a working server
<tjaalton> hi, I'm thinking of proposing unrenamed mesa backports to lts (essentially upgrades the old one to new major release), but thought I should probably ask here too for your thoughts
 * duflu doesn't understand at first
<tjaalton> mesa on xenial would bump from 11.2.0 to 12.0.x
<tjaalton> what's on yak
<tjaalton> lts-hwe stacks have had mesa-lts-foo
<tjaalton> which leaves the original one as is
<duflu> tjaalton: There's an implied (not strongly enforced) ABI between egl-platform-mir in Mesa and libmirclient. I don't think that has broken in a long time(?) so it could be safe
<tjaalton> yeah that's one thing I've considered
<duflu> might be safe
<duflu> tjaalton: It would still live in 'backports' right? Not used by default xenial
<tjaalton> no, it would be in updates
<duflu> My only objection then is that it's poor discipline to do a major upgrade in updates. But if it's X and we really need it to keep building a product on then... *shrug*
<tjaalton> renamed mesa is a hassle
<tjaalton> then again having just one lts-hwe stack makes it a bit easier, so that I might just drop this plan
<duflu> True.. You might want to ask other timezones still -> mir-devel@lists.ubuntu.com
<tjaalton> right
#ubuntu-mir 2016-11-24
<hikiko> hey
<hikiko> question :)
<hikiko> I'm trying to build mir from source
<hikiko> and although I have libcapnp and dev installed, I get this error:
<hikiko> http://pastebin.com/DedN5xKc
<hikiko> ignore, just found the package missing
<seb128> hikiko, you might want to apt-get build-dep mir
<hikiko> I did so seb128
<hikiko> there were some extra dependencies
<seb128> cool
<hikiko> that was cpnproto for the record
<seb128> yeah, if new requirements were added between the archive version and what you builds...
<seb128> k
<hikiko> I just receive new errors now during make for gmock
<hikiko> http://pastebin.com/73LyaAjM this is the output
<hikiko> well I disabled the tests for the moment
<seb128> hikiko, is that on zesty?
<seb128> there are some issues with googletest/cmake-extras there it seems
<hikiko> yes
<seb128> that was discussed a bit on #ubuntu-devel yesterday, kenvandine and attente hit build issues as well
<hikiko> I see
<hikiko> well, the problem is gone if I don't build the tests
<hikiko> seb128, which one of the mir*
<hikiko> in bin/
<hikiko> should I run
<hikiko> to have the server running?
<seb128> no idea, that's a question for the mir people here ;-)
<hikiko> question to all: is still mir_demo_server the right executable to have mir up and running?
<hikiko> or any of the other mir* will start the server automatically?
<greyback> hikiko: only mir_demo_server* will bring up the Mir server, the other binaries are clients for that server
<hikiko> greyback, there's an error that I'm missing libmir_demo_server_loadable.so
<hikiko> there's no such .so in lib/
<hikiko> so I guess I didn't build it
<hikiko> correctly
<greyback> hikiko: that file is in mir-demos, and should be located: /usr/lib/x86_64-linux-gnu/libmir_demo_server_loadable.so
<hikiko> missing
<hikiko> so I have to install mir system wide too
<alan_g> hikiko: you should be able to run in the build tree
<hikiko> hi alan_g
<alan_g> the so should be in lib
<hikiko> alan_g, you mean the lib where I built mir right?
<alan_g> Right. But... what do you want a mir server for? The demos in Mir are rather limited
<hikiko> alan_g, I want to change the chromium backend to use mir
<hikiko> shouldn't I build mir-server?
<alan_g> You could just install miral-examples and run miral-server?
<hikiko> I don't know :) last time I used mir we didn't have that yet :)
<hikiko> is there any documentation for miral-server alan_g ?
<hikiko> basically I need these 2 things:
<hikiko> 1- find the documentation or the source of the mir api
<hikiko> 2- find a way to run mir to test chrome
<hikiko> what is the miral-server?
<alan_g> 1. Sadly out of date online, but you can build & show the mir docs: "make doc-show"
<alan_g> 2. http://voices.canonical.com/alan.griffiths/2016/08/18/miral-mir-is-not-all-about-unity8/
<hikiko> thank you alan_g :)
<alan_g> (If you install miral-examples you can inore building it and the "bin/" part of commands
<hikiko> I only need to start miral-shell?
<hikiko> works!!!!!
<hikiko> fantastic :D
<hikiko> and how do I exit it? kill?
<alan_g> Ctrl-Alt-BkSp
<alan_g> Or the "x" in the corner
<alan_g> (kill works too)
<hikiko> no kill is not a good idea
<hikiko> I have to reset afterwards :)
<hikiko> (I mean reset the term attributes)
<hikiko> anyway :) thanks a lot alan_g :)
<alan_g> That's odd! You just ran as "$ miral-shell"?
 * alan_g wonders why that changed any term attributes
#ubuntu-mir 2016-11-25
<anpok_> alan_g: I think we want people to run miral-shell
<anpok_> when they try clients..
<anpok_> or unity8 directly
<anpok_> so in some way mir demo servers give the wrong impression right now..
<alan_g> agreed
<anpok_> which does not make the documentation wrong..
<anpok_> just thinking that we should have a disclaimer there ..
<alan_g> I was planning to blog about it
<alan_g> Which documentation?
<anpok_> the intro documentation.. http://unity.ubuntu.com/mir-docs/0.25/using_mir_on_pc.html .. and http://unity.ubuntu.com/mir-docs/0.25/building_source_for_pc.html
<alan_g> Sure, that could do with a refresh. Like you say the docs reflect what's in the lp:mir project, not what we've done that is useful
<anpok_> yes
<alan_g> So there are two cases:
<alan_g> 1. testing client toolkits etc. against Mir servers - "just install miral-examples and use miral-shell"
<alan_g> 2. writing servers - "use libmiral-dev"
<anpok_> yes
<alan_g> We should add a couple of paragraphs to those docs, check where the 0.25 release is at, and (maybe) "cherrypick".
<alan_g> You want to write them? Or should I add to my list?
<anpok_> alan_g: I can do that.. do we generate miral docs somewhere?
<alan_g> not currently - it hasn't felt worth the effort of setting up automation for miral as we plan to roll it into lp:mir at some point.
<alan_g> Once the Unity8 integration has settled down we won't need to release it so often and can progress that.
<alan_g> Meantime, I guess http://voices.canonical.com/alan.griffiths/category/miral/ is the least bad option.
<alan_g> anpok_: the blog post I mentioned: http://voices.canonical.com/alan.griffiths/2016/11/25/testing-for-mir/
#ubuntu-mir 2017-11-20
<RAOF> Dear C++: I could really do with compile-time-reflection right now...
#ubuntu-mir 2017-11-21
<alan_g> RAOF: in the hangout you indicated you'd approved this, but you are still "requesting changes": https://github.com/MirServer/mir/pull/36
#ubuntu-mir 2017-11-23
<RAOF> alan_g: Mir KMS tests fail on 18.04 because drmModeAddFB2 had changed its signature.
<RAOF> (and others, but that's what's causing the initial crashes)
<RAOF> Added const to the array parameters.
<RAOF> In case Saviq asks ð
<Saviq> ohkay and why did bors merge it when I did bors r- Â¿?
<alan_g> I don't know. But then I'm new to bors.
<Saviq> RAOF: if you're not thanksgiving, I'd give thanks for https://github.com/MirServer/mir/pull/48 ;)
<RAOF> Just got the email notification :)
<Saviq> RAOF: also, any idea why this got merged even after I "bors r-"'d it?
<RAOF> No, I don't.
<RAOF> I'll have a look.
<Saviq> RAOF: UGH, seems I got tricked by git again, the rev-parse thing has the same problem of not looking at the remote, only at what's fetched
<RAOF> Hah.
 * Saviq feels we should use my dumbcounter until we can use `git describe` :P
<RAOF> Will `git describe` have the same problem?
<Saviq> I think it might if the closest tag is far enough in the history
 * RAOF again curses git for not having a revno.
<Saviq> î° git describe --tags
<Saviq> fatal: No names found, cannot describe anything.
<Saviq> î° git fetch --deepen 100
<Saviq> î° git describe --tags
<Saviq> v0.27.0-641-g766a4f39d
<Saviq> so one thing we could do here is `git fetch deepen 100` until we get a description out of `git describe`
<RAOF> Or we could just fetch the whole history.
<RAOF> It's not that big.
<Saviq> 160MB
<Saviq> .5s to fetch --depth=50 (what travis does) vs. 16s for a full clone
<Saviq> I'd be happier to fetch back 100 at a time until we get `git describe` to work
<Saviq> again, if git tags are what we want to use for this...
<RAOF> Our test suite takes at least 600s. Is saving 16s for not doing a full clone worth it? :)
<Saviq> RAOF: maybe, maybe not ;)
<Saviq> ok for now I'll just go --unshallow
<Saviq> so we can fix this
<RAOF> Yeah.
<RAOF> Launchpad doesn't (yet) allow us to webook successful PPA builds into a GitHub status, right?
<Saviq> RAOF: it can do autopkgtests
<Saviq> where from/how, I'm not sure
<RAOF> Because that would be a good thing to gate bors onâ¦
<RAOF> It would avoid the Travis timeout.
<Saviq> agreed
<Saviq> depending on what the autopkgtests hook does (I can't see results on snapd's PRs any more)
<Saviq> any case, we'd need to create ephemeral PPAs per PR for this to make sense (but yeah, we should!)
<Saviq> ooh my first signed commit, /me likes the green :P
<RAOF> Why would we need ephemeral PPAs?
<RAOF> Oh, yeah.
<RAOF> Never mind :)
<Saviq> RAOF: yeah, that :)
<Saviq> RAOF: ok, https://github.com/MirServer/mir/pull/48/ should be good for real this time
<Saviq> oh and btw, we got the bot key in https://launchpad.net/~mir-team/+archive/ubuntu/dev/+packages
<Saviq> so after that lands we'll have staging populated
