#ubuntu-mir 2013-11-04
<RAOF> Oh, man. std::tie!
<mlankhorst> is that an outcome of std::vote? :P
 * duflu resizes a surface, and kernel panics trusty
<duflu> And again :P
<ogra_> stop resizing surfaces then ...
<alan_g> http://search.dilbert.com/comic/Definition%20Of%20Insanity
<mardy> RAOF: thanks! Then let me refrase the question, in a more direct way
<mardy> RAOF: the Nokia N900 and N9 phones come with EGL drivers (binary only, not open source); is there some chance to get Mir (and Ubuntu Touch) working on these phones?
<mardy> they are real Linux phones, not Android
<tvoss> mardy, what is the graphics buffer management, modesetting api used by those drivers?
<Stskeeps> mardy: you can possibly do it with nitdroid drivers but you'd have to suffer from terrible tearing
<Stskeeps> plus the problem is that n900 doesn't grok thumb2 due to a HW bug
<mardy> tvoss: no idea
<mardy> Stskeeps: Nemo is using the original EGL binaries, right?
<mardy> Stskeeps: I'm not sure what the problem is; are these binary blobs tied in some way to X11?
<tvoss> mardy, would be good to find out to answer your question
<Stskeeps> mardy: yeah and x11.. we've tried with wayland on there but you need to spend immense time to get proper vsync going on that rather custom stuff
<tvoss> Stskeeps, +1, reusing x11 interfaces is close to impossible
<Stskeeps> so i've practically given up on those devices for any purpose
<mardy> Stskeeps: I see... is nitdroid reusing the original drivers, or is it using android drivers taken from some other device (with compatible HW)?
<Stskeeps> uses android drivers of dubious origin and licensing
<mardy> cool :-)
<mardy> Stskeeps: TBH, I don't care about licensing, I would just distribute instructions, not images
<Stskeeps> :nod:
<Stskeeps> but even then, the problem would be that tearing would be quite bad and direct rendering/hw composition is not that sane on those devices
<mardy> again because of the drivers? Or is there some HW limitation (let's forget the N900 for a moment)
<Stskeeps> drivers plus custom vsync handling in display/kernel
<tvoss> mardy, if we do not have the hwc available, results are pretty bad. The same happens for the N7
<mardy> mmm... I guess I won't spend much time on this then :-)
<tvoss> greyback, ping
<greyback> tvoss: pong
<greyback> I saw you've added comments to the doc, I'll have a look shortly
<tvoss> greyback, hey, looking at the scenegraph document right now. I was thinking if we should add an introductory paragraph on different functionalities touched/covered by the scenegraph
<tvoss> obviously rendering, but also, input, application handling, focus handling etc
<tvoss> which would then allow us to augment the proposals with details on how things would be solved for those areas, too
<greyback> tvoss: makes sense
<tvoss> greyback, cool
<greyback> tvoss: after that's done, how best you think to proceed? I've had a meeting with some of the Mir team on the rendering side, I think they were cautiously open to the idea. Input side, I need to get racarr and dandrader and myself in a meeting too.
<tvoss> greyback, we should decide on a rough plan and have an iteration 0 asap to flesh out remainding details and identify blockers early on
<tvoss> greyback, separate branch, full steam ahead. Once complete, we refactor into trunk
<tvoss> greyback, makes sense?
<greyback> tvoss: yes.
<greyback> tvoss: ok, so I'll meet with racarr and dandrader on input matters this evening. If no major blockers are evident from that, I'll send round a mail with a proposed plan, set up a meeting to discuss it, and if I get go-ahead, execute
<greyback> tvoss: how that sound?
<tvoss> greyback, +1. I'm specifically interested in details on how you plan on updating focus, and thus app/surface/input details, atomically
<greyback> tvoss: ok, I'd better get those details sorted
<racarr> Morning
<alan_g> Afternoon
<alf_> Evening
<greyback> racarr: heya, have you time soon to talk about Mir and Qt?
<racarr> greyback: Ok we have our standup in 4 minutes but besides that
<racarr> when is good for you?
<greyback> racarr: well it's getting late here, so I'd prefer reasonably soon. dandrader|lunch should be there, he's been looking more at the input side than I have
<racarr> greyback: Ok how about in 30 minutes? or tomorrow before the standup
<greyback> dandrader|lunch: will you be back in 30 mins?
<greyback> racarr: I'll be here anyway, so we can chat
<racarr> ok
<racarr> Is there no standup now or is my google hangout not working?
<ricmm> kdub: ping
<ricmm> kdub: lemme know when you are around!
<kgunn> greyback: can i just lurk/listen in ?
<greyback> kgunn: sure
<racarr> greyback: ok hangout?
<greyback> racarr: yeah, let's do it. alf_ wanna join?
<greyback> dandrader: ah, good timing :)
<racarr> https://plus.google.com/hangouts/_/7ecpju9thmntft9e183v78t8bc?authuser=1&hl=en
<dandrader> greyback, I'm back
<greyback> dandrader: short notice, but racarr & I are having a meeting now
<alf_> greyback: I am in another meeting, will join as soon as I can, don't wait
<greyback> kgunn: we're in meeting, can you join?
<kgunn> yep
<kgunn> greyback: where you at?
<greyback> kgunn: https://plus.google.com/hangouts/_/7ecpju9thmntft9e183v78t8bc?authuser=1&hl=en
<greyback> alf_: can you join now?
<kdub> ricmm, pong
<alf_> greyback: yes, joining
<alf_> alan_g: ^^ hangout for the scenegraph:input side of things
<alan_g> alf_: ack
<gema> hi, how do I enable mir on trusty?
<gema> is there a wiki explaining this? (for desktop)
<tvoss> gema, this should help: https://wiki.ubuntu.com/Mir/Installing
<gema> tvoss: thanks :D
<davmor2> kgunn, tvoss: so it looks like unity and java based apps hate xmir on intel
<tvoss> davmor2, on trusty?
<davmor2> tvoss: no I haven't done the migration to trust that won't happen to beta time when things settle a bit
<davmor2> tvoss: this was on Saucy for all the commercial apps
<tvoss> davmor2, so unity and java apps together fail?
<davmor2> tvoss: unity3d sorry the games engine and java based apps.  Java says things like no GLX and unity3d Flashes like a strobe light
<tvoss> davmor2, now that is interesting. And it works flawlessly without xmir?
<davmor2> tvoss: indeed
<tvoss> davmor2, okay, did you file bugs yet?
<davmor2> tvoss: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Ai33BkOcORLLdGI2dE5hWHN1cXRaOXVRZHdrY2E5eWc&usp=drive_web#gid=0  no bugs filed yet completing the app migration was the primary task which got completed Friday evening
<tvoss> davmor2, ack and thx, will take a look after dinner
<davmor2> tvoss: if you look for the orange apps from the key those are all the ones that just wouldn't work due to xmir but were released as they worked flawlessly without xmir (which was then nolonger the default)  the unity3d apps were let through as they were fine other than the strobe light effect
<davmor2> tvoss|dinner: http://ubuntuone.com/4EniBLWsk5yxjJYyDjfTGy for the strobe effect
<kgunn> davmor2: ack will look at after i go for a run
<davmor2> kgunn: no rush just had time to go back and see if it was xmir or not :)
<brainwash> it that the DPMS flicker?
<davmor2> brainwash: no idea only happens on the unity3d games I can dig about and find you some that don't cost anything if you want to confirm it and figure it out for yourself :)
<brainwash> bug 1232343
<ubot5> bug 1232343 in XMir "XMir Screen flickering when running steam or SDL games" [High,New] https://launchpad.net/bugs/1232343
<robotfuel> davmor2: brainwash: this could also be related.  https://bugs.launchpad.net/xmir/+bug/1231632
<ubot5> Ubuntu bug 1231632 in XMir "Setting DPMS mode for output to 0 causes screen to blink/flicker once" [Medium,Triaged]
<brainwash> yeah, annoying stuff
<tvoss|dinner> kgunn, ping
<davmor2> brainwash: I think a lot of the apps that have the problem are window/mac conversions so I'm not sure if it is just the way it calls glx that is causes xmir to reveal a bug that is normally hidden in X or an issue in xmir itself  which is also really hard to tell
<kdub> ricmm, where is the hwcomposer library that we're trying to get working?
<kdub> i think it was removed from the nex7 build
<bschaefer> has anyone ran the mir server natively on a 32 bit desktop in while? As im getting a failure to create a GBM buffer (for the cursor) similar to this:
<bschaefer> https://bugs.launchpad.net/mir/+bug/1203070
<ubot5> Ubuntu bug 1203070 in Unity System Compositor "unity-system-compositor doesn't start on some ati card (with opensource driver)" [Critical,Fix released]
<bschaefer> on an intel chip
<tvoss|dinner> bschaefer, can you please file a bug?
<bschaefer> tvoss|dinner, yes i can
<tvoss|dinner> bschaefer, thx
<bschaefer> np!
<bschaefer> https://bugs.launchpad.net/mir/+bug/1247943
<ubot5> Ubuntu bug 1247943 in Mir "Mir server failing to start when compiled for 32bit" [Undecided,New]
<bschaefer> hopefully RAOF or duflu could take a look
<ricmm> kdub: I think it uses the default hwcomposer lib
<kgunn> tvoss|dinner: pong
<kgunn> need to reboot...got some desktop weirdness happening
#ubuntu-mir 2013-11-05
<robotfuel> duflu: ping
<duflu> robotfuel: pong
<robotfuel> duflu: armhf is failing on a new warning, I've opened https://bugs.launchpad.net/mir/+bug/1248014
<ubot5> Ubuntu bug 1248014 in Mir "/tmp/buildd/mir-0.1.1/tests/unit-tests/android_input/input_reader.cpp:758:36: note: 'args.android::NotifyConfigurationChangedArgs::eventTime' was declared here NotifyConfigurationChangedArgs args;" [Undecided,New]
<duflu> robotfuel: Thanks. I noticed just a few seconds ago
<tvoss> RAOF, ping
<Mirv> do you need a bug about unity-system-compositor failing to build against the new Mir?
<Mirv> fatal error: mir/shell/focus_setter.h: No such file or directory
<duflu> Mirv: Yes please. The change looks intentional... https://code.launchpad.net/~alan-griffiths/mir/tidy-shell-component-pass-2/+merge/193418
<Mirv> bug #1248055
<ubot5> bug 1248055 in Unity System Compositor " unity-system-compositor FTBFS on trusty against new Mir (libmirserver10)" [Critical,New] https://launchpad.net/bugs/1248055
<Mirv> bug #1248080 too
<ubot5> bug 1248080 in unity-mir "unity-mir FTBFS libmirserver10" [Critical,New] https://launchpad.net/bugs/1248080
<didrocks> duflu: kgunn: Mir was pulled to trunk without warning us?
<didrocks> and ensuring that the deps are building?
<duflu> didrocks: I was asked by kgunn last week to do it on Monday (so everyone was ready).
<didrocks> duflu: we still need:
<didrocks> 1. to get an email from you knowing you are doing so
<didrocks> 2. you need to ensure we can build unity-mir and u-s-c from it
<didrocks> which isn't the case, right?
<duflu> didrocks: It's impossible to guarantee those simultaneously. And I wasn't aware of any failures. In fact I argued we shouldn't do a pull at all
<didrocks> duflu: so please revert this pull
<duflu> didrocks: Sure
<didrocks> as long as you aren't sure you aren't ready
<didrocks> thanks
<didrocks> reverting to the previous version we released please
<didrocks> Mirv: sil2100: FYI ^
<didrocks> Mirv: sil2100: remove them from the ppa please
<Mirv> didrocks: ok, so so you also want a push --overwrite of the trusty branch to previous released version, or would it be enough to disable mir building + remove all relevant PPA packages?
<didrocks> Mirv: let's get duflu put his trunk in shape again
<didrocks> so just remove the components from the ppa
<didrocks> and rekick a build for them
<duflu> Mirv: An overwrite will be required. As we've lost the history of the post-0.1.0 Ubuntu changes. There's a weakness in the new system
<duflu> I'm not sure who/where still holds a copy of that
<didrocks> (mir, platform-api, unity-mir, u-s-c)
<Mirv> didrocks: ok, duflu should be better suited to do that, as also the mir/trusty history is gone and there is no release commit anymore of the previous release
<duflu> didrocks: I can take it back to 0.1.0 vanilla, but we don't have the history to restore 0.1.0+14.04.20131030-0ubuntu1 accurately
<didrocks> Mirv: really?
<didrocks> duflu: urgh? what have you done?
<Mirv> didrocks: yep https://code.launchpad.net/~mir-team/mir/trusty
<sil2100> ;/
<didrocks> duflu: what happened so that you reverted our commit?
<didrocks> can you please restore it?
<Mirv> didrocks: I think it's the development branch push --overwrite:d to the stable branch
<didrocks> that was explicitely forbidden
<duflu> didrocks: The pull clobbered it (as bzr noticed the same code in development-branch). So you lose the Ubuntu-specific history
<didrocks> duflu: yeah, please restore it, manually
<duflu> ... happens even without --overwrite
<didrocks> and pull that to the dev branch
<didrocks> I think we'll go again with merging if the mir team doesn't know what they do
<duflu> didrocks: Dev is sacred and not overwritable. This is definitely a weakness in the system. If it stops arguments, I don't care if we revert to merging
<didrocks> duflu: so let's merge dev to trunk then
<didrocks> trunk is sacred
<didrocks> and should not be overwritable
<didrocks> you are messing with the whole system
 * didrocks isn't happy
<duflu> didrocks: Yes, I never considered this possibility. I can rebuild the branch by hand, but not with the same history as it had
<didrocks> duflu: so yeah, rebuild with what we had
<didrocks> with 0 change from distro
<didrocks> and the changelog in
<duflu> didrocks: OK... rebuilding back to zero diff to distro
<didrocks> thanks
<duflu> didrocks: Although merging to trunk means it's no longer "sacred" because merge makes the history rubbish :(
<duflu> Hmm
<didrocks> duflu: well, at least, we ensure each commit from trunk can be buildable
<didrocks> with the right soname and so on
<didrocks> which isn't the case when you pull dev to trunk
<didrocks> but I think we already show that pulling dev to trunk is an issue
<duflu> didrocks: Yeah I don't care to argue about it any more. Rebuilding...
<didrocks> thanks duflu
<didrocks> duflu: can you give a sign to Mirv and sil2100 once done?
<duflu> didrocks: Yep. When done I'll reinstate append_only too
<duflu> didrocks,Mirv,sil2100: lp:mir restored to 0.1.0+14.04.20131030-0ubuntu1
<didrocks> thanks
<Mirv> duflu: thanks
<tvoss> greyback, good morning
<sil2100> Thanks
<duflu> ... and now append-only. All pull/push attempts will fail
<greyback> tvoss: hi :)
<duflu> ... I mean pull/push attempts that clobber history will fail
<duflu> didrocks: Does this mean the Ubuntu branch isn't used for anything? (lp:ubuntu/mir)
<didrocks> duflu: this is for automated import from debian, it doesn't work with dailies
<duflu> Ah
<duflu> didrocks: I still can't help but think... what you want from lp:mir is all about Ubuntu requirements, so it should live in lp:ubuntu/something
<didrocks> duflu: you are merging your branch based on ubuntu rules
<didrocks> it's the case for the 250 components we ship and develop upstream
<didrocks> I don't think Mir should have a special treatment
<didrocks> in addition, all teams following the ubuntu/canonical requirements are quite successful in the way they are handling their projects
<didrocks> I think the Mir team should start listening as well to go the same path
<duflu> didrocks: I completely agree with your frustration, which I think is rooted in Mir's lack of stable server ABI. I was arguing against exposing what we have now, and what has led to this situation long before it happened :(
<didrocks> duflu: I'm afraid the only way to mitigate this right now is this dev branch + merging back trunk
<duflu> didrocks: Yep. *everything* is append_only again.
<didrocks> yeah, sounds good :)
<tvoss> duflu, didrocks I would like to point out again that the server api is meant to evolve
<didrocks> tvoss: I don't care as long as transitions are coordinated and everything is known to build against the new API
<tvoss> didrocks, sure, that's the problem we need to tackle, fully agreed
<didrocks> just as told during the sprint, be aware that we have to block everything for 5 hours at each ABI breakage
<tvoss> didrocks, sure, but I still think that an ABI break shouldn't be an unusal case, but considered the normal situation :) Anyway, I know why we need to block right now, so point taken
<duflu> didrocks: Is there a solution in place to locking/unlocking atomic changes between projects? Or is it just convention that consumer projects get updated before providers?
<didrocks> tvoss: you can break your interfaces, but the way it's dealt with would mean everything should be in the same project (source)
<didrocks> duflu: it's a convention for now. I proposed a new CI vision that the infra CI team will start building soon where we can put in place "transactions"
<didrocks> (over multiple projects)
<duflu> didrocks: Yep, "transactions" is the word I meant
<didrocks> your team will be one of the piloting team on that I guess :)
<duflu> didrocks: Isn't that backwards to how non-Canonical updates work? I mean we can't control changes to all non-Canonical "provider" projects like that (?)
<didrocks> duflu: right, but on those projects, people are backward compatible most of the time
<didrocks> we are still at glib2
<didrocks> or gtk3
<didrocks> after years
<duflu> didrocks: Yeah I've never seen an ABI change as much as Mir :)
<didrocks> so yeah, the system will be a way to help for them as well
<didrocks> but not be a requirement
<didrocks> (at least, for now)
<mlankhorst> hey
<mlankhorst> RAOF: ping?
<mlankhorst> it looks the easiest way to support glamor-egl with xxv-ati might be to simply use the same codepath as used by nested mir
<mlankhorst> or I guess make glamor-egl use mir natively without gbm
<duflu> mlankhorst: It's 21:30 for him
<mlankhorst> yeah, I'll look into it a little myself
<mlankhorst> I guess the easiest way is to bypass most of xmir :P
<mlankhorst> hm and I guess it *could* be done in a generic way, removing all the crap from the ddx, only requiring glamor-egl and xorg-server
<Prf_Jakob> mlankhorst: just a quick question, is the plan to use glamour-egl on all drivers as a for of generic driver for Xmir?
<mlankhorst> no idea yet :P I guess some egl magic will be used, and some mir magic for input/screens
<Prf_Jakob> Ok
<Prf_Jakob> If you read my response on mir-devel we have found that xa (and probably glamour) would be slower then software (at least for not insane window sizes).
<mlankhorst> hm don't know if I'm subscribed there *checks*
<tvoss> Prf_Jakob, hey there :) just spotted your nick :)
<mlankhorst> oh indeed
<Prf_Jakob> tvoss: hey hey!
<mlankhorst> sigh vmware being different again
<Prf_Jakob> virgil will be in the same position.
<Prf_Jakob> So its not just us.
<mlankhorst> virgil doesn't have egl though?
<Prf_Jakob> its a gallium driver, so I guess it does.
<mterry> Hello!  I see a problem in nested Mir mode with autopilot input (both host and nested Mir see input, but don't act on it).  I've got some time to investigate on my own now and I was wondering if anyone had any pointers to likely culprits?
<kgunn> alf_: racarr  ^ see post from mterry
<alf_> kdub: http://paste.ubuntu.com/6365435/
<alf_> mterry: I don't if it's relevant in your scenario: if there isn't a focused window, input gets dropped
<alf_> +know
<mterry> alf_, this seems to be a difference between running nested and not.  Like I'm running the same autopilot test in each case, so it's probably not a focus issue
<alf_> mterry: is there a manual way to reproduce this, or does it happen with autopilot only?
<alf_> kdub: also as a second test: http://paste.ubuntu.com/6365552/ i.e. check that the device can display buffers that are also marked as texture-capable
<kdub> alf_, i'm not as worried about the 'second test'
<alf_> kdub: fair enough :)
<mterry> alf_, looks like I got disconnected.
<mterry> mterry> alf_, I've only seen it with autopilot
<alf_> mterry: can you track where the input event messages stop?
<alf_> mterry: I mean in which component in mir or unity8
<mterry> alf_, that's my next step, yeah.  But it's affecting both unity8 and apps, so it's probably not unity8-specific
<mhall119> so I've been running Mir on my x220 laptop for about a week now, and so far so good, but has anybody had an issue where the screen flickers sometimes when Chromium is reloading a page?  I've only seen it do this on G+, and not all the time
<mhall119> w 80
<mhall119> ah, still flickering in r10 on the Nexus 7 :(
<davmor2> mhall119: you don't know what flickering is till you install a unity3d app :)
<mhall119> also, on both my phone and my laptop, if the screen turns off and I turn it back on (power button on the phone, mouse movemenet on the laptop) I see what was displayed before it shut off for a split second before it goes to the lock/welcome screen
<mhall119> is that a known bug or should I file it?
<mhall119> kgunn: ^^ ?
<racarr> mhall119: I think its 'known' but im not aware of a bug filed
<kgunn> time flies...eating a very late lunch
<kgunn> and back
<ogra_> lunch flies too then :)
<kgunn> racarr: you still working on the mir on mir (or is it side by side) mir bugs ?
<racarr> kgunn: Yes  I'm tryingto findwhy input is failing under autopilot now
<kgunn> racarr: that's cool....was just wondering
<kgunn> thinking....i'd like to satisfy thomi 's request for fb grabbing and input coordinates (probed) from AP
<kgunn> racarr: but that change would likely be a shell change maybe ?...e.g. i don't think AP would talk direct to mir
<kgunn> thomi: ^ or do you even care what you talk to ?
<kgunn> you = AP in this case :)
<kgunn> btw, i watched Pi...
<kgunn> i want those minutes of my life back :)
<thomi> kgunn: haha
<thomi> kgunn: AP doesn't really care who we talk to. I guess the important thing  is that it's relatively easy to communicate from python, and that there's not a huge delay involved
<thomi> but dbus would be fine I think
<racarr> kgunn: Seems kind of like dbus to the shellyeah
<kgunn> thomi: i also watched scanner darkly way better
<thomi> yeah, that's a good movie
<kgunn> racarr: kdub ....any volunteers to review and approve ? https://code.launchpad.net/~mir-team/mir/development-branch/+merge/194018
<kgunn> our branch is getting stale
<kdub> i can review
<kgunn> kdub: ta
<kdub> kgunn, why do we go from so.9 to so.10?
<kdub> sorry, to so.11
<kgunn> kdub: yeah i noticed that as well....i think alan subsequently broke again...so he bumped again
<kgunn> kdub: related to my statement about didrocks wanting per comit survivability
<kgunn> kdub: it doesn't hurt anything...but its odd
<kdub> kgunn, well, i approved
<RAOF> tvoss_: Somewhat belated bong.
<RAOF> Or even pong.
<kgunn> RAOF: just fyi....i have every intention of showing up at the 1am
<kgunn> bailing for dinner now...
#ubuntu-mir 2013-11-06
<RAOF> racarr: ^^^ Looks like kgunn would like the meeting to be on this week :)
<racarr> Oi
<RAOF> racarr: Oh, by the way - do we have an input driver model?
<RAOF> My vague understanding of our current input stack is that it expects to open an evdev device and go to town.
<RAOF> I ask this for the reasonably transparent reason that I'll soon be wanting to fold a touchpad driver into the mix.
<racarr> RAOF: Yes basically open an evdev device and go to town
<racarr> actually though all that is constrained to EventHub which emits droidinput::RawEvents
<racarr> and you could call that the driver
<RAOF> So I get to implement an input driver API. Huzzah!
<racarr> but its hardly a driver model
<racarr> RAOF: Living the dream ;)
<duflu_> Ping kgunn
<RAOF> duflu: Maybe you can talk with him at the meeting this afternoon? :)
<duflu> RAOF: That one that no one has come to for a month and I think we informally canceled?
<RAOF> Yeah, that one.
<RAOF> kgunn was on earlier mentioning that he was going to show up this time.
<duflu> Awesome. If only anyone replied to my email about canceling it... or turned up
<duflu> RAOF: Am I in the right hangout? I uninstalled my calendar plugin today so am guessing
<RAOF> Gah. Why hasn't the email with the hangout link come in yet?
<duflu> RAOF: No. I suspect kgunn canceled it after my email :)
<RAOF> Still only static?
<kgunn> RAOF: duflu i'm here...but meeting is in 1 hr i think
<kgunn> we had daylight savings last weekend...bet that's the prob
<duflu> kgunn: Oh. It's on your timezone?
<duflu> kgunn: RAOF and I are in, and we don't expect anyone else
<kgunn> hmmm....lemme check
<kgunn> yeah...i'm showing 1 hr from now
<kgunn> and alexandros is good about showing right ?
<duflu> kgunn: We kind of agreed to cancel it after alf and I were the only attendees for several weeks :)
<kgunn> yeah...
<kgunn> we need to come up with a decent time
<kgunn> i sort of feel like we should maybe have like 3 rotating spots or something
<RAOF> Maybe.
<duflu> kgunn: If you want to chat at all today, we're "all" in the hangout now :)
<kgunn> ok
<racarr> wait are wedoing it now?
<tvoss_> good morning
<mlankhorst> g'day
<duflu> mlankhorst: hallo
<mlankhorst> alf_: hey, did you ever end up merging the mesa / mir changes back? :P
<alf_> mlankhorst: are you referring to the EGLImage changes?
<mlankhorst> yeah
<alf_> mlankhorst: yes, they are in RAOF's github repo
<mlankhorst> ok what about the mir changes?
<alf_> mlankhorst: I don't remember exactly what additional changes were needed on the Mir side, but nested mir works now with lp:mir (or at least it worked last I checked)
<mlankhorst> ah k
 * alan_g smells a missing test case
