#ubuntu-mir 2014-01-27
<anpok> hi
<anpok> according to lttng we need two scheduling steps after reading the input event before it reaches the client
<alan_g> FYA http://tgceec.tumblr.com/post/74534916370/results-of-the-grand-c-error-explosion-competition
<alan_g> anpok: I'm not sure what your observation means nor whether it is a problem
<anpok> i guess it means nothing,
<anpok> i simply observed asio doing the write and the completion handler in a different thread
<alan_g> greyback: the RPC stuff you needed is on development-branch. These tests should show how to hook it up - let me know if you need anything more. http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/tests/acceptance-tests/test_protobuf.cpp
<greyback> alan_g: cool, thank you
<alan_g> You're welcome
<alf_> kdub: question about hwc-layerlist-improvements, could oid mga::LayerList::set_fb_target() also set the fb_target_present property, or does it make sense for fb_target_present to be true even without a set fb target?
<kdub> alf_, fb_target_present is really 'whether to tack on a FB layer at the end' or not
<kdub> so it won't change
<alf_> kdub: does it make sense to have a layer without having called set_fb_target()?
<kdub> yes, for hwc 1.0, we have layers without fb targets
<alf_> kdub: I mean, does it make sens to have an fb_target_layer without an actual fb target set? What I am getting at is if we could remove the has_target_layer constructor argument and rely only on whether set_fb_target has been called, but I don't understand the details very well.
<kdub> alf_, i think thats a decent improvement, it at least eliminates the funny constructor argument
#ubuntu-mir 2014-01-28
<RAOF> In today's fun compiler-bug feature, clang-3.5 doesn't correctly destroy cross-thread capture-by-copy variables in lambdas!
<duflu> ping mlankhorst
<mlankhorst> pong
<RAOF>  Would you prefer Factory? :)
<anpok> good morning mir
<mlankhorst> also good morning
<mlankhorst> duflu: ?
<duflu> mlankhorst: I've found a situation where drmModePageFlip never completes. Is that allowed?
<mlankhorst> when, exactly?
<duflu> mlankhorst: Schedule page flip (but don't wait), put screen to sleep
<duflu> It might be coming on wakeup, but Mir crashes before then :P
<duflu> Hmm, it was a while ago. Let me retest
<mlankhorst> hm interesting, never checked that. :P
<mlankhorst> i guess it might depend on the driver
<duflu> mlankhorst: Yes, twas intel
<mlankhorst> did you write a testcase? I can make one probably
<mlankhorst> would need the arguments to drmModePageFlip though
<duflu> mlankhorst: I need to retest to refresh my memory. I got distracted since the ping
<mlankhorst> :/
<duflu> alf_: You did overlapping DisplayBuffer construction/destruction to minimize visual interruption on config changes, right?
<alf_> duflu: How do you mean overlapping?
<duflu> alf_: When we do config changes... the old DisplayBuffers still exist when the new ones are constructed. So for a while you have 2 DisplayBuffers pointing to each CRTC
<duflu> .. which is safe right now. But not for my future changes
<alf_> duflu: I don't remember exactly now, but I think I had a problem when deleting the existing display buffers first, but this was in the first steps so it may not be a problem still
<duflu> alf_: Yes deleting the old ones first solves my problem. But the "black screen pause" during config changes is much longer
 * mlankhorst pokes duflu again
<duflu> mlankhorst: Looking more like it might be a Mir bug. I won't bother you again till I'm more sure
<mlankhorst> okay
<mlankhorst> I thought as much :)
<duflu> alf_: Whether intentional or not, overlapping the new and old DisplayBuffers seems useful. It makes mode changes appear more instantaneous with much less black screen time.
<duflu> I will try to keep it that way
<duflu> Although it would be nice if mesa::Display was smarter and didn't reconstruct DisplayBuffers at all
<duflu> That would require more work
<duflu> Awesome. After all that I achieved a two-line fix today. But at least it's fixed
<Saviq> hey folks, do you have some machinery to generate the commit message for merging from devel to trunk?
<Saviq> as we're looking at lp:unity8/devel for the new release process :/
<alan_g> Saviq: duflu and kgunn are the guys to ask. I think kgunn had a script - but I'm not sure it's bug free.
<Saviq> alan_g, thanks ;)
 * alan_g lost interest the Nth time the process changed
<alan_g> anpok: alf_ any opinions on how to implement parse_name() in https://code.launchpad.net/~alan-griffiths/mir/some-tidy-up-of-config-options/+merge/203384?
<anpok> hm
<anpok> {name.begin(), name.find_first_of(',')}
<anpok> but then name or begin as it is called now, needs to be a string
<alan_g> yes
<anpok> first time I saw strcspn
<alan_g> That's why I'm unconvinced it is clearer
<anpok> so even with two methods and the short puzzler of substr kdbus proposal is faster to read
<anpok> for the average mir code digester
 * alan_g had to look up what substr(0, std::string::npos) does - the string functions are a minefield of strange indexing rules
<alan_g> But if everyone else thinks it clearer I guess we'll do it hte consensus way
<anpok> hm i am not everyone :)
<alan_g> Well put your opinion in a review and I'll tally the votes
<alf_> alan_g: Setting a new function for mir_connect_impl for a test will affect all tests that follow too, right?
<alan_g> alf_: I seem to remember some mechanism to reset it. (But not any detail)
<alf_> alan_g: ok, thanks, I will take a deeper look
<ricmm> do you guys know
<ricmm> if there is some kind of timeout
<ricmm> for session authorization?
<kgunn> alan_g: ^ ricmm 's query
<alan_g> not in Mir
<alan_g> ricmm: ^
<ricmm> ok
<ricmm> thanks
<kdub_> do we have a place for code shared between the tests and the examples?
#ubuntu-mir 2014-01-29
<RAOF> duflu: Really? Generalise the X11 support so we can support all the other legacy display servers that litter the Linux ecosystem?
<duflu> RAOF: I meant generalize for spawning other processes Mir "might need"
<RAOF> Which would be the process-spawner MP that it depends upon?
<duflu> But that's less important than ensuring we don't have a hard build-dep. Perhaps optional
<RAOF> It's just for the (disabled) acceptance test (at this point).
<duflu> RAOF: Just worth thinking about how to avoiding mentioning "X" so much. There's always another solution no one has thought of
<duflu> RAOF: So long as we don't try to compile code (or require it) that includes X11/*
<duflu> Maybe optional
<duflu> RAOF: I don't yet understand why Mir has to own the Spawner actually. I need educating
<RAOF> It doesn't *have* to, but it's convenient if it does.
<RAOF> Particularly - shells which want to provide seamless X11 support will need to do a bunch of stuff between "I want to start an app that uses X11" and "I've got a Surface that comes from this X11 app".
<duflu> Meanwhile, I finally hit the brick wall of bypass requires 4 buffers to work properly :P
<RAOF> Hm.
 * RAOF dislikes process::ProcessFactory
<duflu> In a way "ps" is more meaningful. Because "ps" is specifically always an OS process and not a generic term for a methodology :)
 * duflu ducks
<RAOF> How would you feel about process::Factory? :)
<duflu> RAOF, mlankhorst: Anyone know if hardware cursor movement implicitly triggers another wait for vblank? I mean... how/when is it rendered if we're not flipping pages?
<mlankhorst> duflu: no
<mlankhorst> it's implemented as an overlay
<duflu> mlankhorst: I mean how does it fit into the physical display timing...?
<duflu> Hardware cursors seem to update much faster than anything else
<mlankhorst> no they are updated on next frame, always tear free
<mlankhorst> at least when you update the position
<duflu> mlankhorst: OK. Sounds like the "next frame" to DRM is sooner than the next frame Mir is able to flip
<duflu> Weirtd
<duflu> Weird
<mlankhorst> duflu: it's an overlay, so it might be possible
 * duflu wonders if there's a wait for vblank hiding inside SwapBuffers
<duflu> That would explain it
<mlankhorst> possibly
<duflu> Otherwise there's no logical reason (I can think of) why the hardware cursor would ever get ahead of compositing
<mlankhorst> well it can be updated while the screen is already drawing, cursor is special :P
 * mlankhorst guesses
<duflu> That's another explanation
<mlankhorst> cursor is special, it's not part of a page flip
<duflu> Yeah there's obviously more display logic beyond my programmer's view
<mlankhorst> ah cursor has its own channel
<mlankhorst> figures :P]
<mlankhorst> so page flipping has nothing to do with a cursor :)
<duflu> mlankhorst: What's a channel? :)
<mlankhorst> duflu: sorry, it's used for command submission, probably some kind of fifo
<mlankhorst> nvidia probably calls it different
 * duflu throws gmock out the window and gains karma
<anpok_> not surface?
 * ogra_ hopes you checked if someone wlaked outside before doing that ... 
