#ubuntu-mir 2013-11-11
<duflu> RAOF: What's the preferred place for Mir-Mesa changes? SRU-style patches to archive? Or are we still using git somewhere?
<duflu> alf_ ^ ?
<alf_> duflu: I usually create pull requests for https://github.com/RAOF/mesa (egl-platform-mir branch, which is the default)
<alan_g> duflu: re recent regression. I was wondering if changing advance_client_buffer() to swap_buffer(BufferHandle&) so that the handle could be released in the implementation before calling flag_for_render() would make the code clearer. (BufferHandle& would be a single-owner, move-only type, not the shared_ptr we have now - that too is an accident waiting to happen). What do you think?
<alan_g> alf_: have you headspace to review https://code.launchpad.net/~alan-griffiths/mir/fix-Surface-hierarchy-break-render_surfaces-dependency-on-BasicSurface/+merge/194551
<alf_> alan_g: sure
<alan_g> greyback: I'd like to get rid of the ugly code I wrote last week. Could you check this out? https://code.launchpad.net/~alan-griffiths/unity-mir/we-dont-need-SurfaceBuilder/+merge/194558
<greyback> alan_g: oh yay
<greyback> alan_g|lunch: approved, thanks
<kgunn> Mirv: ping
<kgunn> Mirv: in case you come back i'd like to land a mir update and its related dependencies (rebuild)
<kgunn> Mirv: i'll send you a mail....but i won't top approve till you give me the go ahead
<alan_g> kgunn: which changes are you landing. (Just wondering: I'm not very bothered as long as those from the week before last land.)
<kgunn> alan_g: right...its actually equivalent to landing rev 1192 from the development-branch into trunk/trusty
<kgunn> alan_g: just need someone from release team to show me some love
<alan_g> kgunn: I hope you get it. (We love you here)
<kgunn> :) thanks...i was starting to develop a complex alan_g
 * alf_ is getting tired of launchpad timeouts
<Mirv> kgunn: hi. it was added for today's landing plan so it should be ok (as long as also unity-mir and unity-sytem-compositor also build against the updated mir), but since the CI move is still ongoing cu2d is down
<Mirv> kgunn: I'll check the situation again in the morning and start the PPA rebuilds + testing if systems functional
<kgunn> Mirv: ok...so i should go ahead and top approve all those MPs ?
<Mirv> kgunn: feel free, I adjusted the commit message of mir a bit (should be fine enough, file the debate probably continues with didrocks later on how to handle the commits etc)
<kgunn> Mirv: :) thanks
<racarr> Morning
<alf_> racarr: Hi!
<rsalveti> how hard would it be to use xmir on top of android drivers?
<rsalveti> just in case someone still wants to use x11 with libhybris + mir
<ogra_> ++
 * ogra_ would be happy to use xmir on his chromebook 
<racarr> rsalveti: Not conceptually hard, you could have an X11 DDX based on EGL (and which does 2d accel,etc via GL)
<rsalveti> kind of https://github.com/axeldavy/xf86-video-wlglamor
<racarr> As far as implementation goes, currently it works based on knowing that mir is givingout GBMbuffers, and importing these in to the existing
<racarr> ati, nvidia, etc DDX
<racarr> yes verymuch like that ;)
<racarr>  </end-lunch>
<kdub> stride detective is no fun
<kdub> but that mali branch of mine is good-to-review now
<racarr> why arent things merging anywhere
<racarr> unity-mir trunk cant build
<racarr> err well unity-mircant build anyway
<racarr> against dev branch
<racarr> grr :p
<RAOF> kdub: Hey, does android have udev?
<RAOF> rsalveti, ogra_: A generic glamor-using Mir EGL DDX is on the radar, but I don't think anyone's got time blocked out to do it.
<kdub> RAOF, i think so
<RAOF> Sweet.
<RAOF> That'll make input that much easier.
<kdub> oh actually, i take that back :/
<kdub> yeah, it does not, just has some android-specific init files
<kdub> RAOF, but our ubunt touch images might?
<kdub> i'm actually not sure... stock android doesnt have it
<RAOF> Grr.
<RAOF> Sweet!
<RAOF> âudevadm --info --export-dbâ dumps roughly what I'd expect on the N4
<kdub> great :)
<RAOF> Bitchn. And âudevadm monitorâ shows events happening.
<RAOF> I won't need two separate input discovery backends, or two separate default configuration stores! Yay!
<kdub> yay indeed :)
<racarr> how doI get stdout/stderrof apps run from autopilot...
#ubuntu-mir 2013-11-12
<kdub> hmm, none of our top-approved things have landed today
<kdub> good morning duflu
<duflu_> kdub: Hi
<duflu_> kdub: Same thing happened Friday-to-Monday
<racarr> unity-mirisnt landingeither
<racarr> also unity mir doesnt build against dev branch
<racarr> also the sky is falling.
<kdub> http://www.savagechickens.com/2013/01/jenkins.html
<duflu_> kdub: I'll land them all manually
<duflu> Back soon
<ogra_> RAOF, android uses ueventd ... but in our setup where we run an android container under ubuntu, the ubuntu side has udev and can monitor the events without issue
<ricmm> alf_: ping
<alf_> ricmm: hey
<greyback> alf_: pings.push_back(greyback)
<ricmm> lol
<ricmm> alf->pings.pop_back()
<ricmm> I need 5 min
<ricmm> greyback: go
<greyback> alf_: just looking for some high-level advice. I had Qt rendering 1 frame successfully as a Mir compositor. But it crashes around the swapBuffer (DisplayBuffer::post_update) call, with a pretty useless stack trace
<greyback> alf_: this is the sort of backtrace: http://pastebin.ubuntu.com/6405348/. The __GI_abort suggests to me an exception is being thrown, but I can't catch it in my code.
<greyback> what would you recommend me do? Step through Mir code? Or track the GL calls with apitrace? Suggestions welcome
<alf_> greyback: Is Mir built with debug symbols?
<ricmm> so many threads
<greyback> alf_: I'm using the last release, and dbg symbols are installed
<ricmm> what sits at 0x4178671c?
<ricmm> I'm gonna go ahead and guess one of the android GL blobs
<greyback> yep
<greyback> so that hints to me some bad GL call
<alf_> greyback: why aren't you developing on the desktop? ;)
<greyback> alf_: because it seems every time I try, I lock myself out of X completely :)
<greyback> alf_: should I? Then I'd be using the usual gbm drivers,, which are probably easier to debug, I guess
<alf_> greyback: That would be my proposal... do you have a laptop you can use as an ssh terminal (or the other way around)?
<tvoss> greyback, seems to be the snapshotter is waiting ... just a wild guess: could you temporarily disable it?
<greyback> tvoss: aye, that was an idea I had too
<greyback> alf_: yep, ok, I'll do that so
<alf_> greyback: in case you continue on the phone, ensure you have -dbg symbols/ddeb packages for all major packages in the stack (e.g. stdc++, qt), since on arm not only you don't get symbols, the backtrace is cut short...
<alf_> tvoss: greyback: FWIW, it's normal for the snapshotter to just wait...
<tvoss> alf_, yup, agreed: as I said, just a wild guess
<greyback> alf_: ah, that's interesting. I thought short BT was only due to corrupted stack. Nice tip, thanks
<ricmm> greyback: I would advise against doing this on the desktop
<ricmm> greyback: as it wont be the first platform to use it
<greyback> ricmm: that was my original motivation
<ricmm> you know my feelings on these kind of things, and from experience we know where it can take us :)
<ricmm> alf_: so my question went in another direction
<ricmm> kdub's investigation of n7 showed that screenshotting is causing it to crash
<ricmm> filling the texture from the buffer seems to be blowing everything up, the screen starts to flicker and it stops getting update
<ogra_> ricmm, screenshotting crashes maguro too ... fwiw
<ricmm> what screenshotting
<ricmm> the shell's running apps thing?
<ogra_> no, taking a screenshot :P
<ricmm> screencap on adb?
<ogra_> ignore, me, we obviously mean different things
<ogra_> mirfbdump
<ricmm> got it
<ricmm> I dont have that one :)
<ogra_> its a script from QA :)
<ricmm> ok
<ogra_> ricmm, http://paste.ubuntu.com/6405471/
<ogra_> works well on mako ...
<alf_> ricmm: so, if you disable the glReadPixels() call then everything continues to work ok (apart from getting invalid snapshots)?
<ricmm> trying that
<ricmm> I disabled the whole path
<ricmm> sec
<ricmm> alf_: yup, works fine with glReadPixels out
<ricmm> well, not fine, but you know what I mean
<alf_> ricmm: well, that indicates a driver issue, i.e., a glReadPixel call shouldn't mess up the system...
<alf_> ricmm: what happens if you enable only the GL_RGBA read pixels path?
<ricmm> alf_: still dies
<alf_> ricmm: any errors logged after this by the driver (or does glGetError() say something)?
<ricmm> alf_: no GL errors, no
<ricmm> seeing something weird tho mmm
<ricmm> sec
<greyback> alf_: sorry this sounds stupid, but I'm confused. On my laptop (this machine, has X running), I switch to VT1, run "mir_demo_server_shell&" - the screen does not black out or anything. I expected that it should, no?
<alf_> greyback: sudo ?
<greyback> then I ssh in to kill mir_demo_server_shell, however now all key events don't get to the VT
<greyback> sudo
<greyback> damn
<greyback> can we not have things fail if they don't have permission?
<alf_> greyback: yes, ideally they would fail but just get you back to a useful VT. There seem to be some failure modes that mess up our tear down.
<mterry> racarr, hello!  I'm back from an American holiday and am looking again at those issues from the sprint.  Are you still focused on scenegraph?
<greyback> alf_: even with sudo, it doesn't seem to work. mir_demo_server_shell just locks my machine, and killing it leaves it in unusable state
<alf_> greyback: what graphics card and driver are you using?
<greyback> alf_: intel sandybridge
<alf_> greyback: can you try running with gdb and 'catch throw'?
<greyback> alf_: ok.
<ricmm> alf_: this thing is still blowing up, no GL error and nothing from the driver in logcat
<ricmm> Tegra has a bunch of weird issues, this might be one of them
<ricmm> I know they dont support pbuffers, do we use that anywhere in the screenshotting path?
<ricmm> 1/10 times it works
<tvoss> ricmm, sounds racy
<ricmm> it does
<alf_> ricmm: yes, on android we create a EGL pbuffer as a dummy surface for the EGL context
<ricmm> for the shared based context?
<ricmm> base*
<alf_> ricmm: For all "dummy" context including the shared one so we can make them current. Can you check if "EGL_KHR_surfaceless_context" is supported?
<alf_> ricmm: one thing you could try is to make all instances of eglMakeCurrent() in android_display.cpp take 'EGL_NO_SURFACE,EGL_NO_SURFACE' instead of the dummy egl surfaces.
<alf_> ricmm: so basically in AndroidGLContext::make_current() and AndroidDisplay::AndroidDisplay()
<ricmm> right, will try
<ricmm> I think it does support surfaceless_ctx
<alf_> ricmm: ok, if using surfaceless contexts fixes snapshotting it's an easy fix to query the extension at runtime and act accordingly.
<kgunn> mterry: you're a bit early for racarr ...and he got sidelined by a performance regression, but he was back to working on the autopilot input bug for mir on mir
<mterry> kgunn, early for racarr?  he lives in UK right?
<mterry> Well, I can continue my own investigation until he can get back to me
<ricmm> mterry: CA
<mterry> ricmm, kgunn: aha...  For some reason my memory of the Oakland sprint was that it was in London.  Yikes...
<ricmm> ;
<kgunn> mterry: haha, yeah...and i'd like you and he to continue that thread
<mterry> kgunn, yar, for sure
<kgunn> Mirv: didrocks ...so with ci off, what's the recommended for the mir update to trunk ? manual land ? or just wait?
<didrocks> kgunn: better to wait, as we don't have dailies as well, we can't land it
<kgunn> didrocks: ack, thot so...just double checking
<didrocks> kgunn: I put Mir on the first thing in the list FYI
<ricmm> alf_: so it supports it "theoretically"
<ricmm> but it blows up the makeCurrent
<ricmm> so, it really doesnt :)
<ricmm> tegra is great
<greyback> alf_: if I ssh into a laptop, can I run mir via ssh? Must it be from a VT?
<alf_> greyback: you just need to have a VT active and use sudo, but it should work (that's how I do it)
<greyback> alf_: yeah. It used to work for me a few months back too
<greyback> sorry, "it" = running from VT. Running from ssh I didn't think would work either
<alf_> ricmm: I just saw that in android_display.cpp we are requesting a config with just EGL_WINDOW_BIT (no EGL_PBUFFER_BIT). What happens if you add EGL_PBUFFER_BIT (EGL_WINDOW_BIT|EGL_PBUFFER_BIT) ?
<alan_g> greyback: if you're running from ssh you need to specify --vt
<kdub> ricmm, alf_ so we're thinking that the nexus 7 doesnt support pbuffers?
<ricmm> whats the best way to confirm that? this comes from reading somewhere a comment that said tegra doesnt play nice with pbuffers
<ricmm> but I cant find the wording in any official doc
<ricmm> it certainly doesnt support EGL_KHR_surfaceless_context
<kdub> i think checking that the config has EGL_PBUFFER_BIT is good... i'll try
<ricmm> kdub: hmm tried here
<ricmm> worked the first attempt but exploded with the second app
<ricmm> checking again
<kdub> alf_, with the screenshotting, should we be using the OES functions? o.O
<kdub> like, glBindFramebufferOES
<alf_> kdub: In OpenGL ES 2.0 the framebuffer extensions was merged into core so the suffix was dropped
<kdub> ah, i kinda felt i was missing a data point like that
<kdub> i just saw sf using all these OES functions to do screencap, but since they were merged, that should be fine
<alf_> kdub: 18:11 < alf_> ricmm: I just saw that in android_display.cpp we are requesting a config with just EGL_WINDOW_BIT (no EGL_PBUFFER_BIT). What happens if you add EGL_PBUFFER_BIT (EGL_WINDOW_BIT|EGL_PBUFFER_BIT) ?
<alf_> kdub: since we are creating pbuffers with this config we should ensure we choose a config with EGL_PBUFFER_BIT
<alf_> kdub: (not sure if it is related with what ricmm is seeing)
 * kdub is still trying to configure unity-mir but
<kdub> ricmm said that didn't help
<ricmm> doesnt help
<ricmm> and thats generic enough, it would blow up in other cases
<ricmm> this is a tegra-specific thing that has to do with the way we take the screenshot
<ricmm> works for SF, not for us
<racarr> microusb bit the dust
<racarr> brb
<kgunn> racarr: ping
<kgunn> racarr: was just trying to run the egltriangle demo client per the instructions http://unity.ubuntu.com/mir/using_mir_on_pc.html
<kgunn> racarr: but remembered we moved the mir socket...not sure how to now
<kgunn> racarr: oops....nvmd....i just didn't sudo
<racarr> kgunn: :)
<kdub> what is up with jenkins? i noticed nothing was landing yesterday, but today, everything has landed from yesterday
<xnox> it's been down, due to DC move.
<xnox> not sure if it's fully up to speed yet.
#ubuntu-mir 2013-11-13
<greyback> hi folks, Mir on my desktop is failing with this: inkerlinker.c:1095| ERROR: Library '/system/lib/libGLESv2.so' not found
<greyback> alf_: ^^ isn't that an android driver?
<greyback> never mind, had libhybris installed
 * ogra_ wonders what an inkerlinker is ... and which color the ink actually has :)