<mlankhorst> hehehe, 'git merge ubuntu' on raof's branch then commenting out the mir patch in debian/patches/series works :P
<mlankhorst> alf_: but what about my fixes ? I disabled vt switching in the nested case
<alf_> mlankhorst: hmm, I am not sure... do you have a link to your changes/branch?
<mlankhorst> http://paste.debian.net/64293/
<alf_> mlankhorst: instead of passing a nullptr it would preferable to pass a NullObject, in this case a NullVirtualTerminal. There is an implementation of that in include/test/mir_test_doubles/null_virtual_terminal.h, so we just move that to src/server/graphics/gbm and use it (and also change the tests to use that too)
<mlankhorst> :/
<mlankhorst> hm lets see..
<mlankhorst> alf_: http://paste.debian.net/64300/ -- enjoy?
<alf_> mlankhorst: Looks good, thanks (only some nits). I will shepherd it into trunk if you want.
<mlankhorst> please :)
<alf_> mlankhorst: ok
<mlankhorst> seems acceptance-tests.ServerShutdown/OnSignal and ServerShutdown.server_removes_endpoint_on_abort hang?
<alf_> mlankhorst: Is it a consistently reproducible? I remember there was a bug about something similar, but I think it was resolved.
<mlankhorst> sort of, it happens in my chroot
<alf_> mlankhorst: hmm, I get a consistent failure (not a hang) in ServerShutdown/OnSignal.removes_endpoint_on_signal/2
<alf_> mlankhorst: ...but only if I run the tests manually. If I use ctest everthing works.
<mlankhorst> oh seems to be random here
<mlankhorst> some other tests can fail too
<mlankhorst> heh maybe my system is too fast :P
<mlankhorst> C++ exception with description "Failed to find server" thrown in the test body.
<mlankhorst> /home/mlankhorst/nfs/xorg/mir/tests/mir_test_framework/testing_process_manager.cpp:240: Failure
<mlankhorst> Value of: server_process_was_started
<mlankhorst>   Actual: false
<mlankhorst> Expected: true
<alf_> mlankhorst: btw, are you using the latest development-branch?
<mlankhorst> not sure, last commit i have is from nov 3 :P
<mlankhorst>     Restore:  mir (0.1.0+14.04.20131030-0ubuntu1) trusty; urgency=low
<mlankhorst> hm nov5
<alf_> mlankhorst: ok
<alf_> mlankhorst: actually, the patch may not be needed after all... we create a different kind of platform when nested ("native platform") which doesn't use the VT at all
<alf_> mlankhorst: did you actually have a problem with the current state of the code?
<dandrader> greyback, ping
<greyback> dandrader: pong
<dandrader> greyback, working on the mir-with-qtscenegraph prototype?
<greyback> dandrader: yep
<dandrader> greyback, let me know when you're something I could use to start experimenting with the input part of it
<dandrader> greyback, or if you need help with it
<dandrader> s/you're/you've
<mlankhorst> alf_: oh is that different? :P
<mlankhorst> i think it used to be needed
<mlankhorst> my bad then
<greyback> dandrader: thanks, I'll remember that :) I've a good day or 2 of hacking to get the basics going, but then I'll ping you
<Prf_Jakob> alf_: hey
<alf_> alf_: hi!
<alf_> Prf_Jakob: hi!
<Prf_Jakob> I'm thinking a bit longer term here, but would you guys be okay with using egl to accessing buffers?
<Prf_Jakob> I'm thinking of trowing together a extension for shadowfb type blitting to images.
<Prf_Jakob> (disclaimer: I'm on the EGL WG at Khronos).
<alf_> Prf_Jakob: Do you mean for the client to access buffers, or for the server to access buffers?
<Prf_Jakob> It can be done in multiple ways, but one way would be that the server creates hardware image, you prime/dma-buf it over to the client (can be hidden in the toolkit) and then create a shadow on the client side which it uses for fast access.
<Prf_Jakob> Alternativly you could prime over the shadow image.
<Prf_Jakob> Both would require you to still load the hardware driver (in our case our mesa dri driver) in the client.
<alf_> Prf_Jakob: I think it would be a useful extension that will cover some of the direct pixel access use cases, although there would still be apps/toolkits that for whatever reason don't want to do EGL/GL at all.
<alf_> tvoss_: ^^ Was there a specific driving case for "software" buffers?
<Prf_Jakob> alf_: yet they are okay with gbm :/
<tvoss_> alf_, plymouth was the original one, yeah
<alf_> Prf_Jakob: that's a good point
<Prf_Jakob> I mean at that point you have already pulled in the dri driver and all the gl bits into the process VM anyways.
<alf_> Prf_Jakob: Actually, a pure "software" client, doesn't load gbm. It currently only uses DRM to map dumb buffers.
<Prf_Jakob> Ah
<Prf_Jakob> Not to comfirtable putting that much of acceleration API in the kernel.
<alf_> Prf_Jakob: :)
<Prf_Jakob> Trying to eat the gpu cake and keeping the not using gpu API cake.
<kgunn> goin' to work out
<racarr> finally making some good progress on my persistent goal of
<racarr> improving theinput acceptance testing framework...
<racarr> hopefully should be able to make an MP with a net line of codeloss :)
<RAOF> Huzzah!
#ubuntu-mir 2013-11-07
<mterry> Heyo!  Does anyone know what drives the creation of the autopilot-finger device in Mir when running under autopilot?  It's not being created correctly in the nested case
<thomi> mterry: I probably do
<thomi> mterry: but I'm not sure I understand the questino :)
 * mterry jumps on thomi and doesn't let go
<thomi> *question, even
<mterry> thomi, I'm looking at running unity8 in 'nested mode' which is where there is a system Mir and a user Mir
<mterry> thomi, input works fine normally
<mterry> thomi, but when under autopilot, the Mir autopilot-finger device gets created as an external pointer, instead of an internal touchscreen, as it should
<thomi> so, when you say "external pointer, instead of an internal touchscreen", is the problem that it shows up as a mouse device, and not a touch device?
<thomi> or the "external" vs "internal" bit?
<mterry> thomi, I believe the problem is that it's a pointer, not a touchscreen.  Because the symptom I'm seeing is that drags don't happen.  And movement with a pointer probably isn't translated into a drag without a button down
<thomi> hmm, so autopilot only supports multi-touch under mir. In order for it to create a mouse device it needs xlib bindings
<mterry> thomi, well, I suppose those are installed.  But I'm not sure why it would decide to do that?
<thomi> it wouldn't, unless the test case asked it to
<thomi> I suspect the problem is elsewhere
<mterry> thomi, I'm running the same test case just with different Mir config
<thomi> do you have a test log from the failure?
<mterry> thomi, yeah  :-/
<mterry> thomi, yeah I've got a log, but with quite a bit of me-specific Mir debugging printfs in it
<mterry> thomi, I'm guessing this is a Mir bug, not an autopilot one
<thomi> so in the AP log, if you see '_uinput' lines, you're using uinput, which means multitouch
<mterry> thomi, well, it makes two devices, one is "py-evdev-uinput" and one is "autopilot-finger", which I'm guessing means it's using uinput
<thomi> mterry: right - the first is the keyboard device
<thomi> the second is the multi-touch device
<mterry> thomi, ah, ok
<alan_g> alf_: any thoughts on https://code.launchpad.net/~robertcarr/mir/client-input-report/+merge/194028 (if not I'll just top-approve)
<alf__> alan_g: sorry, network problems, I am ok with the MP
<alan_g> alf__: nw
<alan_g> alf__: I was just referring to the C++ standard and could not help noticing that the declaration style there is the one Daniel thinks is used by a few eccentrics.
<alf__> alan_g: Some people argue that all C++ users are eccentrics, and we should just go back to C ;)
<alan_g> Some people are welcome to put that into practice (so long as they stop bothering me)
<kgunn> Mirv: just a heads up...we're wanting to update our mir trunk & we have an abi break that needs coordinating, i'll ping you on monday as i understand you guys are struggling to get back to green
<racarr> Morning
<alan_g> kdub: any guess what bug 1249019 might be?
<ubot5> bug 1249019 in Mir "Test failure: AndroidGPUDisplay.hwc_display_ok_with_gles" [Undecided,New] https://launchpad.net/bugs/1249019
<kdub> alan_g, perhaps unity8 is running?
<kdub> let me try
<racarr> alan_g: Try running
<alan_g> kdub: Nope - it fails the first iteration then
<racarr> powerd-cli active
<racarr> and backgroundingit
<kdub> yes, could be that too
<racarr> powerd can put the screen in to a suspsned state that mir cant remove attimes
<alan_g> This is a pass once fail second time scenario
<alan_g> racarr: "powerd-cli active" says "Press ctrl-c to exit."
<racarr> alan_g: Yes you background it
<racarr> the functionisas long as it is alive
<racarr> it keeps powerd in the active state
<racarr> weird interface
<alan_g> racarr: still get a SIGABRT on the second test cycle
<racarr> alan_g: :*
<racarr> :(*
<racarr> not aware of it then
<alan_g> racarr: I'm guessing it is a teardown problem - If I repeatedly run the test executable it doesn't show a problem
<racarr> ah
<racarr> I love writing the literal for a null function "[](){}" lol
<kdub> racarr, hah, yeah
<kdub> ({[](){},[](){}})
<kdub> initializer list of null functions
<racarr> kdub: Code is poetry ;)
<racarr> poetry is just getting reallymodern
<racarr> lol
<sarnold> lol
<RAOF> Whee! Alarm clock malfunction - ZoÃ« didn't wake up until almost 9 this morning.
<RAOF> In her defence, she woke up quite a lot during the night :/
<olli_> RAOF, and what exactly are you giving her? can i get this in the US or can you send some over?
<kgunn> kdub: hey...so the 4 integration tests we were chatting about earlier...if i do apt-get install mir-test-tools will that pull those in ? or do i have to build them ?....i guess i should just ask...how to build and run the 4 tests :) ?
<kgunn> kdub: just a matter of curiosity...i noticed the cmakelist.txt for test_client_render has a if( MIR_PLATFORM STREQUAL "android")
<kgunn> but the others (buffer, display, internal_client) don't....
<kgunn> even tho they're under graphics/android...
<kdub> kgunn, that directory is disabled
<kgunn> kdub: disabled in a sense, those don't become part of mir-test-tools ?
<kgunn> brb...picking up man-child
<kdub> kgunn, http://bazaar.launchpad.net/~mir-team/mir/trusty/view/head:/tests/integration-tests/CMakeLists.txt#L21
<kdub> all of them are compiled on android, but not gbm
<kgunn> ah
<kdub> not really sure what goes in that package, have to check
<kgunn> ok...wife going now...
<kgunn> so what package do those tests go into is the better question kdub
<kgunn> ?
<kdub> kgunn, i'll send an email
<kgunn> kdub: thanks dude!
<racarr> Oh yeah deleting
<racarr> morecode :D
<kdub> racarr, i'm having that experience too over in the android code world
<kdub> 'whoohoo, less code!'
<kgunn> that's good to hear
<racarr> kgunn: It should all be gone by january at the latest
#ubuntu-mir 2013-11-08
<kgunn> racarr: lol...like all the code...?
<Mirv> kgunn: ok, and yes still trying to get all apps green
<RAOF> Really? EventHub uses inotify to watch /dev/input to do hotplug? :(
<tvoss> RAOF, we have a bug open to adjust that admittedly wrong behavior :)
<RAOF> The EventHub is a big ball of spaghetti, isn't it.
<tvoss> RAOF, it is, we need to split it up a little :) we haven't done so far to avoid too big of an investment
<tvoss> RAOF, however, as we prepare for the scenegraph changes, we will tackle the EventHub/InputReader, too
<tvoss> RAOF, if you want to see convoluted, special-cased code, look at InputDispatcher ;)
<tvoss> that's real fun
<RAOF> I'm less interested in that, because dispatching happens after libtouchpad :)
<RAOF> Wheras EventHub is all up in libtouchpad's business.
<tvoss> libtouchpad?
<RAOF> https://github.com/whot/libtouchpad
<RAOF> AKA: make touchpads not horrible.
<tvoss> RAOF, hmmm, interesting, will have a look
<RAOF> Not much there yet, but I plan to help Peter migrate the various bits of functionality from xf86-input-synaptics.
<RAOF> But 8:30 says âtime to stop workâ :)
<duflu> RAOF: Yes there's a problem if I reach my EOD before you :)
<alan_g> greyback: would you check another tweak to unity-mir for me? https://code.launchpad.net/~alan-griffiths/unity-mir/make-portable-across-Mir-versions/+merge/194479
<alan_g> greyback: (repeat in case you missed it) would you check another tweak to unity-mir for me? https://code.launchpad.net/~alan-griffiths/unity-mir/make-portable-across-Mir-versions/+merge/194479
<greyback> alan_g: I missed the first ping. Yes I'll look now
<alan_g> greyback: thanks
<greyback> alan_g: approved, thanks
<alan_g> greyback: ta
<greyback> alf__: question for you: when a display is connected or removed, how is a new CompositingFunctor created/destroyed? Is it that the MultiThreadedCompositor is stopped and then started?
<greyback> And then a second more general question: how is vsync respected? I don't see what blocks after a frame is ready, until vsync is done
<alf__> greyback: 1. Yes, the MultiThreadedCompositor is currently torn down and set up from scratch
<greyback> ok
<alf__> greyback: 2. the blocking happens in DisplayBuffer::post_update(), which is currently called internally by the DisplayBufferCompositor since it needs to call the right overload (with or without bypass)
<greyback> alf__: got it. Thanks!
<alf__> greyback: yw
<kgunn> robotfuel: hey...i'm probably gonna miss the standup (have an external call)...did you happen to file a ci feature bug for adding our demo clients ?
<kgunn> i know we spoke a few days ago...just following up
<robotfuel> kgunn: yes, I already have a test runner for it as well that will pass or fail a demo after running x number of seconds depending on return code or stderr
<kgunn> robotfuel: cool...is it strictly binary for running or not ? or does it look at the performance as its pass/fail ?
<kgunn> robotfuel: just thinking if we could look at the fps # it would help prevent things like this...https://bugs.launchpad.net/mir/+bug/1249210
<ubot5> Ubuntu bug 1249210 in Mir "Mir client frame rate regression in r1196" [Critical,Triaged]
<robotfuel> kgunn: we will add performance eventually as it's printed on tests in standard out, but we need to get data, before we can pass fail based on it.
<kgunn> robotfuel: cool....glad to know you're on it
<kgunn> appreciate it
<kgunn> kdub: so i thot i'd be clever and try to build mir on the device to test the integration tests
<kgunn> sounds like a yo dawg meme
<kgunn> kdub: so all was going ok until i got to cmake ..
<kgunn> kdub: then it complains about the boost libs
<kgunn> kdub: i was now going to try to install them...but just wondering why that's not taken care of through all the install steps (devscripts, build-essential etc)
<kdub> kgunn, i think there is a tool in devscripts for that... i usually use pbuilder-satisfydepends though
<kdub> dpkg-genbuilddeps
<kgunn> kdub: hmmm...i'm doing apt-get install libboost-dev-all
<kdub> that should work too
<kgunn> yeah...more than 1 way to skin a cat
<kgunn> kdub: just to make sure (while i wait on the world to download)...if i simply say "YES" in the rules file for integration test, they should run as part of the build correct?
<kdub> i believe so, but its not something i've tried recently
<greyback> Hey, am I reading this wrong: http://bazaar.launchpad.net/~mir-team/mir/trusty/view/head:/include/platform/mir/graphics/display.h <- does create_gl_context() create a GL context which spans all physical displays?
<kdub> greyback, i think thats how it works
<greyback> kdub: hmm , I was expecting a gl context per framebuffer
<kdub> alf__, would object if i'm wrong though :)
<kgunn> greyback: fwiw, i've actually seen both...context per & 1 for many
<greyback> kgunn: ok. I know both do-able, but I thought i heard someone mention Mir did context per fb. Was just checking
<greyback> think 1 context per many makes my life easier
<kgunn> still a good question...maybe alf__ will enlighten us
<kgunn> i really really heart verizon and their damn wifi route today :-|
<alf__> greyback: Each DisplayBuffer gets its own GL context. However, all contexts, including the ones returned by create_gl_context(), are created sharing a common base share context, so they can all access shared resources (like textures).
<greyback> alf__: ah cool
<greyback> I didn't know that could be done
<alf__> greyback: for a caveat about multithreading with shared contexts see the comment in src/server/compositor/gl_renderer_factory.cpp
<greyback> alf__: understood
 * greyback eod