<ogra_> *walked
<ricmm> Saviq: ping
<Saviq> ricmm, pong
<ricmm> Saviq: do you know if the shell is the one who currently does restore of old brightness
<ricmm> if the screen has gone dim?
<Saviq> ricmm, no, powerd is doing all atm
<ricmm> or is powerd doing the whole bit
<ricmm> ok
<Saviq> ricmm, while I have you here, did you have a think about making the N7 landscape?
<alf_> alan_g: anpok_: Please take a look at lp:~afrantzis/mir/using-stub-client-platform when you get some time (mir-screencast-basic-client-api depends on this functionality landing).
<alan_g> alf_: ack
<ricmm> Saviq: I think it should all happen in the shell
<Saviq> ricmm, not for MWC it can't
<fginther> kgunn, you pinged me yesterday I think?
<kgunn> fginther: yep..no worries...i got helped
<fginther> kgunn, good to hear
<ricmm> kdub_: :)
<dandrader> maybe restarting xchat does the trick
<dandrader> oops, wrong channel
<kdub_> ricmm, Saviq for rotation, the mir compositor will rotate all the surfaces to be composited if the display is reconfigured with a different orientation
<Saviq> kdub_, how about input?
<kdub_> i'm unsure about input
<Saviq> kdub_, yeah, if it doesn't transform input then we need to do it higher anyway
<bregma> is there an easy way to take a screenshot when Mir is running as the system compositor (er, without using a camera on a tripod pointed at the screen)?
<kgunn> bregma: i'll fwd you a mail alf sent racarr
<bregma> kgunn, thanks
<kgunn> bregma: sure, if you have any issues, feel free to hit up alf in the morning
<kgunn> kdub_: (or anyone)....so if you update manta to 4.4.2 are you stuck using rsalveti's preview img's ?
<kgunn> e.g. i have to go back to 4.2.2 to use the phablet distro images ?
 * kgunn wants to avoid bricking
<kdub_> kgunn, you have to flash the radio
<kdub_> but you can go back and forth between them
<kgunn> kdub_: yeah...i see now...no biggie
#ubuntu-mir 2014-01-30
<dupingping86> who is main developer!
<dupingping86> I 'll try to become a main developer.
<dupingping86> let's help each other.
<dupingping86> so let's make mir wonderful.
<prepangolin> Hello everybody.
<alf_> alan_g: Do you want to take another look at mir-screencast-basic-client-api or shall I top-approve?
<alan_g> alf_: If you've got other approvals I won't waste time
 * alan_g is hinting a race condition in buffer management
<alan_g> *hunting
<alf_> alan_g: interesting!
<alan_g> alf_: it is what we software developers live for. ;)
<alan_g> alf_: can you take a peek in case it is obvious to you how this happens? https://bugs.launchpad.net/mir/+bug/1267323/comments/4
<ubot5> Ubuntu bug 1267323 in Mir "Clients freeze on startup if 10 or more are already running" [High,In progress]
<alf_> alan_g: sure
<alf_> alan_g: can you try if calling surface_data->frame_posted(); before swapping the client buffers makes a difference in ms::BasicSurface::swap_buffers() ?
<alan_g> alf_:  sure
<alan_g> No effect.
<alf_> alan_g: a problem in informing the compositor about changes to the scene would have the blocking effect (but that's just a guess in this case)
<alf_> alan_g: hmm, although that would probably block all clients, not just the new ones...
<alan_g> alf_: yeah, trawling through the logic now. Thanks for looking (was hoping different eyes would help)
<alan_g> alf_: in lp:1274208 it is all clients
<alan_g> For the moment I'm assuming that duflu is right about this being one problem. It is simpler that way. ;)
<sil2100> Hi guys, do you know usually how long the mir unit-tests should run on armhf?
<sil2100> Is it taking a long time normally?
<alf_> sil2100: are you running with valgrind/memcheck?
<sil2100> alf_: just what is run in a standard mir package build
<sil2100> alf_: https://launchpad.net/~ci-train-ppa-service/+archive/landing-005/+build/5537029 <- it's like standing there for at least 20-25 minutes
<alf_> sil2100: that's not normal, something is wrong
<sil2100> alf_: it was fine yesterday, and suddenly it started to work like this in the morning
<alf_> alf_: this a native armhf (not cross-compiled) build I gather?
<alf_> sil2100: this a native armhf (not cross-compiled) build I gather?
<alf_> sil2100: where can I get the details for this build, which branch was used etc?
<sil2100> alf_: yes, it's a non-virtualized builder
<sil2100> alf_: let me provide you all the details
<sil2100> alf_: https://code.launchpad.net/~mir-team/mir/trunk-0.1.4/+merge/201707 <- this is the branch being built
<sil2100> alf_: it's the branch that releases all mir development happening in the past
<sil2100> alf_: nothing changed since yesterday it seems, and yesterday we had a green mir in the PPA - all other platforms build fine
<sil2100> alf_: just armhf gets stuck here
<alan_g> alf_: I've made some progress. It appears to be related to the topmost window overlaying other windows - not sure of the exact scenario but I've got a little movie (tries to remember how to access chinstrap)
<sil2100> kgunn: hi! It seems we can't get mir building for armhf now
<sil2100> kgunn: it was fine yesterday, now it hangs infinitely on unit-tests
<sil2100> kgunn: and it's just for armhf
<sil2100> kgunn: I can't block on mir any longer, so I'll free the mir landing silo, release all the queued platform-api bits in another landing and only then re-assign mir a silo
<alf_> kgunn: @mir failing in silo, I am building the branch locally on Nexus 10, to see if I can reproduce the hang
<alf_> alan_g: The first thing that comes to mind is the mc::OcclusionFilter failing somehow, but in that case I would expect the other windows not to be drawn at all...
<alan_g> alf_: I assume we block occluded surface to prevent them repainting. That will block a frontend thread. And if we block enough of them (e.g. the only one) then frontend is dead.
<alf_> alan_g: yes, that sounds right
<alf_> alan_g: (we "block" them by not consuming their previous buffers)
<alan_g> ack
 * alan_g thinks it is easy to test - but not trivial to fix
<anpok> can we discard them
<alan_g> alf_: yes if OcclusionFilter::operator() is hacked to return false then we don't consume all the frontend threads.
<alan_g> anpok: we intend to block the client, but not to exhaust frontend threads
<alf_> kgunn: mir_unit_tests run fine locally, both when cross-compiled and when native compiled on N10 (using trunk-0.1.4 branch)
<alan_g> alf_: anpok can you confirm my logic:
<alan_g> 1. We shouldn't have blocking calls on frontend threads
<alan_g> 2. as currently implemented SessionMediator::next_buffer() can block in SwitchingBundle::client_acquire()
<alan_g> 3. If client_acquire() is changed to non-blocking then it needs to store a completion callback when it can't complete
<alan_g> 4. If SwitchingBundle::compositor_release() finds a completion callback it must invoke and release it
<alan_g> 5. That callback needs to call pack_protobuf_buffer() and done->Run()
<alan_g> 6. This introduces some resource management issues - like the lifetime of the message response object
<alan_g> 7. Not allowing blocking calls on frontend threads means we shoudn't need to unblock them on shutdown (we can delete code)
<kgunn> hey guys...dr appt longer than i thot
<kgunn> alf_: thanks for trying...
<alf_> alan_g: Looks sensible
<kgunn> sil2100: so what's the current thot on mir in ci train ?
<sil2100> kgunn: for now, until alf_ or anyone else figures out why the mir unit tests hang on armhf, we land platform-api pending changes separately - and then we re-enable mir landing
<kgunn> sil2100: so locally they don't...for the ci train is this on calxeda where the unit test fails ??
<sil2100> kgunn: I guess so, it's the kishin builders - it was failing on more than one of the builder machines so it's not only one-hardware issue I guess
<kgunn> sil2100: ok...i'll try local as well...we may have to go down the road of debug on the calxeda
<sil2100> kgunn: the strange thing is that yesterday all was fine
<kgunn> sil2100: no kidding, curious...did platform-api (aka papi) start behaving all of a sudden too ?
<sil2100> kgunn: no, this one got actually fixed - but I guess it was some cmake fix FWIK
<anpok> alf_: async page flips?
<alf_> anpok: yes
<kgunn> sil2100: so is the "fixed" papi in proposed image ?
<kgunn> kdub_: ^
<sil2100> kgunn: not yet... having problems with cmake-related things
<kdub_> sil2100, is there a patch to try?
<anpok> alf_: so the issue is that compositing might happen while the page flip is still scheduled, instead we should wait for the completion of the page flip during the first draw call
<alf_> anpok: yes, that is, keep what we have now, I don't think the optimization Daniel describes will work properly
<anpok> but we dont have it at the next draw call, do we?
<alf_> anpok: right now we schedule and wait for page flips before continuing
<dandrader> is mir supposed to know anything or have any involvement with clipboard (copy/paste)?
#ubuntu-mir 2014-01-31
<alan_g> alf_: anpok - any ideas for a "better interface"? https://code.launchpad.net/~mterry/unity-mir/alpha-greeter/+merge/204069/comments/476680
<anpok> hm they could decorate the exsting policy, all they need is just selecting alpha when needed and supported - thats effectively just find_if
<anpok> like in the translucent server example
<duflu> On the issue of translucency... I recently discovered that making a client translucent was a big enough hit to rendering time that it could trigger clone mode frame drops, sometimes with a single client. Alpha blending is still relatively expensive, even on a Haswell desktop
<alan_g> That's a bigger hit than I was expecting
<anpok> duflu: how big was the client?
<duflu> anpok: 1920x1200
<anpok> oh
<duflu> alan_g: It was mostly due to the clone mode bug I have a fix proposed for. After that's resolved, full screen blending has no visible performance hit
<alan_g> Excellent
<anpok> but still it means that the blending of one output took longer than the update rate of the other output
<anpok> maybe we should allow clients to provide opaque rects together with the buffer
<duflu> Kind of. The issue with the clone mode bug is that we potentially have zero (or very little) rendering time at all
<anpok> alan_g: i could image a better interface
<anpok> alan_g: something like select( Requires(Exactly(1280x768), Try(OpaqueBuffer));
<anpok> bbl
<alan_g> anpok: worth discussing with greyback & mterry when you're back?
<anpok> alan_g: duflu: I would like to add something like a generic report->trace_time_span("string_id", { start,duration} );
<anpok> but still wondering where and how to visualize
<anpok> alan_g: i think so..
<anpok> duflu: but the translucent greeter is translucent everywhere..
<anpok> duflu: maybe we should use the screencast feature for that
<duflu> anpok: I feel that measuring time spans is best hidden inside the report implementations. The interfaces should always just be begin... and end...
<duflu> Not least because the Null report should be Null
<alan_g> anpok: I'm not sure that interface is the easiest to use - usually you'd want something like "Trace trace(report, "ID");
<duflu> AFK, wireless kbd issues
<duflu> wfASJL:
<anpok> duflu: agreed but, we dont have that many possible measure points - maybe that is enough - and i just have issues following the code flow.
<duflu> fscas
<anpok> and i wonder if we could make that not affect the performance at all without instrumenting the build
<duflu> anpok: That's the point of defaulting to a null report with minimal parameter passing :)
<duflu> Eek, I forgot what the old keyboard was like
<alf_> duflu: @async-page-flips, I don't get where I am mistaken... after we schedule a page flip we draw to a buffer that is still potentially being scanned out (since we don't wait for the page flip to complete). We can't touch a buffer that is currently on screen after a page flip, before the next page flip occurs, scanning out is not an instantaneous process.
<duflu> alf_: Preparing for EOW, but let me see if I can find an answer before that
<duflu> alf_: Mesa/EGL/GBM still has separate front and back buffers (obviously). The existence and rendering of the back buffer is kind of implied. But after we have called gbm_surface_lock_front_buffer we hold the locked buffer until the flip has definitely completed. This prevents the buffer from being recycled and rendered to as a back buffer while it's visible.
<duflu> Aside from anything else... if you do accidentally render to the scanout buffer you will see ugly tearing
<duflu> At least I do
<duflu> But if you can prove it wrong, that would be appreciated.
<duflu> Plus, I know the algorithm is complicated. Even *if* it is bug free, I don't expect us to digest and approve it quickly
 * duflu runs away
<sil2100> alf_: hi! Any luck with the mir unit-tests hanging up on armhf?
<alf_> sil2100: no... I can't reproduce them locally at all, and I have no idea what could be hanging so consistently in the builders
<sil2100> Troublesome...
<sil2100> hm hm
<kgunn> sil2100: i also build lp:~mir-team/mir/trunk-0.1.4 natively and ran unit tests just fine
<kgunn> sil2100: can we gain access to the calxeda machines ? don't know what else to do
<kgunn> sil2100: curious, i used image 155 that was in devel-proposed....is that a valid configuration to try and replicate what's happening on the calxeda ?
<sil2100> kgunn: the thing is that we have no idea what triggered that, as it was passing fine earlier - who knows if those wouldn't pass now... did you guys check the code for some obvious race conditions?
<sil2100> kgunn: we tried poking people about access to the devices, but it seems it's not as easy as we thought
<kgunn> sil2100: are the logs still out there ? (i don't think so as silo 005 got reused)
<kgunn> sil2100: we've spent loads of time before christmas cleaning up tests
<kgunn> sil2100: so doubt there'd be anything "obvious"....but if there are some logs that might indicate a particular test that would be interesting
<sil2100> kgunn: I think the logs are still there, but there was not much useful logs - just that it was hanging on, I think, the 3rd unit test
<kgunn> sil2100: do you know what changed ?? that could have possibly made the unit test start to fail ?...e.g. if it was passing on tuesday...what went into the build between now and then ?
<sil2100> kgunn: nothing, the PPA was in a clean state, so the problem had to be there earlier I guess? Let me find the logs
<sil2100> kgunn: it started hanging up here https://launchpad.net/~ci-train-ppa-service/+archive/landing-005/+build/5533752
<kgunn> sil2100: thanks
<kgunn> sil2100: hang on....i thot you said mir was failing...that's unity-mir
<sil2100> Ah, wrong link!
<sil2100> One moment
<sil2100> ;)
 * sil2100 ashamed
<sil2100> kgunn: https://launchpad.net/~ci-train-ppa-service/+archive/landing-005/+build/5535453
<kgunn> sil2100: no worries...i stay permanently "ashamed"  :)
<kgunn> sil2100: you still there ?
<kgunn> sil2100: any chance we can get a silo ?
<kgunn> sil2100: we've got a potential fix for the calxeda unit test hang
<sil2100> kgunn: !
<sil2100> kgunn: still here :)
<sil2100> kgunn: let me clean up some silos though
<kgunn> sil2100: thanks and no problem...
<kgunn> i know its getting late there
<kgunn> bbiab
<sil2100> kgunn: ok, so I think it won't be so easy... it seems platform-api is right now blocking the slot, so until it's not released we won't be able to fill mir in
#ubuntu-mir 2015-01-26
<attente_> hi, is anyone getting this error when running the mir_demo_server? http://paste.ubuntu.com/9881657/
<alan_g> attente_: yes (I see other, possibly related, problems too). Want to raise a bug?
<attente_> alan_g: sure, thanks
<alan_g> attente_: FWIW you can "fix" by reverting -c 2254
<alan_g> Let me know the bug number and I'll update it
<attente_> alan_g: awesome, thanks! https://bugs.launchpad.net/mir/+bug/1414630
<ubot5> Launchpad bug 1414630 in Mir "mir_demo_server exits immediately with boost bad_any_cast exception" [Undecided,New]
<alan_g> anpok: have you a quick way to fix? ^^
<anpok> alan_g|lunch: I will take a look
<anpok> alan_g: i dont see the exception but it isnt working either..
<anpok> but I see whats going wrong, figuring out what could cause it
<anpok> ok I see it .. someting went wrong merging..
 * alan_g hopes that means we can fix instead of reverting