<greyback> alf_: ping
<greyback> alf_: unping
<tvoss> lol
<greyback> tvoss: just fyi, have figured out the crash I was having. I was trying to fetch display information (calling the_display) before I'd started the mir server. That caused the_display to be called twice, which set up a context twice
<tvoss> greyback, ack
<alan_g> tvoss: Does this look right to you? https://code.launchpad.net/~alan-griffiths/unity-system-compositor/fix-local-build/+merge/195063
<tvoss> alan_g, approved
<alan_g> you didn't even test it.!
<tvoss> alan_g, kinda obvious that it is correct
<davmor2> tvoss: doesn't mean it works though :P
<tvoss> davmor2, agreed, but this is really obviously a correct fix :)
#ubuntu-mir 2013-11-14
<RAOF> Oh, *that's* what valgrind is complaining about!
<mickgardner> I have a couple of questions with regards to Mir if anyone is able to answer (more high level than code level...):
<duflu> mickgardner: Yes, the Australian shift is online at least :)
<mickgardner> 1. When is Mir currently scheduled to be released as stable into PC land? (or is it already?)
<mickgardner> :-) Melbourne here...
<RAOF> Depends on what you mean, really.
<RAOF> We've had a number of releases :)
<duflu> mickgardner: Mir technically released for real in Ubuntu 13.10. The packages are not installed by default though. "Stable" is something we're always improving
<RAOF> Probably what you mean, though, is âwhen will I be able to use Unity8 on the desktopâ
<mickgardner> okay then lets ask number 2 and get back to 1. duflu...thats fine.
<mickgardner> 2. I'm developing a multi-seat, multi-touch table based on Linux.
<RAOF> To which the answer is âshould be soonâ - AFAIK the current plan is Unity8 as an opt-in for 14.04.
<mickgardner> I want to be able to have multiple inputs
<mickgardner> on the screen at the same time.
<mickgardner> apologies if this if vague...
<duflu> mickgardner: Mir's multi-touch is working well right now. Although it's only well-tested on the phone/tablet
<RAOF> You mean something like multi-pointer X?
<mickgardner> yes basically.
<duflu> ... and in theory it accepts all input devices simultaneously
<mickgardner> I guess the main use case here is:  Two browser windows open, each person typing in something to their browser window at the same time (using some sort of on screen keyboard).
<RAOF> I don't believe that anything in Mir prohibits that.
<RAOF> Hm, actually, maybe it does.
<duflu> mickgardner: The code is there already to handle multiple pointers at once. What's missing is (1) multiple cursors drawn on screen and (2) multiple simultaneous focuses
<RAOF> And it'd need a shell that supported those features, too.
<duflu> Actually (1) isn't missing if you just mean touch :)
<duflu> and (2) is probably irrelevant if you just mean touch.
<duflu> I think drag-to-scroll would become very confused in the multi-user case. That would need some work
<duflu> Maybe...?
<mickgardner> Thanks guys!
<mickgardner> sorry, multi-tasking here...
<RAOF> Multiple keyboard foci *is* something that'd need support.
<duflu> mickgardner: No problem
<duflu> RAOF: Sounds like keyboards are not involved anyway
<RAOF> OSKs are.
<duflu> RAOF: Oh, oops. Yes, still true for OSK
<alan_g> didrocks: I'm not sure I understand the current process for updating lp:mir so I'm asking what I hope is a simple question. There's a change needed to avoid lp:~mir-team/mir/v0.1.1 breaking lp:unity-mir can we just merge that into the proposed branch and re-top-approve, or is there anything else needed?  https://code.launchpad.net/~alan-griffiths/mir/urgent-fix-unity-mir-build/+merge/195232
<alan_g> didrocks: (repeated in case you missed it) I'm not sure I understand the current process for updating lp:mir so I'm asking what I hope is a simple question. There's a change needed to avoid lp:~mir-team/mir/v0.1.1 breaking lp:unity-mir can we just merge that into the proposed branch and re-top-approve, or is there anything else needed?  https://code.launchpad.net/~alan-griffiths/mir/urgent-fix-unity-mir-build/+merge/195232
<alan_g> alf_: can you check this MP?  ^
<alf_> alan_g: looking
<didrocks1> grrr connexionâ¦
<didrocks1> 16:07:33  didrocks | alan_g: just ensure all branches with MP set to approved are coherent
<didrocks1> 16:07:46  didrocks | meaning if there is an ABI break, everything has version bumped and so on
<didrocks1> 16:07:53  didrocks | once the CI will be back, things will get merged again
<alan_g> didrocks: thanks
<alan_g> didrocks: (repeated in case you missed it) thanks
<alan_g> ;)
<didrocks> yw! ;)
<alf_> alan_g: ok, validated fix locally
<alan_g> alf_: thanks - if you approve then I'll merge into v0.1.1
<alf_> alan_g: ok, top approved
<racarr> Morning
<tvoss_> kdub_, ping
<kdub_> pong
<mterry> greyback, hello!  I have to run out for a little errand, but I wanted to ask you a question that I've started looking at.  It seems that in nested mode, I'm seeing crashes in unity8 when using right-swipe or left-swipe *only* when an app is focused.  Does that make any sense?
<mterry> I can answer questions or read feedback in a bit.  Just wanted to start your brain thinking
<greyback> mterry: nothing obvious comes to mind. dandrader would be a better person to ask about this
<mterry> greyback, ah OK.  dandrader ^ then  :)
<kdub_> mterry, greyback i know the focus mechanism has changed a bit, maybe needs a recompile or something?
<greyback> he understands the edge swipe detection code. It's black magic as far as I'm concerned :)
<greyback> kdub_: good point. mterry, did you recompile unity-mir
 * greyback recalls unity-mir fails to compile against mir10
<mterry> kdub_, greyback, I'm running mir-in-trusty recompiled for extra debugging
<mterry> so it shouldn't cause a problem with trusy unity-mir
 * mterry has to run
<greyback> ok
 * dandrader reads the backlog
<dandrader> mterry, greyback, hmm, I don't think the edge gesture code itself has anything to do with the crash...
<greyback> mterry: I guess a backtrace would help
<racarr> lunch
<racarr> Back
<mterry> back, want to test something first, then will try for a backtrace
<kgunn> kdub_: nice work on n7
<kgunn> mterry: hey...just been a few days...any luck on unity/mir-on-mir ?
<kdub_> thanks kgunn!
<mterry> kgunn, a little bit.  I figured the problem with autopilot not working at all.  Now I'm seeing a crash when you've got an app open, but you swipe the launcher in or swipe from the right...
<mterry> kgunn, working on getting a trace
<mterry> racarr, speaking of nested mir, did you get a chance to look at the u-s-c branches?
<mterry> kgunn, performance numbers seem fine so far (was waiting on autopilot fix to get in-use numbers)
<kgunn> mterry: "seem" = eyeball ?? (still a good sign even if so)
<mterry> kgunn, no, using 'time' to time autopilot runs
<mterry> kgunn, I'll add the numbers to the merge request, but first these crashes are stopping me from running the unity8 tests to completion  :-/
<mterry> Also, they are crashes which are bad in their own right.  :)
<kgunn> uh-oh mterry ...you mean just crashes due to unity?
<mterry> kgunn, not sure why yet.  But the unity8 process crashes, yeha
<mterry> kgunn, only seen on nested so far
<mterry> kgunn, so many yaks!
<kgunn> mmmm, i'll leave you be to debug mterry
<mterry> kgunn, sorry it's taking so long, but progress is being made, albeit slowly
<kgunn> hey...as long as you guys are on it...i got faith
<mterry> kdub_, greyback, racarr: hey Mir folks.  the crash I'm seeing with nested Mir and swiping from right is a thrown "cannot bind buffer to texture without EGL context".  Ring any bells or do you want full core?
<kgunn> alf_: ^ just in case no answer
<kdub_> eglGetCurrentDisplay is failing in mga::Buffer::bind_to_texture
<kgunn> kdub_: at about what time in your video is the crash from glreadpixels ?
<kdub_> that video does not have the crash
<kdub_> the bugreport has one though
<kgunn> ah... yeah saw that one...sorry, just misread ur mail....still...great work
<kdub_> mterry, make sure a context is active before trying to bind the buffer
<mterry> kdub_, only difference I'm doing is nested vs standalone.  Why might a context not be active?
<mterry> How is a context normally set active?
<kdub_> eglMakeCurrent()
<kdub_> mterry, are you doing development, or just debugging a crash that autopilot brought out?
<mterry> kdub_, guh, this looks like some 'fun' tracing of both nested and standalone and seeing where the fork is
<mterry> kdub_, the latter
<mterry> kdub_, this isn't even autopilot related
<mterry> kdub_, this is just when running nested
<mterry> (but autopilot hits it)
<mterry> kdub_, which of the various report modes do you recommend to debug egl?
<kdub_>  --display-report log will print out some information
<kdub_> but it sounds to me like we're missing a call to eglMakeCurrent somewhere
<kdub_> mterry, is the host or the nested server complaining?
<mterry> sure...  those look sprinkled throughout the code though
<mterry> kdub_, nested server (unity8)
<mterry> kdub_, hmm..  Will retest to make sure, but in nested mode, I don't get any output from the --display-report=log bits.  But in standalone I do get a chunk of them at the beginning
<mterry> kdub_, presumably the host server is managing those bits?
 * mterry adds the displayreport bit to u-s-sc
<kdub_> mterry, i know the host server display class has the logging implemented, not so sure about the nested server display class
<mterry> kdub_, ah interesting.  So there might be relevant code there, it might just not be logging it
<kdub_> mterry, it looks like... the display report is in the constructor of mgn::NestedDisplay, but the functions just aren't called
<kdub_> what concerns me is... (looking up line)
<mterry> kdub_, yup, u-s-c shows all the normal graphics output from the report
<mterry> as we'd expect
<kdub_> http://bazaar.launchpad.net/~mir-team/mir/trusty/view/head:/src/server/graphics/nested/nested_display.cpp#L280
<kdub_> i think you need the egl extension EGL_KHR_surfaceless_context
<kdub_> to do that... not sure if n4 has that extension
<mterry> kdub_, you're saying you think that line is being called, but with the wrong EGL flags?
<kdub_> mterry, in http://bazaar.launchpad.net/~mir-team/mir/trusty/view/head:/src/server/graphics/android/android_display.cpp#L79
<kdub_> mterry, i'm suggesting that
<kdub_> http://bazaar.launchpad.net/~mir-team/mir/trusty/view/head:/src/server/graphics/nested/nested_display.cpp#L280
<kdub_> fails silently
<kdub_> we should check that returns EGL_TRUE
<mterry> kdub_, hrm.  OK.  I can compile and test what that returns.  What was the bit about EGL_KHR_surfaceless_context ?
<kdub_> mterry, if that fails silently, we can just make a dummy pbuffer surface for the nested display's context
<kdub_> much like the host display class does
<mterry> kdub_, yup, it's returning EGL_FALSE.  OK, will try with a dummy pbuffer surface
 * mterry looks at how host display does it