<racarr> Had a full system hang from mir_demo_server_shell :(
<doneill_> sam113101: we should've been talking Mir over here, hah!
<sam113101> doneill_: yeah
<sam113101> doneill_: do you work on mir?
<doneill_> Anyway, I suspect you'll bump into Unity-isms in Mir when you start implementing. I'd suggest poking around the Unity8 code and borrow gfx/input initialization from there.
<doneill_> No, I work on Ubuntu Touch apps, but at this stage it requires being at least moderately familiar with Mir and how it works.
<sam113101> ok
<doneill_> I'm not in a very different position than you, except instead of weighing the options I'm using both Mir and Wayland.
<robotfuel> racarr: ping
<racarr> robotfuel: pong
<robotfuel> racarr: I asked the question in #mir
<robotfuel> racarr: :D
<racarr> I see
<racarr> I dontknow about the bug but I have seen it before(just haven't investigate yet)
<racarr> I will check it out once I finish 1249210
<racarr> I basically understand what is happeningwith 1249210 and have the fix butI dont quite understand
<racarr> why it results in halfFPS when bypassed
<racarr> robotfuel: Investigating now as soon as I get a clean build dir:)
<kgunn> updatin' to trusty....
#ubuntu-mir 2014-11-03
<seb128> hey mir team
<seb128> unity8 started segfaulting on start in vivid after recent updates
<seb128> is that a known issue?
<alan_g> seb128: I've just read some emails about it - but otherwise no
<seb128> where those emails?
<alan_g> seb128: well, actually it's about unity8 crashing on phablet@lists.canonical.com
<alan_g> "Sanity test results, rtm..."
<seb128> oh
<seb128> those are random segfaults
<seb128> on desktop unity8 session doesn't start anymore at all
<anpok_> last week someone said that..
<anpok_> i tried to reproduce with a vm.. but could not
<seb128> is mir having logs somewhere?
<seb128> unity8 is aborting in mir::DefaultServerConfiguration calls this time
<alan_g> The mir logs are opt-in I don't know if they're currently turned on for the desktop. (If so, there're probably wherever stdout goes for unity8.)
<seb128> how do I opt in?
<alan_g> DefaultServerConfiguration is usually only used in setup, do you know which calls are on the stack? Or does it vary?
<alan_g> http://unity.ubuntu.com/mir/component_reports.html
<seb128> alan_g, http://paste.ubuntu.com/8800848/
 * alan_g looks...
<alan_g> That is weird. It happens while allocating the memory in which to construct an object. (Which suggests the stack is already screwed.)
<alan_g> seb128: this is the current vivid install? I don't have that anywhere yet (not even on a VM)
<seb128> downgrading unity8 makes the session work, so maybe an issue in there rather..
<seb128> ...
<seb128> alan_g, yes, I've my test laptop on vivid, I just dist-upgraded this morning and I get that, downgrading unity8 makes it go away though
<mlankhorst> anpok_: hey, does mir support setting arbitrary cursors, and does it have support for input?
<anpok_> mlankhorst: havent tried cursors on android, but it ought to work there too?
<anpok_> what do you mean by input?
<anpok_> as in do we handle input? : )
<mlankhorst> on x86
<mlankhorst> I'm just curious, since I want to see if I can get a standalone xmir binary working, to understand the api a bit better
<mlankhorst> using glamor for accel
<mlankhorst> I think it would allow rootless xmir too, which is a todo if i understand it correctly
<mlankhorst> but in the cursor API I only see support for default cursor names
<racarr> mlankhorst: There are actually someexisting xmir glamor branches...but quite out of date at this point.
<racarr> as for cursors /usr/include/mircommon/mir_toolkit/mir_cursors.h
<mlankhorst> ah
<mlankhorst> racarr: yeah none based on when glamor was moved to xorg-server I guess?
<racarr> mlankhorst: Well based on a very early version of that uh
<racarr> I guess all the xwayland stuf fhas probablymade it way more straightforward
<racarr> I can't actually...find the branch right now...
<mlankhorst> yeah
<racarr> -.-
<mlankhorst> tbh I'm just going to cut and paste the xmir output enumeration crap and figure out how to generate a EGL context from mir. :P
<racarr> It used to be a lot more trouble than that because uhhhhh
<racarr> well the difficulty whenI did it was that
<racarr> glamor didnt use eglSwapBuffers anywhere
<racarr> and instead used two egl images of its own ownership
<racarr> which it swapped of its own accord
<racarr> and then posted to the
<racarr> display via secret driver API
<mlankhorst> shrug
<racarr> which wont work with mir :)
<mlankhorst> still don't see eglSwapBuffers anywhere, but can't you hack up glamor anyway? :P
<racarr> mlankhorst: Yes
<racarr> it didnt end up being totally trivial though...ugahsgahsg need to find the branch aha
<racarr> I am 95% sure I sent it to RAOF so I willl ping him this afternoon
<racarr> and make sure it gets to you
<mlankhorst> ok ty
<racarr> I am worried it may only be on my broken ;laptop but I dont think so
<racarr> becauseI remember onceI synced it to a tablet via wifi
<racarr> so its out there somewhere
<mlankhorst> ok
#ubuntu-mir 2014-11-04
<anpok> Avagetto: hi
<Avagetto> hi
<Avagetto> copy questiom here from enother chanel?
<anpok> i think the mir team is in all of the channels
<anpok> hmm what kernel are you using?
<anpok> and which drivers do you want to use?
<anpok> rk3288 is something with vivante?
<anpok> or mali?
<Avagetto> mali
<Avagetto> please wait one sminute
<Avagetto> We talked with you before, if you want I strip off you log a conversation
<Avagetto> i use kernel 3.10
<mlankhorst> RAOF: ping
<anpok> Avagetto: ah I remember
<Avagetto> I tried to install ubuntu touch but at boot it would hang when I didn't have access to the console.
<Avagetto> now i try use ubuntu-desktop-next packages
<anpok> Avagetto: to get unity8 + mir running on that gpu you need a the mir android graphics platform which relies on a working libhyrbris EGL/GL
<anpok> and that one needs the android userspace gpu drivers..
<anpok> Avagetto: i am not sure what you installed there so far?
<anpok> mlankhorst: he might still have flaky connectivity - yesterday he said that he might be best reached by mail..
<mlankhorst> ok
<Avagetto> anpok: I tried, but apparently somewhere made a mistake. now I sit and more carefully reread ubuntu touch porting guide. Then try to repeat the installation on the device. Now I don't want to distract You . Today or tomorrow I will write about the results or ask for more detailed information. Thank you very much.
<anpok> cool!
<anpok> Avagetto: i cant help you much with porting part.. but good that you keep on fighting
<alf_> alan_g: What's your concern about switching from high_resolution to steady? That is, where do you think high_resolution would be useful?
<alan_g> alf_: I don't have specific evidence we need it, but that isn't evidence it isn't needed.
<alan_g> Have you been through all the code that uses mir::Clock?
<alf_> alan_g: My rationale for removing it is: 1. HR isn't safe to time intervals with (unless it happens to be steady, but there is no guarantee) 2. it's not useful for wall clock time since there is no guarantee that it is the system_clock
<alan_g> I think we have three scenarios for use of "clock":
<alan_g> 1. To timestamp logs. For that "wall clock" is an appropriate metaphor
<alf_> alan_g: @been through code that uses mir::Clock, yes, we only use it for relative timings
<alan_g> 2. To measure elapsed time
<alan_g> 3. to timestamp event
<alf_> alan_g: I agree we should have different clock abstractions, but didn't want to introduce them here
<alf_> alan_g: e.g. different interfaces for a MonotonicClock and a RealTimeClock
<alan_g> alf_: OK given the above I don't object to steady clock
<alan_g> OTOH we could have one interface and three implementations
<alan_g> (Admittedly we couldn't just use the boost types for Timestamp and Duration then)
<alf_> alan_g: What I don't like about one interface is that different clocks provide different guarantees and it would be better to encode that guarantee in the type to avoid e.g. passing a system clock to a class that really needs to measure elapsed time
<alan_g> alf_: yeah. Was mostly speculating. If as you say we're only calculating intervals we don't need it yet.
<alan_g> anpok: did you discover why the USC tests were commented out?
<alf_> alan_g: as for not exposing the underlying std clock type, I wonder if we could make something like "using Timestamp = std::chrono::timestamp<mir::time::Clock,std::chrono::nanoseconds>" work, didn't try that...
<alan_g> alf_: there are lots of solutions but it is more complexity than we need now.
<anpok> alan_g: i guess by accident .. i.e. issues with sbuild .. maybe ..
 * alan_g takes that as a "no"
<anpok> :)
<anpok> i could rule out "oh, tests are failing, hmm how can i solve that"
<anpok> it happened with revision 166 http://bazaar.launchpad.net/~unity-system-compositor-team/unity-system-compositor/trunk/revision/166
<alan_g> Looks accidental -anyway I've MP'd a fix
<anpok> ok would have done the same .. since i was refactoring some things to get it testable
<alan_g> It is in dire need of refactoring - as I found out getting to work with mir::Server.
<anpok> i only do low level refactorings .. nothing that changes the big picture
 * alan_g suspects the big picture needs a re-write
<anpok> yes
<alan_g> If only there were some good acceptance tests. ;)
<anpok> the responsibilities are strangely distributed...
<alan_g> And WTF is Qt doing in there anyway?
<anpok> somebody should switch it to dbuscpp ..
<alan_g> /rant off
<anpok> need to grab kids.. brb
<alan_g> alf_: happy now? https://code.launchpad.net/~raof/mir/touch-all-the-things/+merge/240394
<alf_> alan_g: yes, top-approved
<alan_g> AlbertA: it was your change in -c 166 that commented out the tests. Any reason not to restore them? https://code.launchpad.net/~alan-griffiths/unity-system-compositor/uncomment-tests/+merge/240560
<AlbertA> alan_g: wtf.... totally missed that in code review
<AlbertA> alan_g: yeah that should not have made it in...
<AlbertA> that was just my local branch which I disabled tests to get it to cross-compile with the cross-compile scripts...
<alan_g> AlbertA: I guessed it was something like that. (Which is why we have code reviews...)
#ubuntu-mir 2014-11-05
<racarr> RAOF: How goes stub clientAPI stuff?
<robert_ancell> duflu, is mir_demo_server_shell and mir_demo_client_fingerpaint supposed to work in utopic? When I run them you don't seem to be able to draw with the mouse
<duflu> robert_ancell: Yes, it does work. Did you remember sudo (required for input device access)?
<robert_ancell> duflu, the server is run through sudo, yes
<robert_ancell> I'm getting motion events. And if I click on the fingerpaint window it drags it rather than drawing
<robert_ancell> duflu, are you running utopic? Can you confirm it working there?
<duflu> otp
<robert_ancell> ah, it seems that on first click it's in drag mode. If I hold down alt then drag the window it seems to work after releasing alt and then clicking.
<duflu> robert_ancell: Ah, could be a minor demo-shell issue stealing the events then
<duflu> Or not an issue at all
<duflu> Will test
<robert_ancell> It seems like the surface doesn't have focus. When I test GTK+ mir we're not getting any mouse up/down events even when clicking inside the surface until that first drag with alt.
<duflu> robert_ancell: Works fine immediately on startup for me (now using vivid but always worked in utopic too)
<robert_ancell> weird
<duflu> robert_ancell: I fully expect we have input bugs though. I can't reproduce this one is all
<duflu> robert_ancell: Oh, do you have multiple surfaces/clients when fingerpainting?
<duflu> I think I have observed that fingerpainting on an unfocused window only works sometimes
<duflu> Although I'm not sure it should work at all in our current design
<robert_ancell> Who knows the correct way to interpret a current Mir motion event? GTK+ Mir was looking at the button_state field to determine which button event to generate. But touch events seem to have button_state empty. You can't tell it's a touch event without looking at the pointer_coordinates field. If we get a down event with button_state empty just assume it's the primary mouse button?
<duflu> robert_ancell: There's a "tool" field to tell you if it's a finger or mouse (with buttons)
<duflu> In theory
<robert_ancell> duflu, only in the pointer_coordinates list - which could be a different tool for each event
<robert_ancell> for each coordinate I mean
<robert_ancell> We have the magic numbers for the device but no way to interpret them :)
<duflu> robert_ancell: Yeah you could be using multiple tools at once
<robert_ancell> I'm just going to generate a primary mouse button event if the field is empty
<duflu> robert_ancell: Technically you should look at all the pointer_coordinates because any one of them could be a mouse
<robert_ancell> But which one generated the up event?
<duflu> robert_ancell: Hmm sounds like a good question. I'm reaching the limits of my mental memory of the event struct
<robert_ancell> Based on previous discussions I think the answer would be "we're going to replace that struct"
<RAOF> robert_ancell: This discussion is going to be obsolete reasonably soon.
<RAOF> Hah, yes!
<robert_ancell> there we go :)
<duflu> robert_ancell: Kind of. It will hang around for a fair time because breaking the client API will be painful
<duflu> ... for distro
<RAOF> Do what you want for the moment, we'll provide you with an actual pointer in MirInputEvent 2.0
<RAOF> (As in - there'll be a core-pointer like device that is what you care about)
<duflu> robert_ancell: A reasonable kludge is only test pointer[0]
<robert_ancell> I'm just going to do if (button_state == 0) generate_event (PRIMARY)
<duflu> robert_ancell: Actually it's probably a good idea to separate button state from the pointer list. Assuming you don't care about multi-mouse support, you might want to use buttons in concert with some other device. So the device that has the buttons is irrelevant
<robert_ancell> What is with X generating out of order keyboard events when it gets laggy? Very annoying...
 * RAOF is confused and alarmed as to what the hell is happening on https://jenkins.qa.ubuntu.com/job/mir-utopic-amd64-ci/342/consoleFull
<duflu> RAOF: The leak?
<RAOF> That, and the 25 failing tests are failing with valgrind errors in totally unrelated code.
<RAOF> If you look at it, ClientLibraryErrors.create_surface_returns_error_object_on_failure completes fine.
<duflu> RAOF: Yeah I think that's "normal" with valgrind errors... some tests will fail delayed
<RAOF> And then 25 *unrelated* tests fail with by 0x5EA268: ClientLibraryErrors_create_surface_returns_error_object_on_failure_Test::TestBody() (test_client_library_errors.cpp:206)
<RAOF> Oh, it's probably something to do with forking.
<duflu> That's fun. Compiz is mentioned in a kernel header... #define KEY_SCALE               120     /* AL Compiz Scale (Expose) */
<alan_g> alf_: anpok_ any opinions pending on this? https://code.launchpad.net/~alan-griffiths/mir/mir_Server-apply_settings/+merge/240612
<alf_> alan_g: commented
<alf_> alan_g: (approved)
<alan_g> alf_: thanks. (I'll now base my next MP on it.)
<racarr> AWS outage causedirssi to die
<racarr> private message bankruptcy :)
#ubuntu-mir 2014-11-06
<alan_g> does anyone know why the "mediumtest" jobs are not running in CI since the switch to vivid?
<alf_> alan_g: no
<alan_g> alf_: "<vila> alan_g: looks like the mir-mediumtests-vivid-touch doesn't exist, will ping fginther"
<alf_> alan_g: ack, thanks
<alf_> alan_g: the bright side is that our MPs pass through CI a lot faster now :)
<alan_g> LOL
<anpok> https://code.launchpad.net/~andreas-pokorny/unity-system-compositor/expose-powerkey-state-and-screen-toggle-controller-interface would be nice if someone reviews this change.. but not top approve.. it is not meant to be released next week
<anpok> i found a lot of low hanging fruits while doing this..
<alf_> anpok: ok
<anpok> the actual change is kind of trivial... but i needed the code separation..
<anpok> i mean.. i struggled with relating the code to the actual system behavior
<anpok> especially those timeouts..
<alf_> I wonder why/when the tests where commented out...
<alan_g> alf_: it was an accident
<anpok> because they werent working with the cross compile setup
<anpok> usc is also one of the pacakges that do not build with a x-sbuild
<alf_> alan_g: anpok: thanks
<alf_> alan_g: anpok: I was thinking about whether it's worth for time::Timer to have the convenience functions notify_in() and notify_at(), since we can just say "auto alarm = timer.create_alarm(); alarm->notify_in(..);" instead.
<alan_g> That looks like a repeating pattern that could be simplified. So yes.
<anpok> i would have no objection to reduce it to just that
<alf_> ...and the convenience functions return an Alarm object anyway, which we still have to keep alive
<anpok> so from looking at usc .. it is also just .. create_alarm + notify_in that is in use
<alf_> alan_g: anpok: Even if we want them as part of the interface, I am not sure they are worth it as pure virtual functions. Perhaps they could have a default implementation.
<alf_> anpok: yes, the same in Mir proper
<alan_g> I agree they're not appropriate for overriding. Technically they could even be free functions.
<alan_g> But I'd go for non-virtual TemplateFunctions (not C++ templates, just the design pattern)
<desrt> hi hi miristoj
<desrt> what's the word on the prerolled nature of the cursor-names available for use with mir?
<attente_> hi, when i try to run an app from a vt, i keep getting an error like Failed to connect to Mir: connect not called or Failed to send message to server: Broken pipe
<bschaefer> attente_, make sure you've set the socket permissions
<bschaefer> as well as
<bschaefer> export MIR_SOCKET=/tmp/mir_socket (or /path/to/socket)
<desrt> bschaefer: the socket is in the xdg runtime dir with the correct perms
<bschaefer> desrt, when i run mir_demo_server_* it puts it in /tmp for me :(
<desrt> this is a unity8 graphical session
<bschaefer> oo i see
<bschaefer> usually if you've mir in a vt you've got a mir_demo running
<attente_> bschaefer: i'm just trying to figure out how i can run something under unity 8 in a terminal session
<bschaefer> attente_, oo hmm i think ubuntu-app-launch?
<bschaefer> will let you do that, or --desktop_file_hint=/path/to/desktop/file
<attente_> bschaefer: ubuntu-app-launch is giving me Unable to connect to Upstart bus: Cannot launch D-Bus without X11 $DISPLAY
<bschaefer> attente_, i've had that before ... but i didn't get around it :(
<bschaefer> thats a ted question
<bschaefer> tedg, ^
<tedg> attente_, usually means for some reason you didn't get the DBUS_SESSION_BUS_ADDRESS variable set in your environment.
<tedg> attente_, How is your shell session being created?
<attente_> tedg: i'm logging into unity8 from the greeter
<tedg> attente_, And then opening a terminal?
<tedg> Command line shell, not graphical shell.
 * tedg might be partially to blame for that confusion
<attente_> tedg: the command line shell is from a vt
<tedg> attente_, Okay, so you'll need to get the dbus session bus address. It should be /run/user/$(user number)/dbus-session
<attente_> bschaefer: is MIR_SOCKET required to be set? i thought it derived it from the XDG_RUNTIME_DIR
<bschaefer> attente_, no i was wrong in what i thought you were doing
<tedg> attente_, No
<bschaefer> i thought you were using a mir demo, not unity8 haha
<tedg> It'll get MIR_SOCKET from Upstart though
<bschaefer> yeah
<tedg> attente_, This might also be helpful depending on what you're doing: https://lists.launchpad.net/ubuntu-phone/msg09839.html
<attente_> tedg: thanks, i'll try it!
<fginther> camako, is there someone who can take a look at http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-runner-mako/3297/ ? I've updated this to run with vivid bits and it's failing.
<fginther> camako, It's currently not enabled as part of the mir ci jobs, but I can if that's the right thing to do
<camako> fginther, I'll take a look
<fginther> camako, it looks like for this run, mir_performance_tests, took too much time and the job timed out. The timeout is 60 minutes and the whole thing usually takes < 20 minutes
<camako> fginther, I see
<camako> fginther, we were having problems with this test and disabled it in CI... Can't remember if we reenabled it later
<fginther> camako, it was re-enabled right after the device sprint
<fginther> camako, I ran it again without mir_performance_tests, http://s-jenkins.ubuntu-ci:8080/job/mir-mediumtests-runner-mako/3298/console
 * camako looks
<fginther> camako, looks like this one failed: mStaleFrames.are_dropped_when_restarting_compositor
<camako> fginther, ok let me investigate and I'll get back to you
<fginther> camako, thanks. Shall I enable the test for -ci jobs or just hold off until you've investigated?
<camako> fginther, aren't -ci jobs currently enabled against our MPs? Not sure if I understand correctly what is being enabled.
<RAOF> desrt: What do you mean?
<fginther> camako, sorry, I need to give you more context... When the jobs were converted to vivid, the mir mako test was missing and as a result wasn't running on MPs within the last day
<fginther> camako, I would prefer to enable it so that it can be fixed with just an MP
<camako> fginther, Ah ok... I think we should enable them... Just to increase urgency on our end
<fginther> camako, thanks
<camako> fginther, have you committed your vivid changes? Can I get a link to the tree?
<fginther> camako, there were no changes to how the tests are executed. Only that the packages are now built for vivid (and the image is devel-proposed which is now vivid)
<camako> fginther, I see...
<camako> fginther, so still using lp:~mir-team/+junk/mir-medium-test-runner-for-jenkins, right? And if I download the archive.zip mentioned on the link you sent above, then I should be able to repro, correct?
<camako> repro locally , I mean
<fginther> camako, correct
#ubuntu-mir 2014-11-07
<camako> fginther, works for me!
<camako> fginther, though the device seems to be stuck at the 'Google' splashscreen and adb doesn't work... u-d-f generates 'initctl: unable to determine sessions' errors... I suspect the debs that are pulled in may not be correct for vivid...
<RAOF> We're cool with std::experimental, right? :)
<anpok_> RAOF: for optional?
<alan_g> duflu: according to bzr you put the (failing in CI) equality test in StaleFrames.are_dropped_when_restarting_compositor (line 209). It doesn't seem to be testing the stale frames and it isn't obvious to me why it is correct do you remember?
<duflu> alan_g: No idea. My brain is now officially fried
<duflu> I'm departing soon
<alan_g> OK. Have a good night!
<duflu> alan_g: Also bzr blame is notoriously unreliable/hard to follow
<alan_g> agreed
<alan_g> But it is pretty clear that only you and alf_ have touched that test
<alan_g> Definitely you: bzr log -c 2002 tests/integration-tests/test_stale_frames.cpp (and the pre code on that line makes sense)
<alan_g> Anyway, have a good weekend.
 * alf_ bangs head against wall... glib main loop and forking after having created a signal source in the same thread (e.g. from previous tests) don't work well at all
<alan_g> alf_: maybe you should use asio. ;^)
 * duflu vomits on keyboard
<duflu> It must be time to go...
<alan_g> alf_: could you take a look at this? (Trying to unblock CI) https://code.launchpad.net/~alan-griffiths/mir/fix-1390388/+merge/241060
<alf_> alan_g: looking
<alf_> alan_g: Not sure how this version is different than the previous one. The two versions are testing the same thing, expressed slightly differently, or am I missing something?
<alan_g> They are not. Suppose new_buffers[0] is a fourth buffer.
<alf_> alan_g: That's an error (where did the 4th buffer come from?). We want new_buffers[0] to be the third buffer, i.e., the latest sent by the client.
<alan_g> alf_: OK I've misunderstood the test
 * alan_g is still interested to see what happens in CI though
#ubuntu-mir 2015-11-02
 * alan_g_ realizes he needs DisplayConfiguration::clone() and spots alf_'s MP of it.
<alf_> alan_g_: There are some g++-4.9 and clang builds issues with this branch, I need to update
<alf_> alan_g_: @assignment ops, I included them for completeness
<alf_> alan_g_: they are not necessary for our use case
 * alan_g now has a prospective MP with three prerequisites - LP is such fun!
<bschaefer> :) alan_g hopefully you dont need to change anything in any of the branches
<alan_g> bschaefer: changes I can merge - my problem is that I can only specify one prereq in LP
<bschaefer> right, thats been an issue for a long time :(
<bschaefer> i think its just how bzr works under the hood? (i talked to tim about it a while ago)
<alan_g> If only two (or more) of them were on trunk.
<alan_g> I don't see why bzr would be a problem
<alan_g> But I've never delved into the LP code
<bschaefer> i could have been LP that was the issue
 * bschaefer asked about it a couple years ago and cant remember the outcome of that conversation
* You're now known as ubuntulog2
#ubuntu-mir 2015-11-03
<dandrader> anpok, what's the ETA for mouse pointer configurable speed and acceleration in the relative axes?
<anpok> dandrader: it is close.. we want to include it in the next release..
<dandrader> anpok, great!
<dandrader> seems that MIR_SOCKET changed recently. I used to point to the directory where mir_socket was located but now it's meant to contain the full file path. Am I right?
<greyback_> dandrader: I've always specified the actual socket file, not the directory its in
<dandrader> greyback_, news for me... I even wrote it qtmir's README file that MIR_SOCKET points to a directory
<dandrader> greyback_, gotta update that
<greyback_> bad me for not noticing that
<sil2100> kgunn: heeey!
<sil2100> kgunn: does your team (https://launchpad.net/~unity-ui-team) want to be the maintainer (subscriber) of the unity-api package? ;)
<kgunn> sil2100: whats up?
<sil2100> kgunn: to get it included in main we need to have a proper team assigned to it
<sil2100> And cross-checking latest committers with the team members, it fits
<kgunn> sil2100: yeah, guess that makes sense
<kgunn> Saviq: mzanetti greyback_ ^ fyi
<kgunn> i need to reboot....bbiab
<mzanetti> sil2100, hmm... as the name suggests, I thought the unity-api team would be in charge of that... that's probably a Saviq question in the end as he's managing our resources
<sil2100> mzanetti: would be good as well
<sil2100> mzanetti: I just saw that basically that team had most of the committers
<sil2100> Saviq: ping
<sil2100> Anyway, I need one of the two teams to subscribe to the unity-api Ubuntu package
<mzanetti> yes. alecu and Saviq need agree on that, can't decide
<mzanetti> *to
 * sil2100 zaps Saviq with a tazer
<Saviq> sil2100, here, us is fine, it usually needs to land with unity8
<sil2100> Saviq: if you're still around, let's move this discussion to #ubuntu-touch
<greyback_> RAOF: https://code.launchpad.net/~gerboland/qtubuntu/enable-debug-mode/+merge/276293
<Saviq> anpok_, hey, is mir 0.18 anywhere I could try it from?
<bschaefer> Saviq, i think its in trunk :)
 * bschaefer doesnt know of a ppa though
<Saviq> bschaefer, thanks, Cpt. Obvious! ;D
<Saviq> beer o'clock, then
<bschaefer> :)
<bschaefer> enjoy
<bschaefer> Saviq, made a ppa if you wanted to test trunk mir: https://launchpad.net/~brandontschaefer/+archive/ubuntu/mir-trunk
<bschaefer> once these finish... https://code.launchpad.net/~brandontschaefer/+recipe/trunk-mir
 * bschaefer broke it