<anpok> yip seems like it
<anpok> alan_g: https://code.launchpad.net/~andreas-pokorny/mir/fix-1414630/+merge/247594
<alan_g> anpok: testing...
<anpok> strange thing is that my local version of the server-platform-probing branch did have the symbole
<anpok> -e
<anpok> hmm how do I parse a revision number 1457.4.12 in bzr?
<alan_g> I try not to - just cut & paste it
<alan_g> attente_: anpok has a fix (It works for me): https://code.launchpad.net/~andreas-pokorny/mir/fix-1414630/+merge/247594
<anpok> alan_g: hm bzr blame on mir claims that the line was last touched with 1457.4.12.. so that rename just wasnt merged
<alan_g> anpok: I'll just assume I messed up the merges somehow. (I did commit the merge so I should have checked)
<alan_g> camako: do you remember the tests scripts well enough to get them to use "mir_demo_server --test-client" instead of the python script? (That ought to ensure that our servers and clients actually run on the target platforms.)
<camako> alan_g, I can take a look
<alan_g> thanks
<alan_g> anpok: thanks for the quick fix
<camako> alan_g, so the python script is used when the test name includes "mir_demo_client_" otherwise it's run directly.
<alan_g> camako: that sounds like I how remember it
<camako> alan_g, currently "mir_demo_server_basic" is used in the python script.
<camako> alan_g, were you just wanting to use "mir_demo_server" with the "--test-client" arg?
<alan_g> camako: true, but (I never figured out why) when it doesn't work the test run doesn't fail.
<alan_g> camako: yes, that does everything the script does and also reports errors correctly
<camako> alan_g, yes the tests don't make it fail... After we fixed it and saw it running properly, at some point we were going to change that...
<alan_g> camako: I think now is the time, and we shouldn't need the script now we have "--test-client"
<camako> alan_g, So I guess the test names are fed through CI in $test_suites build parameter... That needs to be changed to "mir_demo_server -- test-client".
<camako> alan_g, got it
<camako> I'll chase
<alan_g> camako: I don't think any chasing is needed - just care to test the changes before overwriting the scripts
<isantop> Quick question: Is there any way to enable the Ubuntu Touch onscreen keyboard in the vivid-desktop-next image?
#ubuntu-mir 2015-01-27
<mlankhorst> hah, looks like I can use the drm EGL platform in standalone Xmir instead of the Mir EGL platform. :P
<mlankhorst> at least that one cleans up correctly..
<mlankhorst> RAOF: should I file a bug for eglTerminate not cleaing up correctly with Mir?
<mlankhorst> https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1414999
<ubot5> Launchpad bug 1414999 in mir (Ubuntu) "double free in mir when calling eglTerminate and gbm_device_destroy" [Undecided,New]
<alan_g> alf_: you should mention your suspicions of cloud-worker-13 on #ubuntu-ci-eng
<alf_> alan_g: Have we had an other strange failure? I think I want to wait for one more data point at least.
<alan_g> alf_: Ack. (I've not been counting.)
<mpt> Iâm working on the surface management spec, and I have a question about the minimized state
<mpt> Does/Should an app know, and be able to change, whether each of its windows is minimized?
<mpt> If it could, it could suspend decoding/display of video, pause games, etc, saving battery
<alan_g> the client API allows an app to query the state, get updates when the state changes and to request a state change.
<mpt> Ok :-) thanks
<kgunn> AlbertA: you around?
<kgunn> AlbertA: camako: so will mir permit clients to pass in a preference of positioning ?
<AlbertA> kgunn: we don't have that in the api yet...but there's a question for base windows on
<AlbertA> what would the coordinate system be
<AlbertA> but I see it as an optional field in MirSurfaceSpec
<kgunn> AlbertA: so was just chatting with mzanetti, and he was saying this is important for the "memory" aspect
<kgunn> that when you flip between mobile and desktop
<kgunn> desktop just ends up with all the windows in the same spot...even if you previously spread them all out
<kgunn> whereas, the desire would be for it to recall where they were and put them back into position
<AlbertA> kgunn: I would have thought this would be part of the "cookie" stuff
<AlbertA> which would be used by a shell to save/restore window information on the server side...
<kgunn> oh look...already a bug
<kgunn> https://bugs.launchpad.net/qtmir/+bug/1415161
<ubot5> Launchpad bug 1415161 in Unity 8 "U8 application windows don't remember their location or size when switching between Windowed->Staged->Windowed" [Undecided,New]
<kgunn> AlbertA: true, shell could do the tracking in the near term
<AlbertA> kgunn: at first glance I put it in the same bucket as restoring window positions when an application starts again from scratch which is the
<greyback> so I'm in 2 minds about Mir saving window state/position. Since we have 2 distinct view states (desktop/tablet) that would imply there's 2 separate state/position settings to track for each surface
<greyback> -surface+window
<greyback> should Mir have to support that?
<AlbertA> cookie thing racarr/chris have mentioned in the past
<AlbertA> I would imagine something like
<AlbertA> the client requests a unique cookie from the server
<AlbertA> and gets associated with session/surface maybe
<AlbertA> then a server side interface just asks a helper
<AlbertA> to store/retrieve info, given that cookie - the shell implementation would then
<AlbertA> save whatever pertinent information it wants (like desktop/tablet mode, last known position etc...)
<AlbertA> and likewise, mir server would ask the same helper, given that cookie to retrieve stored state...
<AlbertA> the alternative is the client specifying initial positions....
<AlbertA> but then we have to agree on what type of coordinate system to use...
<AlbertA> it would probably have to be something normalized to the current view coordinate system
<kgunn> AlbertA: right, and we want to avoid absolute positioning iirc
<greyback> yeah that's fair, let the shell save what it needs
<kgunn> AlbertA: client cookie only good for child surface tho right?
<kgunn> e.g. topmost parent isn't going to know it's position right ?
<kgunn> camako: just wondering, looks like racarr addressed alan's comment, we can ta ?
<kgunn> https://code.launchpad.net/~mir-team/mir/add-non-input-event-ctors-and-port-event-sinks/+merge/247084
<camako> kgunn, done
<kgunn> camako: no prob...was just askin' really
<camako> sure
<kgunn> camako: i'm kinda cross referencing backlog and branches....seeing where we're really at
<camako> kgunn, need help?
<kgunn> camako: i might ping you as i go...and you might wanna skim it after i finish
<camako> kgunn, sure
<AlbertA> kgunn: cookie is more anything I think, basically to persist data and give it a unique id
<kgunn> AlbertA: thanks...i did find it in the backlog "MirCookie/MirReference support (focus grant, cross-session/client parenting/referencing)"
<AlbertA> kgunn: oh...yeah that maybe a bit different, that's more about cross-process ids
<AlbertA> kgunn: but could be related...I have not given it deep thought :)
<kgunn> camako: this feels like we should approve, fixes a bug as well...
<kgunn> https://code.launchpad.net/~vanvugt/mir/fix-buffers_ready_for_compositor/+merge/247124
<kgunn> altho if you want to review first, i'd understand
<camako> kgunn, I looked at it.. yeah it looks reasonable
<camako> was going to take a deeper look
<kgunn> camako: and is jenkins still being a punk ?
<kgunn> https://code.launchpad.net/~mir-team/mir/add-dispatchable-interface/+merge/246372
<kgunn> ah...nope seems he's gotta conflict
<camako> kgunn, alf noticed some failures but thought they were contained or due to one specific server
<camako> kgunn, yes that particular one need TLC from RAOF
<kgunn> RAOF: you on?
<RAOF> kgunn: Indeed I am
<kgunn> so i was trying to help :)
<kgunn> RAOF: and i goofed, but already figured out how to do it right...but
<kgunn> don't know how to undo one particular thing
<kgunn> so i was addressign the conflict on
<kgunn> lp:~mir-team/mir/add-dispatchable-interface
<kgunn> and thot i addressed the right --take but i didn't
<kgunn> shoulda done by hand
<RAOF> Heh.
<kgunn> ...and pushed, only to realize the goof
<kgunn> so how does one "revert" the push
<RAOF> Either by adding an extra commit, or by push --overwrite.
<kgunn> cause if you uncommit/revert...then push, it says "you've diverged you fool"
<kgunn> so opportunity to learn for me as well
<kgunn> RAOF: what's the penalty if any of --overwrite ?
<RAOF> Yeah, âpush --overwriteâ is what you want in that circumstance.
<kgunn> or does it simply obliterate that last commit
<RAOF> It obliterates what's currently in the branch and replaces it with what you push.
<kgunn> (e.g. does it negate your approve votes or do some weird history loss thing)
<kgunn> ok...will do that
<RAOF> No, nothing like that.
<RAOF> Some tools can get a bit confused because they expect the contents of a revision to be immutable (ie: rev 2278 has one contents now and will have a different contents after --overwrite)
<RAOF> But it's all fairly harmless.
<kgunn> RAOF: ok, that seemed to work...took a while to make sure i did it correct...of course, i only touch ./tests/CMakeLists.txt
<kgunn> but after...now it's complaining about others
<kgunn> https://code.launchpad.net/~mir-team/mir/add-dispatchable-interface/+merge/246372
<kgunn> is that common ?
<RAOF> No. That would suggest that there are other conflicts introduced.
<kgunn> RAOF:  i suppose i should have done merge lp:mir ...vs lp:mir/tests/CMakeLists.txt
<kgunn> ?
<RAOF> I'm not sure what lp:mir/tests/CMakeLists.txt would do?
<kgunn> it only merges that file
<RAOF> I didn't know you could do that :)
<kgunn> hehe
<RAOF> I'd probably just do âbzr merge lp:mirâ and check that everything's ok.
<kgunn> ok...merging the entire tree
<kgunn> woa... 5 conflicts encountered
<kgunn> and lots of stuff moved about
<RAOF> Yeah, the ABI things now conflict.
<kgunn> yep
<kgunn> Text conflict in common-ABI-sha1sums
<kgunn> Text conflict in platform-ABI-sha1sums
<kgunn> Text conflict in server-ABI-sha1sums
<kgunn> Text conflict in src/common/symbols.map
<kgunn> Text conflict in tests/CMakeLists.txt
<kgunn> RAOF: i assume the map gets taken care as part of the sha1sum updates
<kgunn> ?
<RAOF> symbols.map? No, that needs manual merging.
<kgunn> RAOF: how does one resolve the sha1sums ? script ?
<RAOF> You need to manually edit it to resolve the conflict.
<kgunn> k
<kgunn> RAOF: ok...doing the symbols.map last, and it looks like an hour ago robert added a 3.2
<kgunn> http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/2267
<kgunn> does that mean
<kgunn> i need to mannually add a 3.3 for your adds ? ...or just merge them under 3.2 since we haven't release yet ?
<RAOF> Can probably merge them under 3.2
<kgunn> RAOF: does order matter ?
<RAOF> No
<kgunn> RAOF: one last one... on your add of 3.2 your close brace has MIR_COMMON_3.1; whereas sir robert's has MIR_COMMON_3;
<kgunn> i see 3.1 closed with MIR_COMMON_3 as well...
<kgunn> what would be the correct convention
<RAOF> It doesn't _really_ matter; 3.1 would be slightly more correcct.
<RAOF> Indeed, you can leave out the base-revision entirely. It's basically just saying âThese symbols comprise MIR_COMMON_3.2, and require MIR_COMMON_3.1â
<kgunn> that was my guess
<kgunn> RAOF: thanks for letting me do, learned a little....pushed
<kgunn> gonna kick jenkins, if it passes we should top approve
<RAOF> And I'll merge that through all the dependent branches. Thanks!
<RAOF> Soooo.
<RAOF> For those playing at home, Grim Fandango remastered is available on Linux.
<racarr> On by default the last timeI used it
<racarr> ...
<racarr> lol
<racarr> up + enter mishap
<racarr> qtmir -> event 2.0 port finished...of coursemuch manual testing required
<RAOF> Woot!
<RAOF> racarr: Remember to buy Grim Fandango for the plane trip to Brussels :)
<racarr> I've never played it actually...
<RAOF> Yeah, that's what I though.
<RAOF> t
<RAOF> It might have been a bit before your time :P
<RAOF> Which is why you should buy it, silly!
<kgunn> who doesn't love mexican skull art really
<kgunn> in a video game no less
<racarr> oh that is kind of my jam
<kgunn> never heard of this...but now i am totally intrigued
<RAOF> OH MAN!
<RAOF> You're a travel agent in the land of the dead!
<RAOF> Starting on the day of the dead!
<RAOF> Intrigue! Mystery! Skeletal pigeon eggs!
<kgunn> hehe
#ubuntu-mir 2015-01-28
<alan_g> alf_: can I expect Mir to work in a VM currently?
<anpok> yes for vmware, and yes for kvm if you install 3.18 kernel or later, best from here:
<alf_> alan_g: I haven't tried very recently, but I am not aware of any change that could have broken VMware support.
<anpok> http://kernel.ubuntu.com/~kernel-ppa/mainline/
<alf_> anpok: vivid has 3.18.0 by default, is that enough?
<anpok> oh
<anpok> didnt notice
<anpok> yes
<alf_> anpok: ack
#ubuntu-mir 2015-01-30
<alan_g> alf_:  you're OK dealing with the clang failures?
<alf_> alan_g: Yes, pushing a branch (the problem is also fixed in your newest MVC branch, but we can't wait for it).
<alan_g> Sure - I'll review when you're ready
<alf_> alan_g: https://code.launchpad.net/~afrantzis/mir/fix-1416317-clang-build/+merge/248089
<alan_g> alf_: I suggest a "merge by hand" to get it fixed asap
<alan_g> Are you willing or shall I?
<alf_> alan_g: I will do it
<alan_g> Mmm just tried "use_debflags" locally and got linker errors with clang: /usr/include/pthread.h:1166: multiple definition of `pthread_equal'
 * alan_g decides to ignore it unless CI breaks the same way
<alf_> alan_g: I have had this problem for a while now, but haven't been able to resolve it
<alf_> alan_g: ...but after upgrading to clang 3.6 today I got even bigger problems: clang can't find c++ header files/libs. I had to manually add the std paths to test the fix.
<alan_g> It looks like the inlining macros are ending up wrong, but it isn't immediately obvious why
<alan_g> I'll stick with 3.5 then
<alan_g> alf_: any opinion on https://code.launchpad.net/~mir-team/mir/add-multiplexing-dispatchable/+merge/246674?
<alf_> alan_g: I am trying to wrap my head around the gc stuff
<alan_g> alf_: "Dissapprove - it makes my head hurt" ;)
 * alan_g notices all his VPN setups have disappeared
<alan_g> alf_: I added 0.5kl of forgotten updates to server/symbols.map - I hope that doesn't put you off.
<alf_> alan_g: no problem
<alan_g> alf_: I'm seeing an intermittent segfault in mir::compositor::GLProgramFamily::Shader::init() running Mir on the desktop with --display-config sidebyside. Any thoughts before I dive in?
#ubuntu-mir 2016-02-01
<duflu> RAOF: Thanks for the android-headers. Crisis averted
<duflu> It was a race against time as our xenial build machines on Friday were luckily slightly out of date and didn't have the bug yet...
<RAOF> duflu: Actually, our xenial build machines would have correctly built it ;)
<duflu> RAOF: How's that?
<RAOF> duflu: Because the bug only appears when *upgrading* from android-headers $OLD_VERSION to android-headers 23.
<RAOF> Since we install fresh on the builders, they never would have seen the problem.
<duflu> RAOF: Interesting. How often do we install fresh? Sounds expensive
<RAOF> Every build?
<duflu> Hmm, maybe copy-disk-image rather than install?
<RAOF> Not really; it's certainly < 1m on machines that aren't IO thrashing.
<duflu> Hmm.... why do Mir servers use more CPU to bypass/overlay than to GL composite?
<duflu> Curious
<RAOF> Do they actually use more CPU, or is the CPU in a higher performance state when GL compositing?
<duflu> RAOF: I'm not sure. The meaning of CPU usage also varies between tools (some say 100% is one core and others say 100% is all cores)
<duflu> Never considered power state too
<RAOF> 100% CPU at 800MHz is quite different to 100% at 2.5GHz :)
<duflu> RAOF: I suspect the former does not usually exist. If you're  using 100% CPU at 800MHz the system should have clocked up already
<duflu> But 5% as I'm seeing is plausibly some unknown clock rate
<RAOF> Maybe should, but doesn't.
<duflu> I should check
<RAOF> Or our whole âscrolling is only smooth if you keep a finger on the touchscreenâ bug wouldn't have existed.
<duflu> RAOF: Still does (if not the original bug a new one is open still)
<duflu> I think... I definitely know it's still a problem because that was the sole remaining blocker of double vs triple buffering (and dynamic scaling)
<duflu> Interestingly the second-last blocker just got fixed in Mir 0.19.0
<RAOF> I wonder if the blockers will be fixed before the codepath no longer exists :)
<duflu> RAOF: I'm kind of hoping NBS stumbles upon a way to keep the CPU awake, somewhat by accident
<duflu> Which may happen
<duflu> But before then, hoping we actually test it and assess whether that it doesn't regress anywhere
<zzarr> hello!
<zzarr> hello! duflu, I found this https://wiki.debian.org/InstallingDebianOn/Asus/C201
<zzarr> it's about as close I of a tutorial I can com/find
<zzarr> come*
<duflu> zzarr: Hello. Interesting but it seems they have no news on OpenGLES
<duflu> "OpenGL ES"
<duflu> I've never had a good look at ChromeOS binaries. I wonder what libc they use...
<anpok> hmhm on mali you can get at least three different types opengl es libraries..
<anpok> .. oh actually four if you count lima too..
<anpok> there are es/egl libraries for android, for rendering on fbdev, and for x11..
<duflu> BTW all: Mir 0.19.0 is released now (https://launchpad.net/mir/+milestone/0.19.0)
<anpok> each of those need mali specfic kernel patches.. integrated for your soc
<duflu> Just no announcement yet because we haven't finished documenting the release
<zzarr> duflu, what are the differences between the openGLES libs?
<duflu> zzarr: I don't understand the question. What libs?
<zzarr> is it a specific one that mir needs?
<zzarr> ohh, it was the libc versions?
<duflu> zzarr: Mir like most OpenGL code links to libGLESv2.so.2 which has a clearly defined ABI. The only question is what libraries does the libGLESv2.so.2 link to.
<zzarr> duflu, I see, I understand the question
<zzarr> is there a way to know that?
<duflu> zzarr: Just run ldd, or objdump
<zzarr> okey
<zzarr> duflu, what parts of the tutorial do I need in order to install Ubuntu instead of debian?
<zzarr> I tried changing jessie to xenial and the url to ports.ubuntu.com, and it worked...
<zzarr> basically what failed was to copy the kernel
<duflu> zzarr: I can't say with confidence. I would suggest just setting up crouton. That's an easy way to have full Ubuntu, and a working kernel from ChromeOS, and keep ChromeOS working too.
<duflu> For anything more advanced, you will need to become the expert and answer those questions yourself
<zzarr> I have crouton, but installing Ubuntu on a SD card will not ruin my chromeos
<duflu> Sorry, I haven't played with Ubuntu on ChromeOS in a while. You have just about exhausted what I remember :)
<zzarr> duflu, sry, did not mean to ;)
<zzarr> it's just.. I got exited about running Ubuntu on my chromebook, since it would be 3D-accelerated (which crouton is not)
<duflu> Sadly, Intel Chromebooks are an easier way to do that. Although nowhere near as sexy as the Chromebook Flip
<zzarr> duflu, I know
<zzarr> still, I will fight to get Ubuntu running on my chromebook ;)
<zzarr> duflu, I have copied the kernel and signed it now :-D
<duflu> Cool
<zzarr> I'll try to start from the SD card now
<zzarr> just a black display
<zzarr> maybe the kernel-flags are wrong, maybe it should not be console=tty1
<zzarr> duflu, I can recommend a ASUS Chromebook Flip
<duflu> Yeah looks very nice
<duflu> The thing that lets down most Chromebooks is the lack of IPS display. So that's solved too
<zzarr> yea :)
<zzarr> I would not mind higher resolution, but... higher resolution means shorter battery life
<zzarr> it's a 1280x800 display
<zzarr> but it can handle a UHD over HDMI
<duflu> UHD is great. So long as it can keep up with the frame rate of the video you're playing (or ideally 60Hz)
<zzarr> it should be able to handle a video @ 30fps
<zzarr> duflu, I don't remember, do you have any idea how to activate a console on a kernel that's without one?
<duflu> zzarr: No, sorry. Google! :)
<zzarr> duflu, okey, it was worth a try (to ask you) :-)
<alf_> Saviq: Hi! I saw that you were looking into upgrading sbuild to a newer version in your jenkins builders. What the status of this?
<alf_> Saviq: (I too need a newer sbuild)
<Saviq> alf_, my prepare jobs do this already
<Saviq> alf_, they take it from ppa:launchpad/buildd-staging or is that not new enough?
<alf_> Saviq: I get sbuild 0.64.2, but I need a newer version that supports SBUILD_CONFIG (custom config per build)
<alf_> Saviq: oops, that's 0.65.2
<Saviq> alf_, 0.65.2 is in there https://launchpad.net/~launchpad/+archive/ubuntu/buildd-staging/+packages
<Saviq> alf_, why do you need that, btw?
<alf_> Saviq: Yes, looking at the git repo I need at least 0.66 for SBUILD_CONFIG
<Saviq> alf_, right, misread, problem is it's not a 1:1 backport, I tried building sbuild from xenial on trusty and it failed
<alf_> Saviq: I have been trying to run some custom scripts in the chroot with the facilities that sbuild provides, but either sbuild or jenkins get very confused when passing these as command line args to sbuild.
<alf_> Saviq: So I want to try defining them in a config file
<Saviq> alf_, so you mean stuff like --foo-commands does not work?
<Saviq> I'd imagine you'd have to escape those in a way neither jenkins nor sh -r play with that
<Saviq> alf_, tried putting the script in a file (I need to move all those shell/py blocks to bzr myself)
<alf_> Saviq: Both methods works well locally... not sure what confuses sbuild/jenkins, probably it doesn't escape properly or escapes too much. I have tried with different escape but I haven't been able to find a way that works
<Saviq> alf_, right, I'd put the scripts in bzr and run those instead of coding in jenkins directly
<Saviq> was meaning to do that anyway
<alf_> Saviq: I also tried writing the script to a file and then copying into the chroot, but I found that %SBUILD_CHROOT_DIR doesn't work in jenkins/sbuild with --pre-build-commands, although I think it should be supported in 0.65.2
<Saviq> alf_, an "env" in the script could probably help
<alf_> Saviq: %SBUILD_CHROOT_DIR should be substituted by sbuild, not sure how an env would help?
<Saviq> alf_, ok not sure about that %foo, but I'd imagine stuff's exported as env, innit?
<Saviq> alf_, ah I think that only works in strings
<Saviq> alf_, man says "sbuild --post-build-commands 'foo %SBUILD_CHANGES'"
<Saviq> alf_, so assuming foo is a script, it will be given the argument
<Saviq> alf_, but check env, I'm sure there's quite a bit of data in there already
<alf_> Saviq: yeah, so %SBUILD_CHROOT_DIR is not substituted for some reason
<Saviq> alf_, you said in a file?
<alf_> Saviq: Sorry, I wasn't clear... the script itself is an file that I want to copy into the chroot with --pre-build-commands 'cp script.sh %SBUILD_CHROOT_DIR' but I can't because the sbuild var is not substituted properly
<Saviq> alf_, right, now I get it, just bind-mount a folder with scripts ;)
<alf_> Saviq: thanks, I'll try that
<Saviq> alf_, that's what I planned to do with the existing pbuilder hooks - just bind-mount the folder, although those that run outside the chroot might still need the substitutions to work
<Saviq> alf_, but indeed man says %r should be available in --pre-build-commands
<alf_> Saviq: Let me know when you have moved your scripts to bzr, I will probably want to extend them or branch
<Saviq> alf_, will do, I hope you don't diverge far enough, so we can maintain together all of su
<Saviq> us
<Saviq> alf_, oh btw there was a talk on fosdem about Jenkins DSL https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin
<Saviq> https://fosdem.org/2016/schedule/event/jenkins_as_code/
<alf_> Saviq: agreed, I will try to extend as much as I can (with hooks etc)
<alf_> Saviq: interesting
<Saviq> alf_, related to what jibel proposed (jenkins-job-builder), unfortunately as things stand we can't use either, because the "seed" jobs need to run on the master ;)
<alf_> Saviq: I am seeing cases where jenkins is losing my changes to jobs (I hit save and next time or after a while the job reverts to an older version). Have you seen that?
<Saviq> alf_, nope, don't think so
<alf_> Saviq: good for you, it's very annoying...
<Saviq> I can imagine
<alf_> Saviq: so, let me know if I can help with bzr-ifying the scripts
<Saviq> alf_, ack, I'll jump on that tomorrow morning
#ubuntu-mir 2016-02-02
<duflu> tsdgeos: Is the shell's text rendering ubuntu-ui-toolkit or regular Qt stuff?
<tsdgeos> duflu: i wouldn't say the ubuntu-ui-toolkit has any own text rendering
<tsdgeos> i hope so at least :D
<duflu> tsdgeos: Lemme rephrase that: Who calls into FreeType?
<tsdgeos> Qt if anyone
<tsdgeos> i have the word harbuff inside my mind
<tsdgeos> not sure if that replaces freetype or not
<duflu> tsdgeos: HarfBuzz?
<tsdgeos> duflu: that
<duflu> Yay, another fork I didn't know existed
<tsdgeos> it's quite old
<tsdgeos> afaik gtk is using this too
<duflu> Yeah apparently FreeType links to it
<tsdgeos> so as said, it may not be "the same thing" as freetype
<duflu> tsdgeos: That's OK. My question was who calls the relevant libraries. Not what the libraries are
<Saviq> alf_, so I've been thinking, if we manage to get jenkins-job-builder and/or DSL working, no point in having the scripts in the repo separately, the might as well be baked into the jobs if the job definitions are stored in bzr
<Saviq> alf_, so I'm gonna look into that instead of putting them into bzr
<alf_> Saviq: ok, although one thing that concerns me is that jobs will need to have different defaults depending on project, how will we deal with this?
<Saviq> alf_, I'm sure there are ways
<Saviq> alf_, like a config file or global env vars
<Saviq> alf_, it seems like jenkins-job-builder doesn't even need to run on the jenkins nodes necessarily, as all it does is upload xml via the API
<Saviq> alf_, so assuming we can make stuff smart, you'll just set up some config vars and let JJB do its thing
<QUESTION> ?
<ogra_> 42
<QUESTION> what's my nickname?
#ubuntu-mir 2016-02-04
<alf_> Saviq: Hi! Did you get a chance to try the jenkins-launchpad-plugin improvements for MP messages?
<Saviq> alf_, not yet, sorry, tomorrow might be a good day for that :)
<alf_> Saviq: ack
<alan_g> anpok: with the ongoing input rework, is AndroidInputReceiverSetup.slow_raw_input_doesnt_cause_frameskipping likely to become obsolete?
 * alan_g is thinking about bug 1394369
<ubot5`> bug 1394369 in Mir "[testsfail] failure in CI in AndroidInputReceiverSetup.slow_raw_input_doesnt_cause_frameskipping" [Medium,Triaged] https://launchpad.net/bugs/1394369
<AlbertA> uggh more real time tests....:)
<bschaefer> alan_g|EOD, possibly once we move away from android :)
 * bschaefer now just realized how much test rework will be needed