<mterry> kdub_, thanks for the help, btw!
<kdub_> mterry, no problem
<mterry> kdub_, so you're suggesting that NestedGLContext should create a pbuffer surface and always try to use that instead of EGL_NO_SURFACE, right?  (sorry if being a bit obtuse, but GL is relatively new to me)
<kdub_> mterry, exactly :)
<mterry> kdub_, both of these calls, NO_SURFACE or dummy, seem like they aren't intended to work.  Are these just fallback settings?
<RAOF> Grr.
<RAOF> Do we really need -pedantic?
<kdub_> they're not fallback settings, we just want an context that has been shared with the display without a surface behind it
<RAOF> Every compiler we care about is happy to provide C99 designated initialisers.
<kdub_> RAOF, those would be nice, but i think pedantic is useful overall
<kdub_> if its really useful :) we could push a pragma for a file
<kdub_> i've wanted to do that for hwc in the past
<RAOF> What does pedantic catch that our other -Werrors don't?
 * RAOF is genuinely interested.
<kdub_> not sure
<RAOF> I don't believe (from the gcc manpage description) that it catches any *coding* errors. It explicitly *doesn't* guarantee that code that builds with -pedantic will build on any ISO C-compliant compiler, and having the clang build covers both of the compilers that we're reasonably likely to want to build with anyway.
<mterry> kdub_, BAM, no crash.  You're the best
<mterry> kdub_, will propose a branch
<kdub_> mterry, yay \o/
<mterry> kdub_, https://code.launchpad.net/~mterry/mir/fix-nested-crash/+merge/195320
<RAOF> mterry: Hey, was that crash happening on the desktop or on android?
<kdub_> racarr, do you know the magic build combo for the day (with unity mir?)
<mterry> RAOF, android
<RAOF> Ah, that'd be why.
<mterry> RAOF, didn't try desktop
<RAOF> It'd work on desktop.
<RAOF> kdub_: Do you think we should gate that codepath on the presence of EGL_KHR_surfaceless_context?
<kdub_> RAOF, alf_ has done some work with that
<kdub_> https://code.launchpad.net/~afrantzis/mir/offscreen-display/+merge/194906
<kdub_> about line 1094
<kdub_> we have many places of mg::GLContext in the code... should be shared
<kdub_> alf_ has a new GLContext for the offscreen display... and i have a branch that condenses the 3 different android mg::GLContexts into one
<kdub_> so after that, i think we should go and mop all of them up
<RAOF> Sounds reasonable.
#ubuntu-mir 2013-11-15
<RAOF> Heh.
<RAOF> Don't modify headers part way through a build.
<RAOF> Who'd've thought?
<sarnold> :)
<RAOF> Damnit. Now I'm thinking about hybrid graphics support, making a real DRMDevice class, and all that.
<RAOF> That's not what I need to do now!
<duflu> RAOF: P.S. I've made my pedantism point. If others approve the change, I won't block it.
<duflu> ping Mirv
<Mirv> pong duflu
<duflu> Mirv: If you're ready for it, do you want me to land Mir v0.1.1 to lp:mir ?
<Mirv> duflu: it seems the daily build system is not functional yet, so it wouldn't hurt to wait for the mergers to wake up either to get it automerged.
<Mirv> duflu: no harm in manual merge either, though
<duflu> Mirv: I'm happy to do it by hand, so long as there's no yelling about landing it too early... again
<Mirv> duflu: no, it's fine, mir is first on the list when systems are functional
<Mirv> so go ahead
<duflu> Mirv: Done
<duflu> Mirv: But it's still "unreleased": mir (0.1.1-0ubuntu1) UNRELEASED; urgency=low
<RAOF> Hurray for 500 line *partial* class definitions :/
<duflu> RAOF: You're not giving me happy Friday thoughts
<Mirv> duflu: yeah, that's how it should be
<duflu> RAOF: Wait, no. "definitions" can be huge. Only "declarations" should be small... (?)
<RAOF> Ah, sorry.
<RAOF> Hurray for 500 line *partial* class declarations :/
<alan_g> alf_: duflu - can I just confirm that it is just the name that concerns you with https://code.launchpad.net/~alan-griffiths/mir/fix-Surface-hierarchy-make-SessionContainer-private/+merge/194908?
<alf_> alan_g: yes (but I am not blocking)
<duflu> alan_g: Yes, just naming
<duflu> alf_: Same for Platform. A different name could solve that
<alan_g> alf_: ack, but if folks like the concept, but not the name then I know I should rename it. (Personally, I think the concept dubious and the long name is a consequence.)
<alan_g> duflu: "unblock_swap_buffer_requests_functor()"?
<duflu> alan_g: I don't mind aside from the length. Also just about out of time and have to run in a minute
<alan_g> duflu: sure, have a good evening.
<alan_g> alf_: if you like the name "force_threads_to_unblock_callback()" (as updated) then I'll consider duflu's concern over length addressed...
<alf_> alan_g: fine with me
 * alan_g hates bzr again
<kgunn> :)
 * alan_g knows what happens: "bzr mv file1 file2 file3 dest" moves the physical files, but only tracks one of the moves. The rest are treated as removes + unknown file in dest
 * kdub_ notes bzr quirk
<kgunn> alan_g: ok...that's weird...and sucks!...guessing you have to mv individually
<alan_g> kgunn: I guess I have to switch to git
<kdub_> git? we're switching to git? i heard we're switching to git
<kdub_> ;-)
<kgunn> :))
<greyback__> hey folks, am trying to use qtubuntu on my desktop. It fails though with this: http://pastebin.ubuntu.com/6422376/ <- looks like libEGL imports X11 stuff. Is there an EGL library for Mir I can install on the desktop?
<kgunn> greyback__: hey mir uses the egl associated with mesa
<greyback__> kgunn: I think I'm using it: eglInitialize () from /usr/lib/x86_64-linux-gnu/mesa-egl/libEGL.so.1
<kgunn> e.g. same thing as x11....when mir is run on the desktop
<kgunn> greyback__: just to be sure, the config for qtubuntu is expecting X ? or no...you're still using/expecting mir ?...just confused on your context (e.g. what the heck are you trying to do? :)
<kgunn> racarr: kdub_ ^....i am about to get on the phone...
<greyback__> kgunn: I am running mir_demo_server_shell. I want to run a Qt application that appears there.
<kgunn> greyback__: ah...so you are expecting a qt window running on like vt2 or something ?
<greyback__> kgunn: yep
<kgunn> greyback__: e.g. you've got unity7 running on vt7 ?
<greyback__> correct
<greyback__> I've mir_demo_server_shell running in VT1
<kdub_> hmm, we're using the patched mesa? ( with mir support )
<greyback__> I can bring up the mir_demos in VT1. But I wanted to try a Qt application
<kgunn> greyback__: awesome!
<kgunn> i was sort of farting around with something similar...but i failed :-/
<ricmm> farting!
<ricmm> interesting approach ;)
<kgunn> greyback__: it should be possible to render to a windowless surface tho
<kgunn> ricmm: its new...
<kgunn> :)
<ricmm> greyback__: what issue are you hitting?
<greyback__> ricmm: http://pastebin.ubuntu.com/6422376/
<ricmm> oh I see it
<ricmm> kdub_: sounds like no patched mesa
<kgunn> hmmm....i thot'd all the patched mesa was in the archive
<greyback__> am on trusty
<kgunn> greyback__: yeah...that shouldn't matter i think
<kgunn> RAOF: ^ just in case
<robotfuel> alf_: (if you are still around) I get std::exception::what: Couldn't get list of GL extensions when I try to use --offscreen, however the mir server runs when I don't use --offscreen
<racarr> greyback__: I have no idea but I can run you through my checklist for debugging that
<greyback__> racarr: I'm approaching my EOD. I'll ping you Monday for your help
<racarr> greyback__: Ok :)
<racarr> I wouldlike to see unity-mir runningon the desktop again
<greyback__> +1
<racarr> I think there aretimes...about once a week
<racarr> where I literally waste like 4 hours dealing with the phone
<racarr> to finally track down and test a fix to
<racarr> somethin tiny
<racarr> Anyway happy weekend
<kdub_> racarr, yeah, 'unity has a mir-related problem' has a high mental/setup context switch
<racarr> Every so often I think its a big impediment to development andI want to fix it but dont totallyknow how
<racarr> I think images that came with unity+mir+platformapi,etc built from dev branch
<racarr> and came with the build directories
<racarr> would be super useful :p
<racarr> like we build one every morning
<kdub_> yeah, a list of 'how to build  for today' is really what we need
<kdub_> also moving past building on the phone would help
<mterry> racarr, poke about the u-s-c branches
<racarr> mterry: ...pong sorry I am lost in shellrefactoring
<racarr> promiseI will review today :)
<mterry> :)
#ubuntu-mir 2013-11-17
<lip_> Hi there, was wondering if mir will be supporting legacy drivers ?
<lip_> anyone here ?
<lip_> Is mir already implemented in the daily builds of Ubuntu 14.04 ?
#ubuntu-mir 2014-11-10
<duflu> Fun fact: Almost all our lock contention is in locks created internally by boost::io_service.
<duflu> Don't know how that's useful information yet
<duflu> boost::asio::io_service
<anpok> how can you figure out which locks cause contention?
<duflu> anpok: apt-get install mutrace
<anpok> never heard of it
<duflu> anpok: http://0pointer.de/blog/projects/mutrace.html
<anpok> thx
<mlankhorst> but that's made by poettering and thus evil, wanting to replace valgrind
<mlankhorst> or something..
<anpok> mlankhorst: yeah it should be part of the init process and dump its findings to journald
<ogra_> init=/usr/bin/valgrind :P
<ogra_> (which links to mutrace ... which links to systemd)
<ogra_> systemd is utter nonsense anyway, everything should be a kernel module !
<ogra_> modprobe gnome-terminal
<mlankhorst> no, it should be in the cloud!
<ogra_> modprobe cloud then :P
<mlankhorst> I thought about moving the cloud to the cloud
<ogra_> innception !
<kdub> hello all
<alan_g> kdub: hello one
<kdub> :D
<alan_g> Forgotten sleep yet?
<kdub> no more than engineering college I suppose
<alf_> kdub: Hi!
#ubuntu-mir 2014-11-11
<duflu> Does anyone think we might be overloading the AsioMainLoop thread?
<duflu> I'm assuming it's just one thread. Looks like it (one per run())
<duflu> Especially if we submit jobs that might entail some blocking or IO, that might explain a lot
<duflu> Although that's an easy theory to test
<kdub> I got a failure with linking libmirprotobuf and building qtmir (sbuild/armhf), is this known?
<kdub> kinda looks like https://bugs.launchpad.net/mir/+bug/1388686
<ubot5> Ubuntu bug 1388686 in Mir "[regression] unity-system-compositor & qtmir FTBFS with Mir 0.9 source (libmirprotobuf.so.0 not found)" [Critical,Fix committed]
<kgunn> kdub: i hadn't heard of this
 * kdub investigates further