<bschaefer> Saviq, i should have waited for the branch to finish being pushed :) (should be building now)
<bschaefer> Saviq, hopefully you dont need arm... (since my ppa doesnt have those powers) :(
 * bschaefer assumes you need arm
<bschaefer> Saviq, actually looks like this: https://launchpad.net/~mir-team/+archive/ubuntu/staging
<bschaefer> has trunk mir in it
<bschaefer> for arm
#ubuntu-mir 2015-11-04
 * Guest42341 such a beautiful day, today. great for science and such
<RAOF> Saviq: Daily builds of Mir are available in ppa:mir-team/staging
<zzarr> I just read the explanation why Canonical chose to create Mir instead of using Wayland and I completely agree with the decision. I knew in why earlier but not in the depth that I know now
<zzarr> (not saying I got deep knowledge or anything, but deeper)
<anpok> zzarr: how is your crome os thing coming along?
<zzarr> anpok, I'm trying to install ubuntu in a chroot under arch linux which have gpu 3d acceleration
<anpok> oh I thought you had a crome os rockchip board
<zzarr> anpok, I have had alot to do so I haven't started with any freon -> mir wrapper, but I may do it
<zzarr> anpok, I have a ASUS Chromebook flip with a rk3288 (rockchip)
<zzarr> anpok, do you have a rockchip based device?
<mzanetti> hey, is it possible to start a windowed Mir on top of X11?
<mzanetti> like XMir, but the other way round
<mzanetti> kgunn, ^
<zzarr> anpok, would you like to start a project with me? (freon -> mir wrapper)
<kgunn> mzanetti: https://www.youtube.com/watch?v=QCsZ2jYUTqk
<kgunn> that waht you mean ^
<mzanetti> yes! :)
<anpok> test
<anpok> zzarr: nope .. just saw a few cheap and impressive rk boards
<zzarr> ahh, okey
<zzarr> seen this? http://www.cloudsto.com/products/android-mini-pc-s/new-rikomagic-mk68le-linux-edition-64-bit-octa-core-4k-ubuntu-linux-mini-pc-2gb-ram-16gb-flash-detail.html
<anpok> oh arm64
<zzarr> :)
<zzarr> I wonder why it comes with Ubuntu 14.10 instead of 14.04 LTS
<Saviq> RAOF, mirserer-dev needs a dependency on nettle-dev, otherwise nothing will build against it
<Saviq> what's your process there?
<bschaefer> Saviq, (no sure if you saw the message): https://launchpad.net/~mir-team/+archive/ubuntu/staging/+packages
<bschaefer> i bumped it to xenial as well (so it has arm)
<bschaefer> has trunk mir (which will turn into 0.18)
<bschaefer> Saviq, also, the nettle-dev should be a depend in the ... deb stuff?
<bschaefer> are you saying the pc file is missing it?
 * bschaefer thought we fixed that
<Saviq> bschaefer, the .pc file has it
<Saviq> bschaefer, but debian/control doesn't
<Saviq> which means if you install libmirserver-dev, it's not usable (cmake complains mirserver isn't there, actually)
<Saviq> but that's because it can't discern between that and missing .pc dependencies
<bschaefer> Saviq, hmm i see it under the Source: mir ... nettle-dev
<Saviq> bschaefer, yeah, I'm "fixing" the staging ppa
<Saviq> bschaefer, not enough
<bschaefer> that should have been in the main server branch change
<Saviq> bschaefer, install libmirserver-dev, you need nettle-dev
<Saviq> bschaefer, just try this: uninstall nettle-dev, `pkg-config --cflags mirserver`
 * bschaefer does
<Saviq> (with Mir trunk, btw)
<bschaefer> Saviq, hmm i dont see that but i dont have trunk installed as part of the archive
<bschaefer> Saviq, i think the nettle depends gets pulled in from mir common
<Saviq> bschaefer, basically, any dependency in .pc has to be replicated in debian/control
<bschaefer> right, which i thought we had by adding nettle-dev to the Source: mir?
<Saviq> bschaefer, no, that's a build dependency for Mir
<Saviq> bschaefer, and the dependency in .pc is a "runtime" dependency of libmirserver-dev
<Saviq> i.e. if you want to build anything against libmirserver-dev, you need nettle-dev, too
<bschaefer> Saviq, o right yeah i see
<bschaefer> i need to add that in the libmircommon
<bschaefer> which should get pulled through to libmirserver
 * bschaefer double checks if the libmircommon that it is depending on
<Saviq> which means libmirserver-dev needs a *runtime* dependency (Depends: under Package: libmirserver-dev, not Build-Depends: under Source: mir)
<bschaefer> right
 * bschaefer broke to many things with that
<Saviq> bschaefer, right, it might be going server â common â nettle, not sure
<bschaefer> yeah
<bschaefer> Saviq, let me get a branch out (but ill need to chase down the right sport)
<bschaefer> spot*
<bschaefer> thanks for poking about it :)
<Saviq> bschaefer, but whichever .pc declares it, the package that ships that .pc needs a Depends on it
<bschaefer> yup
<bschaefer> was going to find which pc held the nettle depend
<bschaefer> Saviq, looks like mir client
<bschaefer> Requires.private: protobuf-lite >= 2.4.1, mircookie
<bschaefer> the mircookie is what depends on the nettle
<bschaefer> which is strange...
<bschaefer> since the server doesnt depend on the client?
<Saviq> that I don't know, but if that's â from mirserver and mircookie deps on nettle, then mircookie-dev should depend on nettle-dev
<Saviq> bschaefer, yup http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/src/cookie/mircookie.pc.in
<bschaefer> Saviq, the only issue, i dont see mirserver depending on the mir client
<bschaefer> in the pc file
 * bschaefer checks the deb
<bschaefer> Saviq, nm
<bschaefer> i just cant read :)
<bschaefer> Requires.private: mirclient
<bschaefer> private requires
 * bschaefer adds to the libmirclient-dev the nettle-dev requirement
<Saviq> bschaefer, yup
<Saviq> bschaefer, not libmirclient-dev, libmircookie-dev
<bschaefer> Saviq, i ... dont know why i haddent added that before...
<Saviq> me neither ;)
<bschaefer> Saviq, mixed up the source + the libmircookie part
 * bschaefer thought for some reason the source get propagated to the *-dev parts for w/e reason
<bschaefer> Saviq, https://code.launchpad.net/~brandontschaefer/mir/libmircookie-dev-needs-nettle/+merge/276688
<Saviq> bschaefer, acked
<bschaefer> Saviq, sorry about that!
<Saviq> bschaefer, no need to be sorry :)
#ubuntu-mir 2015-11-05
<greyback> alan_g: hey, is there a way to get the current SurfaceSpecification from a mir::shell::Surface?
<alan_g> greyback: not as phrased. But in the new Window Management paradigm the window management policy can call tools->info_for(surface) to get a superset of that information.
<greyback> alan_g: ok
<alan_g> But we've not landed that in qtmir yet
#ubuntu-mir 2015-11-06
<alan_g> alf_: content with answer? https://code.launchpad.net/~kdub/mir/current-buffer-id-fix/+merge/275986
<alf_> alan_g: yes
<alan_g> alf_: my kms problem from yesterday. I find that DRM_MODE_DISCONNECTED gets set in reset() after the "connector = resources.connector(connector_id);". Any thoughts?
<greyback_> RAOF: http://pastebin.ubuntu.com/13123486/
<RAOF> Ta
<alf_> alan_g: @kms, this seems normal, it gets the latest state from the hardware
<alan_g> alf_: so we're aborting because the hardware state is unexpected?
<alf_> alan_g: yes, but the thing is that we shouldn't be trying to set the crtc on a disconnected connector, so the problem may be at a higher level
<alf_> alan_g: do the instructions for reproducing this still stand?
<alf_> alan_g: (using the two branches over trunk)
<alan_g> alf_: yes. Or use your fix-1511798 branch, in which case you also have to stop the nested server before seeing the crash
<alan_g> BTW one of those branches has landed
<alf_> alan_g: ok, I will give it a go
<alan_g> alf_: thanks.
<alan_g> alf_: I know this is "wrong" but it seems to workaround problems:
<alan_g> -    connector = resources.connector(connector_id);
<alan_g> +    if (!connector || (new_connector && new_connector->connection == DRM_MODE_CONNECTED))
<alan_g> +        connector = std::move(new_connector);
<alan_g> Hmm, missed a "+    auto new_connector = resources.connector(connector_id);"
<alf_> alan_g: ack
<alan_g> alf_: any thoughts on my kms problem?
<alf_> alan_g: with the alternative fix I was able to reproduce only once, further attempts worked fine.
<alan_g> Without the patch to reset() I've been getting it consistently.
<alf_> alan_g: just to make sure, instructions are: sudo gdb --args bin/mir_demo_server --window-manager system-compositor --display-config sidebyside --vt 1 --arw-file --on-fatal-error-abort --display-report log
<alf_> alan_g: plug in screen
<alan_g> alf_: oh! I'm testing on V+, are you on Wily?
<alf_> alan_g: yes
<alf_> alan_g: wily
<alf_> alan_g: 3. bin/mir_demo_server.bin --host /tmp/mir_socket --display-config sidebyside
<alf_> alan_g: 4. bin/mir_demo_standalone_render_surfaces --no-file --host-socket /run/user/1000/mir_socket --display-config single
<alf_> alan_g: Then ctrl-c (4) and (3)
<alan_g> step 3 s/.bin//
<alan_g> Otherwise yes
<alan_g> So it could be specific hardware, or the OS drivers
<alf_> alan_g: It's likely that this is HW/driver related problem, because getting DRM_MODE_DISCONNECTED for a screen that is clearly plugged in, is not something Mir could really affect or mess up (unless there is memory error somewhere).
<alf_> alan_g: @alternative fix, your concern is that although it passes the tests it doesn't have the desired effect in the above scenario (ctrl-c render surfaces), correct?
<alan_g> yes. At least my concern is I don't understand why (yet).
<alf_> alan_g: so, I take it that you are investigating this?
<alan_g> currently tracing through the code
<alf_> alan_g: ok, then I will do something different for now, but let me know if you need me to try something
<alan_g> alf_: thanks. You said you also saw the kms issue sometimes? Is it worth MPing my workaround?
<alf_> alan_g: I think it may break monitor disconnects in some cases (it won't update the connector if the monitor has been really disconnected), so I am hesitant to include it
<alan_g> yeah. I hate having Mir crash as a result though.
<alf_> alan_g: We could try to be more forgiving of incorrect set_crtc() calls, e.g., log a warning instead of aborting
<alf_> alan_g: (incorrect => failed)
<alan_g> alf_: when I've finished handling interrupts and investigating your alternative fix I'll try to find something more plausible.
<alf_> alan_g: ack, from a quick look I think 1. logging a warning + returning false in mgm::RealKMSOutput::set_crtc() and 2. not aborting in mgm::DisplayBuffer::set_crtc() should do the trick, but perhaps there are other points we need to update
<alf_> alan_g: I would propose the changes myself, but I can't really test if it helps for your use case
<alan_g> \o/ alf_: I understand the difference - AbstractShell::focus_next_session() is selecting the dying surface's titlebar. (And that doesn't exist in the core WM that gets tested.)
<alf_> alan_g: great
<alan_g> alf_: should I start another loop by taking your alternate fix and MPing the changes?
<alf_> alan_g: fine with me
<mcphail> bschaefer: ping
<bschaefer> mcphail, pong
<mcphail> Hi - are you still working on SDL2 for mir?
<bschaefer> mcphail, when its needed, or when a bug comes up
<bschaefer> mcphail, any bugs?
<mcphail> do you have a link for a version which works with the current Mir libs on the phone?
<bschaefer> mcphail, yeah: https://code.launchpad.net/~brandontschaefer/libsdl/update-mir-new-abi-api/+merge/276578
<bschaefer> thats the patch
<mcphail> Ta muchly!
<bschaefer> for SDL2 to then new mir API
<bschaefer> mcphail, here is the the actual branch:
<bschaefer> https://code.launchpad.net/~brandontschaefer/+junk/SDL2-new-mir-ABI
<bschaefer> so you dont have to apply the patch, its already applied
<mcphail> slvn_: ^^
<mcphail> bschaefer: you are a hero
<bschaefer> np, poke me if theres any issues!
<slvn_> thanks !
<mcphail> bschaefer: will do
<mcphail> bschaefer: slvn_ is going to bring us some new games!
<bschaefer> sweet!
<bschaefer> slvn_, if it works on arm you can post on that MP that you've tested it and all :)
 * bschaefer needs to double check it works on the phone
<bschaefer> IIRC it does...but i dont remember
<slvn_> what is MP ?
<slvn_> bschaefer, a few month ago my games where working with the SDL / mir backend
<bschaefer> merge proposal
<bschaefer> yup, until mir 0.14 and greater :)
<bschaefer> all i did was move to the new API/ABI
<bschaefer> https://code.launchpad.net/~brandontschaefer/libsdl/update-mir-new-abi-api/+merge/276578
<bschaefer> the MP ^
<mcphail> do we still need to --disable-shared-mir when building?
<bschaefer> mcphail, you shouldnt
<slvn_> Ok ! yes, we found out with mcphail that api function where missing / renamed because of the new api
<bschaefer> the only reason that was needed, was because it was broken :)
<mcphail> ha!
<bschaefer> ie. functions didnt line up
<bschaefer> (they kept changing MirBool to bool and back and forth)
<bschaefer> and would keep the dynamic loading from not working
#ubuntu-mir 2016-11-07
<duflu> RAOF: Care to jam in a last minute review before this one lands?   https://code.launchpad.net/~vanvugt/mir/fix-1638774/+merge/309910
<RAOF> duflu: Sure.
<duflu> RAOF: Ta. I would write proper make_ functions if it was important but they're only tests which compare pointer values
<RAOF> ???
<RAOF> This backtrace makes no sense.
<alan_g> greyback: fixed as requested, but should I port it over to lp:qtmir? https://code.launchpad.net/~alan-griffiths/miral/WindowControllerInterface-isVisible/+merge/310039
<greyback> alan_g: great, thank you. Our current plan is the following: we moved all of lp:miral/miral-qt to  lp:~unity-team/qtmir/miral-qt-integration - we are developing on top of this branch, making MPs on top of it, and merging manually
<greyback> alan_g: I think it would be logical to remove lp:miral/miral-qt - less duplication. wdyt?
<alan_g> greyback: Agreed. There should only be one. I think I'll stop poking at that code for a while to minimise churn.
<alan_g> greyback: there are a couple of [miral-qt] MPs in flight (including the one I asked about). What's the plan for them?
<greyback> alan_g: we'll integrate them into our branch
 * alan_g decides its SEP for the next week or so. ;)
<greyback> alan_g: ok, I've cleaned up the MP list. Aside from your branch, everything else has been included in lp:~unity-team/qtmir/miral-qt-integration
<greyback> "SEP" ?
<alan_g> Someone Else's Problem
<greyback> :)
<alan_g> Will you pick up my PM too?
<alan_g> Ah, just see comment
<alan_g> *seen
<alan_g> sil2100: can I talk you into landing this? https://bileto.ubuntu.com/#/ticket/2155
<sil2100> alan_g: sure, let me take a look
<sil2100> alan_g: done
<alan_g> sil2100: thanks
<dandrader> greyback, you there?
<dandrader> alan_g, I suppose you eventually want to remove that from miral::Window? "operator std::shared_ptr<mir::scene::Surface>() const;"
<alan_g> dandrader: no, it's needed internally (or something equivalent) and I don't want to ban use of it, just make it mostly unnecessary.
<alan_g> dandrader: I assume you're good with this: https://code.launchpad.net/~alan-griffiths/miral/purge-miral-qt/+merge/310192
 * dandrader looks
<alan_g> bschaefer: not tried snapping it yet, but a POC https://github.com/AlanGriffiths/mircade
<bschaefer> alan_g, ooo very nice
 * bschaefer tries it
<bschaefer> game not found, but i have a few others :)
<alan_g> Yeah, there's a few bits need writing
<bschaefer> yeah, but nice looking
 * bschaefer was going to start looking at emulation station on his half days
<bschaefer> alan_g, also, the games werent fullscreen when i started them
<bschaefer> could be one of those things that just need extra writing :)
<alan_g> bschaefer: I noticed that too. Was wondering if miral-kiosk ought to force fullscreen
 * bschaefer thinks thats a good choice