<bschaefer> but at lease all the tests are there haha
<anpok> oh wow
<anpok> and all of that in a unit test
#ubuntu-mir 2016-02-05
<alan_g> greyback: can you confirm? Unity8 uses QtCompositor from qtmir, not Mir's MultiThreadedCompositor?
<greyback> alan_g: confirmed
 * alan_g add Compositor to a list of customization points that could be improved
<alf_> alan_g: greyback: There have been various talks about changing Unity8 to MTC, but there were always more pressing topics to pursue
<greyback> alf_: right, kdub_ did work on that, but is blocked until we adopt qt5.5
<Saviq> alf_, hey,so I was trying lp:~afrantzis/jenkins-launchpad-plugin/deb-artifacts-in-any-dir
<Saviq> DUH
<Saviq> alf_, actually, seems to be working fine, yeah
<alf_> Saviq: good to hear
<Saviq> alf_, and it seems to work for old s-jenkins format as well, cool
<Saviq> alf_, one thing though, think it would make sense to order alphabetically?
<Saviq> I've always felt lost in the list tbh
<alf_> Saviq: I think builds at the same level were ordered alphabetically by jenkins.
<alf_> Saviq: not sure that imposing a global alphabetical sort would make things easier to read, since it would mix different levels
<Saviq> alf_, don't think it is ordered, http://pastebin.ubuntu.com/14886578/
<Saviq> alf_, ah wait, it is
<Saviq> alf_, but the problem is that it's breadth-first instead of depth-first
<alf_> Saviq: yeah, for example all the build-2-binpkg jobs are ordered
<Saviq> alf_, right, it'd be better if it would be depth-first IMO
<alf_> Saviq: well, ok, I can take a look, but perhaps better to leave this for a different MP? Better to have this now I think than no output at all.
<Saviq> alf_, yeah sure, just talking :)
<Saviq> alf_, minor comments on https://code.launchpad.net/~afrantzis/jenkins-launchpad-plugin/triggered-builds/+merge/284117
<alf_> Saviq: thanks, commented and updated
<Saviq> alf_, didn't save comments, did you?
<alan_g> alf_: (not urgent) I'd like your thoughts on duflu's suggestion. (The more I think about it the more complex making it work seems - but maybe I'm missing something.) https://code.launchpad.net/~alan-griffiths/mir/fix-1535894/+merge/285058
<alf_> Saviq: I replied inline, did these get lost?
<Saviq> alf_, need to press "save comments" at the top
<Saviq> alf_, should still be in your browser
<alf_> Saviq: ah, closed tab... in any case: using set() directly would arbitrarily rearrange builds, the way it's done now the order is retained
<Saviq> alf_, regardless if you closed tab ;)
<Saviq> alf_, they're stored in browser
<Saviq> alf_, right, I thought that might be the reasoning
<Saviq> alf_, so you can go to that same URL and press Save and they should be there :0
<Saviq> alf_, approved, let's see if they use autolanding :)
<alf_> Saviq: Thanks for the reviews. Unless there are any objections I will trigger the recipe to publish the new version in the ppa
<Saviq> alf_, +1 from me
<alf_> Saviq: tools PPA now contains all the MP message goodies! Enjoy!
<Saviq> alf_, yay, /me updates
<mariogrip> kdub_:  AlbertA: hi could one of you help debug this issue? https://github.com/ubports/android/issues/1
<mariogrip> android 5.1 on fairphone
<mariogrip> 2
<AlbertA> mariogrip: so it seems then the module open call did not return an error but returned null for the alloc_device_t...
<AlbertA> that's in android_buffer_allocator.cpp (AndroidGraphicBufferAllocator constructor)
<mariogrip> do you know why it does not return? it seems to print correct address
<tvoss> mariogrip, it returns, and let's please keep the conversation in one channel
<AlbertA> mariogrip: oh just looked at the pastebin...
<AlbertA> mariogrip: you are missing symbols in the stack trace so could have crashed on the android side
<tvoss> AlbertA, top of the stack is 0x0 ;) unlikely that anything is mapped to that address
<tvoss> mariogrip, do you have a link to the actual libw module implementation handy?
<AlbertA> null function pointer?
<AlbertA> sounds like android side issue :)
<tvoss> AlbertA, yup
<tvoss> AlbertA, https://github.com/CyanogenMod/android_hardware_qcom_display/tree/cm-12.1-caf-8974
<tvoss> AlbertA, https://github.com/CyanogenMod/android_hardware_qcom_display/blob/cm-12.1-caf-8974/libgralloc/gpu.cpp#L46
<tvoss> alloc is null after the assignment
<tvoss> l. 39 is funky, too, as alloc_device_t is a direct base of gpu_context_t
<mariogrip> tvoss: libw?
<tvoss> mariogrip, sorry, libhardware :)
<mariogrip> https://github.com/CyanogenMod/android_hardware_libhardware
<mariogrip> https://github.com/CyanogenMod/android_hardware_libhardware/tree/cm-12.1
<AlbertA> tvoss: umm treating as pod, but maybe it's not a pod
<tvoss> AlbertA, also assumes default alignment
<tvoss> mariogrip, so I think the gralloc device is initialized here: https://github.com/CyanogenMod/android_hardware_libhardware/blob/cm-12.1/modules/gralloc/gralloc.cpp
<mariogrip> tvoss: it should not, but I can test
<tvoss> mariogrip, ah, no worries, I might be wrong
<tvoss> mariogrip, I will eat something and read code later on
<mariogrip> okey :)
<coretex__> yay mir 0.19.1
#ubuntu-mir 2016-02-07
<mariogrip> is android HWC 1.4 supported in mir?
#ubuntu-mir 2017-01-30
<duflu> RAOF: Did you notice bug 1660017 ?
<ubot5> bug 1660017 in Mir "EDID does not change when hotplugging a monitor" [Medium,New] https://launchpad.net/bugs/1660017
<duflu> I know it's almost EOD
<RAOF> Huh.
<RAOF> I did not.
<duflu> (assuming hotplugging does not crash the server, which still happens but I have not clearly described in any recent bug)
<RAOF> I am confused.
<RAOF> We're using the functions documented as doing a full hardware probe.
<RAOF> ????
<RAOF> EOD
<alan_g> duflu: as you've poked around Xmir, maybe you know the answer... I'm trying to use it in a snap, (where nothing is ever on the default path) and it can't find sxkbcomp. I can see it holds the format string "%s%sxkbcomp" -w %d %s -xkm "%s" -em1 %s -emp %s -eml %s "%s%s.xkm", but is there a way to set the first %s field? (A quick look at the code suggests it's a build-time constant, but I'm hoping I missed something.)
<duflu> alan_g: Did you build Xmir or copy from archive?
<alan_g> from archive
<duflu> (The trick to avoid similar issues when building Xmir is to configure with --prefix=/usr)
<alan_g> duflu: it needs to be (at runtime) %SNAP/usr
<duflu> alan_g: No idea then sorry
<duflu> Oh
<alan_g> But I guess you've confirmed that it's set at build time
<alan_g> thanks
<duflu> alan_g: Maybe this is the same problem in reverse. You need to build Xmir with --prefix=<replacement for /usr>
<alan_g> At build time we don't know %SNAP
<duflu> Yep. Xorg code is a bit older than that
 * duflu looks at the source