<kgunn> dandrader: do you cross build qtmir ?
<dandrader> kgunn, never
<dandrader> did
<kdub> I havent gotten a cross build working, usually use emulated
<kgunn> alf_: so reading duflu's mail about performance and thread blocking...am i wrong in thinking, there's not really a problem there?
<kgunn> i mean if a client blocks for some very small amount of time to feed the server that seems normal
<kgunn> or do i not understand what he's describing
<kgunn> (blocking on the server side for the full frame creation incl gpu time would be a problem)
<anpok_> hm could frame dropping wait on a lock
<anpok_> but it shouldnt drop in that use case..
<alf_> kgunn: I am not 100% sure either, but think what it came down to is that the thread blocking seen in the main loop is actually correct behavior (not waking up more often than required). The problem seems to be that we are not waking as often as we should in some cases.
<kgunn> ah, ok thanks...so it's not a blocking prob, it's a "remained idle and i expected it to run" prob
<alf_> kgunn: i.e. the delays in the main loop are the effect not the cause
<anpok_> ah run_once includes the wait for events..
<alf_> kgunn: yes, that's my understanding, but I haven't looked in depth
<kgunn> alf_: makes me wonder what glib spike would reflect
<kgunn> guess we'll find out as we conclude landing
<alf_> kgunn: unless there is a problem with either our asio or glib implementations, the behavior should be similar in terms of blocking
<alf_> kgunn: yes, getting close
<Saviq> hey folks, we got bug #1377332
<ubot5> bug 1377332 in unity8 (Ubuntu) "UI randomly freezes" [High,In progress] https://launchpad.net/bugs/1377332
<Saviq> Josh has been trying to look into it, but I managed to get it today
<Saviq> and there's an interesting trace: http://pastebin.ubuntu.com/8942307/
<Saviq> recvmsg seems stuck
<Saviq> in thread 29
<Saviq> I still have the phone in that state if there's more data that could be interesting
<greyback> Saviq: glib2.0 debug symbols please
<greyback> Saviq: I'd like to know what thread1 is doing
<Saviq> greyback, hmm thought I had them, coming right up
<Saviq> greyback, http://pastebin.ubuntu.com/8942429/
<Saviq> stuck on socket :/
<greyback> Saviq: hmm, UAL symbols just to be sure what point qtmir is blocking at
<Saviq> greyback, yeah, was just getting them
<greyback> :)
<Saviq> greyback, http://pastebin.ubuntu.com/8942460/
<greyback> what went wrong there
<greyback> Saviq: we need ted
<Saviq> greyback, fwiw I just pressed my last passcode number
<greyback> Saviq: is unity8-dash running?
<Saviq> greyback, yes, SIGCONT'ed even
<Saviq> greyback, with qtmir http://pastebin.ubuntu.com/8942528/
<Saviq> yikes that's a deep bt
<greyback> Saviq: it appears upstart isn't replying to the request UAL is putting to it, so everything blocks
<greyback> why that happens... I can't say
<Saviq> tedg, you about?
<tedg> Saviq, Depends on the question. Easy or hard?
<tedg> Hmm, that's not good.
<tedg> Not sure how we can block on the cgmanager connection.
<tedg> Saviq, How did you get there? Long running or a first time thing?
<ogra_> greyback, https://bugs.launchpad.net/bugs/1391076 ??
<ubot5> Error: ubuntu bug 1391076 not found
<greyback> ogra_: bug not found..
<ogra_> greyback, well, by the bot :P
<greyback> oh I can see it, duh
<ogra_> yeah, i didnt know what to file it against originally
<ogra_> sounds a bit similar and i wouldnt mind duplicating it
<ogra_> if someone confirms it is)
<greyback> ogra_: yeah. Lockup never easy for me to repro, will keep at it
<ogra_> though for me the whole UI stalls ... not sure that is what the bug describes
<ogra_> (and i dont have any process consuming much)
<Saviq> tedg, I was just using the phone for a bit
<Saviq> tedg, have stopped/started some apps
<Saviq> tedg, and then I tried to log in again, and after I tapped the last number in my passcode, it got stuck
<Saviq> tedg, so it was probably trying to resume an app
<tedg> Saviq, Hmm, okay. So it's probably talked to cgmanager before though, when all the other apps started.
<Saviq> tedg, definitely, uptime is 2:15
<tedg> Saviq, Do you have anything in your cgmanager log?
<tedg> Saviq, /var/log/upstart/cgmanager*
<tedg> Or cgproxy I guess, but I don't think it'd be there.
<Saviq> tedg, http://pastebin.ubuntu.com/8942980/
<tedg> Saviq, So assuming we can't find anything useful out from cgmanager, I think one of our only choices is to timeout on the connection. It'll be suboptimal, but at least Unity won't hang.
<Saviq> tedg, sounds like a plan, it will reconcile itself after you stop and start an app again anyway, right?
<tedg> Saviq, Yeah, we'd just miss a pause or resume, or worst case a connection on startup. But it seems to be rather rare.
<Saviq> tedg, yeah, definitely better than hanging
<tedg> It's going to make my code significantly less pretty though ;-)
<kgunn> Saviq: so is this the same bug as ogra_ posted ?
<Saviq> kgunn, symptoms are definitely the same
<Saviq> tedg, could you comment on bug #1377332 please and add tasks as appropriate
<ubot5> bug 1377332 in unity8 (Ubuntu) "UI randomly freezes" [High,In progress] https://launchpad.net/bugs/1377332
<tedg> k
#ubuntu-mir 2014-11-12
<RAOF> duflu_: https://code.launchpad.net/~raof/mir/dont-ask-downstreams-to-link-against-private-libraries/+merge/241475 is available for your FTBFS-fixing pleasure!
<duflu_> RAOF: Ah cool
<RAOF> duflu: I think you must have a libmirprotobuf.so symlink lying around somewhere on your filesystem.
<duflu> RAOF: Yes, it was without deb packaging having deleted it
<duflu> RAOF: I'll manually test your branch. If it works still then awesome
<RAOF> Feel free to verify!
<duflu> ... and that means something else fixed the bug
<RAOF> Quite possibly.
<RAOF> Or, alternatively, the bug is not actually actually a bug but was a local configuration error.
<duflu> RAOF: Doubt it. So far my methodology has raised build faults we otherwise don't discover till silos. I have documented it for Alan and Cemil. Maybe I should share wider
<RAOF> Possibly.
<RAOF> It's also clearly introduced build faults, so maybe we could improve it :)
<RAOF> s/introduced/failed to detect/
<duflu> RAOF: Although yes, I didn't expect our packaging scripts to delete libraries
<duflu> My environment did not replicate that fact
<RAOF> They don't delete libraries on the filesystem.
<RAOF> Even if you remove the rm from debian/rules your change would still be incorrect, because we didn't *install* libmirprotobuf.so anywhere.
<RAOF> (Although once you remove the rm you'd then fail the build because dh_install would tell you that you haven't installed libmirprotobuf.so anywhere, but we deliberately *don't* want to install libmirprotobuf.so)
<duflu> RAOF: Yep, I know. The question is why does it suddenly work going back to zero diff? I need to test
 * RAOF 's money is on the bug not actually being a bug :)
<duflu> The "completed separation of mirprotobuf" might be related
<RAOF> Indeed it could.
<RAOF> Oh, right.
<RAOF> That's probably it, actually.
<RAOF> Oh, no.
<RAOF> Maybe.
<RAOF> It's plausible :)
<duflu> RAOF: Well, my methodology is more plain. If it works only because of something in the deb packaging then that's a bug for other distros
 * duflu is testing
<RAOF> It's not that it only works because of something in the deb packaging, it's that it only works because you've got some detritus lying around in your build environment. That's a bug for everyone that's not you :)
<RAOF> Ooooh, right.
<RAOF> No, I see.
<duflu> RAOF: Unlikely. I'm very clean (always delete and start from fresh) with builds
<RAOF> Ah, right.
<RAOF> You install your build system-wide?
<duflu> RAOF: No, local installs
<RAOF> Ah. So you're never going to pick up problems with the packaging. Fair chop.
<duflu> RAOF: No, I'm intentionally avoiding the slow packaging :)
<RAOF> Hm.
<RAOF> We could probably make the packaging much faster by supporting nodoc...
<duflu> RAOF: Yep, basic library lookup failure. I am now fixing my method :)
<RAOF> Did you fail to set LD_LIBRARY_PATH=$HOME/.local/lib/x86_64-linux-gnu? :)
<duflu> RAOF: Apparently so. And the symbols in our libraries changed dramatically (no versioning to MIRCOMMON now)
<duflu> Always forget that implicit indirect symbol lookup step
<duflu> RAOF: BTW the x86_64-linux-gnu part vanished some time recently. That's nice, but intentional?
<RAOF> NoL
<RAOF> That would be a bug.
<RAOF> Oh.
<RAOF> No.
<duflu> RAOF: See: make install
<RAOF> That would be an artefact of the way you're building mir :)
<duflu> RAOF: OK, fair point. We could make that the job of packaging
<duflu> Which makes more sense
 * duflu still likes being able to build Mir and all downstream projects in 10 minutes
<duflu> If only CI could do the same
<RAOF> I think with a little tweaking you'll still be able to do that *and* do so in a clean sbuild environment.
<duflu> Yeah maybe. I like purity though. Meaning minimal dependency on tools. Helps to understand how everything works (or doesn't)
<RAOF> duflu: https://code.launchpad.net/~raof/mir/moar-timeouts/+merge/241499 addresses the CI failure, too.
<RAOF> Because reliably fast CI infrastructure is for suckers!
<RAOF> Hm. There doesn't seem to be any reason to not require setting a pixel format for a surface.
<RAOF> There's no codepath where you're like âyeah, I don't care what BPP my surface is, whether it's got an alpha channel or not, and what order the pixels are inâ...
<duflu> RAOF: It's a weird use case (e.g. changing video streams while keeping a single surface open), but on the other hand our logic supports switching on the fly perfectly, so why impose limitations?
<duflu> Imposing limitations actually makes it more complex
<RAOF> No, that's not what I mean.
<duflu> Sounds familiar :)
<RAOF> Even in that case you don't *not care* what the pixel format is.
<RAOF> You just want to be able to change the pixel format from the first format you cared about to the second format you care about.
 * RAOF is perfectly happy to allow changing pixel formats.
<RAOF> But you never create a surface going âI don't care at all what pixel format this surface hasâ. Because you're always going to render to it at least once :)
<RAOF> Heh. Or maybe we should make the default pixel format 1bpp. That'd show em'!
<duflu> RAOF: Actually that is a use case: Configure a GL window with rough requirements... and then let the system tell you what the chosen pixel format is
<RAOF> Except GL doesn't allow that.
<duflu> EGL even. Still... it's in the realm of possibility. And there's more likely a future use for it than a good reason to impose limitations needlessly
<duflu> yet
<RAOF> Hm. I guess our EGL layer _might_ be able to do that eventually.
<RAOF> I'm not entirely sure that's spec-compliant, though.
<duflu> RAOF: We're in charge of the /Mir/ spec. The only requirement is that it should support everyone else's specs too
<duflu> Somehow and eventually
<RAOF> Right, but you're use-case for âmaybe we don't need to specify a pixel formatâ is âit could be helpful for EGLâ and that behaviour is disallowed by the EGL spec, then it doesn't really seem like a reasonable use-case :)
<duflu> To say there will never be a toolkit/app that needs to do something is naive. Better to not close the door on future features until you need to
<duflu> Because it's worse to have to remove a limitation later, and admit the limitation was imposed without good reason in the first place
<RAOF> But on the other hand you *cannot* impose a new limitation in future without breaking clients.
<RAOF> It's much much less costly to loosen limitations that were initially too stringent than to tighten requirements that were originally too loose.
<duflu> RAOF: Sounds like the lazy man's way of saving and receiving free karma in future. But I think better if the API just works from day one
<duflu> Nobody thanks you when things *just work*. But it's still better that way
<RAOF> Just like it's naive to say that there will never be a toolkit/app that needs to do something it's equally naive to say that a shell will never need to enforce some behaviour.
<RAOF> And people thank you even less when you break their stuff :)
<RAOF> And âbut the shell can just disallow that behaviourâ is not a response. That means that the shell will not work with existing clients.
<duflu> RAOF: Yeah you can easily argue arbitrary limitations help for future platforms/drivers to fully implement the spec. But there still may never be a reason for the limitation to exist. You never know
<RAOF> Yes, that's true.
<RAOF> But the consequences for âoops, we restricted something too tightlyâ are much better than the consequences for âoops, we allowed something that we shouldn't haveâ.
<RAOF> My philosophy is conservative in that way: given that we can only think of marginal, niche uses for a feature that will be easy to add later but that will be very expensive to remove if it turns out to be difficult, we should choose the easy to fix problem.
<duflu> RAOF: I would err on the side of effort -- Do you have to write any additional code to limit the functionality in question? If you can't immediately justify why you're doing it then ideally don't
<RAOF> That's certainly a reasonable input to the decision, but I (obviously) think it's insufficient.
<duflu> RAOF: You also confuse future maintainers who then ask why the limitation (and test thereof) exists.
<RAOF> Not if that's a consistent pattern throughout the code.
<duflu> The presence of a test suggests reason. So I guess if you do have the limitation, at least don't enforce it by test
<RAOF> The reason is âwe can't think of any reason someone would want to do this, and it might impose significant costs down the line if we allow itâ.
<duflu> Then the limitation can be lifted and everything still passes unquestionably
<duflu> RAOF: Sure, just outline why the significant cost might exist
<duflu> I don't think there's much precedent for people wanting to make code less capable after it matures. Such things do happen, but usually only by accident
<RAOF> I think there's *lots* of precedent for wishing you didn't let users do things.
<duflu> RAOF: On another issue, if Jenkins fails again I will land your branch by hand
<RAOF> Oh, has it died again on the .pc thing?
<RAOF> Oh, not yet :)
<duflu> RAOF: OTOH I'm a fan of limited sized arrays to make APIs simple and then worry about expanding them later as required :)
 * RAOF was hoping to be lazy, let that land, and then his other MPs no longer have extraneous diff :)
<duflu> There's more to debate if the limitation makes things less simple
<RAOF> I think we also differ about what makes an API simple :)
<duflu> RAOF: It's mathematically unambiguous. Or so I thought. Then I met Sam who proposed his 100-character long function names made things easier to understand
<RAOF> 100 character function names suggest that a refactoring might be necessary :)
<duflu> RAOF: That was a refactoring :S
<RAOF> A conceptual refactoring.
<RAOF> On the other hand, modern tooling makes the cost of 100 character function names much less. It's possible they're justified in some strange cases :)
<duflu> I think there's a definite difference between horizontal and vertical code-readers. Not sure if there's much literature on the subject. I prefer the mathematical approach of use all the symbols and then invent new ones
<RAOF> That makes for a really hard codebase to dip into, obviously.
<duflu> Yeah, actually I prefer a compromise
<duflu> Just not function names that are longer than the width of the window
<duflu> Makes you laugh and cry all at once
<sgx1> hi, the Mir Spec wiki page is outdated, e.g. QMir is deprecated. can you update the page to include all the projects associated with mir and give us a picture of the current Mir stack?
<duflu> sgx1: That was bound to happen... We have so far avoided mentioning much about downstream projects but the best place would be to document things in the source code, which then gets mirrored on the web automagically: http://unity.ubuntu.com/mir/
<RAOF> That page is correct, except QMir is actually QtMir
<RAOF> duflu: CI success!
<duflu> RAOF: Are you sure about QtMir? I thought that was the server/shell only in there
<duflu> The docs refer to the client port
<duflu> I think?
<RAOF> wiki.ubuntu.com/Mir/Spec refers to both client and server side stacks.
<RAOF> And just as soon as the wiki lets me login I'll be updating that bit.
<RAOF> You know what? It'd be nice if Launchpad updated the MP diff when the merge-into branch changed.
<duflu> RAOF: Yes, but doesn't scale. Our infrastructure can't keep up already
<duflu> Woo, a profiler that *works*
<duflu> (sudo apt-get install google-perftools)
 * duflu is still amazed there's no adequate open source solution...