<alan_g> The question is "when?" - obviously not for *all* windows
<bschaefer> o true hmm
<alan_g> Ones without parents? The first one?
<alan_g> (First for the app)
<bschaefer> alan_g, possibly yeah the first? Right after your exec command?
<bschaefer> well i guess you already do then :)
<bschaefer>             mir_surface_set_state(surface, mir_surface_state_fullscreen);
<bschaefer> but i suppose you'll need to apply the spec
<alan_g> bschaefer: that's just the mircade client, It can't fiddle with other applications
<bschaefer> (but not sure if you have access to the mir surface for it)
<bschaefer> yeah
<bschaefer> alan_g, can you always force fullscreen for *new* cleans only?
<bschaefer> not sure what would happen with something like gimp though
<alan_g> miral-kiosk can do whatever I decide
<bschaefer> :)
<alan_g> apps with a "splash" screen could also be "difficult"
<bschaefer> o right...
 * alan_g wonders what surface type they are
<bschaefer> thats left up to the client :)
<bschaefer> (ie. could we depend on it? being a specific type?)
 * alan_g is tempted by "type=normal, parent=(none)" => fullscreen
<bschaefer> that seems far... i suppose there could be a few edge cases
<alan_g> Yeah, but "kiosk" isn't intended as a fully functional desktop
<bschaefer> exactly, i think thats a fair assumption to put on
<bschaefer> alan_g, i can only think of a couple cases? *Such as gimp but you can force 1 window IIRC*
 * alan_g doesn't think running gimp on a "kiosk" needs to be supported
<bschaefer> yeah
<bschaefer> but maybe a *drawing* station haha
<alan_g> kgunn might disagree
<bschaefer> with touch (idk if its even supported)
<kgunn> yeah, i wouldn't think gimp kiosk would be a top seller ;)
<alan_g> kgunn: bschaefer and I have been discussing using miral-kiosk for an "arcade" style interface and for that scenario it makes sense to force "fullscreen" for main windows (for some definition of main window)
<anpok> hm I have a photo of an ubuntu drawing kiosk in a sport cloth shop
<bschaefer> alan_g, yeah i think thats a good way to go... i cant think of anything else that would be *strange* but i suppose they are out there!
<kgunn> anpok: was that gimp? :)
<anpok> hm nope..
<attente> anpok: hey, do you know what's happening with keymap support? is the shell taking over there?
<attente> or is the client still expected to do the key event translation?
<anpok> attente: yes .. the shell is in charge.. i.e the shell is now able to configure the keymapping per keyboard in its own process, it will receive mapped keys including compose key results
<anpok> attente: but it still could configure client windows to have different keymap
<anpok> (again per keyboard)
<attente> anpok: i don't understand, does that mean clients could both receive already translated key events and non-translated key events as well?
<anpok> they get enough information yes..
<anpok> key events contain the original scan code and the mapped key
<attente> ah, ok
<attente> thanks!
<anpok> and for the forseeable future - due to xmir - unity8 will configure keymaps for client windows
#ubuntu-mir 2016-11-08
<zzarr> hello! my Apps scope is gone from Unity 8, how do I get it back?
<alan_g> greyback: I just realised you might not have realized that I'm adding the "maximized" functionality and making that the default: https://code.launchpad.net/~alan-griffiths/miral/more-kiosk-options/+merge/310270
<greyback> alan_g: ok, and as your comment says, the lack of usecase does motivate the change
<alan_g> bschaefer: miral (trunk) has the changes we discussed, and I tweaked mircade a little. Together looks somewhat better
<bschaefer> alan_g, nice! (and opps was going to look at reviewing some miral branches as well)
<bschaefer> well looks like someone reviewed them all :)
 * alan_g will have to create more
<bschaefer> alan_g, hmm i didnt see fullscreen windows
<bschaefer> though i locked up
 * bschaefer is having version issues now
<bschaefer> maybe i was running something wrong
<bschaefer> ERROR: Failed to connect: not accepted by server
 * bschaefer will mess with in a bit
<alan_g> bschaefer: which Mir release? There was a nasty lockup bug fixed in 0.24.1
<bschaefer> alan_g, it seemed to load 0.24.1
<bschaefer> even though ive pointed to trunk
<bschaefer> for w/e reason when i load in tty it picks up the right version
<bschaefer> o nm tty is still 0.24.1 hmm why doesnt it pick up 0.25 i have installed in staging
 * alan_g is sorry he asked
<bschaefer> :)
<bschaefer> alan_g, i compiled with the wrong lib ... duh
<bschaefer> soo it was looking for 0.24.1
<bschaefer> alan_g, i approve of the title bars though ... they look nice
<alan_g> in miral-*shell*?
<bschaefer> alan_g, yeah
<alan_g> The "maximized" root windows is in miral-*kiosk*
<bschaefer> duh
<bschaefer> alan_g, that would be the issue then :)
 * bschaefer needs caffine
<alan_g> But I'm concerned about your "hang"
<bschaefer> alan_g, it was 100% 0.24.1
<alan_g> That's on Mir-0.24.1?
<bschaefer> yes
<bschaefer> i compiled against the wrong version
<bschaefer> so it was looking for 0.24.1 not 0.25.0
<bschaefer> (and i saw the start up message saying it loaded 0.24.1)
#ubuntu-mir 2016-11-09
<RAOF> Urgh.
<RAOF> I wish we didn't so systematically destroy our stacktraces at every opportunity.
<RAOF> Admittedly it doesn't help that this is over distributed 2 processes.
<RAOF> ???
<RAOF> OK, so tearing down and rebuilding the compositor is an integral part of applying nested's display configuration?
<duflu> Exceptions. Love them or hate them
<RAOF> Oh, maybe no it isn't.
<RAOF> And it's just that this test relies on a side-effect of restarting the compositor to work.
<RAOF> Aces!
<duflu> Umm, Trump is about to win
<RAOF> Yeah, less aces.
<duflu> RAOF: Could you look at my latency testcase fixes? For some reason that's failing a lot today.
<RAOF> Sure.
<anpok> RAOF: hmm
<RAOF> anpok: Yo?
<anpok> I am looking at a similar spot..
<anpok> the nested platform reconfiguring the display configuration rather late on startup..
<anpok> such that the surface of the nested compositor gets occluded for some time
<anpok> during stop/start in mediating display changer..
<anpok> especially in our tests where stub graphics is used..
<anpok> so no input events can get through.. until the compositors have run another time and have redrawn the surfaces of the nested server
<anpok> we should make that more atomic
<anpok> or refine the occlusion logic..
<RAOF> Hm.
<RAOF> The nested platform's surfaces *aren't* occluded on startup, though.
<RAOF> They just don't have any content, so they're not focused?
<duflu> I would like to think we don't need occlusion testing in future. In the arbitrary compositor case where anything can be translucent, duplicated on multiple desktops, or shrunked to previews, occlusion simply never happens often enough for it to be a useful thing to test for or base logic on
<duflu> *shrunken*
<RAOF> I disagree; occlusion remains a super common case. Almost all of my windows spend almost all of their time occluded.
<RAOF> The times where windows are *not* occluded are the outliers.
<duflu> I think both points are valid. But occlusion testing needs to either be perfect or not present at all. Because faulty occlusion testing is a problem obviously, and a complex one at times
<anpok> RAOF: hm the order is host server starts.. nested server starts.. client connects to nested and posts.. then nested server surface posts.. (is visible then) .. the reconfiguration happens (maybe it was started earlier) .. now nested surface is occluded [meanwhile the tests start to send input events] ..
<anpok> now after the configuration is done compositor in the host server start drawing.. now the nested surface is visible again
<anpok> the configuration change is not atomic to the rest of the system
<alan_g> greyback: I did it for you. 8^) You could vote: https://code.launchpad.net/~alan-griffiths/qtmir/WindowControllerInterface-isVisible/+merge/310184
<greyback> alan_g: thank you
<alan_g> alf_: try this: https://code.launchpad.net/~alan-griffiths/miral/improved-tiling-wm/+merge/310421
<RAOF> We really need to stop writing acceptance tests that rely on real time.
<bschaefer> +1
<bschaefer> RAOF, rather we need to agree upon that :)
<RAOF> Well, no.
<bschaefer> hmm well if someone doesnt agree with that, and still pushes real time tests
<bschaefer> then we'll still have that issue?
<RAOF> What we need to do is have someone stick a faketime wrapper around our existing tests and then reject any branch that adds real time tests.
<bschaefer> that sounds better
<anpok> RAOF: i am off already - what do you think about moving the location of the display buffer out of the graphcis platform - and thus being able to preserve the buffer when the display is reconfigured?
<anpok> or actually moving that information out of the buffer might not be necessary..
<RAOF> anpok: Reconfiguring the display will, in general, require that the display buffer be invalidated.
<anpok> at least it seems as if it should not be there.
<anpok> RAOF: hm thats kind of fine.. but
<RAOF> Now, a bunch of display configuration does *not* require the display to be reconfigured, true.
<anpok> that currently mean that compositor threads are reconstructed
<anpok> *means
<anpok> which means that compositors come and go...
<RAOF> But I think the graphics platform is really the only place where you can tell what sort of configuration changes invalidate the DBs.
<anpok> and produce unnecessary notifications
<RAOF> So, the branches that have landed (for android and kms) and are landing (for nested) reduce this quite a lot, and can be improved to invalidate the DBs even less often.
<RAOF> But, in general, if you've got one thread per display buffer, a display configuration change may require compositor threads to be killed or started.
<anpok> ok .. too tired. I am concerned that our reconfigurations are not processed as a single transaction in mir.. So from one perspective want to avoid the problematic cases.. and from the other perspective fix the way the configuration is applied
<Pharaoh_Atem> hey, do you guys do any testing of your pkg-config files to make sure they are fully defined?
<anpok> Pharaoh_Atem: probably not enough
<RAOF> Hm. By âsingle transactionâ do you mean âHey, shell, I'm going to be changing the configuration, so could you please do a composition pass to these new buffers before I do the switchâ?
<Pharaoh_Atem> anpok: I was asking because I was unable to build something to depend on mir because mir's own pc files don't declare what pkg-config modules they depend on
<anpok> RAOF: not quite there are many internal bits.. that should wait until the switch is done
<Pharaoh_Atem> so it didn't pull in things automatically
<RAOF> Pharaoh_Atem: We *do* use those pkg-config files in all of the Mir downstreams, so we should notice any really glaring lacks. What was missing?
<RAOF> (At least for releases; we don't necessarily notice when lp:mir is wrong)
<Pharaoh_Atem> well, I'm using mir 0.24.1
<RAOF> And what was missing?
<Pharaoh_Atem> one sec
<anpok> RAOF: i found display reconf to be the main source of unexpected misbeheavior on startup
<anpok> in our acceptance tests..
<RAOF> This does not surprise me terribly.
<anpok> with that closing thought.. -> off
<anpok> :)
<bschaefer> anpok, byes!
<RAOF> *Particularly* for nested.
<RAOF> anpok: Sleep well!
<anpok> RAOF: thats why there is now a preserve dbs in stub graphics MP
<bschaefer> RAOF, ill have to poke you after this release about apply config :)
<bschaefer> i suppose it'll just copy the old API?
<anpok> that only helps in the trivial cases
<bschaefer> eww cc1plus: error: invalid argument â/build/mirâ to -fdebug-prefix-map
<RAOF> Race race race your build...!
<bschaefer> haha... sadly this is for CI soo restart...
 * Pharaoh_Atem is rebuilding the libinput->mir->mesa chain
<Pharaoh_Atem> RAOF: https://paste.fedoraproject.org/469496/47817680/
<Pharaoh_Atem> seems like xkbcommon wasn't defined as a Requires for mirclient
<RAOF> Pharaoh_Atem: Quite true.
<bschaefer> huh why dont we have that as a depends?
 * bschaefer has made this assumption
<RAOF> We presumably missed that because all of our downstreams link it explicitly.
<Pharaoh_Atem> that, and also you guys don't have dependency generation from pkg-config files
<bschaefer> RAOF, yeah ive had to manually link with it
<bschaefer> RAOF, hmm libmirclient-dev pulls in libmircommon-dev which should pull xkb?
<bschaefer> (not sure about the pkg file)
<Pharaoh_Atem> it does on Ubuntu, because those are manually specified
<RAOF> Right; we're missing a Requires.private there.
<Pharaoh_Atem> mmhmm
<Pharaoh_Atem> I suspect there's more, but that was the first issue
<RAOF> Quite plausibly. This is indeed not something we use.
<RAOF> Fedora packaging autogenerates build-dependencies by scanning pkg-config?
<Pharaoh_Atem> yes
<Pharaoh_Atem> well, no
<Pharaoh_Atem> that would be cool and awesome, but tricky
<RAOF> But there's a tool that will populate your control files based on pkg-config that you'll need to edit?
<Pharaoh_Atem> yep
<Pharaoh_Atem> no
<Pharaoh_Atem> it's an addendum
<Pharaoh_Atem> generated at build time
<Pharaoh_Atem> https://copr-be.cloud.fedoraproject.org/results/ngompa/Mir/fedora-24-x86_64/00472459-mir/build.log.gz
<Pharaoh_Atem> at the end of the log, you see all the generated install-time dependencies
<Pharaoh_Atem> My spec is nowhere near as defined: http://copr-dist-git.fedorainfracloud.org/cgit/ngompa/Mir/mir.git/tree/mir.spec
<RAOF> Ah. You generate the dependencies for foo-dev from the pkg-config files?
<Pharaoh_Atem> yep
<Pharaoh_Atem> deps are generated from scanning the files (binaries, libraries, dist/egg-info data, pc files, etc.)
<Pharaoh_Atem> for example, instead of using libxkbcommon-devel, I could have used pkgconfig(xkbcommon) as my BuildRequires for that library devel package
<RAOF> Well, I've added the xkbcommon to the relevant pkg-config file in trunk; you're right, though, it's moderately  likely that this isn't the only missing link in pkg-config, as we basically don't use pkg-config that way.
<Pharaoh_Atem> which is somewhat ironic, given that Debian was the creator and maintainer of modern pkg-config :/
<Pharaoh_Atem> not one of the Debian packaging systems supports parsing and exploiting pkg-config for these things
<Pharaoh_Atem> (i.e. classic debhelper, cdbs, dh)
<RAOF> Hm. Having a look through our #includes, I think this is actually the only one we miss.
<RAOF> Yeah :)
<bschaefer> well i can approve w/e its up :)
<RAOF> ...it actually wouldn't be terribly hard to write a dh_pkgconfigdeps helper that extracted the relevant info and put it into ${depends:PkgConfig}...
<Pharaoh_Atem> then you'd need ${Provides:PkgConfig} too
<Pharaoh_Atem> you need a standard form of representation
<Pharaoh_Atem> which thankfully, you guys can do now, since apt now supports version-release in virtual Provides
<Pharaoh_Atem> err EVR
<Pharaoh_Atem> see, I keep up with what you guys are doing on the other side of the fence ;)
<RAOF> No, I don't think so. You'd just look up the -dev package providing the relevant pkg-config file.
<Pharaoh_Atem> RAOF: that's way more expensive though
<RAOF> Absolutely! But it's build-time expensive, which is cheap.
<RAOF> :)
<Pharaoh_Atem> >_>
 * Pharaoh_Atem shrugs
<Pharaoh_Atem> I guess
<Pharaoh_Atem> you already do this for library deps, to some extent
<Pharaoh_Atem> so why not, eh?
<RAOF> To a huge extent, yes.
<Pharaoh_Atem> well, I say some extent, because a large segment of Debian packages opt to not do so
<Pharaoh_Atem> and manually specify everything (which is insane!)
<RAOF> bschaefer: https://code.launchpad.net/~raof/mir/missing-pkgconfig-requires/+merge/310497
<RAOF> Certainly for things which *aren't* shared libraries we don't have nearly the same sort of tracking.
<bschaefer> nice
<RAOF> But I can't think offhand of a single package I've touched which has manual dependencies on a shared library package.
<RAOF> (Python and other things which aren't ELF DSOs, very much yes)
<Pharaoh_Atem> I can't either, but then again, I try not to make Debian packages my reference for packaging very often
<Pharaoh_Atem> too much stuff everywhere and difficult to parse most of the time
<RAOF> Yeah, I feel fairly similar reading .spec files :)
<Pharaoh_Atem> eh, spec files can be clean (and usually are most of the time)
<Pharaoh_Atem> but some really old ones are nuts
<RAOF> Likewise Debian packaging :)
<RAOF> Although spread over multiple files.
<Pharaoh_Atem> I immensely dislike touching libguestfs packaging
<Pharaoh_Atem> CDBS is way too confusing
 * Pharaoh_Atem has to do that from time to time at work
<RAOF> Yeah, also very much old.
<RAOF> CDBS is from the dark ages before debhelper was sufficiently helpful.
<Pharaoh_Atem> now my only problem with debian packaging is that the really modern stuff doesn't tell you what it's doing
<Pharaoh_Atem> it's hard to figure out how it figures out things
#ubuntu-mir 2016-11-10
<RAOF> It's pretty consistent as long as you're familiar enough with the consistency.
<RAOF> Likewise, ${_bindir} in your .spec :)
<Pharaoh_Atem> well, I'm referring the packages that basically have dh: $@ and that's it
<Pharaoh_Atem> so much automagic I have no idea what happened
<RAOF> Yeah, at that point you look at the other files in the debian/ directory.
<Pharaoh_Atem> yeah
<Pharaoh_Atem> or just make everything verbose and note what the hell happened
<ali1234> bschaefer: i have a question about your kodi on mir post. you talked about the raspberry pi. does mir even run on it? if so what driver?
<ali1234> also the snap: will you try to make it work as both embedded and as a "normal desktop" app? if so what challenges do you expect to see?
<bschaefer> ali1234, hello! So i know mir works on the dragon board (i think it works on the raspi3 .. like 95% sure :)
<bschaefer> as for the snap, i have it working on amd64, but for armhf/64 it requires a bit different packages soo ill have to create a different snap for it
<bschaefer> but once its all built it should be as simple as installing from the store (ideally)
<ali1234> and i guess one final question: i'm working on a custom Qt project for rpi, and at the moment i have to custom build Qt and basically he entire distro to make it truely embedded
<ali1234> Qt needs certain configuration options to run on the rpi GPU
<bschaefer> (im 95% sure about the raspi3 dont think 2 works)
<ali1234> neither ubuntu nor debian nor raspbian builds it with those options
<bschaefer> RAOF, do you know if we working raspi3 yet?
<ali1234> i don't know about mir support though
<bschaefer> yea
<bschaefer> thats my next step is to explore that a bit more
<RAOF> No idea
<ali1234> but would it be worth considering using mir? i'm making a kiosk device that runs only one app
<ali1234> at the moment i have no windowing system or display server at all
<bschaefer> yeah you can look at miral
<bschaefer> miral-examples which installs a miral-kiosk
<RAOF> If it runs on the rpi :)
<bschaefer> yeah right if it runs on raspi :)
<bschaefer> i know the dragon board works but not sure about raspi
<ali1234> i've spent about 2 months customizing raspbian to the point where i have a readonly ramfs that does everything and is only 80MB
<ali1234> the rpi has no working open source driver yet
<ali1234> it has a half finished one, at least last time i checked
<RAOF> It doesn't have an android stack, does it?
<ali1234> and the proprietary API is not widely supported. actually wayland recently dropped support for it
<RAOF> That might be easier for you.
<ali1234> rpi? no, not yet
<ali1234> supposedly android 7 will be ported
<ali1234> i'm not sure why it would be easier though
<bschaefer> but yeah *once* mir does work on it, it would be a nice WM
<bschaefer> for that
<ali1234> i've worked with android before... i ported ubuntu touch to a phone... i probably won't ever go near it again at the system level cos it's horrible
 * bschaefer will have to poke someone about the raspi stuff
<ali1234> so you didn't really answer my question about "embedded"
<ali1234> for example, there's problems with audio
<ali1234> if you make a desktop app you must use pulseaudio
<ali1234> and give it all the right plugs and etc
<ali1234> but if you make an embedded snap you have to use raw alsa
<bschaefer> for a snap?
<ali1234> yes
<bschaefer> yeah
<ali1234> desktop snap vs embedded snap
<bschaefer> ali1234, im going to have to create a different snap for embedded (as far as i know)
<ali1234> there's contradictions that prevent one snap from fulfilling both roles
<bschaefer> soo you'll have to maintain two snapcraft.yaml
<bschaefer> yeah
 * bschaefer doesnt like that either and isnt sure if they are working on a better solution there
<ali1234> yeah this is pretty much the conclusion i reached
<ali1234> they are working on an "embedded pulseaudio server" type thing
<bschaefer> you can always attempt to poke in #snappy
<ali1234> that will provide PA services on embedded setups
<bschaefer> that would be nice
<ali1234> but there are other problems
<ali1234> oh believe me i have :)
<bschaefer> :), thats good as im still attempting to learn snap fully atm
<ali1234> i just wanted to see what you thought about this purely because you used the word "embedded" in that post, and nobody else seems really all that interested in it
<bschaefer> (and reaching the same issues)
<ali1234> mostly people are making desktop snaps
<bschaefer> ali1234, yeah so *the* ideal goal is to make an embedded snap which we have one for the mir server
<bschaefer> for arm64 (tested on the dragon board)
<bschaefer> and now its to find nice use cases such as kodi/simple 1 application
<bschaefer> for a kisok type system
<ali1234> yeah that sounds similar to the plan for PA
<bschaefer> kiosk*
<ali1234> well, thanks for your time and thoughts
<bschaefer> np! Hopefully more answer will become clearer soon
<ali1234> i guess i'll keep watching for updates, but meanwhile i'll probably continue using my own hand rolled stuff
 * bschaefer hopes at lease :)