<duflu> alan_g: Looks easily configurable. The first %s is the bin dir and the second is forward or backslash
<duflu> I could do that.
<alan_g> ack, But it isn't a priority (ATM), and likely not the last blocker.
<duflu> alan_g: Are you suggesting the first %s is empty or non-empty and wrong?
<duflu> Looks like building with empty should work (and default to $PATH)
<alan_g> No, the first % is /usr and is wrong in a snap
<alan_g> it needs to be (at runtime) %SNAP/usr
<duflu> alan_g: Yeah looks like the source is written to nicely handle NULL and search the path, but our builds are hardcoded
<alan_g> I was hoping that I'd missed an env variable or similar (windows has winFixupPaths()).
<duflu> alan_g: Sounds easy to test and fix. I'll just stop using the --prefix workaround and see what works then. Sadly there is no environment. It's popen'd with an optional hardcoded bin path
<alan_g> that's what I thought. :(
<duflu> It stumped me too. When I first looked at Xmir it didn't work because the default build uses /usr/local for it which is wrong on Ubuntu
<duflu> I never changed any release build parms, just have a technique for building it in development.
<duflu> alan_g: Tomorrow. Now; dinner
<alan_g> duflu: Have a good one!
<duflu> o/
<alan_g> greyback: starting to think about D&D support. Where are the "drag start, drag move & drop events" initiated (a toolkit API mir_window... call?) handled (a server interface?) and delivered (a toolkit MirWindowEventCallback event?)
<greyback> alan_g: to begin, have you seen this doc? https://docs.google.com/document/d/1IztlvbrJHmvLe3im1xe5WIKHkh4-SlBguokBCgXMgLo/edit#
<alan_g> greyback: was skimming docs but lacking overview. That's the starting point?
<greyback> alan_g: IMO yeah. It was roughly what we agreed on at the sprint in Montreal
<alan_g> greyback: thanks, will read before bugging you again
<greyback> alan_g: np
 * alan_g wonders how to represent "list of drag surfaces + origins"