<duflu> Argh. OK, so Google's profiler is excellent. However it doesn't understand std::function (since Google doesn't allow such things in their code they don't care) :P And most of Mir's time is in std::function::operator
<duflu> So the best profiler is still only partially useful
<alan_g> Can you fix it?
<duflu> alan_g: I can only think of replacing suspicious functors with named functions
<duflu> But that's effort and it's already eating into dinner time
<alan_g> is it really std::function (not lamdas) it doesn't understand?
<duflu> alan_g: More to the point it seems to lose caller info for them. Then it wouldn't matter
<duflu> Are we omitting frame pointers?
<alan_g> That sounds like it ought to be a compiler option
<duflu> Yeah but we're not optimizing so they should be present
 * duflu forces it to be sure
<duflu> Google profiler is *useful* simply because it reports real time spent. Not CPU time used.
<duflu> ... or so some results indicate. If you take that literally then some functions that should be present are absent
<duflu> Ah yes, 69% in sleep_for()
<duflu> alan_g: Fun fact: The one consistently worrying result I get each time is that the compositing thread always spends around 30% of Mir's time destroying (releasing and replying about) TemporaryCompositorBuffer. I can get an instant improvement moving that to a new thread, but it's ugly
<duflu> 20% is the responding with buffers to the client, 10% is wasted by high lock contention in the same code
<alan_g> The client calls are typically blocking and completing on the composit thread? Interesting.
<alan_g> We can likely come up with a better design if we're sure that's a bottleneck.
<duflu> alan_g: Unexpected but that's correct. The last ref is released and the callback happens in the compositing thread, for each client
<alan_g> 69% in sleep_for() seems rather low
<duflu> alan_g: Other functions sleep also
<alan_g> Sure
<duflu> alan_g: The issue right now is, try to be even a little bit clever (like moving the response code into the thread pool) and the additional locking/context switching negates the benefit
<duflu> It's still slow
<alan_g> I guessed that. We *could* put the responses into a lock-free queue and have a thread servicing that.
<duflu> Yeah. Only a quick and dirty std::move of the render list into a thread without locking is working. And that's terrible to start a new thread each frame
<alan_g> BIAB
<greyback> alan_g: hey, I was digging into unity8 doing proper stack unwinding/emergency cleanup last night, and recalled a notion that you were reworking things to get rid of run_mir and just have server::run/stop. Is that still the case?
<alan_g> greyback: yes. I have a spike here: https://code.launchpad.net/~alan-griffiths/qtmir/migrate-to-mir-Server-API/+merge/240451
<alan_g> What you want is shown here: tests/acceptance-tests/server_signal_handling.cpp
<greyback> alan_g: ah nice
<alan_g> (That's mir trunk)
<greyback> alan_g: yep, that's what I need, thanks
<alan_g> yw
<greyback> alan_g: lp:mir is now the development branch?
<alan_g> It is (at last)
<greyback> great
 * greyback deletes
<ad-n770> good morning
<ad-n770> I'm trying to figure out the reason for a regression/crash I've got in Ubuntu 14.10 with one of our products
<ad-n770> the backtrace is like this http://pastebin.com/EqJA0Dy4
<ad-n770> which is triggered from dl = dlopen ("libclutter-glx-1.0.so", RTLD_LAZY);
<ad-n770> this is comming from a GStreamer plugin which and .so file also opened via dlopen
<ad-n770> I've tried to reproduce it with no luck from a regular executable
<ad-n770> it seems similar to https://bugs.launchpad.net/mir/+bug/1358698
<ubot5> Ubuntu bug 1358698 in mir (Ubuntu) "[regression] Test failure holding up all merge proposals: "File already exists in database: mir_protobuf_wire.proto"" [Critical,Fix released]
<ad-n770> and the issue isn't reproducible in Ubuntu 14.04
<alan_g> ad-n770: you're on a channel for Mir (see topic). Why do you think your problem is related to Mir? It doesn't appear in your backtrace.
<ad-n770> /usr/lib/x86_64-linux-gnu/libmircommon.so.2
<ad-n770> from frame #5
<alan_g> ad-n770: sorry, missed that
<ad-n770> do you know any trick to get debugging info for libmircommon and protobuf ?
<ad-n770> I'm here for suggestions on how to dig further on the issue
<ad-n770> mmm, I've to leave for a while now. I'll come back later on this
<alan_g> ad-n770: are you intentionally using mir? It isn't the default
<alan_g> ad-n770: the problem is happening in the protobuf support library and looks different to the bug you referenced. The latter was caused because protobuf errors if the same description is initialized twice - it doesn't segfault as your backtrace shows. But I don't know why clutter loads libmircommon (I know gtk has some /optional/ support for mir, but I don't know any details without digging)
<ad-n770> I'm not using mir intentionally
<ad-n770> the GStreamer plugin is Fluendo's VA decoder
<ad-n770> this is a plugin that does HW accelerated video decoding via  XvBA/VDPAU/VAAPI
<ad-n770> it also provides beside decoding GStreamer features for rendering on an XWindow or into a Clutter Actor
<ad-n770> the plugin uses dlopen in order to enable the features at runtime accordingly to the system capabilites
<ad-n770> the actual crash comes from this very early discovery when it tries to discover if clutter is available in the system
<ad-n770> the worst is that it causes nautilus crashes as per a customer report when it tries to generate thumbnails
<ad-n770> alan_g|lunch:  let's talk about it when you'll back
<ad-n770> alan_g: I'm back
<alan_g> ad-n770: I don't have much for you really. Does uninstalling Mir help? (I'm not suggesting it as a solution, just for adding a data point.)
<ad-n770> the think is that I haven't installed mir
<ad-n770> it's a freshly installed ubuntu 14.10 system
<ad-n770> an nothing installed on top of it a part of nvidia drivers
<alan_g> Mir is installed - although I don't know why. I don't have a fresh 14.10 installation to figure why, but it shouldn't be needed by the default stack
<alf_> ad-n770: alan_g: Could it be that what you are seeing comes from trying to load EGL drivers?
<ad-n770> maybe, I couldn't track yet the reason for clutter going into mir
<ad-n770> if I try to sudo apt-get remove libmircommon2 a lot of packages are going to be removed
<alan_g> ad-n770: For the debug packages https://wiki.ubuntu.com/DebuggingProgramCrash#Debug_Symbol_Packages
 * alan_g is curious which packages are installed by default with a dependency on libmircommon2
<ad-n770> ok, going to try get debug symbols and a better backtrace
<alf_> ad-n770: my bet is on EGL loading drivers to check what it can use, but let's see
<kgunn> ad-n770: curious, did you happen to install unity8-desktop-session ??
 * kgunn missed some of the backscroll
<alf_> ad-n770: hmm, I was wrong, ldd shows that libclutter-glx-1.0.so.0 brings in libmirclient/common
<ad-n770> kgunn: http://pastebin.com/2ZSZ34EF
<alf_> ad-n770: not directly, though
<ad-n770> new backtrace with debug info http://pastebin.com/f8uWFJ3d
<ad-n770> frame 5 is suspicious
<ad-n770> this=0x0
<alan_g> this=0x0 is always suspicious
<alf_> ad-n770: alan_g: so, libclutter-glx-1.0.so.0 depends on libgdk which depends on libmirclient, at least now we know why we load libmircommon
<alf_> ad-n770: alan_g: tells us nothing about the failure, though
<ad-n770> well I've debug symbols and source code on gdb now
<ad-n770> mmm, mir_protobuf_wire.pb.cc is generated
<ad-n770> I don't have source code for this one
<ad-n770> there's any way to get /build/buildd/mir-0.8.0+14.10.20141010/obj-x86_64-linux-gnu/src/common/protobuf/mir_protobuf_wire.pb.cc ?
<ad-n770> running  sudo apt-get build-dep libmircommon2 now
<ad-n770> if those help generated_database_->Add(encoded_file_descriptor, size)
<ad-n770> generated_database is NULL
<alf_> ad-n770: That's all deep in protobuf code. It seems that InitGeneratedPool() (through InitGeneratedPoolOnce()) doesn't run, which implies that perhaps protobuf has been setup and torn down in the same process before? Not sure...
<alf_> ad-n770: Is there an easy way to reproduce this locally?
<kgunn> desrt: hey there, so we were talking about the concept of reparenting windows, understand that gtk supports this...but does anyone actually use ?
<seb128> kgunn, desrt is on vac this week
<seb128> just as a fyi
<kgunn> ah
<greyback> kgunn: https://searchcode.com/?q=gtk_window_set_transient_for&loc=0&loc2=10000&lan=28&lan=16&lan=15
<greyback> whether those calls are all necessary or not, I don't know
<kgunn> right
<alf_> AD-N770: I've managed to reproduce the crash on my intel machine
<AD-N770> good
<alf_> AD-N770: I will take a deeper look tomorrow
<AD-N770> ok, thanks
<AD-N770> in any case I will write a test case too
<alf_> AD-N770: that would be great
<mlankhorst> bleh :P
<mlankhorst> Xmir standalone thingy working
<alan_g> kdub: you're not working on lp:1391923? (I need to fix that anyway)
<kdub> alan_g, I took a quick look, but have stopped
<kdub> so no
 * alan_g grabs it
<kdub> cool
 * alan_g wishes that C++ didn't think char const* -> bool is a better conversion than char const* -> std::string.
<alan_g> Which ultimately, is because string should be a builtin type, not a UTD.
<greyback> +100
<alan_g> kdub: fixed - https://code.launchpad.net/~alan-griffiths/mir/fix-1391923/+merge/241585
<AD-N770> alan_g, alf_: the issue is reproducible with http://pastebin.com/qzfHa547
<AD-N770> at the end it seems that our product is doing dlopen twice
<AD-N770> I will refactor our code to avoid it
<alf_> AD-N770: Your example code also fails when trying to load only libmircommon.so.1 , so it's certainly something wrong there, either because we are not using protobuf right, or because protobuf has a bug.
<alf_> AD-N770: thanks!
<alan_g> AD-N770: thanks
<alf_> alan_g: AD-N770: https://bugs.launchpad.net/mir/+bug/1391976
<ubot5> Ubuntu bug 1391976 in Mir "Loading libmircommon.so twice leads to a segfault in protobuf code" [Undecided,New]
#ubuntu-mir 2014-11-13
<alan_g> alf_: @glib-main-loop-signal-custom couldn't we get some of it under test? (Or is that addressed in a later MP?)
<alf_> alan_g: There are existing tests added with the previous implementation. Do you think we need something more?
<alan_g> It looks to me as though there's functionality added here without new tests. But maybe I'm missing something.
<alf_> alan_g: No new functionality is added in this MP, we are just re-implementing GLibMainLoop::register_signal_handler().
<alan_g> OK approved with caveat
<kdub_> alf_, have time for a re-review? https://code.launchpad.net/~kdub/mir/platform-operations/+merge/241563
<josharenson> After upgrading to 15.04, I get a black login screen.. anyone see this?
<greyback_> josharenson: I first thought after upgrade is always, are there PPAs installed that could break stuff
<greyback_> s/I/my?
<RAOF> josharenson: Unity8?
<greyback_> josharenson: check if lightdm is actually running
<josharenson> greyback_ its running
<josharenson> I can restart it too
<greyback_> josharenson: yet you saw no login screen at all?
<josharenson> nothing at all ,just a black screen
<greyback_> josharenson: is X running?
<josharenson> greyback_ yes
<josharenson> humm... startx did something
<josharenson> I see a desktop w/ no unity components
<greyback_> josharenson: output of /var/log/lightdm/lightdm.log and x-0-greeter.log could help
<josharenson> ok 1 min
<greyback_> ah lightdm never worked for you?
<josharenson> greyback, no it didnt... was using gdm
<josharenson> x-0-greeter.log "Failed to open /dev/null: Permission denied"
<josharenson> Permissions are 664
<greyback_> here too
<greyback_> but that's a strange error
<greyback_> RAOF: ideas?
<josharenson> I'm going to try making a new dev/null
<RAOF> That's a ridiculous error :)
<RAOF> So, I've been using 15.04 for a while now, and it's working fine for me.
<greyback_> josharenson: can you run "/usr/lib/lightdm/lightdm-greeter-session /usr/sbin/unity-greeter" as root?
<greyback_> output of lightdm.log might help too
<josharenson> greyback_ I'll try... recreating devnull did nothing (same symptoms, same error inthe log)
<greyback_> josharenson: I doubt you could boot without a valid /dev/null
<josharenson> greyback_ starting unity-greeter "Failed to connect to Mir: Failed to connect to server socket: No such file or directory"
<greyback_> josharenson: aha, it's trying to use Mir.
<josharenson> How do I make it use X?
<greyback_> josharenson: does this doc help? http://unity.ubuntu.com/mir/using_mir_on_pc.html
<greyback_> it has a 'if you wish to deactivate XMir' section
 * josharenson reads
<greyback_> do you have a /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf file ?
<greyback_> if so, stick a # in front of the "type" line
<josharenson> I don't have that file
<greyback_> :(
<greyback_> how about in /usr/share/lightdm/lightdm.conf.d/
 * ogra_ wonders how you got into that state in the first place
<ogra_> its not like we magically switch people to Mir on upgrades
<josharenson> greyback_ there are config files, but not for usc
<greyback_> mterry: you about? Would you know how to help?
<mterry> hmm
<mterry> uh...  I can't remember how this works on the desktop
 * mterry scratches head
<josharenson> Might just reinstall from a clean image...
<mterry> josharenson, do you have ubuntu-desktop-mir installed?
<greyback_> josharenson: maybe. If you try to remove mirserver, I wonder if it'll clean things up
<josharenson> ill try that
<RAOF> Yeah, removing libmirserver should do *something* :)
<ogra_> would be interesting to know what else that removes to see what dragged it in in the first place
<josharenson> ill keep you posted with what works
#ubuntu-mir 2014-11-14
<duflu> Glorious 1-frame lag compositing. I'll try to get it down to zero before Christmas :)
<alan_g> duflu: client of nested?
<duflu> alan_g: No nesting :)
<duflu> Just talking about system compositors
<alan_g> pity
<duflu> alan_g: Next week or so will get the compositor lag from 2 to 1 frame. Then will think about zero
<alan_g> Sounds like a plan
<duflu> And regretfully work around intel bugs
<duflu> They on guarantee rendering will finish if you glFinish() once or swap buffers _twice_.
<duflu> Crazy
<duflu> *They only
<alan_g> Have they accepted it is a bug?
<duflu> alan_g: Haven't reported anything. Only got the confidence that it is a driver bug this arvo
<alan_g> ack
 * duflu -> weekend