<bschaefer> yeah
 * bschaefer will be diving into this next week or so soo... hopefully i can get more info out as well
 * bschaefer eods
<duflu> ali1234, RAOF: I recall last month during his presentation, kgunn said that tvoss made the step to getting things going on Raspberry Pi.
<duflu> Presumably no code change was required because we haven't seen any
<duflu> (other than my code change which just means in Mir 0.25 you'll see less logging about "Unknown" output types)
<RAOF> That's right! That's what I was thinking of.
<duflu> Ha. I just noticed GLX explicitly does not support correct multi-monitor frame sync. Just "the monitor used to determine MSC is screen 0 of <display>."
<fritsch> !seen bschaefer
<ubot5`> I have no seen command
<alan_g> fritsch: he's likely asleep (on east coast time)
<fritsch> alan_g: then we let him sleep. Wanted to say thank you for his well written Pull Request to kodi for MIR support
<fritsch> alan_g: and discuss if we can get VAAPI support somehow, as this is one - in comparison to vdpau does not need any x11 dependencies
<alan_g> fritsch: that's likely better asked during USA day (not my area of expertise). alf_ ^ any thoughts?
<alan_g> duflu: ^
<duflu> I have no thoughts on that right now. Also it's getting late...
<fritsch> :-)
<fritsch> no hurry
<fritsch> i will idle here for longer
<duflu> Night
<fritsch> just though it would be nice if a kodi mir variant could also use hw accelerated video decoding
<tvoss> fritsch: we have had some initial discussions on vaapi support, we are definitely aiming to support it
<fritsch> if you use gles for rendering anyways
<fritsch> there is nothing that would disturb that
<tvoss> yup, exactly
<tvoss> RAOF: if you are still around: did jhodapp talk to you, yet?
<fritsch> we also don't use vaPutSurface anymore in kodi
<fritsch> which would have this x11 pixmap dependency
<fritsch> so, what you get is two textures Y and VU
<fritsch> and then can do whatever you want with them
<fritsch> I pinged bschaefer about that in the PR, let's see what discussion reveals
<fritsch> from code pov, there is nothing that stands in the way merging it into kodi
<tvoss> ack and thx, sounds great :)
<fritsch> (we are currently only discussing if it can make it into our v17 release, which RC is just some days ahead, we hope we do so)
<tvoss> fritsch: great, just let bschaefer know if you need anything for inclusion with your release
<fritsch> tvoss: nope, his code is fine - it's us internally, that need discussing. I voted +1 - so let's see
<tvoss> ack
<Son_Goku> are the mir demo clients supposed to segfault with vmware gfx driver?
<alan_g> they're not supposed to, but it's a known problem
<alan_g> bug 1639745 is probably the most relevant
<ubot5`> bug 1639745 in Mir "Mir GL clients never appear at all on VirtualBox" [High,In progress] https://launchpad.net/bugs/1639745
<Son_Goku> it might not be the same issue
 * Son_Goku is installing debuginfo packages now
<Son_Goku> alan_g: https://paste.fedoraproject.org/477293/78868414
<ogra_> bschaefer, yo ... i just looked at your kodi snap ... try: --with-ffmpeg=force ... that will build it in-tree
<bschaefer> ogra_, hmm it tired lots of combos (building ffmpeg my self) then it would have a linking error at the end
<bschaefer> ogra_, ill try that again though!
 * ogra_ is trying to get it to build on pi3 currently 
<bschaefer> ogra_, o sweet was wanting to ask if we had kernel support for mir on that :)
 * bschaefer only has a dragon board
<ogra_> also, once you are done we should roll a dedicated kodi-core image ;)
<bschaefer> ogra_, theres also issue with armhf
<bschaefer> packaging
<bschaefer> like crystal-hd
<ogra_> i think there are still kernel patches missing
<ogra_> yeah, i had to drop crystal-hd for the moment
<bschaefer> dang, well hopefully soon ish
<bschaefer> ogra_, yeah i tried to ask around #snappy if there was any arch support
<ogra_> (trying to get it to finish a build ... not trying to get it to run yet ;) )
<bschaefer> :)
<bschaefer> well that works as well (i was planning on tackling that for dragon board next week)
<ogra_> i think tvoss and ppisati work together on the kernel patches for dragon and pi support
<bschaefer> o nice
<bschaefer> ogra_, if you get it working you can throw me a diff :)
<ogra_> i surely will
<bschaefer> (or create a new kodi-mir-arm snap branch)
<bschaefer> since i think we'll need to support two different branches atm
<ogra_> INSTALL	libavutil/ffversion.h
<ogra_> INSTALL	libavutil/libavutil.pc
<ogra_> checking for FFMPEG... yes
<ogra_> Checking for SWIG installation
<ogra_> that doesnt look to bad
<ogra_> (though i'm indeed not at any linking stage yet)
<bschaefer> ogra_, yeah ive gotten past that then i hit a linking issue (did you install any extra packages?)
<bschaefer> if i tried ffmpeg from universe it would fail to compile
<bschaefer> due to some breakage somewhere
<ogra_> i used your snapcraft.yaml on a plain rpi3 in the classic shell
<ogra_> with the =force added and crystal-hd dropped for now
<bschaefer> hopefully thats all! (as i force should work for both desktop/arm)
<fritsch> i see kodi's ffmpeg building externally driving you nuts :-)
<fritsch> before I forget it
<fritsch> bschaefer: https://cgit.freedesktop.org/libva/tree/va/egl/va_backend_egl.h
<fritsch> when I build ffmpeg manually I use it like:
<bschaefer> fritsch, :) mainly our builders block wget for the package
<fritsch> ./configure --prefix=/opt/ffmpeg --extra-version='VERSION=3.0.1-Krypton-alpha' --disable-devices --enable-ffplay --enable-ffmpeg --disable-ffserver --disable-doc --enable-gpl --enable-runtime-cpudetect --enable-postproc --enable-vaapi --enable-vdpau --enable-bzlib --enable-gnutls --enable-muxer=spdif --enable-muxer=adts --enable-muxer=asf --enable-muxer=ipod --enable-encoder=ac3 --enable-encoder=aac --enable-encoder=wmav2 --enable-protocol=http --e
<fritsch> to /opt whatever
<fritsch> and then tell cmake how to use it
<bschaefer> o nice as I can setup a git clone + build (with those commands) and hopefully that'll help
<fritsch> cmake -DENABLE_VAAPI=1 -DENABLE_VDPAU=0 -DENABLE_CEC=0 -DCMAKE_BUILD_TYPE=Release -DENABLE_INTERNAL_FFMPEG=0 -DFFMPEG_PATH=/opt/ffmpeg project/cmake/
<fritsch> adjust the version above, it's currently 3.1.5-Krypton-something
<bschaefer> fritsch, sweet thanks, that should help with that! (was running into issue with our builders nothing local :)
<fritsch> i can also get you our build system cmake guy and ppa packager in here
<bschaefer> fritsch, hmm and right we do have EGL/DRM support
<fritsch> for a "howto build it with standard ubuntu's ffmpeg"
<bschaefer> its something i need to look into (was looking into while doing the kodi work but mainly a the heck does this do :)
<bschaefer> fritsch, o a ppa would work as well
<bschaefer> i should try building it by hand again with those options first
<fritsch> we have a ppa for kodi, yes. but that is currently building for x11
<bschaefer> i could always roll my own as well
<fritsch> jep
<bschaefer> didnt think about it :)
<fritsch> cmake -DENABLE_VAAPI=1 <- might need to set that to 0
<fritsch> until investigated
<bschaefer> yup was thinking that
<fritsch> btw. I read crystalhd above
<fritsch> you plan to bring it back? :-)
<ogra_> sigh
<ogra_> g++: internal compiler error: Killed (program cc1plus)
<ogra_> Please submit a full bug report,
<ogra_> with preprocessed source if appropriate.
<fritsch> good old times + a whole lot of kernel patches?
<bschaefer> fritsch, i had no clue what it did :|
<ogra_> ...
<bschaefer> i should disable it
<bschaefer> ogra_, :(
<fritsch> it's a little card that can decode h264 / mpeg2 and sometimes vc1
<fritsch> 1080p is max
<bschaefer> sounds like something thats not even supported by this
<fritsch> if you see it working the first time, you will see a "green dot" in the upper left corner :-)
 * bschaefer looks at disabling it
<fritsch> the decoder people used this green dot to say: all okay
<bschaefer> haha
<bschaefer> thats a good way to know if its working!
<bschaefer> ogra_, also kodi take a bit of time compiling on arm ...
<fritsch> we removed support for it some years ago, but there are a huge load of ATV devices out there, where they removed the wireless lan card
<ogra_> yep, i know
<fritsch> and added a crystalhd
<ogra_> not my first attempt ;)
<bschaefer> ogra_, :)
<ogra_> (and i usually give up after a few days :P )
<bschaefer> o good to know (i just threw that depends when it complained when i was trying to get the snap together)
<fritsch> for arm we currently run on amlogic (pretty massive closed blob for the gpu driver), IMX, raspberry pi and related stuff, like odroid
<fritsch> pandaboard
<ogra_> heh
<ogra_> there are still people actively using pandas ?
<fritsch> most stuff is pretty useless if you cannot use hw acceleration for gpu decoding
<fritsch> not really
<fritsch> cause of ^^
<bschaefer> i was worried about that
<ogra_> yeah, dead since 2012
<bschaefer> since with out gpu decoding it looks fine on the desktop
<fritsch> jep
<bschaefer> but i assumed since better hardware
<fritsch> there is currently content approaching VP9, HEVC-10 bit based
<fritsch> that no reason CPU will be able to playback
<ogra_> pi3 with libreelec and dvb-s2 card is what drivey my TV currently ...
<bschaefer> ogra_, o also we cannot use CMake for kodi building sadly since snappy doesnt support non-root cmake files
<fritsch> ogra_: jep
<ogra_> i want that to be ubuntu-core eventually
<fritsch> probably the most optimized kodi device on the planet
<ogra_> (but am totally not in a hurry)
<fritsch> some say: 1/3 of the pi's firmware is kodi workarounds
<ogra_> haha
 * bschaefer would like a cmake plugin support for root_dir=/path/to/root/CMakeLists.txt
<fritsch> popcornmix, main contributor to pi development is in our kodi team
<bschaefer> o very nice!
<fritsch> bschaefer: that hw accel stuff is why I jumped in. You won't have happy people on MIR if everything is sw decoded
<ogra_> yeah
<bschaefer> yeah i can imagine (also why most likely my VM was working very well either :)
<bschaefer> it something i had been looking at but i should dig in to see if its supported already and how to use it!
<bschaefer> if not it *should* be simple enough according to RAOF, do to a mir backend but we may be missing some API for it specifically (something i hadnt dug further in yet)
<anpok> pixel format types probably
<bschaefer> anpok, it was /me attempts to remember... taking an eglimage thats decoded and shoving it into a mir surface
<anpok> hm getting a mir buffer from an egl image?
<anpok> that on our list fro 17.04
<anpok> +s
<anpok> hm or nearly that
<bschaefer> anpok, right for RenderSurface stuff?
<bschaefer> or outside that?
<anpok> actually outside that for xmir
<fritsch> bschaefer: if you can do it with just egl/drm the better
<bschaefer> fritsch, i agree (not sure if we are missing some drm support there for it though)
<fritsch> cause showing that a display server bases on standards and not setting explicit new ones, would be great
<bschaefer> in the driver... ill have to double check
<fritsch> vdpau is dead anyways :-)
<bschaefer> agreed
<bschaefer> o good, dont have to look into that then :)
 * bschaefer hadnt yet but was on the list
<anpok> fritsch: would it sense at some time.. to turn kodi into a server?
<fritsch> anpok: it's on the way
<anpok> oh
<bschaefer> o sweet
<fritsch> we try to separate gui render thread from the rest
<fritsch> you know, we started with a mainloop
<fritsch> with a huge and ugly mess of global gfx_locks
<fritsch> :-(
<fritsch> and on that move you get "server" or headless for free
<fritsch> but needs a lot architectural cleanup
<bschaefer> yeah i can imagine, but thats sounds awesome!
<anpok> fritsch: oh ok ... we meant using miral instead of mirclient
<tvoss> fritsch: we could theoretically put kodi on top of mir as a "shell"
<anpok> and running applications inside of kode
<anpok> *kodi
<fritsch> we can act as a window manager
<tvoss> so you would just transparently become a mir server
<fritsch> on x11 already
<tvoss> fritsch: hah, interesting
<fritsch> but yeah, we cannot open new windows and such
<anpok> fritsch: oh where is the code for that?
<fritsch> but as bschaefer made a brilliant PR which our chief architect liked very much ...
<tvoss> fritsch: miral is our answer there, it's a layer that allows you to specify window mgmt policy
<fritsch> I am sure there is a log of credit for something like that in the future
<tvoss> fritsch: yeah, probably a step two, get started as a client first
<fritsch> though - I also have to say, we are also looking into wayland and also direct DRM direction
<fritsch> for settop boxes mainly
<fritsch> to run on KMS
<bschaefer> fritsch, well your code was quite easy to read (some hiccups) and thanks!
<anpok> fritsch: we too for the same purpose
<fritsch> but we try very hard to get last release buggers ironed out to release v17 in time
<fritsch> wanted to do ReRo, but failed :-)
<bschaefer> yeah we had this happen with mir 0.25 (im trying to release that now) but we should have released it a bit ago haha
<bschaefer> (always one more blocker/bug you would to get fixed next)
<bschaefer> would like to*
<fritsch> there is a shirt for that:
<fritsch> https://teespring.com/shop/99bugs?aid=marketplace&tsmac=marketplace&tsmic=category#pid=2&cid=2397&sid=front
<bschaefer> haha
<fritsch> bschaefer: something else concerning ffmpeg, if you run: depends/target/ffmpeg/autobuild.sh -d
<fritsch> before hand
<fritsch> it will download that ffmpeg tar
<fritsch> and you can then build without internet
<fritsch> with default options
<bschaefer> fritsch, the issue is our build system (iirc) firewalls it for w/e reason? Blocking the download
<bschaefer> as thats what its currently trying to do
<bschaefer> but fails to download it
<fritsch> how do you get kodi.git on tht machine?
<fritsch> on the build machine
<fritsch> cause if you scp the kodi folder, just scp it after that above command
<bschaefer> fritsch, they allow git clone specifically for snapcraft
<fritsch> ah okay
<bschaefer> so i can git it but it wgets the tar ball
<bschaefer> which it fails
<bschaefer> (ive also tried the manual grab ffmpeg from git hub as well to build
<bschaefer> )
<bschaefer> which ill try again but with the arguments you have!
<bschaefer> as i added nothing
<fritsch> if you want to download everything, that might come during build, you can do that before creating the source package
<fritsch> http://paste.ubuntu.com/23456771/
<bschaefer> fritsch, for the current build system it pulls directly form the github branch i have up
<bschaefer> (which i dont wan to commit anything there :)
<fritsch> oki
<bschaefer> but i could fork something for it
<bschaefer> for now
<bschaefer> fritsch, im hoping when i manually grab ffmpeg from github and build it with those args it works, we shall see!
<fritsch> jep it works, at least on your local machine
<bschaefer> is this the wrong branch? https://github.com/FFmpeg/FFmpeg
<bschaefer> as thats something i can pull in for the snap
<fritsch> that's ffmpeg's master branch
<fritsch> latest and greatest
<fritsch> at the moment it should work
<fritsch> but we are internally still on 3.1.5
<fritsch> though 3.2 is ready and will be upgraded the moment we have branched v17
<fritsch> remember your local ubuntu most likely ships 2.8
<fritsch> if you are happy
<bschaefer> i was building on xenial soo idk how old that was but it was failing
 * bschaefer will attempt again from trunk
<bschaefer> thanks!
<Pharaoh_Atem> anyone have any idea what's going on here? https://paste.fedoraproject.org/477293/78868414/
<alan_g> Pharaoh_Atem: probably some failed interaction with drivers. Currently we have Ubuntu on "metal" and qemu-kvm working. This is something else?
<Pharaoh_Atem> VMware Fusion
<alan_g> We're working on it, but there are known bugs: https://bugs.launchpad.net/mir/+bugs?field.tag=vm
<anpok> I thought vmware would work
<alan_g> anpok: it will
<ogra_> bschaefer, hmm, so i cheated my way around the ffmpeg bits ... but ...
<ogra_> /build/kodi-pi/parts/kodi/build/xbmc/windowing/mir/WinSystemMirGLESContext.h:7:43: fatal error: rendering/gl/RenderSystemGLES.h: No such file or directory
<ogra_> https://launchpadlibrarian.net/292945257/buildlog_snap_ubuntu_xenial_armhf_kodi-pi_BUILDING.txt.gz
<bschaefer> huh
<ogra_> any idea where that header should come from ?
<bschaefer> ooo dang
<bschaefer> yeah im stupid
<bschaefer> ogra_, rendering/gles/RenderSystemGLES.h
 * bschaefer fixes upstream
<bschaefer> my bad
<ogra_> ah
 * bschaefer pushed that last night but didnt compile that change
<bschaefer> ogra_, pushed change
<bschaefer> thanks for catching that!
<ogra_> thx
 * bschaefer compiles it here just to be sure
<bschaefer> ogra_, more compiling issues :) I really should have checked after removing more things
<bschaefer> ill let you know when i fix them (again my issue :)
<ogra_> no hurry
 * ogra_ is really only doing that for fun atm ... dont feel pushed
<bschaefer> is raspi3 arm64?
<ogra_> nope
<ogra_> armhf
<bschaefer> ogra_, o well its actually really nice since im fixing issues for this PR :)
<bschaefer> soo its good
<bschaefer> ogra_, dang was hoping once you got a snap made i could use it for dragon board :)
<ogra_> (there is an arm64 image in the works though ... but not done yet)
<ogra_> well, i'm building on LP ... if armhf builds it shouldnt be any prob to enable arm64 too
<bschaefer> ogra_, o very true
<bschaefer> ogra_, yeah once i figure out how to disable crystal-hd + (if you fixed that ffmpeg issue)
<bschaefer> then we can get one branch for amd64/armhf/64
<ogra_> well, i cheated badly :)
<bschaefer> :)
<ogra_> i git cloned your treee inot the snapcraft bzr tree ... changed snapcraft.yaml to "source: ./xbmc" and copied the ffmpeg tarbal in the right place
<ogra_> a quick and dirty "fix" :)
<bschaefer> :)
<bschaefer> yeah thats kind of what i did before
<bschaefer> but i didnt want to push the entire xbmc up to launchpad but i should have for a launchpad snap
<ogra_> well, you could include the tarball in your github tree otherwise
<ogra_> if the code finds it in the right place it wint wget it ...
<ogra_> *wont
 * bschaefer just has to figure out why it wants to do the Windowing EGL vs just mir
<bschaefer> ogra_, right but i cant do that since my github is in a PR and i dont want to include that in the PR
<bschaefer> my plan was to fork it if i couldnt get something working though
<ogra_> uh,  yeah
<bschaefer> so i could have a copy of kodi with that tarball in it
<bschaefer> (super backup case :)
<ogra_> well, cjwatson told me there is a fix for the wget issue in LP ... just not landed yet
<ogra_> so the hacks are all just interim anyway
<ogra_> https://code.launchpad.net/~cjwatson/launchpad-buildd/snap-proxy-allow-build/+merge/310050
<ogra_> there
<bschaefer> o sweet
<bschaefer> yeah i should have poked someone about that
<bschaefer> hmm not sure if i can use opengles with out the egl windowing system wanting to be ticked on
 * bschaefer is not so great at cmake/autotools haha
<bschaefer> as i really dont want to create an empty EGL Mir type
<kdub> no one's great at autotools
<bschaefer> haha
 * bschaefer may have fixed both autotools and cmake ...
<bschaefer> ogra_, fixed, and pushed
 * bschaefer testing out a new snap setup ... hopefully it'll work
#ubuntu-mir 2016-11-11
<bschaefer> hmm no usage for INTERNAL_DVDCSS seems to want to download its own tarball
<duflu> Morning
<duflu> Bye
 * duflu -> EOW
#ubuntu-mir 2016-11-12
<fritsch> bschaefer: https://github.com/fritsch/xbmc/commit/372a3ff88360ded6fb09692621cbfe88d34aa9f0 works for me quite fine on X11
<fritsch> that's basically your work with some kodi glue and proper closing of the handle
<fritsch> that will really make VAAPI X11 unaware which is really great
<fritsch> thanks very much for that
<bschaefer> :) yeah was reading the code
<bschaefer> and *all* the direct calls for the x11 display it self was only used to get the va display
<fritsch> jep
<fritsch> "historic reasons"
<bschaefer> yeah it happens :)
<fritsch> we use glx via vaPutSurface before
<fritsch> used
<bschaefer> oo yeah that makes sense
<fritsch> which was _the only_ way
<fritsch> to use vaapi for a very long time
<bschaefer> fritsch, here is a cheap RAII for the fd http://paste.ubuntu.com/23467327/
<bschaefer> (since i wasnt cleaning it up before)
<bschaefer> o i see, well seems like DRM/EGL is a very nice cross display server
 * bschaefer was going to look into making a better look up of /dev/dri/renderD