<dandrader> alan_g, does a mir_buffer_stream_swap_buffers_sync ever time out? I'm debbuging a situation where I have an internal client (mirclient run in a thread) gets stuck in mir_buffer_stream_swap_buffers_sync() forever while because server is unable to drop buffers from it. that all happens when I'm trying to close that client.
<alan_g> dandrader: no timeout AFAIK
<alan_g> greyback: quick one I see "A list of drag surfaces + origins" in one of the diagrams. Is this buffer stream(s) + hotspot(s)? Why is there a list?
<greyback> alan_g: list because multiple items may be selected, and we thought it made sense to allow shell to decide how those items can be laid out
<greyback> we've not had much design input until recently
<greyback> alan_g: this is all I know: https://docs.google.com/presentation/d/1NEcPwodymSAjvsUGWlDx7ocDLhs41edkPGq_MsA_BdM/edit#slide=id.g19dd5d1a07_2_23
<greyback> alan_g: also note there is a process diagram in there, which differs to the one in the doc I gave you. The differences have yet to be figured out and clarified
<greyback> I'm doing that right now actually
<alan_g> ack
#ubuntu-mir 2017-02-02
<duflu> Oh look, Mir 0.26.0 released to zesty!
<alan_g> greyback: I see you've opened the MirAL: Workspaces notes. Let me know when you've thought about it.
<greyback> alan_g: sure
<greyback> I'm chewing on it
<greyback> all the fancy unity8 workspace per display stuff should work ok
<duflu> I can see you hands waving from here
<duflu> your
<alan_g> Yeah, it took me some time to reach that division of responsibility too.
<anpok_> greyback: workspace per display is the way it should be..
 * duflu shrugs. Just do it well and see if the users agree