<alan_g> Have a good one!
<greyback_> alan_g|lunch: do trust sessions need an ordinary app in them? Or could a trust helper start its own trust session and that's enough. I'm thinking of future when OSK will be a trusted helper of shell
<alan_g> greyback_: I think they do: PromptSessionClientAPI.when_application_pid_is_invalid_starting_a_prompt_session_fails
<greyback_> alan_g: ok, that might be something we'll need to look at later.
#ubuntu-mir 2014-11-16
<robert_ancell> The Mir headers have no flag to check version right? I was looking how we can make GTK+ conditionally support new enum values
<robert_ancell> Trevinho, you're making GTK+ depend on unreleased Mir code and you haven't added any checks to configure.ac
<desrt> robert_ancell: i yelled at him for that a bit earlier :)
<robert_ancell> desrt, ah good
<desrt> (i think he's not around on account of it being sunday, though)
<desrt> jhbuild is currently broken :/
<desrt> also: not sure who acked Trevinho to push patches to gtk...
<RAOF> robert_ancell: We do not have such a flag, no. This sounds like a reasonable idea.
<robert_ancell> RAOF, I vote for the same as the GTK+ #defines for versions
<robert_ancell> they seem to work
 * RAOF shall whip up a branch providing such things.
<RAOF> I was going to say âHm, what about feature-flagsâ, but screw it. Versioning's simpler.
<robert_ancell> RAOF, yeah, featuring flags gets a bit out of control
#ubuntu-mir 2015-11-09
<bschaefer> slvn_, this is how it looks :)
<bschaefer> http://i.imgur.com/Vua6Iap.png
 * bschaefer looking into it
<bschaefer> it doesnt happen like that on the desktop...
<bschaefer> (and touch wasnt working)
<slvn_> bschaefer, this is bad, but this is because I provided a bad application
<bschaefer> slvn_, no, all apps
<bschaefer> even my own
<bschaefer> (using opengles2)
<bschaefer> not sure if those are software or what
<slvn_> then there is a bug :)
<bschaefer> yup
 * bschaefer looking into it
<bschaefer> tic tac toe: http://i.imgur.com/tLA6jtn.png
<bschaefer> there must be a reason :)
<slvn_> yep bad also ...
<slvn_> at least portrait/landscape orientation seems to work :)
<slvn_> (but there is the status bar ... would be great to be able to hide it, or to know its size/position)
<slvn_> also the colors seems wrongs. it's black and white ok, but there is some noise.
<bschaefer> slvn_, you've to set the surface to fullscreen
<bschaefer> to move the top bar
<slvn_> ok
<slvn_> for the Tic Tac Toe, some debug message are enabled .. it might help
<slvn_> maybe the resolution that I retrieve if wrong
<bschaefer> slvn_, ill use my own for now since i've the source :)
<bschaefer> yours will be the test after a fix
<slvn_> ok !
<slvn_> bschaefer,  Maybe that can help : when we tested the same apps on McPhail device, there was no issue of rendering ! (though I saw no screenshot)
<bschaefer> slvn_, was it vivid+overlay?
<bschaefer> or was it wily/xenial?
<slvn_> I guess his device is vivid. and the app is vivid+overlay
<slvn_> the app I sent you is vivid+overlay
<bschaefer> well then it shouldnt run :)
<bschaefer> if his device is vivid only then mir is like 0.13
<slvn_> no sorry, his device is problably vivid+overlay also
<bschaefer> yeah
<bschaefer> hmm
<slvn_> we need you branch :)
<slvn_> the app is then vivid+overlay+your_branch
<bschaefer> https://code.launchpad.net/~brandontschaefer/+junk/SDL2-new-mir-ABI
 * bschaefer is getting his phone setup to debug and hopes he doesnt run out of space
<bschaefer> cross compiling takes to long
<bschaefer> i also need to check unity8 desktop... to see if the same issue
<bschaefer> if thats the case it might be qt/mir
<bschaefer> but ... not really sure atm
<bschaefer> slvn_, the one thing sdl2 does strangly is talks to mir directly
<bschaefer> vs going through the mir platform
<bschaefer> which *could* cause strange issues (possibly?)
<slvn_> it talks to mir to configure the screen/surface, then it does opengles2 things
<slvn_> maybe we could check that the renderer is actually opengles2
<bschaefer> wait... i didnt actaully check opengles2...
<bschaefer> but it should use opengles
<bschaefer> slvn_, i have an app that is 100% opengles2 (otherewise it'll fail)
 * bschaefer should test that out
<bschaefer> if its all software rendering then it could be my fault (some how getting 1/2 on my stride)
<bschaefer> slvn_, http://i.imgur.com/ZEyDjRW.png
<slvn_> it could YUV
<slvn_> it could be YUV
<slvn_> mis interpretation of pixel format
<bschaefer> yeah, which would mean 1/2 stride
<bschaefer> meaning clone surface
<bschaefer> (ie. RGB16 vs RGB32)
<slvn_> Could be the algorithm in SDL2 that set the GLES2 config that does somethings wrong ...   see SDL_EGL_ChooseConfig() ..  the first config should be the better
<bschaefer> slvn_, it is most likely me picking a pixel format that is to large while the surface is actually a 16
<bschaefer> so if i think its rgb32, i create a surface that is twice the size
<bschaefer> of the actual surface in sdl2
<bschaefer> soo im copying (two chunks of the same thing)
<bschaefer> theres also this nice new function:
<bschaefer> client/mir_toolkit/mir_connection.h:194:MirPixelFormat mir_connection_get_egl_pixel_format
<slvn_> I should patch SDL2/mir backend ?
<bschaefer> slvn_, naw its my problem :)
 * bschaefer is looking into fixing it
<slvn_> ok L)(
<slvn_> :)
<mcphail> Hi slvn_ and bschaefer. I'm not getting that odd doubling on my phone, nor errors with the rendering of the balloons.
<bschaefer> mcphail, what version of sdl2 are you using?
<mcphail> bschaefer: whichever one slvn_ bundled with his app. I don't have the source
<bschaefer> hmm
<bschaefer> mcphail, what are you running on your phone? vivid+overlay?
<bschaefer> or wily/xenial?
<bschaefer> mcphail, also what phone do you have?
<mcphail> bschaefer: I'm running stock, so I presume it is vivid+overlay
<bschaefer> as right now it looks like an incorrect pixel format
 * bschaefer has a nexus 4
<mcphail> perhaps it is the same rendering bug reported by popey a while back?
<mcphail> https://bugs.launchpad.net/ubuntu/+source/libsdl2/+bug/1460149
<ubot5> Ubuntu bug 1460149 in libsdl2 (Ubuntu) "Visible corruption in SDL apps (Neverball, Neverputt) on Nexus 4 / Nexus 7." [High,Triaged]
<bschaefer> mcphail, i think that was different
<bschaefer> that actually looks like corruption
<bschaefer> what i have is just pixel format issues
<mcphail> bschaefer: see comment 18
<bschaefer> i even made a comment on that
<bschaefer> umm
 * bschaefer re-reads
<bschaefer> mcphail, but yeah mir supports 16 PF now...
<bschaefer> 16 bit pixel formats
<mcphail> aah ok
<bschaefer> (in 0.17), unless ... that landed?
<bschaefer> later
<bschaefer> naw it should have landed in 0.16
<mcphail> I think it is 0.16 on the phones?
<mcphail> I'm certainly not getting rendering issues on mine (except the tictactoe grid doesn;t have any horizontal bars - probable resolution issue)
<bschaefer> mcphail, 0.17 is on the phone
<bschaefer> from the overlay
<bschaefer> mcphail, what device do you have?
<mcphail> krillin (bq 4.5)
<bschaefer> i could try it out on that... but im thinking that might not support the pixel format that is getting hit on the N4
<mcphail> might explain why the N4 seems to hit more rendering bugs than the bq
<mcphail> the issue I get with the games is the touch input doesn't work properly
<bschaefer> yeah that... i have to to look into its only
<bschaefer> up/down motion still works
<bschaefer> at lease was working for me
<mcphail> first touch works, but subsequent ones are ignored. Did slvn_ copy you in to the log from my phone?
<bschaefer> yeah
<bschaefer> err
<bschaefer> not the log
<bschaefer> but
<bschaefer> i've seen that issue before on the N7
<slvn_> I can explain this issue
<bschaefer> where you get a down, but never an up
<slvn_> what happens is there are lot for FINGER_DOWN but no FINGER_UP
<bschaefer> yeah
<slvn_> not enough FINGER_UP
<slvn_> and, I think there are multiple reasons for the missing finger_up
<slvn_> one of the reasons, if the "event" action_cancel, that should emit some finger_up
<slvn_> which is not in the backend I think
<slvn_> other reasons are more obscure ... the way of decoding the datas ...
<bschaefer> slvn_, that might explains some issue i dont remember that action
<slvn_> bschaefer, mcphail  here's my old SDL_mirevents.c  with modifications to fix/workaround the input issue :  http://paste.ubuntu.com/13210696/
<slvn_> see mir_motion_action_cancel and also mir_motion_action_pointer_up
<bschaefer> slvn_, that doesnt exist anymore :(
<bschaefer> action wise
<slvn_> and as a "diff" : http://paste.ubuntu.com/13210720/
<slvn_> action_cancel does not exist anymore ?
<bschaefer> nope
<slvn_>  action_pointer_up
<bschaefer> slvn_, mir event 2.0 changed a lot
<bschaefer> theres: mir_touch_action_up = 0,     mir_touch_action_down = 1,  mir_touch_action_change = 2
<bschaefer> for touch events
<slvn_> ... what is important is the "for()" loop in action_pointer_up to do a up on all events.
<bschaefer> yeah
<slvn_> maybe there is no more action_cancel bug then !
<bschaefer> you need to go through and eat all the touch events
 * bschaefer looks at his touch code
<bschaefer> slvn_, http://paste.ubuntu.com/13210751/
<bschaefer> thats the current touch code...
<bschaefer> and i loop through it all
<bschaefer> but i still see touch issues up/down
<slvn_> is there still the android layer under mir to handle touch/input ?
<bschaefer> currently yes
<slvn_> so this action_cancel probably still exists
<bschaefer> not in the mir public api
<bschaefer> (android most likly)
<slvn_> so maybe it should be translated as several finger_up
<bschaefer> slvn_, if its only an issue in SDL2 then i must just be doing something wrong :)
<bschaefer> ie. it seems to work fine in all other QT/QML apps
<slvn_> are they using multiple fingers?
<bschaefer> slvn_, we have having issues with just 1 figure
<bschaefer> and i assume yes
<slvn_> it's easy to see if the bug is in (SDL+SDL_mir_backend) or in (mir+...)
<slvn_> just log the up / down
<slvn_> + ids
<slvn_> for each finger down, there must be a finger up
<slvn_> I mean, that what SDL rely on .. but SDL could also be more robust by implement some timeout etc.
<bschaefer> slvn_, one issue i saw is: AddTouchDevice(device_id);
<bschaefer> was in the for loop
<bschaefer> for each touch event
<bschaefer> (that could cause some sort of issue with sdl2 under the hood but idk
<slvn_> bschaefer, AddTouchDevice is still in the for loop !
<bschaefer> yeah i just moved it
<bschaefer> but idk
<bschaefer> what it does atm, need to look at that
<slvn_> like before
<slvn_> no, before and now, it has always been there
<bschaefer> im not sure what sdl2 does (if its a mapping of the id then it shouldnt matter)
<bschaefer> yeah
<bschaefer> im not sure if thats causing a sync issue
 * bschaefer just needs to check the mir logs
<bschaefer> for up/down touch events
<slvn_> AddTouch is for SDL only
<bschaefer> ... why does it even compile
<bschaefer> i dont see that function anywhere haha....
<slvn_> wrapper to SDL_AddTouch
<bschaefer> but its not defined anywhere... unless grep is failing me
<slvn_> in  SDL/src/events/SDL_touch.c
<bschaefer> i see SDL_AddTouch
<bschaefer> i just dont see AddTouchDevice
<slvn_> and SDL_mirevents.c
<slvn_> AddTouchDevice
<bschaefer> slvn_, im just saying AddTouchDevice is not defined anywhere
<bschaefer> and i dont see a
<bschaefer> #define AddTouchDevice SDL_AddTouch
<slvn_> no no, in SDL_mirevents.c, static void AddTouchDevice
<slvn_> just doing a SDL_AddTouch
<bschaefer> slvn_, ug
<bschaefer> im not use to
<bschaefer> static NEW LINE
<bschaefer> AddTouchDev :)
<bschaefer> slvn_, confirmed the cloning issue
<bschaefer> assume the PF is 32, and setting it to such, even though we are a 16 pF
<bschaefer> PF*
<slvn_> ok, not sure of the implication though ...
<bschaefer> it what causes the cloning
<bschaefer> of the surfaces
<bschaefer> ie. the two copies
<bschaefer> sooo now its just trying to figure out how to pick the correct PF (which can prove to be hard)
<mcphail> bschaefer: ha! - so it _is_ the same as the bug above ;)
<bschaefer> mcphail, yeah :) (it looks that way)
<bschaefer> mcphail, the issue atm is, i just loop through the available pixel formats
<bschaefer> and return when one is supported (to use as the PF for the mir surface)
<bschaefer> but the PF that is actually given to EGL is 565
<bschaefer> and we create a mir surface of 888
<mcphail> is there a robust way to fix that?
<bschaefer> mcphail, yes but it crashes atm :)
<bschaefer> and is fixed in 0.17.1
<bschaefer> but overlay+vivid is 0.17.0
<mcphail> bschaefer: so close..!
<bschaefer> quite :) (well hopefully it fixes it)
<slvn_> bschaefer, mcphail  I am leaving the chan. I would be glad to have some news by email. I'll be there tomorrow++
<bschaefer> c ya
<mcphail> slvn_: cheerio
<slvn_> bye!
<bschaefer> hmm so far testing output on touch... when i hit a down, i get an up...
<bschaefer> but i dont have a good app to test atm :(
<bschaefer> mcphail, haha... guess why touch didnt work :)
<bschaefer> HandleTouchPress(device_id, id, SDL_FALSE, n_x, n_y, pressure);
<bschaefer> was being sent for DOWN
<bschaefer> and for UP
<bschaefer> HandleTouchPress(device_id, id, SDL_TRUE, n_x, n_y, pressure);
<bschaefer> wellllll
<bschaefer> SDL_TRUE is the slot for DOWN being true
<bschaefer> soo i just flipped those around when i re factored the code...
<bschaefer> so when we get a DOWN action we were saying DOWN is false and when we got an UP action we were saying a DOWN has happened
<mcphail> bschaefer: nice catch! This is the advantage of having people writing games for the device in SDL - highlights these problems.
 * mcphail might retry his Baldur's gate port