<bschaefer> and to check for kernel >= 3.15
<fritsch> there is a better one
<fritsch> let me find it out - I just "patched it together" for a wayland packager
<bschaefer> o sweet :)
<bschaefer> i was just reading its somewhere between 128 < 128 + 64
<bschaefer> fritsch, also the other thing i wanted to ask: CSingleLock lock(g_graphicsContext);
<bschaefer> was that just needed to get the X11 display?
<fritsch> the problem here is
 * bschaefer didnt dig around to much about the thread saftey
<fritsch> that rendering in that does only work from thread 1
<fritsch> so whenever you access the display stuff
<fritsch> you need to make sure to use a more or less global lock :-(
<fritsch> which DRM will also solve for us
<fritsch> in that regard
<bschaefer> i see, but there was no g_Windowing usage there before?
<bschaefer> it just did a XOpenDisplay() vs a g_Windowing.GetDisplay();
<bschaefer> or you ment anytime you access the m_X11Display
<bschaefer> you'll need to lock, that makes sense
<bschaefer> fritsch, also the check of the ret of vaInit was only needed because i wasnt checking the FD (was getting a -1 on KMS/mir)
<fritsch> looking again
<fritsch> it was used from decoder thread
<fritsch> yeah, please pick what you need from that commit
<fritsch> it's yours :-)
<fritsch> not mine
<bschaefer> :)
<fritsch> i just fixed it up a bit
<bschaefer> yeah, anyone can take it :)
<fritsch> concerning the RAII - I think explicit close is fine
<fritsch> we have the destroy context anyways
<fritsch> so, something explicit is done never the less
<bschaefer> yeah thats fine, i was checking when i manually hit exit it wasnt hitting the dtor anyway (not sure why)
 * bschaefer assumes someone kills the thread in an unkind way :)
<fritsch> but do it how you prefer it, you know what you are doing :-)
 * bschaefer spend yesterday just reading about drm/vaapi soo still figuring things out
<fritsch> you exactly hit the 4 points that needed adjustment
<bschaefer> but yeah ill attempt to clean it up and would most likely be better in a different branch
<fritsch> so all fine
<fritsch> jep
<bschaefer> (as this branch would also affect x11 less confined)
<fritsch> This change can also be PRd separately
<bschaefer> yeah i agree
<fritsch> then we can discuss it and you can base your other MIR work on that then
 * bschaefer should figure out git a bit more
<bschaefer> sounds good!
<fritsch> what kernel version has ubuntu 14.04?
<fritsch> 3.13 right? iirc?
<bschaefer> dang let me check im always way to far on the ubuntu version ... on yakkety atm
<fritsch> 14.04.4 should have a far newer one
<fritsch> i have zero issues dropping support for any kernel < 4.0 anyways
<fritsch> as we require vaapi 0.34 anyways
<bschaefer> well then that makes things easier :)
<fritsch> which only 16.04 or later ship (of the supported ones)
<fritsch> it's intel gpus - things were pretty rough back at 3.13
<bschaefer> looks like 3.16
<fritsch> nope
<fritsch> that can't be :-)
 * bschaefer checks the actual
<bschaefer> source list
<fritsch> http://packages.ubuntu.com/trusty/linux-image-generic
<fritsch> 3.13
<fritsch> let's see what the debian stable guys are doing
<bschaefer> yeah there we go
<fritsch> 3.16
<fritsch> no problem - just write a comment above it
<fritsch> and fine
<bschaefer> sounds good, sounds like if you dont have vaapi 0.36 you disable it anyway
<fritsch> jep
<bschaefer> cool, ill try doing a branch directly from xbmc vs fork
<fritsch> it should all run on 16.04 (concerning vaapi)
<fritsch> what do you mean by that? :-)
<fritsch> I'd just fork kodi once to your repo, that you did
<fritsch> now create a seperate branch: vaapi-dropx11-dependency
<bschaefer> well dont think i can fork again... i know bzr but not git very well :)
<bschaefer> ooo
<bschaefer> from my fork dang... well ive been pusing to master in my fork
<fritsch> you already forked on github :-)
<fritsch> by clicking fork
<bschaefer> right, then i didnt branch
<bschaefer> in my fork haha
<fritsch> jep, you dev on your master
<fritsch> not a problem
<fritsch> stash everything or commit it locally
<fritsch> then add xbmc-upstream as remote, by doing
<bschaefer> hmm how do i go back to xbmc master then branch from that? So i can avoid the mir changes?
<fritsch> git remote add xbmc-upstream https://github.com/xbmc/xbmc.git
<bschaefer> since the vaapi stuff is differnet
 * bschaefer will just have to read up on git
<fritsch> i just tell you
<fritsch> now do in your master: git commit -m "Squash me later, clean me up" -a
<fritsch> followed by:
<fritsch> git fetch xbmc-upstream
<fritsch> git checkout -b vaapi-drop-x11 xbmc-upstream/master
<fritsch> now you are on a vanilla new branch of kodi's master
<bschaefer> oo that make sense
<bschaefer> cool, thanks!
<fritsch> now either cherry-pick the commit you have in your master
<fritsch> by doing: git log master
<fritsch> finding the id
<fritsch> and doing: git cherry-pick id
<fritsch> that will apply just that commit on top
<fritsch> you can also add me as remote
<bschaefer> o so i can pick from your commit
<bschaefer> vs commit this
<fritsch> git remote add fritsch https://github.com/fritsch/xbmc.git
<fritsch> git fetch fritsch
<fritsch> git cherry-pick b044a9ff578d3fddb4a717e266d5e6f8b32bb678
<fritsch> that gets you my commit I showed you
<fritsch> now do your changes, commit them
<fritsch> git commit -m "squash me" -a
<fritsch> now comes the git magic after you are finished with everything:
<fritsch> git fetch xbmc-upstream
<fritsch> git rebase -i xbmc-upstream/master
<fritsch> now squash the squash commit in the first one (writing squash in front of it instead of pick)
<bschaefer> that happens on the rebase?
<fritsch> afterwards: git push -f origin vaapi-drop-x11
<fritsch> on the rebase it uses the xbmc-upstream/master branch
<fritsch> as a given base
<fritsch> and tries to apply your commits on top of it
<bschaefer> to *base* the changes against (something i wish bzr had)
<fritsch> you can see them (-i <- interactive)
<fritsch> and either pick them, or squash them
<bschaefer> o cool, ill be using that
<fritsch> pick 1234
<fritsch> squash 4567
<bschaefer> fritsch, from there do a pull request from that branch?
<fritsch> that will squash 4567 into 1234
<fritsch> jep exactly
<bschaefer> sweet
<fritsch> you should never rebase if you are the upstream
<fritsch> as rebasing means: loosing history
 * bschaefer now knows git until something goes wrong horribly :)
<fritsch> :-)
<fritsch> yeah, just ping me - I can help you
<bschaefer> cool, and thanks again!
<fritsch> oki, so let's as next step try to get that DRM PR out to us
<fritsch> i hope I convince everyone to branch in a very near future
<bschaefer> do the PR now before clean up?
<bschaefer> (for at lease conversation)
<fritsch> nope, after you are finished with everything
<bschaefer> o ok sounds good
<fritsch> as you like it
<bschaefer> yeah
<fritsch> then we can discuss on the final commit
<fritsch> concerning printf and kodi
 * bschaefer likes printf
<fritsch> for kodi we use CLog and its static method Log
<fritsch> there is LOGNOTICE, LOGDEBUG, LOGERROR
<bschaefer> i tried looking for this log before...
<fritsch> notice spams everything, LOGDEBUG only when debug logging is enabled
<fritsch> ERROR makes it red in the log
<fritsch> hehe
<bschaefer> is it an env var?
<fritsch> nope
<bschaefer> or compile time?
<fritsch> you include it
<fritsch> #include "utils/log.h"
<bschaefer> i mean umm how do i read these logs?
<fritsch> all that stuff lands in ~/.kodi/temp/kodi.log
<fritsch> tail -f ~/.kodi/temp/kodi.log
<bschaefer> o ok thats where i was missing
<bschaefer> fritsch, yeah i usually use printf for my own debugging to stdout/err but usually switch to loggers :)
 * bschaefer will attempt to just use the logger
<fritsch> For DIVX: Player Settings (Expert Hierarchy) -> Enable Mpeg4
<fritsch> we have it disabled by default. As you know: in the times of divx and mpeg-4
<fritsch> the standard was not so standard as h264 was
<bschaefer> o dang, yeah i can imagine
<fritsch> hehe
<fritsch> oki, for the DRM change I think it won't make it into v17 - as it is a majore change and we are near to RC
<bschaefer> yeah i agree (it has possible problems not tested out)
<fritsch> but if the code is written and ubuntu will ship mir + kodi
<fritsch> you can easily pick your "upstream" commit
<fritsch> into your package as upstream backport patch
<bschaefer> yeah i can also push a pathc
<bschaefer> yeah
 * bschaefer was my plan :)
<fritsch> that's why it's brilliant if we get it upstream
<bschaefer> if it wasnt part of the release
<fritsch> we often need to cope with the other way round :-(
 * bschaefer prefers upstream == less patches
<fritsch> distros patch and patch
<bschaefer> yeah
<fritsch> and we don't see the patches - and more severe - cannot tell what is wrong
<bschaefer> gets very crazy trying to debug someones binary when they have all these patches
<bschaefer> yeah!
<fritsch> if you can make the first mir release with a fully mir aware kodi + hw accel
<fritsch> people will realize something: it's easy to use mir
<fritsch> and it just works
<fritsch> at the end ubuntu is aimed at the desktop
<fritsch> not at the frickler, that is hacking everything together
<fritsch> so out of the box experience is the most important for such a goal
<bschaefer> yup, soon *hopefully* people will realize they wont even notice what display server they are running
<fritsch> that's the goal, exactly
<bschaefer> yup :)
<fritsch> perhaps there is even a "better way" of surface sharing without egl
<fritsch> with just drm
<fritsch> i know there is, but zero copy rendering is not just about copying
<fritsch> but yeah, displaying it directly
<fritsch> current limitation with vaapi is, that there is no way to transfer yuv420p10
<fritsch> via egl / mesa
<fritsch> means: hevc-10 decoded content we can currently not display
<fritsch> (won't work on your laptop anyways)
<fritsch> need to wait for the T470
<bschaefer> o so its planned but not released?
<fritsch> but we are working on that with the mesa guys
<bschaefer> very nice!
<fritsch> i have a poc already that decodes and shows what is missing for the render part
<fritsch> basically we miss the R16 G16 and RG16 transfer format
<bschaefer> also, to really see the difference between a hw accel vs software for the video...
<bschaefer> should i just stress my system?
 * bschaefer cant really tell when software seems to render fine
<bschaefer> i assume the embedded devices will be a big difference
<fritsch> https://github.com/fritsch/xbmc/blob/372a3ff88360ded6fb09692621cbfe88d34aa9f0/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1238 <- see
<fritsch> you can do: kodi-send -a PlayerDebug
<fritsch> there you see render skips and render drops
<fritsch> if you don't get any skips
<fritsch> all fine
<bschaefer> ooo very good to know
<fritsch> if you want to test mir's throughput
<fritsch> there is a 3840x2160p60 <- 60 progressive frames
<fritsch> of a h264 big buck bunny
<fritsch> that's a good throughput test
<bschaefer> o geez, yeah that sounds like a good test
 * bschaefer goes to download
<fritsch> as you run windowed, make sure to set the scaling to bilinear
<fritsch> your broadwell (T450) won't be fast enough to do it with lanczos3
<bschaefer> fritsch, well the screenshots i usually show is in the X11 platform (ie. Mir on X)
<bschaefer> which is not great for throughput testing
<bschaefer> since theres the added X11 layer
 * bschaefer will test on the metal for that in KMS which will be fullscreen
<fritsch> you can press enter while playback
<fritsch> go to the video settings comming up
<fritsch> and choose: Deinterlace-Method: VAAPI-MCDI
<fritsch> and Scaling-Method: Bilinear
<fritsch> and do: save for all videos
<fritsch> normally we prefer lanczos3 (quality of course)
<fritsch> but it makes no sense to upscale 1080p to 1080 display with a lanczso scaler
<fritsch> :-) as nothing is scaled
<bschaefer> hmm i only see VAAPI-Bob, VAAPI-MotionAdaptive
<bschaefer> and motion comp
<fritsch> jep
<fritsch> mcdi <- motion compensation deinterlacing
<fritsch> the "translation" guys :-)
<fritsch> had fun
<fritsch> http://forum.kodi.tv/showthread.php?tid=231955 <- here is a bit of a read up why vaapi is as it is now
<bschaefer> o cool im trying to read up a bit more on this whole thing
<fritsch> and also some settings - but "slow" :-) too much information currently
<fritsch> don't stress yourself, please - I am a bit in ahurry, that's why I post so much information
<fritsch> hehe
<bschaefer> o no worries :)
<bschaefer> i can always re-read the logs (which i usually end up doing to double check things)
<fritsch> oki, then I wish you good luck on the rest of the way to a working mir + vaapi
<fritsch> i think if you have some nice screenshots up and running
<bschaefer> thanks, and thanks again for all the info!
<fritsch> the "linux bild zeitung" <- german for news paper stuff
<fritsch> will make something about it
<fritsch> phoronix.com
<bschaefer> yeah ill make sure to get some screen shots of mir + x11 as well
<bschaefer> to show both still working
<fritsch> not for me - if you want some positive publicity about "how easy it is" to support mir
<fritsch> then www.phoronix.com is a good thing ... (only for that ;-))
<bschaefer> true, depends on how its spinned :)
<fritsch> we sometimes ask them to publish things whenever hw vendors don't make good drivers
<fritsch> there was a "fglrx time"
<fritsch> in shorT: their driver sucked, their xvba sucked, we made it public. amd oss devs implemented vdpau with us
<fritsch> we dropped fglrx completely
<bschaefer> :)
<fritsch> tadaaa :-) dead of fglrx in linux world for any video decoding stuff
<fritsch> and since then we still work with the amd oss devs together, especially when we plan new stuff
<fritsch> wayland support, egal buffer sharing
<fritsch> and so on
<bschaefer> nice! That helps a lot i can imagine!
<fritsch> oki - afk now :-) good luck with all the stuff
<fritsch> and do not hessitate to ping me
<bschaefer> thanks! (only about noon here)
<fritsch> or send me an email
<fritsch> or github
<fritsch> whatever you prefer
<bschaefer> cool, sounds good
<fritsch> bschaefer: PlayerProcessInfo -> just press "o"
<fritsch> (so, now I am really gone)
<fritsch> but this does not show PlayerDebug info
<bschaefer> ill hvae to use that debug command from above i assume?
 * bschaefer can dig around
<fritsch> or map it to another key, e.g. ctl-o
<bschaefer> good idea
#ubuntu-mir 2016-11-13
<bschaefer> fritsch, soo im guessing that DRM branch (if I cant show it works for multiple monitor + multiple gpu wont be a go)
<bschaefer> which is fine. I can ifndef around to keep x11 in place then just DRM for anything else
<fritsch> bschaefer: :-)
<fritsch> don't use ifdefs are he will get more "angry"
<bschaefer> :)
<fritsch> you did nothing wrong - but yeah, you hit something that broke kodi over time
<bschaefer> yeah, the drm code was just put out in vaapi in 2014? or 15
<bschaefer> very recent
<fritsch> not really recent
<fritsch> as we (kodi) helped developing the egl interop
<fritsch> so for us not recent
<bschaefer> yeah, im still not sure of the pro for using x11 display directly
<fritsch> the discussion was not ontopic anymore - just some old battles fought out
<fritsch> about recent "problems"
<fritsch> there is no advantage
<fritsch> none at all
<bschaefer> (besides picking a device if youve multiple i suppose?) But i cant test that
<fritsch> it was from ancient time, when the vaPutSurface method for vaapi was tight to the rendering / display
<bschaefer> o i see, which im assuming your trying to decouple?
<bschaefer> (though depends on EGL atm anyway)
<bschaefer> from the display server
<fritsch> i see no point in coupling a decoder on a window server
<fritsch> if everything it needs is a EGLDisplay
<bschaefer> right... which it already does that :)
<fritsch> the libva guys also saw that ... if you look in the android "backend" code
 * bschaefer will have to poke RAOF about render nodes today when he gets on
<bschaefer> fritsch, o yeah theres like nothing there
<bschaefer> fritsch, the issue is i cant *open* card0
<bschaefer> since mir already opens that
<fritsch> no need to do so
<fritsch> let me link you something
<bschaefer> which is why render nodes are perfect
 * bschaefer is still waking up and starts making coffee
<fritsch> https://lists.freedesktop.org/archives/libva/2014-September/002719.html
<fritsch> here is the patchset that added it
 * bschaefer looks
<fritsch> the 2/2 patch
<fritsch> has a test code
<bschaefer> fritsch, o yeah i read that yesterday while digging around
<fritsch> gwenole (the master mind of intel va) - not at intel anymore sadly - gave that test code
<bschaefer> (well when i was running into issues with drmOpen)
<fritsch> so, usage is perfectly fine
<fritsch> back at the time, when render nodes nor EGL dma buf sharing existed
<fritsch> the only way to get surfaces was either use vaPutSurface
<fritsch> which was used for rendering, therefore used "X11" or whatever dependencies
<fritsch> but then the infrastructure was finished
<bschaefer> which makes sense!
 * bschaefer needs to read how render nodes was implemented in the kernel
<bschaefer> as im not *sure* what happens if you multiple render nodes
<bschaefer> though reading it *shouldnt* matter
<fritsch> I'd say nothing
<fritsch> caus either: you can't open the node at all
<fritsch> vaapi -> side
<fritsch> or b) the interop fails
<fritsch> but that should only fail if the eglDisplay / context
<fritsch> is not valid
<bschaefer> well lets say you have intel +  nvidia and you want to make kodi run on nvidia while your main display server runs on intel
<bschaefer> IIRC you *can* do that
<bschaefer> which idk ... what would happen or if we even support that :)
<fritsch> nvidia has no support for the R8,G8 whatever sharing
<fritsch> that means the moment the intel driver does no "own" the EGL context
<fritsch> querying the extension will already fail
<fritsch> I assume :-)
<bschaefer> well then ... seems like more and more pointing to drm will work
<bschaefer> how it already works
<fritsch> yeah, as said - keep the PR as is for now. Thing will settle and calm down
<bschaefer> yeah, I fixed the camel case and made a small comment but figured best left to let the dust settle :)
<bschaefer> no worries
<bschaefer> in the meantime ill now attempt to test mir how you mentioned in hopes of really testing the difference :)
<bschaefer> it seems faster then x11 atm (at lease on my tests) for skipping at lease which means... the rendering
<bschaefer> i think (vs drop which is the decoder?)
<fritsch> i hope it IS faster than X11 :-)
<fritsch> btw. are you sure you use lanczos3 scaler?
<fritsch> afaik that only had GL support last time I looked
<fritsch> drop is the decoder, yes
<fritsch> skipping <- render performance
<fritsch> benchmark case: 3840x2160 h264 60p, downscaled with lanczos3 to 1080p60
<fritsch> you might only have nearest neighbour + bilinear available, though
<bschaefer> fritsch, i wasnt really sure, i tried to change things but the settings when i hit o didnt seem to reflect the changes
<bschaefer> which was confusing
<fritsch> they don't afaik
<fritsch> those values are hold in a ProcessInfo class
<bschaefer> o well that makes sense since when i hit o it says dinterlace method: None
<fritsch> that's fine
<fritsch> you don't want to deinterlace progressive content
<fritsch> http://solidrun.maltegrosse.de/~fritsch/
 * bschaefer checks the scaler
<fritsch> here are some samples I used when developing IMX6 support
<fritsch> the 1080i50 should show something else, preferable VAAPI-MCDI
<fritsch> then there is "Bob and Deinterlace" <- be careful with them, those cause a SSE copy and either deint in render (GL) or via ffmpeg's yadif on the cpu
<fritsch> they switch the "path" in vaapi automatically, as told on github with the Prefer VAAPI-Output
<fritsch> which was the last line you got? :-)
 * bschaefer froze
<bschaefer> <fritsch> you don't want to deinterlace progressive content
<bschaefer> sometimes devices like to fight when running two display serves
<bschaefer> servers*
<fritsch> 16:37 < fritsch> http://solidrun.maltegrosse.de/~fritsch/
<fritsch> 16:37  * bschaefer checks the scaler
<fritsch> 16:37 < fritsch> here are some samples I used when developing IMX6 support
<fritsch> 16:37 < fritsch> the 1080i50 should show something else, preferable VAAPI-MCDI
<fritsch> 16:38 < fritsch> then there is "Bob and Deinterlace" <- be careful with them,  those cause a SSE copy and either deint in render (GL) or via  ffmpeg's yadif on the cpu
<fritsch> sorry :-)
<bschaefer> o sweet yeah missed all that!
<bschaefer> right after i said checks the scaler i dropped :)
<fritsch> btw. something for ubuntu: there is only one render node by default
<bschaefer> fritsch, yeah youre right linear/bi
<bschaefer> even when theres multiple gpus?
 * bschaefer use to have a laptop that had two