<greyback> well moving workspaces beteen displays is the more complex part of the spec
<greyback> but that can be done by simply keeping the workspace, and confining the windows on the desired display of that workspace
<alan_g> and we understand how to do that in "policy"
<greyback> right
<greyback> alan_g: does your spec allow for a window to exist *not* on a workspace?
<alan_g> greyback: yes, but the policy can add it to one in advise_new_window()
<greyback> alan_g: because I'd consider the collection of windows not on a workspace to be equivalent to a workspace
<alan_g> Yeah, I considered a default workspace, but I think it complicates things
<greyback> could someone here comment on the correctness of this: https://code.launchpad.net/~ted/ubuntu-app-launch/mir-26/+merge/316173
 * alan_g looks
<duflu> greyback: I'm going to EOD instead, but equally could you sanity check this? https://bugs.launchpad.net/ubuntu/+source/ubuntu-app-launch/+bug/1654915
<ubot5> Ubuntu bug 1654915 in Canonical System Image "[regression] ubuntu-app-launch doesn't launch apps any more" [Critical,Confirmed]
<dandrader> alan_g, oh no. mir 0.26 api revolution
<dandrader> alan_g, what replaces SurfaceSpec::for_normal_surface nowadays?
<alan_g> s/surface/window/g
<alan_g> s/Wurface/Window/g
<alan_g> s/Surface/Window/g
<dandrader> alan_g, oh, so it's WindowSpec::for_normal_surface. I would expect WindowSpec::for_normal_window
<alan_g> So would I...
<alan_g> dandrader: I can fix that in the next release (it isn't part of the ABI)
<dandrader> alan_g, ok
<greyback> alan_g: one question you may have missed: https://docs.google.com/document/d/12jA76Pfjjg9HgiAJGGeOOi5OavaQaio9637tNiCBAgo/edit?disco=AAAABG6ocYI
<alan_g> greyback: replied
<dandrader> alan_g, there's also miral::toolkit::WindowSpec::create_surface
<alan_g> dandrader: thanks. I must have missed checking that header.
<taiebot> Hey was reading about mir 0.26 is there anyway to test this on mako running rc-proposed ?
<alan_g> taiebot: if that's still vivid+overlay, then not supported.
<taiebot> alan_g: yep sadly still vivid+overlay.
<alan_g> taiebot: I know it's a frustrating transition, but we have to focus our limited resources on the future: 16.04LTS+overlay and 17.04
<alan_g> greyback: just checking I've understood - input method windows don't (shouldn't) get input focus ever?
<greyback> alan_g: for the simple case of the OSK - yes. For more general cases, I'm not 100% certain, but I think os
<alan_g> Sounds right, just checking as I'm not 100% either
<alan_g> Surprised you didn't MP the fix, bug report reads like you found the line that's wrong.
<dandrader> alan_g, how do I set the initial MirWindowState using miral::toolkit::WindowSpec?
<dandrader> alan_g, more specifically, I wanna create a fullscreen window
<dandrader> alan_g, I guess it's missing a wrapper for mir_window_spec_set_state() ?
<dandrader> alan_g, reported a bug
<alan_g> dandrader|afk: there are missing wrappers, but in any case you can use it with mir_window_spec_set_state() - as the first argument
#ubuntu-mir 2017-02-03
<duflu> Wow. Easier to launch and debug Unity8 standalone than I expected. Win.
<duflu> greyback: Launching unity8 standalone looks different. Missing pulldown, and now inexplicably in tablet mode too. How to I reset it to look like a proper desktop login?
<duflu> Also how to dismiss the tutorial? :)
<greyback> duflu: "gsettings set com.canonical.Unity8 usage-mode Windowed"
<duflu> Cool ta
<greyback> strange that changed, I don't see any unity8 changes that would break those things on you
<greyback> dismissing tutorial? I think you just gotta be tutored :)
<duflu> Even stranger, sometimes the 12x slowdown Unity8 has compared to other servers just goes away
<greyback> 12x slower rendering? Input lag?
<duflu> greyback: In production U8 is 10ms per frame, but demo servers are 0.8ms. However in debugging sometimes U8 occasionally becomes just as fast
<greyback> unity8 is doing a lot more gl calls..
<duflu> I know and am trying to debug it. 10ms per frame on a high-end server is a problem..
<greyback> please let us know what you learn
<greyback> I've not done an optimisation pass of unity8 graphics in a good while now
<duflu> greyback: Was only curious because I wanted to do something new to clear my mind of the week. Now looking at SVG profile graphs of Unity8 but not yet understanding...
<greyback> duflu: this might help with high-level perspective, if you've not seen it before: http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph-renderer.html
<duflu> Oh I forgot I need debug syms for this to be readable
<duflu> And now it's the weekend
<greyback> duflu: have a good one!
<duflu> I give up. Bye
<anpok> sometimes?
<hikiko> hi alan_g
<hikiko> question :)
<alan_g> hikiko: well, what is the question?
<hikiko> where should I start looking to write a client for mir? miral api or mir client api?
<hikiko> is miral something like a simplified mir server or a totally different program?
<alan_g> hikiko: miral is, in principle, about writing servers.
<alan_g> Although, there's some C++ wrappers for the client API in there that we need to split out as they are proving useful.
<hikiko> yes, but I guess that if I need to have access to all mir features I need to run the mir server and start using the client API
<alan_g> For access to all the mir features you need to run miral-server. Unity8 is getting there (and does it more stylishly).
<alan_g> You writing C++ or C for this?
<alan_g> hikiko: http://voices.canonical.com/alan.griffiths/2016/11/25/testing-for-mir/ and, if you're writing C++ you may want to use miral's miral/toolkit headers that wrap the Mir client API.
<alan_g> We ought to move those headers into a separate package, and probably to Mir.
<alan_g> ...one day there will be time!
<hikiko> alan_g, does miral wraps every mir client function?
<hikiko> wrap*
<alan_g> nope, originally only the ones I happened to need. Then dandrader started using them too...
<alan_g> But they don't replace, just simplify use and inter-work just fine.
<dandrader> like C++ version of  the client API I guess
<hikiko> yeah
<hikiko> I need to port the ozone platform on mir
<hikiko> so I think it's better to use mir directly
<hikiko> I might need most of the client functions
<alan_g> it's fine to use mir_toolkit directly, but that isn't a reason to avoid miral/toolkit
<alan_g> hikiko: see for example, https://github.com/AlanGriffiths/mircade/blob/master/main.cpp#L141 - that calls a mir_toolkit API with a miral/toolkit Surface.
<hikiko> so alan_g you suggest that I run miral server
<hikiko> and I use miral where I can
<hikiko> and mir_toolkit
<hikiko> when miral doesn't have a wrapper?
<alan_g> hikiko: running miral-server is easy: sudo apt install miral-examples && miral-app
<hikiko> and when I need to use a mir_toolkit functionality that isn't wrapped by miral, will I be able to use it with miral-server?
<hikiko> or I need mir server for that case?
<hikiko> #include <miral/toolkit/surface_spec.h>
<hikiko> #include <mir_toolkit/mir_buffer_stream.h>
<hikiko> I see here you combine miral and mir_toolkit
<hikiko> so I guess that the miral-server can receive mir-server requests
<hikiko> is this correct?
<alan_g> miral-server is a mir server (and implements the most features)
<alan_g> the miral/toolkit headers just make using the client-side mir_toolkit more convenient.
<alan_g> They can be used in any mir client.
<alan_g> And  work against all mir server
<hikiko> so, if I find out that something I need desperately is not in miral-server yet I can just run mir keeping the mira/toolkit headers in my program?
<hikiko> I mean
<hikiko> the client will still be running on mir without changes?
<hikiko> (if that's the case then I go for miral :D) I want to be sure that if I use miral I won't have to switch to mir in the future because something I need from mir isn't there
<hikiko> or if I switch, what I've written in miral/toolkit will still be working
<hikiko> it seems that miral can do that, correct?
<alan_g> miral/toolkit depends only on the mir/toolkit API, it doesn't need a miral server, just any mir server.
<hikiko> then that's great :) I'll start with miral-server miral/toolkit and I'll use mir_toolkit when necessary and then we see if I need to swap servers :)
<hikiko> thanks alan_g
<alan_g> The easiest mir server to test with is miral-shell (used one of the scripts miral-app or miral-desktop). But you should also test with Unity8
<alan_g> hikiko: if you find stuff missing from the miral/toolkit wrappers, please MP it for everyone to use.
 * alan_g resolves logs bug 1661584
<ubot5> bug 1661584 in MirAL "split miral/toolkit out of libmiral-dev as it doesn't belong" [Low,Triaged] https://launchpad.net/bugs/1661584
<dandrader> alan_g, is thre any difference between mir_create_input_method_window_spec() and mir_create_window_spec()+mir_window_spec_set_type()+mir_window_spec_set_width()+mir_window_spec_set_height() ?
<alan_g> dandrader|afk: yes, it defaults buffer usage and pixel format
<alan_g> dandrader: in case you've not found it yet: https://bazaar.launchpad.net/~mir-team/miral/trunk/view/head:/include/miral/toolkit/window_spec.h#L124
<dandrader> alan_g, did you just push this?
<alan_g> A few hours ago - after the MP got approved
<dandrader> alan_g, I had to stop using miral::WindowSpec as it has no equivalent to mir_create_window_spec()
<dandrader> alan_g, besides some other methods
<alan_g> miral::WindowSpec spec{mir_create_window_spec(...)}
<dandrader> alan_g, and going back and forth between miral::WindowSpec and MirWindowSpec makes the code confusing
 * dandrader looks
<alan_g> You can use miral::WindowSpec anywhere you use MirWindowSpec*
<dandrader> alan_g, ah, you call mir_create_window_spec() WindowSpec::for_changes in miral. a bit confusing
<alan_g> Well, that is the original intent. It is a PITA to use it to create things as it doesn't init various default values