<bschaefer> o.m.g someone ported that game?
<bschaefer> to sdl2?
<mcphail> bschaefer: I have a port which gets as far as the menu
<mcphail> bschaefer: using gemrb
<bschaefer> mcphail, nice! I've not heard of those, but i loved baldurs gate haha
<mcphail> bschaefer: unfortunately, my porting has been delayed by the fact I'm wasting so much time playing Planescape Torment on the PC... :)
<bschaefer> haha
<bschaefer> the down side of porting games, testing to long :)
<mcphail> bschaefer: also hampered by the ever-growing list of games on Steam. My life is ruined
<bschaefer> haha
<bschaefer> very true
<mcphail> bschaefer: incredibly cool to see the BG intro on the phone, though
<bschaefer> mcphail, yup had the exact feeling when i saw the dota2 intro
<bschaefer> (on the desktop)
<bschaefer> though i had a multi thread gl context bug after that, that ended with me digging through the video driver...
<bschaefer> but still fun... i've to get that working again so much has changed
 * bschaefer heads to a bar to do some work
<mcphail> bschaefer: the life of a linux gamer will never be easy, i suspect
<bschaefer> :)
#ubuntu-mir 2015-11-10
<slvn_> Hello ! I am waiting for bschaefer/mcphail for some help & bug fixing ... In the mean times, could some one test a game/click package on his device (the version needs to be vivid + ppa phone overlay).
<slvn_> ?
<slvn_> hello, I wished someone could test my ubuntu-touch game for debugging purpose !
<dandrader> kdub, ping
<kdub> hello dandrader
<dandrader> kdub, hi
<dandrader> kdub, how do I fill out a cursor using a buffer stream
<dandrader> ?
<kdub> dandrader, lp:mir:examples/animated_cursor_demo_client.c might be an example of what you need
<dandrader> kdub, thanks! just found out about it as well by grepping mir. sorry for bothering you :)
<dandrader> kdub, was grepping only the tests so far
<kdub> no problem
<dandrader> kdub, I'm not doing an animated cursor. do I still have to call mir_buffer_stream_swap_buffers_sync(stream) after mensetting it?
<kdub> i think so, thats how the buffer would be updated
<dandrader> kdub, right, makes sense. after all you could update the buffer with multiple memset calls and what not
#ubuntu-mir 2015-11-11
<jeembe> hi
<jeembe> i see 2 mouse pointers when running gedit on mir
<jeembe> even when i close gedit i still have 2 mouse pointers (one is bigger than the other)
<jeembe> i have to restart unity8 to get rid of the second mouse
<anpok> I supposed you are running gedit using the gtk backend, arent you?
<anpok> hm I guess unity8 currently doesnt override the cursor provided by applications and allows it to be forwarded to unity-system-compositor, which will have a different notion of current cursor position..
<jeembe> anpok: yep, and the other problem is that i get a black window with xmir (just landed). i'm using nouveau so i don't have much hope for this beeing fixed any time soon
#ubuntu-mir 2015-11-12
<alan_g> alf_: anpok_ - do you want to review this? (Or shall I just TA?) https://code.launchpad.net/~alan-griffiths/mir/remove-RTLD_GLOBAL-hack/+merge/277277
<alf_> alan_g: feel free to TA, the code change looks sane, but I won't have time to test until later today
<anpok_> just did
<alan_g> alf_: anpok_ - thanks
<anpok_> further messing with clocks spawned https://bugs.launchpad.net/canonical-devices-system-image/+bug/1515515
<ubot5> Ubuntu bug 1515515 in Unity 8 "Monotonic clocks behave weird after a wakeup " [Undecided,New]
<anpok_> .. hm why does it say in unity8 ..
<anpok_> anyhow .. I will probably settle with CLOCK_REALTIME for now.. it seem to be a problem in kernel .. at least glibc just forwards the clock id..
<anpok_> now I wonder .. should we also change mir::Clock::SteadyClock to not use steady_clock?
<anpok_> or should I .. for now have different clock passed to the input platforms..
<alf_> anpok_: Did you see my comments in that bug?
<anpok_> alf_: we do now() + some_next_frame_estimate then forward events to it
<anpok_> but let me look again..
<anpok_> alan_g: I seem to have tested in the wrong build directory... i was about to add another check to the module entry points..
<anpok_> with that branch - as opposed to lp:mir it seems to fail while trying to probe the kms platform
<alan_g> anpok_: which scenario? (I haven't seen any problems)
<anpok_> what i tried was: ./mir_demo_server --vt 2 --file /tmp/mir_host --launch-client './mir_demo_server --host-socket /tmp/mir_host --file /tmp/nested --launch-client "./mir_demo_client_eglplasma -m /tmp/nested "'
<anpok_> oh
<anpok_> thats the new platform probing
<anpok_> it decides to pick dummy platform.. if I remove all by kms .. it claims none found.. while
<anpok_> on my old build it did..
<anpok_> so we broke probing with nested and thats not related to this branch
 * alan_g is nearly as confused as anpok_ 
<anpok_> i would guess it fails here:
<anpok_> http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/src/platforms/mesa/server/kms/platform_symbols.cpp#L181
<anpok_> need to look with a vm..
<anpok_> and then returns in line 191 ..
<anpok_> s/191/194
<anpok_> nah not confused .. just stale builds..
<anpok_> i mean our current probing logic in mir requires the nested server to launch with a --vt paramter or being at least temporary capable to drmSetMaster while probing.. otherwise the platform isnt considered
<alf_> anpok_: alan_g: hmmm... I don't the nested server shouldn't be probing anything, it should select its guest platform to match the host platform the host server is using
<alf_> anpok_: alan_g: s/I don't//
<alan_g> +1
<anpok_> yes, but does that also apply for x11 host and mesa-kms nested?
<anpok_> hm does that even work?
 * alf_ 's fingers have started hurting from all the proximity sensor (un)covering, and wishes he had some Lego Technic... looks around the house for any kind of mechanism to automate this
 * alan_g wonders if, after NBS lands in the client API, we'll even need guest platforms
<alan_g> anpok_: I confirm your finding. Did you file a bug?
<alan_g> anpok_: https://bugs.launchpad.net/mir/+bug/1515558
<ubot5> Ubuntu bug 1515558 in Mir "Nested servers on mesa-kms select wrong (dummy) guest platform" [Undecided,New]
<anpok_> alan_g: had to run and unconfuse me..
<anpok_> alan_g: maybe only for the mesa reload hack :)
#ubuntu-mir 2015-11-13
<alan_g> anpok: I think we should land a few MPs by hand to clear the backlog. Do you have any candidates for that?
<anpok> oh so ci is still down?
<anpok> https://code.launchpad.net/~andreas-pokorny/mir/input-configuration-api/+merge/273975 this one should be fine
<anpok> and of course this one https://code.launchpad.net/~alan-griffiths/mir/delete-dead-code/+merge/277094
<alan_g> anpok: Unless I'm mistaken we still have intermittent failures on krillen.
<anpok> and this one https://code.launchpad.net/~kdub/mir/current-buffer-id-fix/+merge/275986
<anpok> hm the landing problems yesteday afternoon were caused by the jenkins shutdown
<anpok> for certain definitions of yesterday and afternoon
<anpok> but .. there still seem to be problems.. one cannot access some of the jenkins instances for build results also no testrunners have been run today
<alan_g> yeah, just seen that
<alan_g> Let's leave it a bit then and review towards EOD (Europe)
#ubuntu-mir 2016-11-14
<RAOF> bschaefer: Yo!
<bschaefer> RAOF, hey! Sooo questions about render nodes!
<RAOF> Cool.
<bschaefer> if you had a mythical machine that supported drm buf with multiple render nodes
<bschaefer> does it matter which node you pick? From my reading they dont relate to the specific card and is there for legacy reasons only
 * RAOF has such a machine, yes.
<RAOF> If you've got two different GPUs you'll have two different render nodes, one per GPU.
<bschaefer> right
<RAOF> So it does indeed matter which render node you pick.
<RAOF> But!
<bschaefer> RAOF, https://dvdhrm.wordpress.com/tag/drm/
<RAOF> Whichever node you pick, you should be able to display.
<bschaefer> so if mir is rendering on intel
<bschaefer> and youve an amd gpu and you told kodi to render on it
<bschaefer> and then picked the amd render node, it wouldnt display on mir?
<RAOF> It would.
<RAOF> That's what dma-buf is for!
<RAOF> Cross GPU sharing.
<bschaefer> sooo then it doesnt matter which one you pick!?
<bschaefer> :|
<bschaefer> RAOF, https://github.com/xbmc/xbmc/pull/10922
<RAOF> It *does* matter which one you pick.
<RAOF> For example, if you pick the one that doesn't support GPU decoding you won't be able to do GPU decoding on it :)
<bschaefer> it matters *but* it'll always display?
<RAOF> Yes.
<RAOF> Asterisk.
<bschaefer> :)
<RAOF> The relevant asterisk here is: You can't currently hand a buffer to Mir at all.
<bschaefer> hmm so how would one pick a GPU render node that *supports* this? Poke the extension?
<bschaefer> from the fd?
<RAOF> Correct.
<bschaefer> sooo thats *all* that matters is picking a correct render node that supports the extension you want to support
<RAOF> You'd just need to initialise vaapi on the render node.
<bschaefer> right, soo its up to me to pick a render node that supports what i expect out of vaapi
<bschaefer> so for kodi, in this case only supports intel atm
<RAOF> Or, rather, you could initialise the vaapi library on *all* render nodes, and then pick!
<bschaefer> EGL_LINUX_DRM_FOURCC_EXT
<bschaefer> since it *needs* this
<bschaefer> based on which one fails?
<bschaefer> when you init vaapi?
<RAOF> You could happily use both simultaneously if you wanted - picture in picture, or something.
<RAOF> There's no requirement that you use a single GPU :)
<RAOF> Except, I think, in the kodi code :)
<bschaefer> :)
<bschaefer> yeah it slightly depends on one va display atm
 * bschaefer can possibly come up with a decent solution to query extensions *somehow* from the fd