<fritsch> i think he is not correct
<fritsch> as the dma_buf is a kernel infrastructure
<bschaefer> yeah x11 has the lanczo3 scaler
<bschaefer> not mir
<fritsch> it is just used as a zero copy
<fritsch> interface
<bschaefer> yeah reading that link you put (which clearly states its not a 1to1)
<bschaefer> its like that for legacy reasons
<fritsch> which one was that?
<bschaefer> "Itâs also important to know that render-nodes are not bound to a specific card. "
<bschaefer> https://dvdhrm.wordpress.com/tag/drm/
<bschaefer>  Instead, if user-space requires hardware-acceleration, it should open any node and use it.
 * bschaefer would still like better documentation on render nodes, since i had a hard time finding the *real* number after renderD<num>
<bschaefer> found some kernel usage of 128->128+16 soo i assumed but still didnt find any real manual pae
<bschaefer> page*
<fritsch> yeah, try to link him that thingy above if you want to get into a discussion
<fritsch> in fact he is not right
<fritsch> :-)
<fritsch> but I gave up
<bschaefer> "Yes, driver-specific user-space can figure out whether and which render-node was created by which driver, but driver-unspecific user-space should never do that!"
<bschaefer> but kodi *is* not driver specific
<bschaefer> soo it *shouldnt* matter
<fritsch> jep
<fritsch> cite that and see what happens :-)
<bschaefer> done! But yeah I was going to poke RAOF later (which he knows far to many things...)
<bschaefer> and hopefully can confirm the same... I can try to find more documentation or just read the kernel code
<bschaefer> fritsch, so if im comparing against X11 and Mir doesnt support lanczos3 it seems unfair
<bschaefer> to test them against each other using different scalers
<fritsch> you needed to port the GL code of lanczos3 to the EGL render
<fritsch> you can do differently
<fritsch> mmh, nope you can't
<bschaefer> haha, yeah something to *do* later
<fritsch> concerning the render nodes
<fritsch> just open two mirs
<fritsch> and two kodis
<fritsch> i say: both work fine, as the EGL ctx decides
 * bschaefer shutters at resampling for rewriting some of those bits for touch events
<fritsch> no matter which render node in use
<bschaefer> fritsch, thats the things about render nodes though, they are unprivileged and allow for rendering on it with out any auth magic
<bschaefer> (from my reading at lease)
 * bschaefer can try to open two mir servers in kms and see what happens never really did that
<fritsch> you can also just run kodi twice
<fritsch> and see what happens
<bschaefer> o true
<fritsch> cause, consider the use case: video playback, someone comes via ssh
<fritsch> and transcodes his video
<fritsch> both must work
<fritsch> :-)
<bschaefer> fritsch, yeah no issues
<bschaefer> with two kodis one 1 mir server
<fritsch> bschaefer: yeah, a nice screenshot would also help
<fritsch> that proves: the EGL ctx
<fritsch> decides
<fritsch> and the render node is just "below"
<fritsch> and even copes with two processes
<bschaefer> fritsch, like http://i.imgur.com/fEsKY5p.jpg?
<fritsch> play a different video :-)
<fritsch> in one of the windows
<bschaefer> haha true
<fritsch> but yeah, it's obvious already
<fritsch> nice - two times 60 fps
<fritsch> or open the "o" dialogue on one
<bschaefer> o right
<bschaefer> fritsch, http://i.imgur.com/0cEq880.jpg
 * bschaefer needs a different 60pfs video
<fritsch> hehe
<fritsch> really fine
<bschaefer> fritsch, also there was nothing else needed to be done on the mir branch it self?
<ogra_> bschaefer, FYI  https://code.launchpad.net/~ogra/+snap/kodi-mir-snapshot ...  (but i cant get it to run )
<ogra_> (and arm64 is completely unknown to the kodi build system it seems)
<bschaefer> ogra_, sweet! You cant get it to run because raspi?
<bschaefer> or you're trying on the dragon board? I can imagine...
<ogra_> i cant get it to run on qemu either ...
<bschaefer> :(
<ogra_> no, dragonboard is arm64 ... that doesnt build
<ogra_> well, its a start ...
<bschaefer> ogra_, https://github.com/asciper/KodiDragonboard410c
<ogra_> on the pi i have no mir-libs
<bschaefer> err i ment arm64
<ogra_> oh, cool
 * bschaefer hopes that *might* have some patches to make it work
<bschaefer> ive yet to dig to deep into that branch
<bschaefer> it adds an arch64 though
<ogra_> yeah, there are quite some changes to WinSystemX11.cpp
<bschaefer> soo hopefully thats whats missing
<ogra_> i guess the mir one would need them too
 * bschaefer looks
<bschaefer> ogra_, hmm looks like it just reports errors
<ogra_> looking at https://github.com/asciper/KodiDragonboard410c/blob/master/patches/ubuntu/0001-Patch-for-DragonBoard410c-Kodi-build.patch
<bschaefer> more so
<bschaefer> yeah
<bschaefer> diff --git a/xbmc/windows/GUIWindowSystemInfo.cpp b/xbmc/windows/GUIWindowSystemInfo.cpp
<bschaefer> that *may* be needed
<ogra_> anyway, i have the snaps but cant run them, there seems to be no armhf mir-libs in the store
<bschaefer> pretty much ill need to go through and find any define for __arm__ and and __aarch64__
<bschaefer> ogra_, dang and alberto is out until nov 22
<bschaefer> or 21st
<ogra_> same for me (theoretically) ... i'm alread on vacation ;)
<bschaefer> :)
 * bschaefer is just messing with kodi upstream patchs soo no real work today!
<bschaefer> ogra_, thanks for testing that and getting a snap on launchpad!
<ogra_> well, there is still a lot work ahead i guess ... but its a start
<bschaefer> yeah i agree
<ogra_> (despite a horribly hackish one)
<bschaefer> ogra_, o also got vaapi working
<bschaefer> for mir
<bschaefer> soo thats good
<bschaefer> using the DRM + EGL backend + Render Nodes
<ogra_> nice
<ogra_> (not much helpful for pi3 though ... which is what i'm after)
<bschaefer> :( you mentioned that needed a kernel driver?
<ogra_> but i guess there getting mir at all up is the biggest blocker
<bschaefer> for actually getting mir working?
<bschaefer> yeah :)
<ogra_> well, tvoss and ppisati seem to work on that
<bschaefer> cool, we can assume it'll be done eventually :)
<ogra_> but i dont know any current status
<bschaefer> ogra_, do you use lxd or pbuilder or chroot for arm64?
 * bschaefer should get something setup for testing at lease vs the dragon board directly
<ogra_> after an initial bringu i tend to rely on launchpad
<ogra_> native and really fast ...
<bschaefer> that works as well!
<bschaefer> cool, and thanks again! Enjoy your vacation :)
<ogra_> :)
<ogra_> well, i'll surely tinker around during it :)
<fritsch> bschaefer: nope all fine I think, squash the relevant commits together and keep it standing there
<bschaefer> fritsch, o so its bad to have like 20 commits? Wouldnt it all be merged into one when it gets pulled into xbmc?
<fritsch> nope
<fritsch> you can decide what you want to squash before hand
<fritsch> it needs to be: bisectable after squashing
<bschaefer> well ill just squash into one commit Mir windowing system
 * bschaefer will look into that
<fritsch> commits "fitting together" need to be squashed
<bschaefer> hmm "fitting together?"
<fritsch> example:
<fritsch> Vaapi: 2 changes, LinuxRenderGLES: 3 changes
<fritsch> the vaapi fixes is feature + squash for feature => squash the two commits
<fritsch> for linux render, 1 bugfix and one new feature in 2 commits
<fritsch> squash the 2 commits into one
<fritsch> and leave the bugfix separated
<fritsch> in your case: squash everything together that implements only MIR
<bschaefer> o ok that makes sense
<bschaefer> yeah
<fritsch> if there was bugfixes for generic code, leave those as is
<bschaefer> since its a feature + no bug fixes since it wasnt around before :)
<fritsch> yeah
 * bschaefer doesnt think he fixed anything for xbmc in this branch
<fritsch> btw. rethinking the GPU1 and GPU2 scenario
<fritsch> that scenario would be: intel gpu1, amd gpu2
<fritsch> cause neither nvidia nor fglrx support dma_buf (GPL)
<fritsch> so that would mean, you need to use the intel gpu1 for processing (as gpu2 would not do vaapi anyways)
<bschaefer> thats a more realistic example
<fritsch> now you needed to display on gpu2, which is AMD
<fritsch> but - this card does not support the R8G8 mesa extension
<fritsch> :-)
<fritsch> so, figure
<fritsch> https://linux.slashdot.org/story/12/10/11/1918251/alan-cox-to-nvidia-you-cant-use-dma-buf <- nvidia
 * bschaefer trying to figure out *when* a render node is allowed to open
<bschaefer> anytime?
<bschaefer> i assume so
<fritsch> and something else:
<fritsch> there won't be two heads active
<fritsch> even not in a laptop
<fritsch> so the given code neither runs on amdgpu as of now via vaapi
<fritsch> and with nvidia it would make zero sense, that you choose the nvidia rendernode
<fritsch> as that is not vaapi capable
<bschaefer> true, i think that branch is a step forward (ie. it does everything that is currently supported)
<bschaefer> from what i understand
<fritsch> yeah
<bschaefer> i suppose possibly more voices will come through in a few days
<fritsch> there is only exactly one "problem"
<fritsch> gpu1 decodes via vaapi
<fritsch> gpu2 would be needed to display and would support R8G8 dma_buf sharing
<fritsch> what would not happen, that's the only case I see a problem with
<fritsch> cause for now - we fail much earlier
<fritsch> and there are simple not two intel gpus
<fritsch> you cannot just "stick" 2 of them into your computer
<bschaefer> i suppose for ... imagining sake. *if* there were two active GPUs
<bschaefer> it *shouldnt* matter from what im reading... render nodes *do not* 1to1 to a card
<fritsch> if there were, both need to support dma_buf and both need the mesa RG8 extension
<fritsch> jep, they don't
<bschaefer> for legacy reasons render nodes are create per device
<bschaefer> does not mean they map 1to1
<bschaefer> 1toany is more like it
<fritsch> dma_buf is a kernel API
<fritsch> it does not matter which gpu is rendering
<fritsch> as long as it supports dma_buf and the extension to create the image
<fritsch> yeah, take your time to reply ...
<fritsch> :-)
<fritsch> getting popcorn
<bschaefer> its kind of misleading to be honest and i was thinking about the same :)
<bschaefer> im going to wait a bit
<bschaefer> as, i dont think that paper helped sway his point of view
<fritsch> yeah
<bschaefer> as this point, i mean ill need a concrete example to convince which i dont have the hardware atm :)
<bschaefer> at this point*
<fritsch> there is no such hw combination
<fritsch> for what he is asking
<fritsch> as there is no GPU besides intel that has this support: https://github.com/BrandonSchaefer/xbmc/blob/6a668e62f15c8114cb43585af8760ed7a42d01dd/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1285
<bschaefer> a mythical device
<fritsch> he might come up with - then let's share with RGBA ...
 * bschaefer doesnt actually fully understand that code :)
<bschaefer> as i understand it, you get a raw decoded image
<fritsch> it's quite easy
<bschaefer> from vaapi then copy it
<bschaefer> (into a texture then render?)
<fritsch> you tell vaapi to derive an image
<fritsch> use that via vaAcquiteBufferHandle
<fritsch> and now create an egl image of it
<bschaefer> which is just the decoded buffer from the hardware?
<fritsch> yeah
<fritsch> then the eglCreateImageKHR is used
<fritsch> to create Y
<fritsch> and VU
<fritsch> this is later used in a yuv2rgb shader for display
<bschaefer> then just render this through a shader?
<fritsch> jep
<bschaefer> well that makes sense
<bschaefer> and you need EGL_LINUX_DRM_FOURCC_EXT to get that raw image?
<fritsch> that's the format we use
<fritsch> YUV 8 bit
<fritsch> Y -> 8 bit
<bschaefer>     This extension allows creating an EGLImage from a Linux dma_buf file   descriptor or multiple file descriptors in the case of multi-plane YUV  images.
<fritsch> and UV
<bschaefer> right
<fritsch> yeah, was created for kodi :-)
<bschaefer> otherwise you would have to convert?
<bschaefer> o very nice!
<fritsch> otherwise we needed to say to vaapi: create a RGBA
<fritsch> and 4*8 >> 8 + 2*4 = 16
<bschaefer> i suppose the shader could do that... possibly
<fritsch> and doing yuv-> RGBA needs an intermediate
<fritsch> yeah, but why?
<bschaefer> haha yeah :)
<bschaefer> better then software
<bschaefer> (looking at how bad software was!)
<fritsch> I am currently in contact with the intel guys to get RG16 and R16
<bschaefer> o nice
<fritsch> as their hevc-10 bit is stored in P010 format
<fritsch> basically same as NV12
<fritsch> but 16 bit and the 10 bits are only relevant
<fritsch> so the shader afterwards needs to do something "additional"
<fritsch> down dithering for 8 bit rendering
<fritsch> and extracting the values
<bschaefer> huh its 16 bits but you only use 10
<bschaefer> for p010
<fritsch> jep
 * bschaefer has never heard of that
<fritsch> how would you efficently store 10 bit?
<fritsch> :-)
<fritsch> while still using fast data access?
<bschaefer> haha yeah
<fritsch> and that way we are ready for 12 bit, 16 bit and so on
 * bschaefer would hope to use those extra 5 bits for more data
<fritsch> btw. "more data"
<fritsch> i hope MIR has something like metadata
<fritsch> all that 10 bit to 8 bit
<fritsch> limited range to full range
<fritsch> just sucks for userspace
<fritsch> we would normally juse say: here -> texture / image / whatever -> it is limited range
<bschaefer> hmm most pixel formats we have are 32 bit + some 24 bits
<fritsch> display it properly
 * bschaefer isnt fully sure
<fritsch> that's the desktop
<fritsch> yes
<fritsch> but when doing video we have limited range by default
<fritsch> 16 .. 235
<fritsch> values
<fritsch> if you display them 1:1 on a full rgb display
<fritsch> you end up without whites
<fritsch> and without blacks
<bschaefer> o eww
<fritsch> that's why metadata is so important
<bschaefer> thats something RAOF would know :)
<fritsch> i am quite sure he does
<fritsch> now good luck with your reply
<bschaefer> haha
<bschaefer> thanks
<fritsch> afk a bit
 * bschaefer does the same
<bschaefer> fritsch, also is there interest in support arm64 in kodi? At lease for me there is :)
<bschaefer> configure: error: unsupported native build platform: aarch64-unknown-linux-gnu
<bschaefer> https://launchpadlibrarian.net/293127083/buildlog_snap_ubuntu_xenial_arm64_kodi-mir-snapshot_BUILDING.txt.gz
<bschaefer> ogra_, also you can try cmake vs their autotools.... since they plan on deprecating autotools: http://bazaar.launchpad.net/~brandontschaefer/+junk/xbmc-snap/view/head:/snapcraft.yaml#L48
<bschaefer> its commented out (plus you can fix some of the extra options since you've ffmpeg manually)
#ubuntu-mir 2017-11-06
<Son_Goku> alan_g, so this kind of is annoying
<Son_Goku> right now, I can run the unit tests for Fedora < 28
<alan_g> Son_Goku: totally agree
<Son_Goku> because Fedora 28 changes to offer libgmock library
<Son_Goku> so that means it needs to handle piles of sources OR libraries for BOTH gtest and gmock
<Son_Goku> @_@
<Son_Goku> tbf, RAOF asked for this :P
<Son_Goku> I didn't know it had been already fixed for Fedora 28
<Son_Goku> but it had
<Son_Goku> and I still don't understand why the one test fails on my computer
<Son_Goku> alan_g: interestingly, none of the tests fail in Koji (the build system)
<Son_Goku> so it's really just a problem for me testing builds locally
<alan_g> Son_Goku: the gmock changes go in the right direction, so I don't mind hacking around that. (But it may be few days before I can get to it)
<alan_g> The test failure is weird.
<xnox> alan_g|lunch, Son_Goku - i'm happy to change googletest/gmock/gtest in debian & ubuntu to whatever is the new best known practice to make things nice again everywhere.
<xnox> i heard here that compiling a shared library is sane again.
<xnox> but not currently done?
<Son_Goku> xnox: it is in Fedora now
<Son_Goku> but Debian explicitly doesn't do it yet
<Son_Goku> the only annoyance is that googletest/googlemock still doesn't do sonames for it
<Son_Goku> and Google doesn't want that either
<Son_Goku> so *shrugs*
<Son_Goku> they're very strange about this stuff
<Son_Goku> I've got a couple of patches to apply to our gtest package in Fedora to fix the soname thing
<alan_g> xnox: the irritation for me is that Ubuntu 16.04, 17.x and Fedo
<Son_Goku> supporting both ways is probably not a bad thing anyway
<alan_g> xnox: the irritation for me is that Ubuntu 16.04, 17.x and Fedora 26-27 and 28 all do it differently
<Son_Goku> given how fickle Google is
#ubuntu-mir 2017-11-08
<tjaalton> hi, the mesa vulkan-mir.patch broke radv (radeon vulkan) driver. I'll drop the patch unless it's fixed "soon"
<tjaalton> last I heard it doesn't work on intel either
<alan_g> tjaalton: I don't expect to find time to understand and fix the vulkan patches, unless some mysterious stranger volunteers go ahead and drop them.
<alan_g> Son_Goku: did you ever find a clue how to recreate your build error?
<Son_Goku> alan_g, I'm trying on a different computer now
<Son_Goku> if I can't reproduce it there, then fuck if I know what's happening
<tjaalton> alan_g: ok, thanks
<tjaalton> can be revisited later
<Son_Goku> alan_g, any progress on fixing the gmock detection?
<alan_g> Not yet reached the top of my list
<Son_Goku> alan_g, yep, basically there's something wrong with my computer
<Son_Goku> it works on another one of my computers just fine
<alan_g> I'm still curious how your computer can pick on that one test case. But I'll try not to worry.
<Son_Goku> the main difference is that my regular graphical user is ngompa, I sudo to makerpm user (which is a member of the mock group) and run mock there
<alan_g> Son_Goku: is there a Fedora 28 image around? (I only see Fedora 27 beta on getfedora)
<Son_Goku> alan_g: https://www.happyassassin.net/nightlies.html
<Son_Goku> download one of the green links under the Fedora Rawhide column
<alan_g> thanks
<Son_Goku> alternatively, you can install 27 and upgrade it to rawhide
<Son_Goku> I just did that yesterday and that worked pretty well
<Son_Goku> you'll want an ISO that's within the last month or so
<Son_Goku> if it's too old, then it's probably not going to be the Rawhide that will be Fedora 28
<alan_g> A recent 27 I already have in a VM. (Just need to figure out how to upgrade.)
<Son_Goku> that's easy
<Son_Goku> first, are you fully up to date?
<Son_Goku> not that it matters, but it makes things a bit smoother
<alan_g> I was on Monday
<Son_Goku> okay, then you're fine for the next step
<Son_Goku> sudo dnf --refresh --releasever=rawhide --nogpgcheck distro-sync
<Son_Goku> you'll want to do this in either a tmux session or in a VT so that if your graphical session dies, it doesn't break
<Son_Goku> it doesn't happen often, but it can
<alan_g> Not really a problem. I cloned it so I keep 27 around too.
<Son_Goku> cool :)
<Son_Goku> alan_g: I also emailed you a WIP (aka still broken) attempt at fixing it, perhaps you can use it to help get it fully working
<alan_g> Son_Goku: Got it, thanks.
#ubuntu-mir 2017-11-09
<Guest13499> Oh, good.
<Guest13499> Now that I'm actually testing Mir, it doesn't pass the wlcs tests.
 * Guest13499 thinks CLion at least should have a static analysis for âthis function which claims to return an int will instead always throwâ
<Guest13499> Good!
<Guest13499> Now GNOME Shell passes the wlcs tests!
<Guest13499> VICTORY
<alan_g> Son_Goku: I fixed the gmock issue in cmake, but am getting weird errors running some of the tests and wondering if F28 has known issues.
<Son_Goku> it's possible
<Son_Goku> Fedora 28 isn't branched yet
<Son_Goku> think of it like Debian sid at this point
<alan_g> In that case I'll leave it (for the time being).
<Son_Goku> I'm going to take a look and see what might be wrong with gmock
<Son_Goku> alan_g, what do the errors look like from the tests?
<alan_g> "double free or corruption"
<alan_g> And assorted expectation failures
<Son_Goku> hmm, are they happening in the test or in gmock?
<alan_g> https://pastebin.com/GLuMKTLe
<alan_g> I guess that one's an "invalid pointer"
<Pharaoh_Atem> alan_g: did you intend to not tag and release mir 0.28.2?
<alan_g> Pharaoh_Atem: 0.28.2? That's still under development
<Pharaoh_Atem> ah, I thought it was released since you made a debian changelog entry for it
<Pharaoh_Atem> https://github.com/MirServer/mir/commit/45e10eec40e8cdb590ef63b276823169fb9713d1
<alan_g> That's just a working draft ATM
<Pharaoh_Atem> ah, okay
 * Pharaoh_Atem is running through a build of mir with 0.28.1 with the two patches for Fedora
<alan_g> Cool, let me know how that works for you