<bschaefer> RAOF, the good news is it *does* work on mir
<bschaefer> and works well
<RAOF> Oh, sweet.
<bschaefer> the drm side of things
<bschaefer> so DRM + EGL + Render nodes 100% works (with only liner/bi for scaling)
<bschaefer> scaler* since nothing else seems to be implemented in the driver as far as i know?
<bschaefer> RAOF, running the same video 3840x2160p60 on mir with the same settings frames dropped 0, frames skipped 0
<bschaefer> for X11 dropped 0, skipped 101
<bschaefer> err skipped for mir was 3
<bschaefer> (for 8 min of that video)
<bschaefer> (using mir on kms)
<bschaefer> RAOF, are... the extensions part of the inode? ie. stat that fd?
 * bschaefer looks around more
<RAOF> No.
<RAOF> The only way you can check extensions is to bring up a driver on the fd.
<RAOF> Because it's the driver that implements the extensions, anyway :)
<bschaefer> right, soo bringing up the driver on the fd
<bschaefer> opening a gl context?
<bschaefer> RAOF, i suppose the kernel does that somewere i can dig around as my googling is missing specific terms atm haha
<RAOF> No, not the kernel.
<RAOF> The userspace driver.
<bschaefer> o so mir would be doing that?
<RAOF> No, mesa/libva
<bschaefer> RAOF, which would be part of the vaDisplayMir?
<bschaefer> bits?
<RAOF> Well, which is currently a part of the vaDisplayDRM bits.
<bschaefer> right, but the DRM part puts that on the users
<bschaefer> well for RenderNodes
<bschaefer> since we cant drmOpen a device
<bschaefer> since kms already opens it
 * bschaefer locked up his machine debugging that a few times...
<RAOF> So, if vaDisplayDRM returns non-null you've handed it a rendernode that it has a driver for.
<bschaefer> RAOF, but that doesnt mean *it* supports an extension we need
<bschaefer> so for kodi it has a specific extension EGL_LINUX_DRM_FOURCC_EXT
<RAOF> Right.
<bschaefer> that it uses to get a decoded image in an expected format
<RAOF> *That* extension is required on the *display* device.
<RAOF> So, since you've already got an EGL context on the Mir surface, you can query it.
<bschaefer> ooo right and we use
<bschaefer> the egl context in vaapi atm
 * bschaefer checks if they already do that
<bschaefer> hm no they take the current egl context from the windowing system and create a different one
<RAOF> Well, whatever EGL context they create on the Mir surface is going to be on the display device.
<bschaefer> riht
<bschaefer> right*
<bschaefer> they make current with
<RAOF> (Which is not necessarily the same device that vaDisplayDRM is using, but that doesn't matter much)
<bschaefer> err create a context
<bschaefer> new_context, mir_context
<bschaefer> RAOF, right, which is where i was wrapping around to
<bschaefer> soo if mir is using amd
<bschaefer> which wont have EGL_LINUX_DRM_FOURCC_EXT, it'll have to bail out *anyway*
<bschaefer> before we even get to the drm va display btis
 * bschaefer doesnt see any extension checking strangly
<bschaefer>   if (gpuvendor.compare(0, 5, "intel") != 0)
<bschaefer> o yeah they check for that specificly
<RAOF> The proprietary drivers may or may not support EGL_EXT_image_dma_buf_import ; AFAIK all the mesa drivers do, though.
<bschaefer> RAOF, i suppose from there is up to me not to pick the wrong render node though?
<bschaefer> ie. if we are on render node 130 (the one mir is using with the intel support)
<RAOF> Nope, doesn't matter.
<bschaefer> as long as the display
<bschaefer> right
<RAOF> What you *should* do, though, is loop through all available rendernodes.
<bschaefer> so that extension is only required on w/e card the mir serve ris running on
<bschaefer> RAOF, what im doing currently is just running through 128 --> 128 + 16 and seeing if they exist
<RAOF> Because there's no guarantee that vaGetDisplayDRM will return non-null on the first one you pick.
<bschaefer> ooo very true
 * bschaefer updates branch
<RAOF> Argh.
 * RAOF notices the lack of ++counter in the test.
<bschaefer> thanks for answering those... and enjoy fixing tests!
<fritsch> RAOF: bschaefer: this mysticaly machine needed to support RG8 and R8 extensions for the dma_buf transfer - and as besides intel no one implements it ...
<fritsch> concerning the post on github: vaPutSurface is no usecase for kodi, we use egl_createImageSomething extension
<RAOF> fritsch: Only the EGLImage consumer needs that extension, though, right?
<fritsch> jep
<fritsch> so intel would be the "consumer"
<RAOF> fritsch: So Intel is the only GPU that can *output*, but any dma-buf capable GPU can decode.
<fritsch> and amd for example would be the decoder
<fritsch> jep
<RAOF> Yup. Fierce agreement!
<fritsch> yeah, in that github discussion something else, we had a little fight two days before was "discussed" un the vaapi cover ...
<RAOF> Why don't you use vaPutSurface, by the way?
<fritsch> lol
<fritsch> reason in 1 minute, as work is calling:
<fritsch> it scales
<fritsch> it scales limited video range to full range without dithering
<fritsch> killing all the grey ramps
<fritsch> 2nd: it does a full copy!
<fritsch> so, quality sucks and performance also
<RAOF> Urgh.
<fritsch> with the dma_buf approach we can directly use a shader on the Y and VU plane
<fritsch> and are done
<fritsch> without copying anything
<fritsch> also vaPutSurface is GLX only
<fritsch> there is no EGL alternative to it and also (obviously) no DRM alternative
<RAOF> Fair enough. vaPutSurface *should* be able to do zero-copy to display in optimal circumstances, but I don't know if it *does* :)
<fritsch> it can't
<fritsch> it is basically a texture from pixmap approach
<fritsch> or better said: you can use it as texture from pixmap copy
<fritsch> that will only work with real opengl
<fritsch> oki - got to go. Back in 12 hours :-)
<RAOF> :)
<fritsch> thx for your post in the bugreport
<RAOF> It should be able to use the Present extension and zero-copy it, but probably doesn't :)
<fritsch> does anyone on the planet use its present extension?
<fritsch> :-)
<fritsch> especially if you are an OpenGL / OpenGLES application?
<fritsch> s/bugreport/pull request/
<RAOF> Yeah, GL uses the Present extension nowadays.
<RAOF> GLX (via DRI3)
<alan_g> attente: where's the best place for tracking gtk-mir bugs? I've seen them reported against lp:mir and lp:miral and am not 100% sure where to redirect them.
<attente> alan_g: against gtk with the tag gtk-mir
<attente> alan_g: can you point me to your surface positioning feedback branch? sorry it's taken so long for me to look at it
<alan_g> attente: therre's two parts, one is in mir-0.25 (which is in a silo somewhere) the other got released in miral-0.2 but needs the unreleased Mir for you to make much use of it.
<attente> alan_g: it's ok, don't need a release, but if you have links to the branches, that works too
<alan_g> lp:mir/25 lp:miral/release
<kdub> does anyone know if the -egl and -egl_sync flags work on xmir? strange green-screen behavior for me
<kdub> sw works alright
<anpok> last time i tried I experienced the same..
<kdub> anpok, thanks
<fritsch> RAOF: can you test the patches with your amd gpu doing vaapi decoding and the intel card doing the rendering?
<fritsch> kodi's code blocks non "intel" renderers anyways ...
<fritsch> vaapi will be disabled for these when not overwritten
<fritsch> anyways
<bschaefer> fritsch, he is on UTC + 11 :)
<fritsch> ah - so he will wake up soon, right? :-)
<bschaefer> hmm maybe 4 hours?
<bschaefer> maybe 3 when he'll be on
<fritsch> :-)
<fritsch> was for the backlog anyways. I met him that morning before I was going to work
<fritsch> so just returned
<bschaefer> o nice
 * bschaefer didnt see the backlog due to sleep and to lazy to setup a way to be on at all times :)
<fritsch> isn't it publically logged somewhere?
<bschaefer> o yeah i think so
 * bschaefer should fix kodi seg faulting when theres no mir socket
<bschaefer> hmm actually that happens on x11 as well
<fritsch> jep
<fritsch> :-)
<bschaefer> fritsch, eek... i rebased... and seem to have added random things?
<bschaefer> https://github.com/xbmc/xbmc/pull/10898
<bschaefer> fritsch, nm fixed, just needed to fetch upstream and rebase
<bschaefer> (also thanks for telling me about ctrl+o made me realize I didnt do that for mir :) fixed now
#ubuntu-mir 2016-11-15
<fritsch> bschaefer: perfect
<om26er> bug 1641901 says Hi!
<ubot5`> bug 1641901 in MirAL "Need surface geometry for autopilot" [Undecided,New] https://launchpad.net/bugs/1641901
<alan_g> om26er: mir_debug_surface_coords_to_screen() waves back
<om26er> alan_g: hm, that looks like a bool[1], I presume it requires some parameters that we are actually trying to determine. [1] http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/src/client/mir_debug_api.cpp#L34
<alan_g> https://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/include/client/mir_toolkit/debug/surface.h#L48
<alan_g> om26er: the bool tells you whether this extension has been enabled by the server.
<alan_g> greyback: any likelyhood of miral reviews today?
<greyback> alan_g: sure
<om26er> alan_g: re your comment on the bug report. "Mir-0.25 provides a server-side API that allows this debug extension to be enabled dynamically. E.g. by Unity8"
<om26er> Do you think it would make more sense to keep this feature one layer above unity8 ? think of the case of a Kiosk-like environment where unity8 is not the server. That way we can enable autopilot to work on more environments.
<om26er> that brings me to question, will starting `unity8 --debug` enable the debug extensions ?
<alan_g> om26er: *any* Mir server will respect the "debug" option which can be supplied at startup via commandline, environment variable or config file. The server-side API is available in Mir-0.25 & MirAL-0.5, but needs a mechanism for the server to call it
<alan_g> In short, yes "unity8 --debug" will work
<alan_g> I understand from greyback that there's a desire to do this dynamically (via dbus) for some test scenarios
<alan_g> A kiosk implementation probably doesn't need dbus.
<alan_g> greyback: thanks for the reviews. (ALL approved!?)
<greyback> alan_g: you did good :)
<greyback> alan_g: I only questioned if "debug extensions" should be plural
<greyback> which is a nitpick of the highest order
<alan_g> but a perfectly good one
<alan_g> To me it sounds better (and future proof) with the "s", but multiple APIs could be "an extension" so I see your point
<greyback> not something worth blocking on
#ubuntu-mir 2016-11-16
<bschaefer> ogra_, whenever you get this ive snaps being built (stealing your ideas :)
<bschaefer> https://code.launchpad.net/~brandontschaefer/+snap/kodi-mir
 * bschaefer testing it on arm64 now
<ogra_> whee !
<alan_g> greyback: I presume you've not looked at this yet? (If you have I'll create a follow-up instead of updating) https://code.launchpad.net/~alan-griffiths/miral/test-active-window/+merge/310905
<greyback> alan_g: I've not, sorry
<alan_g> greyback: np - I'll just shove more into the one MP
<greyback> ack
#ubuntu-mir 2016-11-17
<duflu> Ah crap. We forgot to add Ubuntu tasks so the robots know to update all the 0.25.0 bugs
#ubuntu-mir 2017-11-15
<ogra_> hrm
<ogra_> alan_g, i just filed https://github.com/MirServer/mir/issues/35 ... only to notice later that mir-kiosk is its own GH project ...
<ogra_> should i close and re-file or can you move it over somehow ?
<alan_g> ogra_: not anymore we rolled MirAL into Mir 0.28
<ogra_> well, there is no snapcraft.yaml anywhere else
<ogra_> (and the bug refers to "please add additional apps to snapcraft.yaml)
<alan_g> ogra_: sorry, misread. Yes, better under mir-kiosk
<alan_g> AlbertA: greyback: ^^ who's the snap guy?
<greyback> alan_g: eehhh I guess I can be
<alan_g> greyback: if you hate the idea I guess I could have a go.
<greyback> alan_g: no I'm fine with it
<ogra_> greyback, alan_g moved it to https://github.com/MirServer/mir-kiosk/issues/3 under the correct project now
<greyback> ogra_: thanks!
<AlbertA> ogra_: yeah we'll transition to that github project... still using the launchpad one one last time
<ogra_> yeah, i'm fine with that ... i just didnt realize the snap bits live in an extra branch
<AlbertA> perhaps we should just merge it into the mir project actually... we'll see...
<alan_g> AlbertA: I guess it depends whether we want (long term) to pull debs from the PPA or always build it.
<AlbertA> alan_g: well I'm thinking more to build it as part of the "release process", either with build.snapcraft.io or CI
<alan_g> AlbertA: yeah, I just have the impression we rework the snaps more often than we release. (But that /shouldn't/ be the case.)
<AlbertA> alan_g: that's true... usually for reasons other than mir...
<AlbertA> so probably makes sense to keep it in its own project for now
#ubuntu-mir 2017-11-17
<RAOF> It is surprisingly hard to test a Wayland compositor without introducing special protocolâ¦
<RAOF> Ah, designing for testing...
 * Son_Goku sighs
<Son_Goku> joy of joys, my merge of the mir package is blocked on it being broken in rawhide... again
<alan_g> Son_Goku: https://github.com/MirServer/mir/pull/40
<Son_Goku> alan_g: testing now
