#ubuntu-mir 2013-04-08
<duflu> thomi: That glmark2 build failure... Don't fix it yet. I suspect the bigger problem is the API change, which I would like to revisit in Mir
<thomi> duflu: ok
<RAOF> Oh. Maybe *that's* why.
<RAOF> Adding a new mir_egl_mesa_display_is_valid() without removing mir_egl_native_display_is_valid() seems a bit hostile :)
 * duflu wonders if he's meant to understand RAOF's comment
<RAOF> I was just wondering why I can't get racarr's enable-inprocess-egl branch to work with more sensible mesa changes.
<RAOF> It was calling mir_egl_native_display_is_valid(), and mysteriously getting "false" for the answer.
 * duflu nods cluelessly
<RAOF> BAH! mir_demo_inprocess_egl is a Mir compositor itself. Of course it is.
<RAOF> In related news: we *really* suck at useful error messages :)
<RAOF> thomi: How's github mesa autopublishing coming?
<thomi> RAOF: hmmm, good point - last I heard Martin said "leave it with me". then he had a baby
<thomi> well, not *martin*, so much as his wife, I guess
<RAOF> That would have been even bigger news :)
<thomi> either way, I somehow doubt he's going to look at it in the next few days.
<thomi> I'll make a note to ping Larry tomorrow - we just need network access added for the jenkins instance, shouldn't be a biggie
<smspillaz> huh
<smspillaz> so can someone explain to me how chromium can use 2GB of memory in the space of an hour ?
<smspillaz> everything is getting oom-killed ... this is stupiud
<smspillaz> *stupid
 * smspillaz reboots
<RAOF> Hm. grep /**/*.* is unlikely to return anything useful in a short period :)
<duflu> smspillaz: Assuming it is real memory and not just address space bloat, it's likely some web page/script you had open
<smspillaz> duflu: google docs
<smspillaz> :(
<smspillaz> I'd like to see what Google does with docs given that they've forked webkit and want to focus on delivering NaCl
<smspillaz> it'd be kinda awesome to have docs without the massive overhead that comes from js
<smspillaz> duflu: also, something tvoss and I figured out yesterday that's worth watching out for https://bugs.launchpad.net/ubuntu/+source/gcc-4.7/+bug/1165732
<ubot5> Launchpad bug 1165732 in gcc-4.7 (Ubuntu) "GCC 4.7.3 internal compiler error when using std::make_shared" [Undecided,Confirmed]
<smspillaz> I was wondering why I periodically got them when working on compiz with boost::make_shared
<RAOF> smspillaz: I've also got a bug filed about that, but I'm not sure that it's as well-specified.
<smspillaz> RAOF: ah, I knew you'd beaten us to it
<smspillaz> RAOF: bug link? we can mark it as a dupe
<smspillaz> (the one tvoss filed at least)
<tvoss> RAOF, smspillaz there is a comment on the bug report saying that it works fine with gcc 4.6 and 4.8
<smspillaz> tvoss: this is usually the case :)
<RAOF> Also, clang :)
<smspillaz> they will still backport the fix if you ask
<tvoss> RAOF, yup :)
<smspillaz> also, hi
<tvoss> RAOF, didn't know that you tracked down the multitude of ice bugs :) should have asked :)
<RAOF> Hey smspillaz!
<RAOF> tvoss: I didn't so much track it down as get annoyed enough to hit "submit" on one of the apport popups :)
<tvoss> RAOF, ;)
<tvoss> RAOF, same here
<smspillaz> it'd be nice if gcc would print a trace of which line it was trying to compile when it hit an IRC
<smspillaz> *ICE
<smspillaz> I had the same problem when I was working on the compizconfig test suite some time ago, and it was a matter of blindly trying different designs until I didn't hit the bug anymore
<RAOF> https://bugs.launchpad.net/ubuntu/+source/gcc-4.7/+bug/1156457 is my go at the ICE bug.
<ubot5> Launchpad bug 1156457 in gcc-4.7 (Ubuntu) "Invalid google mock code causes ICE" [Undecided,New]
 * tvoss loves variadic templates
<duflu> tvoss: Scary. What for? std::function/bind?
<tvoss> duflu, compile-time signature generation for dbus messages :)
<duflu> Free karma: https://code.launchpad.net/~vanvugt/mir/generalize-event/+merge/157310
<duflu> I actually have a couple of branches depending on it already :P
<RAOF> duflu: Enjoy.
<Ranomier_> Hey whats wrong with it to write mir as a wayland client and work with wayland upstream, to release wayland2 wich is compatible with the  proprietary amd inten and nvidia driver?
<Ranomier_> intel*
<duflu> RAOF: Thanks. I just can't see it right now. Having excessive LP timeouts today
<RAOF> Ranomier_: The last four posts of http://blog.cooperteam.net/?view=magazine have some details.
<Ranomier_> Im not shure, it is right that u becoming the rights of my code if im developing on mir.
<Ranomier_> sry -becoming +get
<duflu> Ranomier_: Mir's libraries are meant to be LGPL so that you do not have to release the source to your code. Any library headers that mention GPL are a mistake and need to be fixed (changed to LGPL)
<RAOF> Ranomier_: You need to sign the contributor agreement for us to accept patches to Mir, yes. That's not taking the rights to your code; it's essentially getting you to contribute patches under a MIT/X11/BSD-like license.
<duflu> Authors do keep their own copyrights, so long as they're adding new features, right?
<RAOF> Authors always keep their own copyrights, regardless of what they're doing.
<duflu> RAOF: ... unless you work for a company that owns your copyrights. ;)
<RAOF> Well, yeah.
<duflu> You keep your own copyrights, unless you have signed them away in a contract
<RAOF> But then the company is essentially the author, and *they* keep their own copyrights :)
<duflu> And if you're a consumer (not contributor) of Mir, then LGPL means you are not required to give away your source. You can keep it private.
<RAOF> Correct.
<duflu> ... although if you ask IBM's lawyers they will tell you LGPL is very weak and you should always use MIT/X11/BSD instead
<RAOF> *As long as you can swap out the Mir libraries that you're using.
<duflu> Which ironically are much more terse licenses
<RAOF> I don't know how weak LGPL is in practice, but in theory it's significantly stronger than MIT/X11/BSD.
<duflu> I've had this argument, for years on end. I just did what the lawyers told me
<duflu> That doesn't mean they're definitely right
<RAOF> I'm using MIT elsewhere; it's kinda required for anything that you want to be useful on mobile.
<duflu> RAOF: I mean the other way round -- it is high risk to use LGPL is proprietary code, because you're not necessarily fully protected in being able to conceal your own IP
<RAOF> Ah, right.
<duflu> I forget the exact reasons why. Weird given that's the point of LGPL
<RAOF> Yeah, that wouldn't surprise me.
<RAOF> Because it's like 20,000 words of licence? :)
<duflu> Yeah, more words lead to more ambiguous clauses
<duflu> It takes a special kind of person to enjoy law ;)
<tvoss> katie, ping
<katie> tvoss, am just in a meeting
<tvoss> katie, can you ping me after that?
<katie> tvoss, sure
 * duflu goes to organise dinner
<tvoss> katie, thx
<katie> tvoss, ping
<tvoss> katie, pong :) my question is answered with your reply to the edge thread
<katie> tvoss.. great, i hoped that would be what you were looking for
<tvoss> katie, yup :)
<alf_> alan_g: Any more thoughts on display-server-main-loop?
<alan_g> alf_: was just looking at that again
<alf_> alan_g: ok
<BigWhale> Greetings.
<kdub> goood moring
<alf_> kdub: goood eveing
<alf_> status: iterating main loop proposal
<kdub> status, iterating on the fbnative window....  hooking hwc into the framebuffer posting
<racarr> Morning
<alan_g> Evening
<racarr> status: Working more on xkbcommon stuff, I got a prototype going by doing the mapping in Qt
<racarr> I think...it might be time to remove droidinput::InputEvent though?
<alf_> alan_g: updated display-server-main-loop MP
<alan_g> alf_: looking
<alf_> alan_g: updated (but waiting for diff to update too...)
<alan_g> alf_: ack
<racarr> alan_g: btw I merged trunk on enable-inprocess-egl if you can remove your needs fixing
<racarr> so I can land it with raof and kdub later
<alan_g> racarr: ack
<alf_> racarr: does the example still crash? :)
<alf_> racarr: (when shutting down)
<racarr> alf_: Oh I guess.
<racarr> Ill look at that before RAOF shows up
<racarr> Right now I think I convinced myself tht I can remove droidinput::InputEvent
<racarr> so I am going to do that before I get nervous about it again and forget how to do it
<racarr> Easy https://code.launchpad.net/~robertcarr/mir/reorganize-shared-input-code/+merge/157702 :)
<racarr> More refactoring pulled out of this droidinput::InputEvent removal branch https://code.launchpad.net/~robertcarr/mir/remove-dummy-dispatcher-policy/+merge/157716
<BigWhale> Is there an update to Mir Hacking guide? Apparently I am missing some dependencies or I need to set some environment variables set:  EGL_LIBRARY EGL_INCLUDE_DIR
<Cheery> I'm reading wayland specs right now, and soon I'll be reading yours.
<Cheery> I've been proponent of both before, because I think choice is good.
<Cheery> I get the feeling you've evaluated the wayland worse than I have
<Cheery> that allows input event handling to be extended for more advanced devices.
<Cheery> also making the shell a client app is okay.
<Cheery> probably..
<thomi> morning
<racarr> Morning thomi
<kgunn> robert_ancell: hey, was chatting with tedg earlier today around how we roll out mir/unity next...when things become default etc
<kgunn> robert_ancell: i was thinking mir/unitynext are sort of lockstep
<robert_ancell> kgunn, yes, except for the system compositor which we can roll out before unity next. However if we're focussing on the phone then they are lockstep
<kgunn> robert_ancell: he was wondering about using mir as a system compositor
<kgunn> robert_ancell: cool...you beat me to it :)
<kgunn> robert_ancell: i'll note those slides about our road to convergence
<robert_ancell> kgunn, my guess is if we'll end up doing the phone first so when we roll to desktop we might as well do both at once
<robert_ancell> though unofficially you can probably run the system compositor before then for testing/being ahead of the curve
<kgunn> robert_ancell: he was bringing this up in the context that the desktop guys would probably want as much to be default in 13.10
<kgunn> fearing a frankenstein switch in 14.04...
<thomi> folks: is there any way I can run the mir server on terminal X without having to start it from that terminal? I'm still struggling to get the mir benchmark stuff going from jenkins
<thomi> ideally I could do: "mir --run-on-terminal 2" :)
<robert_ancell> thomi, no, it's not VT aware so it just runs on the VT you started it on
<robert_ancell> kgunn, frankenstein or big switch?
<kgunn> robert_ancell: right...big switch...fearing lack of test/confidence
<kgunn> but i would think we could just slowing make things default on s-series towards convergence/14.04....and viola...you get testing feedback
<robert_ancell> kgunn, yes, not sure the safest strategy here. We either go fully in for both phone and desktop or we bring the phone code across when we're ready with it
<kgunn> robert_ancell: my gut says the latter
<robert_ancell> me too
<robert_ancell> kgunn, though any slowing on desktop means putting the cost on the shell team to maintain the current unity. Easier decision to make from a Mir perspective than from theirs
<kgunn> robert_ancell: true...but in reality the "maintenance" of current unity is _extremely_ manageable...if you catch my drift ;)
<robert_ancell> kgunn, :)
<thomi> RAOF: good news: mesa autolanding is back in action.
<racarr> [       OK ] TestClientInput.clients_receive_us_english_mapped_keys (15 ms)
<racarr> Whee
<RAOF> racarr: Woo!
<RAOF> thomi: Ta.
<thomi> racarr: how come it takes 15ms?
<thomi> RAOF: we should get notifications next time that job fails on Canonical IRC server
<racarr> thomi: Eh. it doesn't always take that long but
<racarr> it starts up a server and a client process and sends a few events and has some synchronization points
<racarr> acceptance test
<thomi> racarr: ahh, ok, not a unit test, that's just fine then :)
<RAOF> Sam has just asked whether it's too early for coffee. Heresy!
<thomi> it's never too early for coffee
<RAOF> Correct!
#ubuntu-mir 2013-04-09
<thomi> Hi mir-folk - I finally got the glmark tests to run on our highend intel hardware machine - the results are here: http://10.97.2.10:8080/job/mir-glmark-daily/7/label=ps-intel-4000-he/artifact/results.json
<thomi> tldr: getting 60FPS on every test
<thomi> which doesn't seem very useful
<RAOF> thomi: That's currently expected behaviour.
<thomi> so I'm wondering if I should run this on a lower-end machine, or perhaps customise the way we run glmark?
<thomi> RAOF: so how to we notice performance degredations?
<RAOF> thomi: Someone (and by "someone" I probably mean "me") fixes https://bugs.launchpad.net/mir/+bug/1130553
<ubot5> Launchpad bug 1130553 in Mir "Mir does not support eglSwapInterval(0)" [Medium,New]
<thomi> RAOF: ahhhh, right
<thomi> RAOF: yeah, you should do that :)
 * RAOF is the mesatron.
<thomi> now that we have mesa autolanding.... no more excuses :)
<thomi> robert_ancell: is it OK to publish these benchmark results to the public jenkins server? It'll make them easier to chart that way
<robert_ancell> thomi, yes, sounds good
<thomi> sweet
<robert_ancell> thomi, btw, how hard would it be to set up autolanding for lightdm?
<thomi> robert_ancell: very easy
<robert_ancell> autolanding? I mean the "merge and push when MP set to approved"
<thomi> yup - that's autolanding. You also get CI (aka: "build & test every MP before it's approved and comment on the MP") for free
<robert_ancell> thomi, awesome. What do we need to do to turn that on now?
<thomi> I need to propose a MP that modifies some confguration, then tomorrow morning I can get Francis to review it for me
<robert_ancell> thomi, please do
<thomi> should be able to turn it on before lunchtime tomorrow
<thomi> ok
<thomi> robert_ancell: which packaging branch should I use for the autolanding?
<robert_ancell> thomi, can you just set it to compile for now?
<thomi> robert_ancell: hmmmm, I actually don't know, I'll find pout
<thomi> *out
<robert_ancell> thomi, short answer is there isn't one in use at the moment
<thomi> robert_ancell: OK - if need be we can grab the ubuntu packaging info and hack it till it works :)
<robert_ancell> thomi, yeah, that will work
<thomi> robert_ancell: also, do you want autolanding for lp:lightdm or for some other lightdm branch?
<robert_ancell> thomi, lp:lighdm
<thomi> robert_ancell: and finally, if we build a package, we can push it to a PPA at the same time...
<robert_ancell> thomi, yeah, that would be handy
<thomi> what PPA?
<thomi> robert_ancell: also, which series should we be building for? The default is quantal & raring, but I can add precise support as well
<robert_ancell> thomi, it should build fine on precise, so that would be useful too
<thomi> robert_ancell: which PPA should it dput to?
<robert_ancell> thomi, https://launchpad.net/~lightdm-team/+archive/daily
<thomi> cool
<RAOF> Mmm. Return code checking. Who needs it!
<RAOF> Not gallium's DRI code, that's for sure!
<alf_> RAOF: How is dma-buf on radeon going?
<RAOF> alf_: Most of the way through the setup.
<alf_> RAOF: great
<RAOF> Most of the effort is in extending the gallium interface, which is now done. Actually pulling a buffer out of a dma-buf fd is (should be!) pretty simple :)
<alf_> Anyone else want to take a look at https://code.launchpad.net/~afrantzis/mir/display-server-main-loop-1/+merge/157693 ?
<alan_g> alf_: apparently not
<alf_> alan_g: heh, you approved it already :)
<alan_g> ;)
<mlankhorst> I'm trying to build mir on precise, getting an error there
<mlankhorst> /home/mlankhorst/nfs/xorg/mir/include/server/mir/time/time_source.h:34:29: error: 'virtual mir::time::TimeSource::~TimeSource()' declared virtual cannot be defaulted in the class body
<alan_g> mlankhorst: what compiler version are you using?
<mlankhorst> gcc 4.6.3
<alan_g> You'll need 4.7
<xnox> mlankhorst: 4.8 would be even better =) precise has exccelent support for lxc, so just start up a raring container for mir development =)
<mlankhorst> blegh I'll mess up my raring chroot then
<mlankhorst> no need for virtualization when I can boot my chroot off the network too :P
<mlankhorst> is there a branch of mir somewhere that uses dma-buf instead of flink for passing buffers?
<mlankhorst> oh found it
<alan_g> alf_: I'll be off in half an hour (for the rest of the week). Anything you'd like me to look at first?
<alf_> alan_g: No, thank you. I haven't pushed any vt stuff for review yet.
<mlankhorst> ah great xxv-nouveau works with xmir
<mlankhorst> http://people.canonical.com/~mlankhorst/xmir-nouveau.patch
<mlankhorst> plus http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=for-airlied-next
<alf_> status: More work on vt switching (getting close)
<kdub> status: more work on fb native window (getting close)
<kdub> specifically, it has some anxious jitter that I have to root out, but it can post to screen
<racarr> hi
<racarr> mlankhorst: Client rendering and everything works with Mir/noveau? Cool :) I don't know of anyone to have tested it so far
<racarr> Iterated on fix-shell-focus-locking
<mlankhorst> racarr: I only tested xserver
<racarr> Ah! Well xserver is a client
<racarr> so good news :)
<ogra_> now try XDMCP :P
<mlankhorst> glxgears ran though, dno what xdmcp would give me, apart from a security hole
<ogra_> would it ? i woould actually expect it to block
<ogra_> or rather expect Mir to block it
<mlankhorst> shrug
 * ogra_ would consider the security hole in Mir if Mir allowed  a client such things , but i might be wrong 
<racarr> iterated on xkb-mapper and enable-inprocess-egl...now orking on making qtubuntu work on top of mirclient with xkb
<racarr> Hey! I connected to my screen session via terminal emulator in mir :Dï¿½ï¿½ï¿½
<racarr> lssï¿½ï¿½ï¿½Â¿Â½ï¿½ï¿½oh god funny characters
<mlankhorst> invalid characters, even
<racarr> this QML terminal emulator is a little weird
<racarr> is jenkins broken someho?
<racarr> oh maybe I just segfaulted gdb or whatever
<racarr> kdub: So I updated the two build scripts for android for xkbmapper to install xkbcommon and xkbcommon-dev
<racarr> but it gets put in /usr/lib/arm-linux-blabla/
<racarr> so -lxkbcommon doesn't work.
<racarr> ideas?
<racarr> I don't really understand
<racarr> multiarch /usr/lib
<racarr> kdub: p.s. btw want to check out enable-inprocess-egl again? I think I fixed your last comment
<racarr> mir_native_display() name -> shell_egl_display()
<kdub> racarr, cool, ill look that over then
<kdub> racarr, i had similar problems with glog, maybe look at that cmake file?
<racarr> kdub: Ok ill check it out in a few
<thomi> morning
<kdub> hello thomi
<racarr> have I ever mentioned that I love curry.
<bschaefer> racarr, curry? http://en.wikipedia.org/wiki/Curry_%28programming_language%29
<racarr> bschaefer: http://en.wikipedia.org/wiki/Vindaloo ;)
<bschaefer> racarr, :), nice, curry is always good! I still yet to have a favourite
<racarr> bschaefer: Vindaloo is my favorite indian curry but lately I am really obsessed with the thai curries...with lots of coconut milk and bamboo
<racarr> also a place close by started doing curry burritos oO
<bschaefer> red curry is awesome as well! Curry burritos! I need to try that...
<racarr> works really well with just rice and beans all rolled up
<bschaefer> yeah, you need the right % of rice vs curry otherwise a mess!
<racarr> mm
<racarr> Working on a short refactoring to use a method similar to mia::InputConfiguration for SessionManager construction
<racarr> then going to use that to make a demo-shell example binary with some input filters
<thomi> robert_ancell: you around?
<robert_ancell> thomi, yes
<robert_ancell> racarr, curry burritos?
<racarr> robert_ancell: Yesssss
<racarr> Mexican<OtherFoodType T> is commonly instantiated in these parts ;)
<RAOF> racarr:
<RAOF> racarr: When you say "the old version [mir_egl_native_display_is_valid] still works" what do you mean?
<RAOF> racarr: Because when I used it, it didn't :)
<racarr> RAOF: Err ok lets investigate hsortly
<racarr> I am getting ready to propose a different branch then take a tea break
<racarr> then I will figure out what is going on there
<RAOF> Ok.
<RAOF> I shall therefore have a shower.
<racarr> right now im building my branch with clang to figure out whyt he last test I had to refactor
<racarr> generates internal compiler errors
<racarr> the joy!
<RAOF> Woot!
<RAOF> Is it the same std::make_shared<AbstractType>() causes ICE bug?
<racarr> in this case it was
<racarr> mt::fake_shared(std::shared_ptr)
<racarr> lol
<thomi> robert_ancell: sorry for the ping earlier - we're working on getting autolanding for lightdm going, and we hit a few issues. We're slowly getting through them though
<robert_ancell> thomi, nice, thanks!
 * kdub wonders about hooking an android phone up to jenkins
<kdub> and actually, i *think* the android unit tests and acceptance tests are driver-free and should be able to run on an emulator
<thomi> kdub: Martin already did some work hooking a few phones up to jenkins
<thomi> kdub: when he getsback from holiday I expect I'll take over that work
<thomi> and then.... run the glmark tests on a real phone :)
<thomi> the difficult bit (IIRC) is provisioning them in a sensible way
<kdub> thomi, cool
<racarr> RAOF: I am looking and I think mir_egl_native_display_is_valid is fine
<racarr> RAOF: Were you passing it MirConnection maybe?
<racarr> That no longer works you need mir_connection_get_egl_native_display
<RAOF> racarr: I mean, if you replace mir_egl_mesa_display_is_valid() with mir_egl_native_display_is_valid() with no other changes in the Mesa EGL platform patch, mir_egl_native_display_is_valid will always return false.
<racarr> RAOF: Hmm
<racarr> RAOF: Testing now
<racarr> It was using mclg::MesaNativeDisplayContainer::validate from mir_egl_mesa_display_is_valid
<racarr> and mcl::EGLNativeDisplayContainer::validate from the mir_client_library.cpp impl
<racarr> err
<racarr> ::instance
<racarr> ::instance is static on mcl::EGLNativeDisplayContainer only
<racarr> what happens...;)
<racarr> RAOF: Oh hmm its true
<racarr> I can't understnad how it happens!
<RAOF> Why do we have both again?
<racarr> RAOF: Eh I guess we don't necessarily need both though it's hard to make a strong argument that mir_egl_native_display_is_valid doesn't belong either I think
<racarr> but why doesn't it work seems more important the code path should be the same:/
<racarr> I mean literally they are both one line functions
<racarr> I onder if there are bits lost in casting somewhere
<racarr> thats the only difference
<racarr> unless something strange is happening with translation units and multiple instances of the static instance are created
<racarr> I guess maybe it is a weird function
<racarr> my laziness about deleting it is now ovveridden by my laziness about fixing it
<racarr> RAOF: Removed in r590 ;)
<robert_ancell> any C++ experts can help me with a problem I'm having with virtual methods, shared pointers and constructors?
<robert_ancell> I have code http://paste.ubuntu.com/5693963/ and error http://paste.ubuntu.com/5693965/
<RAOF> robert_ancell: No (co?)variance in std::shared_ptr.
<robert_ancell> RAOF, say what?
<racarr> There is for return types though right?
<RAOF> robert_ancell: A std::shared_ptr<NullDMMessageHandler> is NOT a std::shared_ptr<DMMessageHandler>, even though a NullDMMessageHandler is a DMMessageHandler.
<robert_ancell> RAOF, so this is copied from mir/src/server/frontend/socket_session.h, where it does the same sort of thing except it uses structs
<racarr> Yeah I think in this case either the return types are covariant and it works or the copy constructor is invoked...
<racarr> we use this pattern a bunch
<racarr> though um...-.- I don't know why it doesn't work ;)
<racarr> robert_ancell: -DCMAKE_CXX_COMPILER=/usr/bin/clang++ -DCMAKE_C_COMPILER=/usr/bin/clang
<robert_ancell> racarr, really? It would work in clang and not gcc?
<racarr> robert_ancell: No but it might have better errors
<robert_ancell> It does work if I switch them to structs, but that's not clear to me why that would make a difference
 * robert_ancell gets massive flashbacks of the last time he worked with C++ and it was super inconsistent
<racarr> robert_ancell: I bet it would also work
 * RAOF thought the only difference between "struct" and "class" was the default visibility?
<racarr> with class NullDMMessageHandler : public DMMessageHandler ?
<racarr> RAOF: The other difference is
<racarr> private is the default base class access-specificer for classes
<robert_ancell> racarr, with them both struct DMMessageHandler, and struct NullDMMessageHandler. Which is what is done in the frontend code
<racarr> and public for structs
<racarr> robert_ancell: ^ Need public inheritance is the problem I think :)
<racarr> so either struct or explicit public inheritance
<robert_ancell> racarr, bingo - that did it
<robert_ancell> what is the default inheritance?
<RAOF> private for classes.
<racarr> public for structs
<racarr> whoops...
<racarr> I made a circular dependency in the server configuration XD
#ubuntu-mir 2013-04-10
<racarr> in this little demo shell the application switcher event filter is constructed from in the_event_filters from, but needs to get the_frontend_shell() hich needs the_input_focus_selector() which needs the_event_filters() ;)
<racarr> hmm. I don't think I have moved more than 15 feet since tvoss went to sleep
<thomi> ugh - as an interim hacky solution, benchmark data is being stored here: https://code.launchpad.net/~mir-team/+junk/benchmark-graphs  - so please nobody delete that branch ;)
<racarr> weird problems with my demo shell server configuration...seems the contents of my std::initializer_list are being lost in passing around
<kdub> fbnativewindow defeats me another day :/
<racarr> aww
<smspillaz> hmm, neat http://codicesoftware.blogspot.com/2013/04/put-your-hands-on-programming-language.html
<smspillaz> language aware merge tool
<RAOF> Hm. Interesting. Build Mesa with clang and Mir segfaults.
<RAOF> Woot!
<RAOF> We draw!
<duflu> RAOF: Still building Mir with gcc?
<RAOF> Yes.
<RAOF> Fun fact: A radeon 5350 can't render mir_eglplasma at 1920x1200 at 60 FPS
<duflu> RAOF: My first guess is accidental writes to const variables (which are memory protected under clang)
<duflu> RAOF: I'll look at optimizations :)
<duflu> RAOF: Oh. eglplasma is trying to do 1.3 billion single precision cosines per second :/
<RAOF> That'sâ¦ quite a lot :)
<duflu> RAOF: I've been thinking for some cases (like this) it may make sense to create a low-res surface and flag it as needing upscaling. The other case I thought of was simple games
<RAOF> That's a part of the "fullscreen" request, isn't it?
<RAOF> You say "make me fullscreen" with flags such as "and please change the output's resolution" or "upscale me if necessary" or etc.
<duflu> RAOF: Yeah in the real world. Though some of our work-items are marked as DONE without such forethought :/
<duflu> I've been guilty of similar
<RAOF> Oh, have we marked fullscreen as done?
<duflu> RAOF: No, that one's in progress pending my state work
<RAOF> <value optimised out>
<RAOF> MY NEMESIS!
<duflu> RAOF: What was your frame rate BTW?
<RAOF> 40 FPS
<RAOF> Which is not bad for a two-generations-ago low-power GPU.
<duflu> RAOF: Hah. I call that a great success then
<duflu> Hmm, we're out by two orders of magnitude. Best I can find, AMD advertise the 5450 as "Processing power (single precision): 104 GigaFLOPS"
<duflu> Though it's likely that cosine takes many FLOPS
<duflu> This might also be a limiting factor: Pixel fill rate: 1.6 Gigapixels - 2.6 Gigapixels/sec
<duflu> I can't find specs for 5350. Seems to happen with all my graphics cards too. They're always so low-end that the manufacturer does not publish their existence
<RAOF> You can find it on http://en.wikipedia.org/wiki/Comparison_of_AMD_graphics_processing_units - it's an RV710
<RAOF> Which has specs around what you've listed.
<RAOF> Hm. With -O0 I can see why clang's failing - the glFlush pointer appears to be garbage.
<duflu> glFlush has a "pointer"?
<duflu> To the context?
<RAOF> The dri2_drv structure has a glFlush function pointer.
<RAOF> ...which is populated via dri2_drv->get_proc_address("glFlush"), which is presumably the thing that's broken.
<RAOF> ...which, in turn, is dlsym()'d from _glapi_get_proc_address
<RAOF> And clang does throw a warning somewhere in the mapi/glapi build, so that might be it.
<RAOF> And that suggests that the problem is not in *my* code, and we build mesa with gcc, so I'm going to call it good :).
<duflu> Sounds a bit odd. Plain old C issues with clang should be easy to resolve. I surprised Mesa is not yet clang-friendly
<RAOF> Oh, it's Wednesday!
<RAOF> That means it's SRU DAY!
 * duflu wonders if the SRU/SRY pun has been overdone yet
<thomi> behold: mir/glmark benchmark graphs: http://people.canonical.com/~thomir/
<thomi> errr... kind of hacky, I know
<thomi> now the preasure is on RAOF to fix that bug in mir :P
<thomi> err, mesa
<RAOF> The pleasure's all mine!
<racarr> https://bugs.launchpad.net/mir/+bug/1167133 this stuf is weird
<ubot5> Launchpad bug 1167133 in Mir "Input Filters fail to work when overriden through server configuration" [Undecided,New]
<racarr> thomi: I see only 59 fps on one of the tests
<racarr> I guess someone is to be fired.
<smspillaz> isn't fps a bad metic ?
<racarr> :p
<racarr> yes
<racarr> espescially when its capped to vsync ;)
<thomi> right, so let's fix the vsync issue
<smspillaz> I thought I read this article on arstechnica about measuring frame time
<racarr> it's just a start
<thomi> if anyone has any better ideas, I'm open to suggestions
<smspillaz> racarr: the clear answer to this one is to just make mir hot-patch monitor firmware to make them refresh faster
<smspillaz> "hey guys"
<smspillaz> "my monitor goes at 50,000fps"
<racarr> smspillaz: What do you think mir is doing no??
<racarr> w*
<smspillaz> "all thanks to mir"
<racarr> we stole the code from beryl
<smspillaz> racarr: you stole code from norwood?
<racarr> err...^H^H^H
<smspillaz> oh sorry, norwood is the protocol
<smspillaz> I meant northfield
<smspillaz> you stole code from northfield
<robert_ancell> duflu, you seem to have a very unreliable computer!
<duflu> robert_ancell: It was working fine. Then I upgraded gtalk
<robert_ancell> alf_, racarr, meeting?
<alf_> robert_ancell: ah, sorry I was waiting for a link on irc :)
<robert_ancell> alf_, np :)
<robert_ancell> kdub, ^
<RAOF> Aaah, hangouts :)
<alf_> robert_ancell: sorry, network died for a moment there
<robert_ancell> alf_, :)
<alf_> thomi: btw, glmark2 prints frametime if you prefer to parse and display that (although you could also calculate it yourself easily)
<RAOF> Only if we're not vsyncd :)
<duflu> Argh. Stupid audio subsystem. Now looks like system-wide, my audio goes to/from the wrong devices and ignores my selection of devices to use. It worked last week...
<RAOF> Wheee!
<duflu> It's even broken in gnome-control-center
<duflu> Oh, and my other headphones that would have worked recently disintegrated from age
<thomi> alf_: yeah, I have frametime - if you think that's a better metric to use it'd be simple to switch
<RAOF> alf_: Do we need nouveau support for use-dma-buf before landing it? I've got radeon support.
<RAOF> Eh, I'll just implement nouveau support as well. It's not like it's hard.
<mlankhorst> erm
<mlankhorst> didn't I do that? :P
<RAOF> mlankhorst: That was in xmir; it needs mesa as well.
<mlankhorst> oh
<mlankhorst> glxgears seemed to have worked though
<RAOF> You probably didn't do that, because the gallium changes you need only just landed on github :)
<mlankhorst> ok
<RAOF> Yeah glxgears will work. es2gears_mir won't :)
<alf_> RAOF: Feel free to add nouveau now or leave it for later, I don't think it blocks anyone.
<mlankhorst> it blocks meeeeeeee and I'm not a mesa developer
<alf_> RAOF: ^^ well I guess you have your answer ;)
<mlankhorst> alright alright I'll poke mesa some
<RAOF> mankhorst: Ok. I'll do nouveau as well and land use-dma-buf tomorrow.
<mlankhorst> RAOF: I was sarcastic :P
<RAOF> Probably a better idea anyway; landing in the morning means I can put out fires at my leisure during the day.
<mlankhorst> i'll fix up nouveau and any bugs I come across myself
<mlankhorst> just put it somewhere
<mlankhorst> RAOF: ^
<RAOF> mlankhorst: github.com/RAOF/mesa - egl-platform-mir-dma-buf and mir-ppa.
<mlankhorst> kk
<RAOF> You need to implement whandle->type == DRM_API_HANDLE_TYPE_FD in bo_from_handle and bo_get_handle. See also: https://github.com/RAOF/mesa/commit/4deaa1bd5377e6224eb266f6a5c8e602f666aeff
<RAOF> (You might notice the stunning kludge in that commit )
<mlankhorst> aw, installing some armhf packages removes some amd64 ones
<mlankhorst> libboost doesn't like multilib, it seems :(
<mlankhorst> looks like my nexus 7 doesn't like mir either, I tried the instructions, but mir just crashes
<mlankhorst> done with nouveau I think, I'm ignoring the GART stuff as it's unneeded with the kernel patches..
<alf_> mlankhorst: for nexus 7, ping kdub, he should know more about what's up there
<kgunn> mlankhorst: something about libhybris mods required only for nexus7 & only to egl...something about pthreads....platform team is workin' on it
<kgunn> w kdub
<mlankhorst> sounds about right
<mlankhorst> RAOF: mir_egltriangle seems to work for me(TM)
<mlankhorst> http://people.canonical.com/~mlankhorst/mir-mesa-nouveau.patch
<mlankhorst> it's against the dma-buf branch but with debian from your ppa-dma-buf branch, which is why i disabled the egl-platform-mir patch
<racarr> Morning!
<kdub> good morning
<alf_> racarr: kdub: Good morning!
<alf_> status: Proposed VT switching MP, investigating potential performance improvements
<kdub> status, working on stabilizing my fb branch, i suspect i'm not using the hwc right somehow
 * kdub likes how a fresh day brings fresh perspective on problems 
<kdub> mlankhorst, with the nexus 7, hybris at the moment, does not support process-shared pthreads (which the nvidia drivers need for sharing buffers with clients)
<katie> morning racarr
<racarr> Hi Katie!
<katie> racarr, how's it going? do you have time for a brief hangout?
<racarr> katie: Sure lets do it!
<racarr> hmm xkbcommon-mapper test hangs on jenkins
<racarr> for 120 minutes until jenkins quits ;)
<racarr> comcast business = faster downloading of chroots woo
<racarr> kdub: Did another around of updates on enable-inprocess-egl
<kdub> racarr, will look it over shortly
<racarr> kdub: more to xkbcommon-mapper too (I think the latest jenkins error there is a network quirk should be fixed soon)
<racarr> fixed build in with FindXKBCommon.cmake :)
<thomi> morning all
<racarr> morning
<robert_ancell> racarr, hello
<kgunn> robert_ancell: hey...how did the team meeting go?
<kgunn> robert_ancell: i literally woke up at 12:50 with no alarm....like an internal clock went off
<robert_ancell> kgunn, we had alf, RAOF, duflu me and thomi there
<kgunn> robert_ancell: i thot about joining....then thot better
<robert_ancell> mostly did a round of "what we're doing" then talked about some CI stuff
<robert_ancell> kgunn, good idea :)
<kgunn> robert_ancell: bummer...no racarr or kdub?
<robert_ancell> kgunn, no :(
 * kdub is here
<robert_ancell> kgunn, we found it funny that we moved the meeting to a better time but had less people!
<kgunn> kdub: past tense
<kgunn> robert_ancell: and alan was out
<kgunn> robert_ancell: so did you know what to do after leaving that prd review with richard?
<robert_ancell> kgunn, I didn't think we had any actions other than to keep him up to date on planning changes
<kgunn> robert_ancell: i suppose we did agree to split out mir into pieces...like, input support, system compositor, app copy/paste etc
<robert_ancell> kgunn, the PRDs not editable by us right?
<robert_ancell> kgunn, and those splits are reflected in the blueprints
<kgunn> robert_ancell: prd isn't editable but the m2m planning one is....
<kgunn> i'm gonna take a crack
<kgunn> i'll let you correct the damage :)
<robert_ancell> kgunn, heh :)
<thomi> I just finished configuring jenkins to graph mir autolanding build times. The result is: http://static.inky.ws/image/3841/showChart.png
<thomi> tl:dr: it's getting longer
<thomi> robert_ancell: got a minute?
<robert_ancell> thomi, sure
<thomi> robert_ancell: so WRT the lightdm autolanding, we need to hack the packaging stuff a bit. Lots of the PS projects have started using inline packaging, which makes it easier to keep the packaging & source code synced
<thomi> so I could either propose a MP that adds the debian/ dir to lp:lightdm, *or* I could make a new branch: lp:lightdm-team/lightdm/trunk-packaging
<thomi> it's up to you :)
<robert_ancell> thomi, yeah, I'd prefer the packaging was separate as lightdm is used outside of ubuntu
<thomi> robert_ancell: sure, OK.
<thomi> I think there's some script that strips out the debian/ dir for "upstream" releases for Unity... but that's some deep juju that I have nothing to do with
<kgunn> robert_ancell: hey is duflu going to propose his surface state stuff this week? (curious)
<robert_ancell> kgunn, I though he was but I'm not 100% sure. I'll ask today
<thomi> robert_ancell: any chance you could add me to the lightdm-team so I can push these packaging branches to be owned by that team?
<robert_ancell> thomi, what's you LP id?
<thomi> thomir
<robert_ancell> thomi, done
<thomi> thanks
<RAOF> PSA: I've pushed the use-dma-buf mesa changes and marked use-dma-buf as approved. In the period while these things are not in sync, Mir EGL will not work.
<RAOF> And by that I mean "Mir clients won't be able to use EGL"
<racarr> robert_ancell: Merr...sorry...forgot about IRC.
<racarr> ripping the InputDispatcher controller stuff (for focus) out of the InputManager to fix a focus  bug to make my demo shell work :)
<racarr> I made a demo shell that fullscreens everything and adds and alt tab keybinding but it crashes when you cycle focus because
<racarr> the second time a window is made focused the way we recycle the android window handles in set_input_focus_to
<racarr> causes the InputChannel to be destroyed and recreated...closing the fd
<racarr> triggering an assert!
<racarr> So it seemed like a good time to just go ahead and bite the bullet and implement the proper focus selection where the dispatcher controller maintains a list of all the window handles (this is what is needed to enable picking for touch input as well)
<racarr> but then it became a refactoring spiral
<racarr> haha
<racarr> almost done
<racarr> RAOF: Do you think you could do another review of https://code.launchpad.net/~robertcarr/mir/enable-inprocess-egl/+merge/155888 to override Alf's need's fixing (was fixed yesterday)
<racarr> kevin approved so I think if you are ok with it we can land it
<RAOF> racarr: Sure
<racarr> Would like to land it so I can do a software cursor example
<racarr> (a really funny one ;))
<racarr> kdub: Does this mean anything to you https://jenkins.qa.ubuntu.com/job/mir-android-raring-i386-build/337/console
<racarr> err, loaded question maybe :p but you know what I mean
<kdub> racarr, no unfortunately :/
<racarr> hmm
<racarr> ill try a rebuild in an hour or so and maybe it will fix itself
<racarr> if not investigate deeper
#ubuntu-mir 2013-04-11
<racarr> I like when commit messages come off like plot twists
<racarr> "The DispatcherController is the InputFocusSelector" (audience gasps)
<kdub> racarr, haha :D
<robert_ancell> RAOF, use_dma_buf landed \o/ congrats!
<RAOF> robert_ancell: Even better, I'm about to mark enable-inprocess-egl for landing, too ;)
<robert_ancell> RAOF, woohoo!
<racarr> yay coed landing
<racarr> code
<thomi> robert_ancell: autolanding & CI should be working for lp:lightdm - do you have a MP we can use to test it?
<robert_ancell> thomi, not currently but I'll make something
<thomi> robert_ancell: cool - if/when we know that's working I'll enable it for the mir branch as well
<thomi> robert_ancell: ping me when you have a MP link and I'll make sure everything's hunky-dory on the backend
<robert_ancell> thomi, ok
<robert_ancell> thomi, https://code.launchpad.net/~robert-ancell/lightdm/whitespace/+merge/158264
<thomi> awesome, I'll follow that and make sure everything works as expected
<thomi> do you mind if I approve it once the CI stuff has done it's thing?
<robert_ancell> thomi, sure
<thomi> robert_ancell: can you please add 'ps-jenkins' to the lightdm team? This allows the CI task to comment on MPs.
<robert_ancell> thomi, done
<robert_ancell> thomi, do you need a second MP?
<thomi> robert_ancell: nah
<thomi> the first one will get picked up again
<thomi> robert_ancell: CI worked (second time around, anyway): https://code.launchpad.net/~robert-ancell/lightdm/whitespace/+merge/158264
<thomi> merging it now
<robert_ancell> thomi, weird error on first attempt!?
<thomi> robert_ancell: lightdm doesn't build on quantal chroots without addinga build-dep
<robert_ancell> thomi, ah
<thomi> the first time around we had it running ona  quantal box
<thomi> so we change the config and set it running again
<thomi> autolanding is running...
<duflu> robert_ancell: Re performance issues... Usually it is std::string construction/destruction that's the biggest problem. Because event a string on the stack will indirectly be allocated to the heap. And heaps are slow.
<duflu> But string comparison is usually very fast. With Rabin-Karp (and better) algorithms in use in all the STLs
<duflu> -event +even ;)
<duflu> Hmm, Rabin-Karp is for searching. But still, string comparison is relatively fast
<tvoss|sick> duflu, protobuf support fixed-sized arrays, too. Might be an option to look into that, too
<duflu> tvoss|sick: Hmm, yeah good idea. Assuming some profiler tells us that's the problem
<tvoss|sick> duflu, agreed
<duflu> tvoss|sick: Though seriously, we should have lots of room to do lots of things 60 times per second and stay around 0% CPU. There must be more to it
<tvoss|sick> duflu, I think running it through cachegrind again should reveal other hotspots
<duflu> tvoss|sick: Would love to. Once my other work is done
<duflu> tvoss|sick: Go rest!
<tvoss|sick> duflu, feeling better already :)
<tvoss|sick> thomi, still around?
<duflu> tvoss|sick: And if not resting then please look at normalize-MirEvent :)
<duflu> tvoss|sick: Careful to not confuse cachegrind for callgrind
<tvoss|sick> duflu, I meant callgrind :)
<duflu> Which reminds me, we should try helgrind. It's bound to tell us our locking sucks
<tvoss|sick> duflu, that's its purpose, yes :)
<tvoss|sick> duflu, approved
<duflu> tvoss|sick: Thanks. You can rest now ;)
<tvoss|sick> duflu, nice :)
<thomi> tvoss|sick: Hi
<thomi> tvoss|sick: what's up?
 * thomi heads off to read his book.
 * robert_ancell notices 58 or so users here. This channel has got a lot busier!
<shadeslayer> hi, this is a bit offtopic, but I was told you guys probably have the best idea on how to go about this, I want get kwin + X + hardware acceleration working on the nexus 10
<shadeslayer> can I just plop the graphics driver from here https://developers.google.com/android/nexus/drivers#manta
<duflu> shadeslayer: Yes that's quite off-topic. You might get an answer in #ubuntu-desktop or #ubuntu-unity
<shadeslayer> ack
<kgunn> racarr: \0/ ....in process egl landing
<kdub> good morning folks, working on cleaning up my nativewindow branch, i think i've finally overcome the big hurdles
<alf_> kdub: good morning
<alf_> status: Iterated VT switching branch, started investigation of pending "High" priority bugs
<alf_> kdub: I am still getting a frozen screen (only the first frame) on the nexus 4, have you seen that?
<kdub> no :/ havent seen that yet
<kdub> maybe you could send me your phone image using the recovery mode?
<alf_> kdub: well, it's just a normal ubuntu image... I will investigate a bit more and as a last resort I will send you the image (or try updating again first)
<alf_> kdub: could the problem (hypothetically) be due to a different hardware revision?
<kdub> alf_, could be, although i don't think its likely... could you send the 'adb logcat' of  when it starts?
<alf_> kdub: http://paste.ubuntu.com/5698763/
<kdub> alf_, i think surfaceflinger is running, based on that
<kdub> mv /system/bin/surfaceflinger /system/bin/sf
<kdub> then reboot. the system won't be able to find it :)
<alf_> kdub: yes, I haven't yet stopped it (it's a logcat of device startup, did you mean a logcat of mir startup?)
<kdub> right of mir startup
<alf_> kdub: http://paste.ubuntu.com/5698810/ (this is render_to_fb, surfaceflinger certainly not running)
<alf_> kdub: Like before, I can only see the first frame
<alf_> kdub: hmmm, I think that my cross-compiler may have been inadvertently upgraded to the raring version at some point...
<alf_> kdub: let me downgrade and try again
<alf_> kdub: (I have a feeling that this is the cause)
<kdub> alf_, yeah, i think i got hangs last time that happened to me too. something in chrono if i recall
<alf_> kdub: yes, that was it, sorry for the false alarm
<kdub> alf_, cool :)
<kdub> 189 character-long function declaration, i think thats a new record :)
<racarr> yay not having to juggle mesa trees between my branches anymore XD
<thomi> morning
<racarr> Morning
<kgunn> robert_ancell: gotta bug out early for baseball today....i'll be on later
<robert_ancell> kgunn, bye
<racarr> robert_ancell: Ready when you are
<racarr> *announcer voice* The 1-1 Sync-Up hangout everyone has been waiting for! Robert - Robert. Live on G+ at 9:00 UTC.
<racarr> :p
<robert_ancell> racarr, do you know the correct way for a shell to know when a session is connected?
<racarr> robert_ancell: Hmm...I don't think there is a most correct way at the moment
<racarr> I mean you could listen to the SessionMediatorReport but that seems incorrect
<robert_ancell> racarr, yeah, I'm trying to find *any* hook at the moment to know when sessions appear/disappear
<racarr> robert_ancell: ^
<robert_ancell> yes, I thought so too
<racarr> But um.
<racarr> I mean also you could replace various parts of the Shell configuration
<racarr> we should add a SessionManagerListener
<racarr> I ant to do this also to invert
<racarr> well, change, the control flow for focus setting
<racarr> robert_ancell: It will be really easy to add a SM listener with https://code.launchpad.net/~robertcarr/mir/ease-shell-configuration
<robert_ancell> racarr, yes, that's what I want
<robert_ancell> I think I'll just wait for that to land
<racarr> Ok. hopefully tomorro
<racarr> yay android jenkins for xkbcommon-mapper fixed itself
<thomi> robert_ancell: got a second?
<robert_ancell> thomi, sure
<thomi> robert_ancell: I'm just looking through https://code.launchpad.net/lightdm/+activereviews to make sure that the CI process is working as expected before enabling it for the mir branch
<thomi> robert_ancell: I notice that lots of CI jobs are failing due to a lack of commit message on the MP
<thomi> robert_ancell: I wanted to make sure you were aware that this is a requirement for the autolanding process to work - it uses the commit message in debian/changelog
<robert_ancell> thomi, yep
<thomi> ...although we can turn that requirement off, but it's not recommended
<thomi> other than that, it looks like everything is running flawlessly, so I'm going to add the mir branch now
<robert_ancell> thomi, awesome, thanks
<robert_ancell> thomi, I'll fix up the MPs now
<thomi> robert_ancell: you mentioned there was an extra build-dep for the mir branch - is that libmirclient-dev?
<robert_ancell> thomi, yes
<thomi> coolio
<robert_ancell> thomi, oh, it there going to be some sort of fix for Jenkins giving links to 's-jenkins'?
<thomi> robert_ancell: I keep asking Martin to fix that, but he won't - his "solution" is to add s-jenkins to your /etc/hosts file, which... ewwwww
<robert_ancell> thomi, but you also need VPN access right?
<thomi> robert_ancell: exactly
<thomi> robert_ancell: and you can specify DNS servers to be used when you connect to the VPN
<robert_ancell> thomi, so it should at least say "YOU NEED VPN ACCESS" because these branches are public and it will confuse people
<thomi> robert_ancell: right, we can also publish the jenkins results publically, which will chanegt he links to point to jenkins.qa.ubuntu.com
<thomi> which I'll look into doing today as well
<robert_ancell> thomi, oh, the other thing that confuses me is. I enable the VPN, then I click the link and I can't work out what to do to make it rebuilde
<robert_ancell> thomi, do I also need to log in?
<thomi> robert_ancell: it will rebuild automatically when the MP changes
<thomi> so, if you push a new revision, for example
<robert_ancell> thomi, so in the case of https://code.launchpad.net/~mterry/lightdm/enums/+merge/156695 I need to rebuild because the commit message hadn't been set
<robert_ancell> It even tells me I have to trigger the rebuild myself :)
<thomi> you can trigger a rebuild manually, which is sometimes needed, and you do need to be logged in for that
<thomi> right
<thomi> do you have an account on that jenkins box?
<thomi> if not, I can create one
<robert_ancell> thomi, that's where I'm not sure - what would my login be?
<thomi> let me see if I can find you
<thomi> you don't exist :-/
<thomi> I'll create you
<thomi> robert_ancell: what username would you like?
<robert_ancell> thomi, robert-ancell so it matches my LP one and I don't forget it :)
<robert_ancell> thomi, any chance that will be linked so SSO?
<thomi> robert_ancell: hahaaaaa... no :)
<thomi> robert_ancell: lp:lightdm/mir should be released into ppa:mir-team/staging correct?
<robert_ancell> thomi, yes
<kdub> robert_ancell, if i want to add hwc1.0 support to the blueprints somewhere, which one would be the one to do that to?
<robert_ancell> kdub, I think you'd attach that to a blueprint for the particular device that requires it
<kdub> robert_ancell, that would be the galaxy nexus... can we re-open blueprints, or should we start new ones?
<robert_ancell> kdub, just reopen it
#ubuntu-mir 2013-04-12
<thomi> I wonder if any of the mir developers are GLSL experts? I need to pick someone's brain on the subject at Oakland... maybe RAOF or kdub?
 * RAOF is in no way a GLSL expert
 * kdub knows how to write glsl
<thomi> kdub: you'll, do, I'll swap you some alcohol for advice :)
<thomi> robert_ancell: hey - autolanding and ci for lp:lightdm/mir has been deployed - would be good to test it, if you have some code that needs merging
<duflu> RAOF: What's the correct state for this bug? https://bugs.launchpad.net/mir/+bug/1102762
<ubot5> Launchpad bug 1102762 in Mir "Support nouveau drivers" [Medium,In progress]
<kgunn> duflu: thanks for mp'ing your surface state work!
<duflu> kgunn: No problem. I have not got to looking at it or any MPs yet. But have allocated the rest of the day/week to it
<kgunn> duflu: cool....felt good to see dma buff, in process egl & your stuff mp'd...
<duflu> kgunn: Yeah the number of line-items is significant :)
<robert_ancell> thomi, do you know why Jenkins hasn't built https://code.launchpad.net/~andrzejtp2010/lightdm/lightdm-trunk-xephyr-multiseat/+merge/120286?
<thomi> robert_ancell: let me see...
<robert_ancell> thomi, also https://code.launchpad.net/~agateau/lightdm/move-to-sbin/+merge/89146
<thomi> robert_ancell: yeah, for the first MP it's because the proposing user isn't a canonical employee. The CI server builds the proposed branches, so we have apolicy of not building branches from outside, since you can make debian/rules do anything you want, including evil things. However, this shouldn't be a concern any more, since we build inside chroots these days
<thomi> robert_ancell: there's a way you can force it, I think, but I can't remember the details
<thomi> robert_ancell: it may be that autolanding will still run, once you approve the MPs
<robert_ancell> thomi, ah, that's an annoying limitation for lightdm as one of the devs is not a Canonical employee. It would be great if we could remove that limitation
<thomi> robert_ancell: I'll send an email to the people who maintain the CI infrastructure and get back to you on that
<robert_ancell> thanks
<thomi> robert_ancell: I think it's mostly a historical limitation from the days where we built things on the CI server itself :-/
<mardy> hi all! Will Mir support embedding another process's window into one's own?
<tvoss> mardy, we haven't decided on that, yet.
<mardy> tvoss: OK, then the most important question is whether it's technically feasible or not (or just extremely difficult)
<tvoss> mardy, I think both holds true, and I think there are better approaches to include rendered content within an apps surface. I would think it depends on the actual use-case. So what are you trying to solve?
<mardy> tvoss: https://wiki.ubuntu.com/OnlineAccounts#phone-settings (see the bottom of the page, that "WebView" square comes from another process)
<mardy> tvoss: but the design is in its early stages, and we can affect it, I think
<tvoss> mardy, what's the technology we want to use for the webpage? is it webkit?
<mardy> tvoss: what about window reparenting (that is, making it look like a window is part of this process, while it comes from another one)?
<mardy> tvoss: yes, webkit
<tvoss> mardy, that's the same as embedding isn't it? @webkit: it's multi-process by default, isn't it?
<tvoss> mardy, so that being said: what would prevent us from just embedding a webview in process for your use-case?
<mardy> tvoss: no, maybe I didn't use the correct term; I mean, something like http://www.gtk.org/api/2.6/gtk/GtkWindow.html#gtk-window-set-transient-for
<mardy> tvoss: that is, the window is entirely drawn by the same process, but the WM places it on top of another process's window
<tvoss> mardy, it's not possible right now, and we have been talking about embedding/setting other applications transient multiple times. However, I wonder what prevents us from just using a browser component within the same process?
<mardy> tvoss: about webkit, the problem is that the flow is: client application -> signond (via D-Bus) -> signon-ui (host of the webkit)
<mardy> tvoss: I don't think it's impossible to embed webkit in the client, but it would be a lot of work, and I don't like it from a security and performance POV
<mardy> (signon-ui exits after some seconds of inactivity, and in the future Mir could provide some special decorations to it to tell the user that it's a trusted window)
<tvoss> mardy, can you make sure that the requirement is noted down in the design spec?
<mardy> tvoss: you mean the wiki page I pointed you at, or some Mir document?
<tvoss> mardy, the wiki page first, it will bubble up from there :)
<mardy> tvoss: will do, thanks
<tvoss> mardy, cool, thanks
<Ranomier> http://www.phoronix.com/scan.php?page=news_item&px=MTM0OTE
<Ranomier> whooo
<Ranomier> huuu
<Ranomier> Im done with mir everything will be supported by wayland, there is no reason to use mir. Kde, Gnome (and with it lxde xfce), Enlightenment, Android drivers, Qt, if nvidia and/or ati write their driver for wayland then ... xD
<Ranomier> Thank u mir, for pushing wayland devs in their seats :D
<Stskeeps> Ranomier: i wrote that blog post and it's not cool to troll other people's development channels.
<Ranomier> Yeah u right, sry for that. My whole body want it to say that^^ I could not stop it.
<RAOF> That's not actually very surprising - Wayland on Android was first demoed quite some time ago :)
<tvoss> RAOF, yup :) however, good work :)
<RAOF> Indeed. There's generally substantial work between "here's a demo of $X" and "and now $X works" :)
<tvoss> RAOF, agreed :)
<Ranomier> So pleeease, canonical, work upstream with wayland and share your attained
<duflu> OK, let the potential trolling end there. I think we would all like both Wayland (plus a real display server if not Weston) and Mir to succeed. Competition is a good thing
<Stskeeps> indeed - people have different goals and methods
<duflu> And having multiple options in the open source world is a very good thing
<duflu> It's only fragmentation if the parts began as a whole. I'm not so sure they really did. So don't call it fragmentation. Call it competition :)
<duflu> Morning katie... Was there any movement on the "edge" discussion?
<Ranomier> I think it is very important to have a basis that all linux distros share, it is ok to make multible Desktop Environments and multible Programs that do the same, BUT it is not ok to touch that basics
<duflu> Ranomier: So you don't like Android because it is Linux with a very different DE?
<Ranomier> No use it, but i think i dont like becouse it uses surfaceflinger and another c libary
<Ranomier> sry *i use it   From freedesktop.org: "freedesktop.org is building a base platform for desktop software on Linux and UNIX"
<Ranomier> I want to start any graphical programm under linux, that is writen for linux
<katie> Hi duflu.. not after the email
<Ranomier> i can install qt and gtk at the same time, but mir and wayland?
<Ranomier> and use it at the same time
<duflu> Ranomier: Yes I think you will be able to have Mir and Wayland installed simultaneously. In fact Mesa will link dynamically to both. But only one can occupy the graphics hardware at a time
<Ranomier> Yeah thats my problem
<Ranomier> i cant start wayland and mir
<Ranomier> it breaks that basis.
<RAOF> It's highly likely that you *will* be able to use a Wayland compositor inside Mir, and visa-versa.
<katie> duflu, I shoud get to it today, and let you know when I change any docs
<katie> should
<duflu> RAOF: Yeah I thought as much. Just possibly with performance for one being limited?
<RAOF> duflu: No, not really, any more than running Mir under Mir-system-compositor hinders performance.
<tvoss> RAOF, Ranomier it's essentially a cascaded compositor approach, leaving aside how certain nodes in the tree are called, isn't it?
<Ranomier> Sry, i dont understand this.
<duflu> katie: Ta. Though I probably wouldn't implement anything till Monday. It's almost end of the week
<Ranomier> At the moment, i can install awesome and then i start a kde programm, and then a qt only programm, then a gnome programm and then a enlightenment programm.
<Ranomier> everything ontop one basis.
<tvoss> Ranomier, sure, which is X at the moment, isn't it?
<Ranomier> Yeah
<tvoss> Ranomier, well, that is going to go away anyways, no matter which other competitive display server you are considering :)
<Ranomier> And that have to work later too! With android programm, with qt programms, with Unity programms usw
<RAOF> And it's reasonably likely to work later (except without the awesome bit, because neither Mir nor Wayland support external window managers)
<Ranomier> AND it has to be performant and easy programable! Thats two reason why we dont want X. If we have wayland and mir and surfaceflinger, we have the old proplem we have to care for each of those and it has to be performant.
<RAOF> By and large you shouldn't. Unless you're writing a game and trying to wring the last 5% of performance out.
<duflu> Funny thing about performance is that except for obvious visible bugs, people only care about performance if you give them numbers. Without numbers (and without bugs) most people are happy
<Ranomier> Yeah the people that us it are happy but not the developer!
<Ranomier> use*
<Ranomier> im learning coding from a friend, hand he is saying performance is importand, but if ur idee of the code and the code are not clean and clear u never get that performance and bugfree programm.
<Ranomier> Do it right from the beggining.
<Ranomier> idea not idee*
<duflu> Sure, you need to keep performance in mind right from the design. You don't want to implement an algorithm that is slow by design. But a lot of performance improvement comes after the initial implementation
 * tvoss notes that premature optimization without hard numbers is the source of all evil
<Ranomier> Yeah thats right! But i u have wayland AND mir there is no clear basis to optimize, there a two documentations there are two apis and and and
<Ranomier> i = if
<duflu> tvoss: I mean err on the side of low complexity by big-Oh notation. That's something you do from the beginning
<tvoss> duflu, yup :) I was referring to the final 5% :)
<duflu> But don't waste time measuring performance early on
<tvoss> Ranomier, in almost all cases, a developer will and should not know what display server technology to develop against. A developer either works in terms of a toolkit or in terms of egl/gl(es). And both Wayland and Mir provide client side egl integration as well as accelerated gl to clients/developers
<Ranomier> From ground up there have to be ONE well defined API for graphical Programms and DEs.
<Ranomier> If i write a game i dont use a toolkit and our company have his own little toolkit.
<Ranomier> And the devoloper of the toolkit have that problem, it is no solution to say: u dant have care about the display server.
<tvoss> Ranomier, cool, even better. If you are doing games, I'm assuming that you are doing egl/gl(es)?
<Ranomier> I dont know im learning programming, i dont now how to write a game, im a coding bigginner.
<tvoss> Ranomier, perhaps you can find out, but I'm pretty sure that egl/gl(es) is what you are using. Any pointers to your company's website, or the abstraction layers they use? Are you using SDL (2.0)?
<Ranomier> No im using nothing^^ Im learning coding at the moment with the basics libs of c++
<tvoss> Ranomier, you might want to look into Mir's code then, it's using c++, too and it leverages/illustrates a lot of modern c++ techniques
<Ranomier> Yeah i know buts wrong about c?
<Ranomier> linux is mostly written in c
<tvoss> Ranomier, linux as in? what's wrong with c++? you are learning it yourself?
<Ranomier> because wayland is written in c , nothing is wrong about c++ or c
<tvoss> Ranomier, I think I don't understand your argument. Wayland is written in C, fine. Mir is written in C++. It's an implementation detail, nothing more
<Ranomier> sry i missunderstood u
<Ranomier> Ok i have to go to work now, i think it is not good to fragment the basics of linux. i think it is important to be compatible with one standart. See http://en.wikipedia.org/wiki/Freedesktop.org
<Ranomier> after X
<Ranomier> bye for now
<katie> tvoss, duflu could we just have a quick hangout to discuss the edges. I think that'd be easier than me writing another email..
<katie> (doesn't have to be now, could be on Monday morning)
<duflu> katie: Yes, but no. May hangout the other day failed because my audio is totally broken. Let me see if it's fixed since upgrading/rebooting
<duflu> -May +My
<duflu> katie: On the other hand, I've already expressed my opinion (which is not changing). I'm happy to let you fight/discuss with tvoss :)
<tvoss> katie, duflu I'm fine with Monday, too
<duflu> It's such a minor change to add another enum and test cases. We don't need to make an issue of it. Just let me know which way to implement it. And no rush
<tvoss> duflu, ack and thx :) you should be in the weekend now, shouldn't you?
<duflu> tvoss: Not quite yet. But I should start thinking about dinner soon
<katie> duflu.. ok :)
<smspillaz> duflu: dinner? I only just had lunch :(
<duflu> smspillaz: Enjoy student-hood. But I'll refrain from suggesting these are the best years of your life
<smspillaz> duflu: there is a certain number of times you hear the words "your research assignment is due"
<smspillaz> before it starts to take out on your social life
<smspillaz> and / or sanity
<smspillaz> aha.
<katie> tvoss, do you have time for a quick catchup hangout?
<katie> now
<katie> ?
<tvoss> katie, is in 45 minutes fine for you? would like to finish a document and a mail
<katie> tvoss, sure
<tvoss> katie, cool, thx :)
<mardy> tvoss: I edited the page (added one paragraph): https://wiki.ubuntu.com/OnlineAccounts#preview
<mardy> tvoss: please let me know if/how I should take this further
<tvoss> mardy, ack, let me take a look. I will make sure that kgunn knows about it, too
<katie> hey tvoss, time for a chat now?
<tvoss> katie, sure, let me grab headset
<ogra_> tvoss, (you aret in -touch, so i'm pinging here)  ... seems the latest changes to platform-api break the android builds ... https://code.launchpad.net/~ogra/platform-api/fix-config-generation/+merge/158560 should fix that i think
<ogra_> (you approved the breaking change apparently)
<tvoss> ogra_, hmmm, as jenkins signalled all good :)
<tvoss> ogra_, but thanks for pointing out
<ogra_> yeah, its weird
<ogra_> it made the andrpidn image builds fail which jenkins didnt catch either
<ogra_> (todays touch image builds only consist of a rootfs and jenkins considered that a good build)
<tvoss> okay, that's a weird fix
<ogra_> i'm not a cmale pro :) but all docs i find use it capitalized
<ogra_> *cmake
<ogra_> if you have a better idea why there is no config.h in the end, please apply that one instead :)
<ogra_> we apparenlty end up without that file
<tvoss> let me check again
<tvoss> ogra_, ^
<ogra_> yup
<tvoss> kgunn, ping
<kgunn> tvoss: pong
<tvoss> kgunn, good morning :) had a conversation with mardy earlier on about "embedding" surfaces, I asked him to note down the req. in https://wiki.ubuntu.com/OnlineAccounts
<kgunn> tvoss: good one....like embedded video in dash
<tvoss> kgunn, which could be solved differently. I'm not sure an embedded surface is the best way to model/implement htis
<kgunn> tvoss: guess it depends on what your definitions/assumptions about embedded surf is...what are you thinking? (or what's the concern?)
<tvoss> kgunn, for me, the dash reasoning in terms of a texture, that a video decoder streams to is a better abstraction.
<kgunn> tvoss: ok, you mean, dash is just a client app to the video engine? (vs dash actually interacting w video app)
<kgunn> tvoss: but then you might be duplicating effort for VCR controls, time bar...unless you have common widgets
<tvoss> kgunn, ack, the dash uses the decoding service, and receives a decoded image stream as a result
<tvoss> kgunn, agreed, but think about the user scrolling the dash while playing the video
<tvoss> kgunn, if the surface should really be embedded, the compositor would need to know about that
<kgunn> tvoss: mmm, don't see why that would be a problem? (unless you're pointing to compositing synch where you have the video window lagging)
<kgunn> tvoss: true
<tvoss> kgunn, which breaks encapsulation to a certain degree. A surface is atomic to the compositor
<kgunn> tvoss: right...back to orig ques, assumptions on "what means embedded"
<kgunn> tvoss: you could truly have a seperate surf...e.g. it just appears embedded
<tvoss> kgunn, right. if the preview is just an overlay, all good. If it should be seamlessly embedded into the dash, it is way more difficult
<kgunn> tvoss: and actually...that's when you see "weirdness" in video it when the fmwk is trying to "cut a hole" in the scene graph somehow to stream video in
<tvoss> kgunn, and as I see it on the wiki, we are talking about truly embedded for the use-case at hand
<tvoss> kgunn, exactly. If it is a texture, and dash composites its content, things are way easier
<kgunn> tvoss: ok, yeah....you have a +1 here for "embedded" just meaning another surface composited on top
<tvoss> kgunn, we should clarify with design, especially for the signon-ui use-case
<kgunn> tvoss: w/ eglimages (aka texture stream)....i think the perf will be high enough....
<kgunn> tvoss: in the past we always got into weird bypass mechanisms for video
<tvoss> kgunn, I would think so too, plus priv
<kgunn> tvoss: that never were quite right :)
<kgunn> tvoss: yes, another reason, drm
<tvoss> kgunn, exactly, and performance with the android approach of relying on http://www.khronos.org/registry/gles/extensions/OES/OES_EGL_image_external.txt is performing really well on Ubuntu Touch right now
<kgunn> tvoss: yep
<alf_> status: mostly reviewing
<kdub> good morning, status, mp'd my changes to the android display
<kdub> thanks for the review alf_ :)
<alf_> kdub: it's not done yet, but my mind has been fried today by too much reviewing :)
<kgunn> kdub: ...that had to feel good to get that sucker in mp shape...nice job
<kdub> thanks kgunn, it does feel good to give it some air
<alf_> kdub: racarr: kgunn: btw, please try the VT switching (in trunk, don't forget to run it with root priveleges!), and let me know if you have any issues. I haven't had the chance to try it on many systems yet.
<kdub> kgunn, should make our android display story much more flexible... we even have a primitive layer list for hwc now!
<tvoss> kdub, did you have a chance to measure performance, yet?
<kdub> tvoss, not in a quantified way
<tvoss> kdub, and in a totally subjective way?
<kdub> well, for the qml demo yes, with the mir_egl* demo's they seem to run at vsync rate
<tvoss> kdub, okay
<kdub> annoying how nicemocks don't work with noexcept very well
<alf_> quick update on vt switching: The basic use case (running mir and switching from/to VT) works, as long as we don't have new clients trying to connect or requesting things from the server. We will need to block this at at the communicator level, that is, when we are paused we will need to accept but block all client requests.
<alf_> kgunn: ^^
<racarr> reading the C++14 papers is eird
<racarr> weird*
<kgunn> alf_: ack
<kgunn> alf_: so basically don't be launching/closing apps in the midst of swithing
<kgunn> ?
<racarr> kdub: I feel like you and I love bzr commit the most
<racarr> when I see things like rev 659 from jenkins
<racarr> im like oh thats me or kdub
<kdub> racarr, haha, indeed :)
<kgunn> kdub: hey....we don't have bypass comp do we ?
<kdub> kgunn, nope
<kdub> there's a blueprint entry for it though
<kgunn> kdub: or...well...do we if we say "hey hwc1.1 here's 1 layer"....then it says "oh, i can do that"
<kgunn> kdub: right...we don't have it for "gpu as fallback path"
<kdub> kgunn, i don't see how all those comments relate :)
<kdub> we have the gpu fallback path (if the hwcomposer.<platform>.so is missing)
<kdub> and hwc at the moment just works on one layer
<kgunn> kdub: right...i'm cheating
<kgunn> i just know that "most" platforms use HWC to be the bypass composition
<kgunn> kdub: its kind of irrelevant....the gpu comp path is the one  that matters to me....
<kgunn> ....more planning :|~
<kdub> if a bug on lp is a potential duplicate, what's the right state to put it in?
<kgunn> kdub: isn't duplicate a potential state ?
<kgunn> kdub: at least i always put a note in each w/ the respective dups' link in it....then pick one to work & mark the other dup
<kdub> no, seems 'incomplete' with a comment about duplication is the way most people do it
<kgunn> kdub: otherwise verbalize its a dup & state can be reject
<kgunn> kdub: ah...there you go
<kgunn> weird choice....but....a convention at least :)
#ubuntu-mir 2013-04-14
<Cheery> Hi
<Cheery> Is Mir going to provide an alternative driver model, which would separate the compositor's protocol from the drivers?
<Cheery> so that closed source drivers do not need to provide handlers for different window system bindings.
<thomi> robert_ancell: ping?
<robert_ancell> thomi, hello
<thomi> robert_ancell: hey - I just heard back from my fellow QEs regarding allowing non-canonical employees to trigger CI & autolanding in MPS.
<robert_ancell> duh duh... duh!
<thomi> essentially: it's a security risk, but we have a whitelist for people we trust, as long as: 1) we really trust them, and 2) they've signed the CCA
<thomi> so, if there's anyone you want us to add to the whitelist that meets both these criteria, please let me know
<robert_ancell> thomi, could you add david.edmundson - he's the main one
<thomi> ok
<robert_ancell> thomi, he works for blue systems, has been working on lightdm/kubuntu for ages
<thomi> robert_ancell: can you get him to sign the CCA? I think when you do you get added to a launchpad group, which I don't see on his lp.net page
<robert_ancell> thomi, he already has
<robert_ancell> thomi, yeah, I don't know who manages that group but none of the people I have got to sign show up on it
<thomi> oh, huh, i thought there was a group or something... I guess not
<thomi> ok
<robert_ancell> thomi, https://launchpad.net/~contributor-agreement-canonical
<thomi> robert_ancell: ok, I sent the request off, and CCed you
<robert_ancell> thomi, ta
<thomi> ahh, he is there too - I missed it
#ubuntu-mir 2014-04-07
<RAOF> I know everyone's either Sundaying or enroute to London, but have I accidentally broken cross-compile-chroot.sh?
<dandrader> anpok, hey alan_g just told me that you plan to work on item 5 of https://docs.google.com/a/canonical.com/document/d/12aVPbX5qzr2GqF8yBcc17ZWsD9Z1kQfoSaYi2yMm1rE/edit#heading=h.17wq5abcr8cb
<dandrader> anpok, is that so?
<ogra_> W/Adreno-ES20( 2074): <core_glReadPixels:212>: GL_INVALID_OPERATION
<ogra_> W/Adreno-EGLSUB( 2074): <CacheInvalidateHandle:243>: PMEM_INV_CACHES undefined
<ogra_> i see a lot of this lately in the logcat output on a mako (N4) ^^^
<anpok> dandrader: yes
<anpok> there is just some recuring distraction around the split greeter work
<kgunn_> camako: hello
<alan_g> camako: welcome
<mterry> Are there any known problems with mir/devel?  I've tried it on my mako, but the unity8 session never appears on screen (seems to be running fine).  What's the easiest way to debug this?  Get a display report, I'm guessing.  Any other reports that might be useful?
<alf__> mterry: to use mir/devel you need some changes in platform-api, unity-mir and unity-system-compositor
<mterry> alf__, yup, I built those branches
<alf__> mterry: oh, the latest compatibility branches need mir/devel + lp:~alan-griffiths/mir/scene-grabs-Session-and-SessionListener (yes it's a mess)
<mterry> alf__, ah...  I don't have that one
 * mterry builds more branches
<alf__> greyback: How can I get the latest Qt (the one that exhibits the blocking problem) to try on the phone?
<greyback> alf__: it's already on your phone
<greyback> Qt5.2 has the issue
<alf__> greyback: ok, how can I trigger it?
<alan_g> mterry: I couldn't reproduce the problem you reported as bug 1302689 (but I wrote a test case) - maybe you can provide more details.
<ubot5> bug 1302689 in Mir "Session raising problems" [Undecided,In progress] https://launchpad.net/bugs/1302689
<mterry> alan_g, hmm OK.  Well that's good in a way.  Maybe I'm just misusing API or some such in USC.  But I have a new problem when I tried to use a newer mir revision where unity8 sessions don't want to appear at all.  Working on that (see scrollback)
<alan_g> alf__: there are compatibility branches without (as well as with) scene-grabs-Session-and-SessionListener. The ones without "proposed" in them match devel
<greyback> alf__: handiest is to grab the QML code in https://bugreports.qt-project.org/browse/QTBUG-37677, save it to a file on the device as test.qml. Then as phablet user run "qmlscene test.qml --desktop_file_hint=/usr/share/application/<something>.desktop"
<greyback> alf__: that file prints the time every second to your console
<alan_g> (yes it's a mess)
<greyback> alf__: actually let me check something...
<greyback> alf__: yeah that's fine
<alf__> greyback: thanks
<greyback> alf__: ok, now with that program running, hit the power key, and watch the console - the time stops printing after a few seconds
<greyback> alf__: we want it so that the time does not stop printing to the console
<alf__> greyback: thanks, reproduced
<greyback> alf__: np, lemme know if you need a volunteer to test
<mterry> alan_g, ah OK.  Then maybe I was using right compatibility branches anyway...  But no matter.  I'll try with all the proposed branches
<alan_g> mterry: the related changes are largely moves & renames - so if it compiles you've got a consistent set.
<mterry> alan_g, that's what I figured / have
<mterry> alan_g, so mir/devel is working OK for you in tests?  Have you tried with a full stack with unity8 and such?
<alan_g> mterry: not recently enough
<mterry> alan_g, well.  It wasn't working great for me.  If you have time, I'd appreciate a sanity check on those results.  (specifically, I'm seeing no frames on screen, but no errors in logs)
<mterry> alan_g, and this is without my split branch nonsense
<alan_g> mterry: greyback has been using it
<greyback> mterry: things were working on Thursday
<mterry> greyback, would you mind retesting with tip?  I updated on Friday and things got worse for me.  But I'm not sure exactly what revision I had before
<greyback> mterry: okay
<alf__> greyback: could you please test the latest version of lp:~afrantzis/mir/non-blocking-swap-buffers-spike
<alf__> greyback: (merged with the version of mir/devel + Alan's branches you are using, of course)
<alf__> greyback: ^^^ also don't forget that you need the change in USC too
<greyback> alf__: working on that now
<alf__> greyback: thanks
<alan_g> alf__: happy with the new names: https://code.launchpad.net/~alan-griffiths/mir/scene-grabs-Session-and-SessionListener/+merge/214275
<greyback> alan_g: could you take https://code.launchpad.net/~alan-griffiths/unity-mir/compatibility-with-mir-changes/+merge/213079 , branch it at rev 209, and push as 0.1.8 compatible branch
<greyback> it compiles for me against 0.1.8 anyway :)
<alan_g> greyback: your wish will be granted (as soon as I get some CPU cycles on my laptop)
 * duflu warms hands on greyback's laptop vent
<greyback> alf__: slow going, but finally tested: bad news though, it's still blocking
<greyback> alf__: to confirm, I built your spike branch, platform-api, unity-mir and USC
<greyback> after about 3-4 seconds, the small qml test app stops printing to screen (I disabled the process suspend/resume just in case, no difference)
<greyback> alf__: it's interesting, as when I unlock the screen, the greeter is visible, but as soon as I tap the screen, the test app appears and starts rendering once again
<greyback> s/tap the screen/tap the right edge of the screen/
<mterry> Saviq, so I lost my latest silo.  Is there a silo crunch right now or could I get a new one?  I've got a plan for avoiding the Mir nonsense I've dealt with recently
<kdub> is it just me, or is khronos.org down today?
<bschaefer> down for me
#ubuntu-mir 2014-04-08
<greyback> alan_g: a 1 line change to https://code.launchpad.net/~alan-griffiths/platform-api/compatibility-with-mir-changes/+merge/214264 and it will be good for 0.1.8. Fancy it?
<alan_g> greyback: I'll not fight - but is it easier to explain to me or to do it yourself?
<alan_g> kgunn: Opinion? https://code.launchpad.net/~albaguirre/mir/fix-1285215/+merge/214452/comments/509057
<Saviq> greyback, https://code.launchpad.net/~saviq/mir/fix-cross-build/+merge/214740
<Saviq> aargh
<Saviq> devl
<Saviq> greyback, https://code.launchpad.net/~saviq/mir/fix-cross-build/+merge/214741
<greyback> thanks
<kgunn> greyback: so does this
<kgunn> https://code.launchpad.net/~alan-griffiths/platform-api/compatibility-with-mir-0.1.8/+merge/214700
<kgunn> superceded
<dandrader> alf__, is mir::graphics::DisplayConfigurationOutput::extents in pixels?
<alf__> dandrader: yes
<dandrader> alf__, ah, ok. because the documentation doesn't make it clear. is logical coords === pixel coords?
<dandrader> or, better saying, are the logical coords in pixels
<alf__> dandrader: yes
<dandrader> ok, thanks
<dandrader> alf__, in src/server/shell/graphics_display_layout.cpp:85
<dandrader> alf__, shouldn't it also confine the rect size to the output size?
<dandrader> alf__, well, I'm actually a bit confused about what it should do or not.... looks more like a policy decision thing belonging to the implementor (shell)
<dandrader> or maybe that's the strictly task of clip_to_output()...
<dandrader> strictly the*
<kdub> nice when you find a way to knock out a fair amount of interface cruft and reduce the amount of locks you have to get per render :)
#ubuntu-mir 2014-04-09
<kgunn> duflu: this one
<kgunn> https://cvs.khronos.org/bugzilla/show_bug.cgi?id=12052
<RAOF> kgunn: Yeah, we need to work out what we want done there.
<RAOF> Also, where did my comments go?
<kgunn> RAOF: weird...my latest comment not there either ?
<RAOF> EOD!
<kgunn> alf__: for the non-block spike, duflu is wondering if we should "keep" the blocking eglswap as a potential path....
<kgunn> in fact, he thinks non-block is effectively "swapinterval0+sync"
<kgunn> sync meaning it doesn't tear
<duflu> As the default path at least. So clients and compositors don't regress/spin/etc
<kgunn> alf__: also makes me wonder, are we trying too hard on the spike ? .... duflu says the swapinterval 0 today is non-tearing
<duflu> eglSwapSleep(dpy, GL_TRUE)
<kgunn> hmmm...maybe not on android tho
<alf__> kgunn: duflu: swapinterval 0 is not bound above by vsync, the spike is
<alf__> kgunn: duflu: that is, with just swap interval 0, clients will render as fast as they can
<kgunn> alf__: ah....its in between
<kgunn> or rather requires vsync...true...
<kgunn> its like it wants some blocking (just not indeterminate blocking :)
<alf__> kgunn: at least some kind of throttling, which in the spike is a fake vsync at 60Hz
<duflu> alf__: That's a bad idea. We fail the "zero wakeups" test during sleep. And that's something Mark mentioned this week too
<alf__> duflu: the buffer consuming thread only wakes up if triggered by a scene change, like the other compositing threads. It's just also enforces a fake vsync. So it's no worse than having another screen attached.
<duflu> alf__: It's a basic power management requirement to avoid wakeups during sleep. Only intentional background threads should be the exception
<duflu> A fake vsync would create a regression we'd just be forced to remove/fix eventually
<alf__> duflu: The fake vsync is only a throttling measure, it *doesn't* wake up the buffer consuming thread itself. The thread is only woken up if triggered by scene changes, and it consumes buffers at most at 60Hz, mimicking an output.
<duflu> alf__: I know, but that's still poor power management, and a step backwards from Ubuntu as we know iyt
<duflu> alf__: If nothing else, I think we need to keep defaulting to the existing behaviour. Then you can safely add optional behaviour for *anything*
<alf__> duflu: The existing behavior (eglSwapBuffers blocking indefinitely) 1. breaks Qt 2. Khronos told us that it's not how things should work
<alf__> kgunn: ^^ can you verify point 2, in case I misunderstood something
<duflu> alf__: I know and I know. What I'm saying is don't make unblocking behaviour the default, but optional. We would break too many existing apps/compositors/toolkits
<duflu> Plus you need buy-in from all the driver vendors, which will take time too
<kgunn> alf__: accurate
<kgunn> duflu: i agree, spec isn't clear & its not the greatest but side channels have to be used...which alot of OS's use (ios, android, qt)..so which toolkits don't have a side channel ?
<kgunn> greyback: did you update the unity-mir branch for 0.1.8 ? (just wanted to make sure i wasn't mistakenly waiting)
<greyback> kgunn: not yet, in meeting
<kgunn> ack
<greyback> kgunn: https://code.launchpad.net/~alan-griffiths/unity-mir/compatibility-with-mir-0.1.8/+merge/214610
<kgunn> greyback: thanks...sorry about that...my fault
<Saviq> duflu, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1304959
<ubot5> Ubuntu bug 1304959 in unity8 (Ubuntu) "unity8 crashed with SIGABRT in qt_message_fatal()" [Medium,New]
<duflu> Saviq: That's the current (stable) Mir. I can't see any issue with Mir as yet
<kgunn> racarr__: here's some fun...
<kgunn> https://bugs.launchpad.net/mir/+bug/1305080
<ubot5> Ubuntu bug 1305080 in Mir "libmirclientplatform-android isn't loaded upon libmirserver install" [Undecided,New]
<kgunn> alf__ might have an opinion
<mterry> kgunn, I tested your Mir 0.1.8 silo, seemed to work for me
<mterry> kgunn, in related news, is there a silo open for split greeter again?  I think I can avoid the Mir troubles I was having last silo by just basing off 0.1.8 and patching it for the one fix I need (which doesn't break ABI)
<PreSSion> hello! I want start to develoment a tool to be used in multiplataform linux smartphones, tablets and pc, I going to choose Qt, but I need the develoment of the MIR protocol is seriously and ubuntu will abandon this.
<PreSSion> and sry for my "engrish"
<kgunn> PreSSion: hi, Mir is serious and won't be abandoned
<kgunn> PreSSion: consider the fact that Mir is _the_ display server being used by default in our ubuntu on phones & tablets
<PreSSion> nice
<kgunn> and we are working toward eventually making it the default display server on the desktop as well
<PreSSion> because I want develoment a "yakuake" but not a command line, a tool to make a human script software, where you can say script in human language, for example: Delete files from /home/user that contain the word hello, and a voice input and i will try to add google voice
<PreSSion> I think woulkd be fine, I have got money and I will have got full time then summer
<PreSSion> I will write in Qt
<PreSSion> and kgunn, just the last question, MIR will be use in the future in PC'sÂ¿?
<kgunn> PreSSion: yes, absolutely, it will be used in our desktop / PC distributions
<PreSSion> thanks! good bye
<kgunn> PreSSion: you're welcome
<fginther> kgunn, is josharenson the right contact for the benchmarking work?
<kgunn> fginther: he is!...i think he was able to connect with robotfuel but dunno
<kgunn> he might have  more questions
<robotfuel> fginther: is there a new way to stop unity8 that you know of?
<robotfuel> fginther: stop unity8 as the phablet user used to work, but now I get stop: Unable to connect to Upstart: Empty address ''
<fginther> robotfuel, I don't have any specific knowledge of this, try asking in ubuntu-ci-eng
<fginther> kgunn, thanks
<kgunn> fginther: no thank you!
<kgunn> Saviq: ^ any ideas on robotfuel's ?
<Saviq> robotfuel, upstart died for you
<Saviq> robotfuel, there's a known crash
<Saviq> robotfuel, restart lightdm as root
#ubuntu-mir 2014-04-10
<jibel> Saviq, I think you're right about 1304959, the machine must be unsupported (too old?). I tried on another laptop and unity8 runs fine. I also filed bug 1305513 to fallback to a lightweight session or at least warn the user when unity8 is started on an unsupported platform.
<ubot5> bug 1305513 in unity8 (Ubuntu) "Start a fallback session if platform is too old or unsupported" [Undecided,New] https://launchpad.net/bugs/1305513
<Saviq> jibel, right, thanks
<om26er> when I start Mir demo server I get this http://paste.ubuntu.com/7230196/
<om26er> is that another way of saying unsupported platform ?
<RAOF> om26er: No, that's our way of failing to un-negate errno in some cases :)
<RAOF> errno 22 is EINVAL, which either means you don't have a /dev/dri/card* that udev knows about, or some other error.
<RAOF> (Such as your kernel driver being all screwy)
<om26er> RAOF, i have sandybridge, is that not supported ?
<om26er> IntelÂ® Sandybridge Mobile x86/MMX/SSE2
<RAOF> That's supported, but there's obviously something wrong.
<om26er> oh, maybe I have the nvidia driver installed ? even though I have forced the GPU to be intel
<RAOF> dmesg might be instructive.
<om26er> RAOF, http://paste.ubuntu.com/7230255/
<RAOF> om26er: Hm. That looks odd to me, but nothing jumps out as *broken* per se.
<duflu> om26er: https://bugs.launchpad.net/bugs/1292384
<ubot5> Ubuntu bug 1292384 in mir (Ubuntu) ""Error opening DRM device" is always followed by "Unknown error -(some negative number)"" [Low,Triaged]
<duflu> Although getting the error message is not necessarily more enlightening
<anpok> dandrader: https://code.launchpad.net/~andreas-pokorny/mir/custom_input_dispatcher/+merge/215174 InputChannel wrapper still outstanding - should follow soon
<robotfuel> josharenson: I replied to your email. let me know if you have more questions.
<josharenson> robotfuel: thanks I see the e-mail.
#ubuntu-mir 2014-04-11
 * RAOF -> EOW
<seb128> ricmm, hey, could you look at https://bugs.launchpad.net/ubuntu/+source/qtubuntu/+bug/1306465 ?
<ubot5> Ubuntu bug 1306465 in qtubuntu (Ubuntu) "system-settings crashed with SIGABRT in __libc_do_syscall()" [High,New]
<seb128> settings abrt() in QUbuntuIntegration::QUbuntuIntegration(QUbuntuInputAdaptorFactory*) () at ../../../../../src/platforms/ubuntu/ubuntucommon/integration.cc:75
<seb128> we had other sigabrt in qtubuntu showing on e.u.c, could be the same issue (e.g I don't think it's specific to settings)
<seb128> ricmm, Saviq thrown your name as maybe a good candidate to look at it since that seems a qtubuntu issue (could be mir though)
<Saviq> ricmm, or at least bounce it to someone who owns qtubuntu these days...
<seb128> the log seems to have a "could not create application instance" error
<seb128> Saviq, ricmm: ogra_ is saying that there is a known mir issue fixed in trunk, could be it
<ogra_> well, not sure thats exactly the same one ...
<ricmm> seb128: Saviq if the instance is failing to be created
<ricmm> it means that unity is disallowing the connection
<ricmm> seb128: is this reproducible with steps?
<ricmm> this kind of bug needs to be reproducible to fix it, with steps
<ricmm> because it deals with a couple processes talking to each other
<seb128> ricmm, can you ask psivaa on #ubuntu-ci-eng, seems to happen during touch tests
<ricmm> and u-al-l inthe middle
<seb128> ricmm, he says that it happens during unity8 tests
<ricmm> seb128: yup im in the channel
<seb128> ricmm, saw that, thanks
<josharenson> racarr__ Are you at Bluefin today?
#ubuntu-mir 2014-04-13
<cpatrick08> I am building mir on trusty and I am on the Building Mesa Step, and get following error message configure: error: DRI driver directory 'mir' does not exist
#ubuntu-mir 2015-04-07
<alan_g> alf_: is there actually a reason for ExternalSpinner to be a separate process?
<alf_> alan_g: I think the idea was that the default spinner could be easily replaced with a branded version by phone vendors
<alan_g> OK that's a plausible reason.
#ubuntu-mir 2015-04-08
<duflu> That's scary. I'm seeing documentation that shows the C++14 ways of doing things won't still work in C++17
<RAOF> duflu: Which particular bits? I seem to remember seeing some edge-case stuff that didn't seem to be terribly unreasonable.
<duflu> RAOF: unique_ptr and destructors I think it was
<chrisccoulson> RAOF, are you still around? I've got something you might be able to help me with :)
<RAOF> chrisccoulson: I am, briefly.
<RAOF> chrisccoulson: What can I do you for?
<chrisccoulson> RAOF, how familiar are you with the graphics architecture in oxide + chromium?
<RAOF> chrisccoulson: I think you might be after racarr.
<RAOF> chrisccoulson: On the basis that he did most of the Mir backend for chromium.
<chrisccoulson> RAOF, possibly, but you don't know what I'm going to ask next :)
<RAOF> I am not particularly familiar with the graphics arcitectures you're talking about :)
<chrisccoulson> RAOF, the short story is - Oxide has a webiew compositor that composites to a texture via chromium's GPU service thread. We then create an EGLImage from that which gets passed to the QML scenegraph compositor
<RAOF> Sensible enough.
<chrisccoulson> RAOF, but we want to move the GPU service thread out of process, as it is with Chrome / Chromium
<RAOF> Also sensible enough.
<chrisccoulson> so the EGLImage we pass to QML has to be backed by something that lives in another process
<RAOF> Welcome to nonstandardland.
<chrisccoulson> I know how to approach this on X + GLX (we have a different compositing path for X currently)
<RAOF> There's no simple way to get an EGLImage across process boundaries.
<chrisccoulson> Yeah, that's what I was expecting
<RAOF> In the not *too* distant future EGLStream is what you're after.
<chrisccoulson> Having different implementations for mesa / hybris isn't really too much of an issue
<RAOF> For mesa you can use... EGL_EXT_image_dma_buf_import and EGL_MESA_drm_image, I think.
<RAOF> For hybris...
<RAOF> ...have you perhaps considered becoming a Mir compositor? :)
<chrisccoulson> Hah, I haven't. I'm not entirely sure what that would involve (we're pretty much tied to Chromium's compositor)
<RAOF> Oh, you'd just use the Mir backend for that :)
<chrisccoulson> RAOF, For mesa, I was looking at libgbm. Is that not the right thing to use?
<RAOF> Not really, no.
<chrisccoulson> ah, ok
 * RAOF heads out.
<RAOF> Sorry I couldn't be of more help!
<chrisccoulson> RAOF, oh, you've been helpful enough. Thanks! :)
#ubuntu-mir 2015-04-09
<mterry> XMir still opens input devices itself it seems.  Is there a way to disable that yet and just use Mir input directly?
<kenvandine> greyback_, any chance of getting your window-close-support branch landed soon?
<greyback_> kenvandine: it's not been on my list of priorities tbh. qtmir needs work to enable first asking window to close politely, then waiting a bit, before timing out and killing it
<greyback_> so that branch cannot be landed alone
<kenvandine> bummer
<kenvandine> ok
<kenvandine> i've been quietly watching and hoping :)
<greyback_> kenvandine: welcome to add a card to our scrum backlog, that'll get it moved along
<kenvandine> not sure i have access to do that
<greyback_> I'll do it
<kenvandine> thx
<mterry> XMir doesn't seem to get the screen size right -- can it not talk to Mir correctly to query that?
#ubuntu-mir 2015-04-10
<seb128> hey there
<seb128> unsure if that's a mir regression but that seems to have started with the u-s-c rebuild for mir 0.12
<seb128> https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bug/1442505
<ubot5> Ubuntu bug 1442505 in unity-system-compositor (Ubuntu) "/usr/sbin/unity-system-compositor:11:mir::frontend::SessionMediator::create_screencast:mir::frontend::detail::invoke:mir::frontend::detail::ProtobufMessageProcessor::dispatch:mir::frontend::detail::SocketConnection::on_new_message:mir::frontend::detail::SocketConnection::on_read_size" [Undecided,New]
<seb128> same for bug #1442508
<ubot5> bug 1442508 in unity-system-compositor (Ubuntu) "/usr/sbin/unity-system-compositor:11:Add:add_surface_pixel_format:mir::frontend::SessionMediator::connect:mir::frontend::detail::invoke:mir::frontend::detail::ProtobufMessageProcessor::dispatch" [Undecided,New] https://launchpad.net/bugs/1442508
<alan_g> RAOF: still working? Would be useful to discuss surface modification APIs
<alan_g> anyone got time to review this? I hope it isn't contentious - https://code.launchpad.net/~alan-griffiths/mir/some-surface-modification-infrastructure/+merge/255648
#ubuntu-mir 2016-04-11
<RAOF> hallyn: You* can specify arbitrary xkb options; ctrl:nocaps is probably the one that you want.
<RAOF> hallyn: *: For values of âyouâ equal to âthe shell that you're using, and AFAIK Unity8 has no UI for setting thatâ
<hallyn> RAOF: so 'the shell' means 'the UI shell' ?
<RAOF> hallyn: Specifically, âthe shellâ means âthe thing that's linked against libmirserver and is providing your Mir serverâ
<hallyn> no way to make it configurable by the user regardless of the shell?
<duflu> Yes. I can use my mouse in 1000Hz mode with Unity8 now
<duflu> Since Mir 0.21.0 got released
<RAOF> hallyn: By default we *should* respect the udev
<RAOF> -set preferences, but there's nothing stopping shells from overriding that.
<RAOF> (I don't think we currently *do* respect the udev-set preferences, but we should)
<hallyn> RAOF: hm, well lemme try that.  new to me
<RAOF> It's what keyboard-configuration sets.
<hallyn> Not sure what 'keyboard-configuration' is.  if it's the thing in the gnome gui, it doesn't have such an option (since like precise or something)
<RAOF> âapt search keyboard-configurationâ âº
<hallyn> or rather dpkg -L.  ok so to my surprise that means that i should expect mir to respect *X*KBPOPTIONS :)  i'll try, thx
<hallyn> no joy
<RAOF> Yeah, I'm not sure that we *do* respect those options, but we should.
<RAOF> Feel free to file a bug :)
<dandrader> alf__,  how do I assign a value to a mir::geometry::Point.x?
<alf__> dandrader: = mir::geometry::X{1}
<dandrader> alf__,  that worked. thanks
<alan_g|EOD> kdub: FWIW cmake runs each test suite in a separate execution. All the process start/stops take extra time
<kdub> alan_g|EOD, ack, thanks
<kdub> still poking around that one
<alan_g|EOD> just use "make ptest"
#ubuntu-mir 2016-04-12
<duflu> RAOF: When you get time, could you cast your eyes over this and tell us if we should worry? https://bugs.launchpad.net/mir/+bug/1568966
<ubot5`> Launchpad bug 1568966 in Mir "[regression] mir_integration_tests take significantly longer when running with ctest" [Medium,New]
<RAOF> That's odd :)(
<RAOF> duflu: In case you're particularly interested: https://code.launchpad.net/~raof/mir/emfasten-mir-integration-tests/+merge/291578
<duflu> RAOF: Weird, ta
<RAOF> I have apparently confused launchpad too much for it to show any commits.
<tsdgeos> alf__: hi, have a sec?
<tsdgeos> or anyone that understands how the lttng stuff in mir works
<tsdgeos> i have a question
<alf__> tsdgeos: sure, what's up?
<tsdgeos> alf__: trying to understand the lttng stuff you guys have, and i'm a bit lost on what TracepointProvider & subclasses are used for
<tsdgeos> it loads a library but as far as i can see it never uses it for anything?
<alf__> tsdgeos: It's used implicitly by lttng. The idea is that we want to load lttng only if the user requests it (i.e., uses an lttng report).
<alf__> tsdgeos: lttng supports "TRACEPOINT_PROBE_DYNAMIC_LINKAGE" which tells it to load the tracepoint symbols at runtime
<tsdgeos> ah, i see
<tsdgeos> you have client/logging/input_receiver_report.h and client/lttng/input_receiver_report.h
<tsdgeos> and only when the second is used
<tsdgeos> the lib is actually loaded
<alf__> tsdgeos: right, and in client/lttng/input_receiver_report.cpp note that the tracepoints are used in "#define TRACEPOINT_PROBE_DYNAMIC_LINKAGE" mode
<tsdgeos> alf__: oki
<tsdgeos> alf__: mir_tracepoint is basically a defined to tracepoint, right?
<alf__> tsdgeos: yes, mir_tracepoint used to provide a workaround for building with clang, but the problem got fixed eventually and we removed the workaround but not the name
<tsdgeos> ok, that helps a lot
<tsdgeos> tx
<alf__> tsdgeos: np
#ubuntu-mir 2016-04-13
<tedg> Howdy folks.
<tedg> Getting the classic: UbuntuClientIntegration: connection to Mir server failed. Check that a Mir server is
<tedg> I thought I could set some environment variables to dump stuff
<tedg> But they don't seem to be working right now.
<tedg> Did they change? Am I doing it all wrong?
<tedg> The note I have is this: MIR_{SERVER,CLIENT}_{DISPLAY_REPORT,COMPOSITOR_REPORT,CONNECTOR_REPORT,MSG_PROCESSOR_REPORT,SESSION_MEDIATOR_REPORT}=log
<tedg> If I have the same major versions of the Mir libraries those should connect, right?
<tedg> Even if I got one from xenial and other is from the vivid overlay?
 * bschaefer would expect :|
<bschaefer> tedg, check the umm drivers
 * bschaefer looks them up
<bschaefer> mir-client-platform-android,  mir-platform-graphics-android, mir-platform-input-evdev
<bschaefer> tedg, should all be the same version as the major version of the server/client
<bschaefer> (they wont be auto upgraded, since mir doesnt have a hard depend on them)
<tedg> Where are those located?
<bschaefer> tedg, packages
<bschaefer> mir-client-platform-android5
<bschaefer> tedg, should be in universe
<bschaefer> mir-platform-graphics-android8 and mir-platform-input-evdev5
<bschaefer> tedg, if you've just upgraded to mir 0.21, and those platforms are 0.20.3 then it'll fail
<bschaefer> tedg, soo you could check dpkg -l | grep mir | grep 0.20.3 to see if you've older packages around
<tedg> Looks like I'm 20.3 here on the phone.
<bschaefer> tedg, o for the server/client?
<tedg> That seems to be the version of the platform in OTA 10.1
<bschaefer> hmm soo if thats not the issue then i would expect them to work :)
<tedg> Hmm, Xenial has 0.21
<tedg> Not sure if that's the issue, but it could be.
<bschaefer> there was an issue yesterday with someone having newer client/server and older drivers soo figured i would assume that :)
#ubuntu-mir 2016-04-14
<duflu> anpok: Fun for you:   https://code.launchpad.net/~mir-team/mir/fix-1528109/+merge/291860
<anpok> oh
<duflu> It works!
<anpok> o**g displacement is not storing floats?
<anpok> args..
<anpok> hmm make ptest passes in 16 seconds
<duflu> Passes? Too good to be true
<duflu> anpok: Would you kindly own that branch? I'm not meant to be looking at such things
<anpok> oh interesting
<anpok> on a 32 core machine it runs in 14 seconds -j 64..
<anpok> but on a 8 core it fails with -j 64..
<anpok> meh
<anpok> duflu: hmm i would want to change displacement and point
<anpok> so that confining just works..
<duflu> anpok: That's a can of worms. What I've proposed works and doesn't require any type changes
<anpok> what do you think is missing in your MP?
<duflu> anpok: Tests
<anpok> hm i guess the same is true for scroll events
<anpok> but we do ticks now.. so it will only be a problem later when we also supply scroll motion axis
<duflu> Heh. It would be amusing it smooth touchpad scrolling was always there and we just accidentally lost precision
<anpok> unless of course you scale down the scroll ticks..
 * alan_g realizes he pushed to the wrong miral branch
#ubuntu-mir 2017-04-10
<Dazev> Hi, one question, is mir to stay or is the ubuntu team switching to wayland with the 18.04 release?
<tsdgeos> was a pleasure working for Canonical! /me waves
#ubuntu-mir 2017-04-11
<duflu> bregma: Are we skipping the hangout?
<duflu> camako, bschaefer ^
<bschaefer> umm i think so
<bschaefer> duflu, i think its just me and you around
<duflu> And then more
<mariogrip> alan_g: ping
<alan_g> mariogrip: ?
<mariogrip> alan_g: I saw your post "a-new-hope", and about canonical maybe continuing mir, and at the same time i'm trying to create a wayland platfrom in mir. but i'm then wondering if I should stop that and keep using mir instead of having mir on top of wayland, since what we dont want is to maintain a display server on our own. And do you know if the android
<mariogrip> platform would also be maintained?
<alan_g> mariogrip: at the moment I don't know.
<alan_g> Canonical hasn't had practice at redundancies and information isn't flowing well.
<alan_g> In particular I don't know if any of the proposed IOT projects would use the android stack.
<ogra_> unlikely (but still possible)
<mariogrip> right, i'm also a bit worried that android would not prioritized
<ogra_> not only that ... i doubt anyone at canonical will look at hybris in the future
<ogra_> so even if the Mir bits keep working, hybris integration will be in possible limbo
<alan_g> mariogrip: sorry, I gotta go just now.
<mariogrip> alan_g: no problem
<mariogrip> ogra_: well, libhybris we can manage since we are not alone on that, but maintaining our own display server is a bit too much
<ogra_> well, the thing is that you need to maintain  the hybris integration of Mir ... neither mir alone or hybris alone
<ogra_> mir itself ... at least in form of the mir-kiosk snap will surely persist ... but i dont know if there will even be any development
<ogra_> or if it will just go into "maintenance mode" directly
<mariogrip> right, that's what im worried about that libhybris will change and mir breaks
<ogra_> it does what it is supposed to do ... (display a single standalone kiosk app) ... so not sure there will be any additional investment
<mariogrip> that's why i'm trying to create this wayland platfrom in mir, that way we dont have to maintain the part that talks with libhybris
<tvoss> mariogrip: libhybris is surprisingly stable. I think you are creating more work for yourself by using wayland as an abstraction layer here
<tvoss> mariogrip: because ultimately, you would have to maintain hybris anyway
<ogra_> tvoss, well, if the hal stack changes and hybris gets adjustments for that you usually need to adjust Mir as well ...
<tvoss> ogra_: sure, but you would need to patch thewayland adaptation layer, too
<ogra_> given the amount of maintainers that care for Mir on hybris ...
<ogra_> tvoss, upstream will fix all wayland issues
<ogra_> since they use wayland
<tvoss> ogra_: upstream of what?
<ogra_> but nobody will fix the Mir side
<ogra_> of hybris
<tvoss> ogra_: sure, but the assumption is that the wayland bits would stay untouched and that the abstraction layer in Mir would need changes either
<tvoss> ogra_: just saying that introducing an abstraction layer at that level will likely just move the problem
<ogra_> indeed
<ogra_> but you add another abstraction that probably makes it easier
<ogra_> i.e. if the upper side of wayland doesnt change you dont need to adjust Mir ... and the lower side of wayland will be managed by upstream anyway
<tvoss> sure, that's a risky bet, though
<ogra_> (i'd actually be more concerned about the performance impact ... maintenance wise it could be less work after all )
<ogra_> ...but yeah, based on assumptions :)
#ubuntu-mir 2017-04-12
<AdamH> Hello, I am trying to understand Qt, mir and snaps. I have written a Hello World app using Qt which works on a Desktop. But when I install the Snap on Ubuntu Core I get the following error Apr 12 10:50:58 localhost snap[1292]: cannot perform operation: mount --bind -o ro,nosuid,nodev /snap/mir-libs/28/mirlibs0/usr/lib /snap/falconhelloworld/x1/mir-libs: No such file or directory. Directory doesn't exist but not sure what I am missing
<AdamH>  as I have used mir-kiosk-apps as a guide. Any pointers as to how I debug this?
<AdamH> https://github.com/AdamHeavens/falconhelloworld/
<alan_g> AdamH: sounds like you're missing the mir-libs content interface.
<alan_g> I'm not very familiar with the snaps error messages, but have you tried the example clients?
<AdamH> alan_g: I have the following interfaces mir-kiosk:mir             falconhelloworld and mir-libs:mir-libs         falconhelloworld,mir-kiosk
<AdamH> I have used mir-kiosk-apps and it works correctly. So must have something set wrong in snapcraft I assume
<alan_g> That would be my guess too. (But all the snapcraft I've done has been copy & change.)
<alan_g> When you say the directory doesn't exist do you mean /snap/mir-libs/28/mirlibs0/usr/lib or /snap/falconhelloworld/x1/mir-libs
<alan_g> ?
<AdamH> It is /snap/falconhelloworld/x1/mir-libs that does not exist
<alan_g> OK, you're just missing that directory in your snap.
<AdamH> Yes just not sure how I pull it in at the moment
<alan_g> Do you have the (empty) folder in github?
<AdamH> No but I have noticed in the mir-kiosk-apps demo there is an emtpy folder in glue, is that all I need to do?
<alan_g> You need the empty folder for bind to work.
<AdamH> ha thanks... will give that a try now
<alan_g> My example uses this yaml: https://bazaar.launchpad.net/~alan-griffiths/mircade-snap/trunk/view/head:/snap/snapcraft.yaml
<alan_g> If that doesn't work, the folks on #snappy may know what the incantations mean.
<AdamH> Thank you will give it a go
#ubuntu-mir 2017-04-13
<Son_Goku> alan_g, hey
<Son_Goku> I saw your blog posts about Mir earlier today
<Son_Goku> I'm a bit confused by it though
<Son_Goku> are you talking about Mir acting like a Wayland compositor or just offering support for the Wayland protocols so applications that are clients to Wayland compositors work on Mir, too?
<alan_g> Son_Goku: this is an area prone to misunderstandings. If *hypothetically* Mir offered support to clients using Wayland why wouldn't you consider it a Wayland compositor.
<Son_Goku> I really don't see a problem with that, and in fact, I'd love that
<Son_Goku> my *only* problem right now is that I *really* can't handle dealing with libinput having non-upstream APIs in order for Mir to build
<Son_Goku> several months ago, I did build Mir for Fedora, but it became quickly unrealistic to maintain
<Son_Goku> alan_g: Ubuntu moves too slowly :)
<Son_Goku> the Mesa and libinput patches not being upstream makes adding Mir to Fedora *really* hard
<Son_Goku> not to mention, libinput effectively has a different ABI when the patch is added
<Son_Goku> as I've explained to tvoss, it would really be nice and helpful if I don't need to do terrible things like this in a copr repo that will break as Fedora moves forward
<alan_g> Son_Goku: I've not tracked the upstreaming closely. I know what the plans were and the guys that were working on it, but with recent events there was no opportunity for a handover.
<Son_Goku> well, the libinput patch was written by anpok_
<alan_g> yes
<Son_Goku> he submitted it once long ago in 2015
<Son_Goku> but apparently he never followed up after the initial review
<Son_Goku> so now we're stuck in this bad situation where no one can actually add mir without breaking libinput ABI
<alan_g> I agree its a bad situation. I don't know any detail of how Canonical plans to proceed yet. I hope to get some decisions next week.
<Son_Goku> I've gotten Mir to work on Fedora, for about a week :)
<alan_g> Terrific! Have you blogged about the issues you encountered?
<Son_Goku> I have not
<Son_Goku> I didn't think anyone would be interested
<Son_Goku> tvoss actually helped me get off the ground
<Son_Goku> the big issue that I've heard from people about even thinking about Mir vs Wayland is that no one can reasonably use Mir due to non-portability
<Son_Goku> the Big Idea(TM) was to make it so that Mir worked on Fedora without screwing with the core of the system so that people could reasonably consider it
<Son_Goku> it helps that because Fedora is a very upstream-centric distribution (as opposed to Debian and Ubuntu), it's much easier to trust that others can pull from us and repackage for their own distros, and that opens the door to make Mir a very credible option
<alan_g> Sure. That's also why there was work in progress to upstream to mesa and libinput.
<Son_Goku> alan_g: I even found a problem while packaging Mir which someone fixed once I told tvoss about it ;)
<alan_g> Son_Goku: :)
<alan_g> Really, we've tried to address problems but the Canonical re-org was a surprise. It's still in progress and I don't know what the future holds.
<alan_g> Having a write-up of the issues you found could help the replanning.
<Son_Goku> alan_g: I guess I can give it a shot
<alan_g> Son_Goku: thanks.
<zyga> Son_Goku: wow, I'm surprised to see you here :-)
<Son_Goku> zyga: I've been here for months
 * zyga imagines mir having a brigher future after being abandoned by canonical
<Son_Goku> the irony is that if Mir is mostly abandoned by Canonical, it could be more flexible
<Son_Goku> certain things that might have been disallowed in the past could be done and merged in
<zyga> yes, that's true
<Son_Goku> really, I'd love to have Mir packaged in Fedora, but the libinput and mesa patches make it hard
<Son_Goku> Peter Hutterer (libinput developer and Fedora package maintainer) and Adam Jackson (the chief maintainer for mesa in Fedora) aren't willing to accept patches like these that aren't backports from already merged upstream things
<alan_g> Mir was always eager to consider pull requests
<Son_Goku> but you're on Launchpad :(
<zyga> Son_Goku: which is free software and supports git and bzr
<Son_Goku> I maintain a private copy on GitLab because the GitLab CI is so nice
<zyga> Son_Goku: pro tip: if you want to contribute, make it easy to get the contribution
<Son_Goku> yep
<Son_Goku> I know this
<Son_Goku> launchpad doesn't make it "difficult" per se
<Son_Goku> but afaik, it uses bzr and its MR mechanism is quite weird compared to what most people are used to these days
<zyga> Son_Goku: so use that to make the contribution (not sure if mir is git or bzr)
<Son_Goku> mir is bzr, I believe
<Son_Goku> I did the conversion for gitlab
<Son_Goku> yep
<Son_Goku> still is bzr
<zyga> one battle at a time
<Son_Goku> eh, I'm not too concerned about mir itself
<Son_Goku> mir is not the problem child yet
<alan_g> Canonical's Mir is bzr. But... coming soon... https://github.com/unity8-team
<Son_Goku> the problem is the infrastructure required for mir to build
<Son_Goku> alan_g: that's unattached from Canonical entirely?
<Son_Goku> and if I might make a suggestion, GitLab is a much nicer system
<Son_Goku> I've been using it for my own projects and the much richer CI system built into it makes it so much more powerful
<ogra_> but they trash their servers :P
<alan_g> Some of the ex-employees are copying the U8 ecosystem there
<Son_Goku> ogra_: one of the things I've been doing is actually running builds against multiple distros in parallel and executing tests
<Son_Goku> not with mir specifically, but with some of my own things
<zyga> alan_g: nice!
<Son_Goku> my original motivation for mir was because unity
<Son_Goku> and I was told to not try unity 7
<Son_Goku> so I moved on to unity 8
<alan_g> U7 is based on compiz+gnome
<Son_Goku> ah, that would have been a problem then
<Son_Goku> iirc, ubuntu uses compiz 0.9.x
<Son_Goku> but Fedora reverted back to 0.8.x after much breakages
<Son_Goku> and now there's a group actively working on compiz 0.8.x development
<alf_> Great discussion with Jono Bacon: https://www.youtube.com/watch?v=4mOPmM4Y15o
<zyga> odd, that test no longer fails
<zyga> hrmm hrmm
<zyga> let's retest
#ubuntu-mir 2017-04-14
<fritsch> RAOF: what shall we do with the MIR port in kodi? Removing it prior to v18 release?
<fritsch> RAOF: will wait for bschaefer who implemented it
<RAOF> fritsch: I'm on paternity leave, so somewhat or of the loop. I *think* it's still useful, even if we don't use it on the desktop.
<fritsch> RAOF: oki, thx
<fritsch> RAOF: and congrats! to the "paternity leave" root cause :p
<ogra_> fritsch, the mir support is the only way to get kodi to run on ubuntu core (where mir-kiosk will stay around and be maintained)
<ogra_> does it cause much trouble to just keep it in ?
<fritsch> nope - not for us.
<fritsch> we will ping bschaefer from time to time
<fritsch> if we change sth architectural
<ogra_> well, as long as it works it would be nice to keep it ... once it braks i cant tell if there would be someone to fix it though
<fritsch> yeah, if it's not maintained anymore we will remove it
<fritsch> but as it was implemented non intrusive at all
<fritsch> no problem for now
<ogra_> cool
<fritsch> we will see, currently pure drm is on the way
<fritsch> to get merged
<fritsch> and afterwards we will concentrate on wayland
<fritsch> pure drm, e.g. gbm
<ogra_> neat
#ubuntu-mir 2017-04-15
<fritsch> bschaefer: yeah - we will keep it and ping you whenever something touches it. Thanks much. Next on our todo (including gsoc) is: wayland.
<bschaefer> fritsch, awesome, yeah was looking that the drm branch and that looked awesome!
<fritsch> if you have some comments for it, please do not hesitate to state those - highly appreciated
<bschaefer> Yup was going to test it out this weekend, my only concern was if SDL was selected for events ... only joysticks would work IIRC
<bschaefer> as theres no backend for drm
<bschaefer> but was looking and SDL isnt default selected (unless i missed it) so shouldnt be a big issue
<fritsch> it should not use sdl
<fritsch> if you test it, please report your results in the PR
<fritsch> i think for now, you need root access to run it
<fritsch> the VAAPI commits will go to vp_updates branch
<fritsch> as we are currently heavily reworking vidoe player too
<fritsch> and therefore lrusak removed those commits
<fritsch> but he has drm + vaapi working already
<bschaefer> yeah figured it shuldnt
<bschaefer> o nice!
<bschaefer> yeah theres a drm vaapi backend
<fritsch> the same you use in mir
 * bschaefer recalls that being already supported?
<bschaefer> yeah
<fritsch> those commits: https://github.com/lrusak/xbmc/commits/drm-kms-vp
<fritsch> on top of:
<fritsch> https://github.com/xbmc/xbmc/tree/vpupdates
<fritsch> + the PR will give you hwaccel, too
<bschaefer> ive not heard of PR, will it give you hwaccel outside that intel specific extension?
<fritsch> PR: <- PullRequest
<fritsch> git specific
<bschaefer> pfft haha
<fritsch> hehehe
<fritsch> nope, we still use default vaapi
<fritsch> + the R8 GR88 drm extension
<bschaefer> yeah ive heard of that, was thinking something PR that gave you hwaccel outside of vaapi
<fritsch> nope
<fritsch> vdpau will die
<fritsch> bound to X11
<bschaefer> yay
<fritsch> and we will consider wayland the new "default" in the near future
<fritsch> now that you guys also transition
<bschaefer> yeah that sounds perfectly reasonable
<fritsch> though I will also give drm a try. I am mostly interested in the boot time
<fritsch> anad the KMS to kodi transition
<bschaefer> yeah, i cant imagine mir/wayland being much slower (not to many layers on top) but yeah direct kms will be faster
<bschaefer> though you lose the *displayer* bit but since you're a fullsreen app anyway
<fritsch> for appliances without the need for a browser
<fritsch> drm kms directly is nice
<bschaefer> yeah
<fritsch> but when you need a window manager / browser whatever
<bschaefer> i can only think if someone wants to run it on their desktop
<fritsch> jep
<bschaefer> in a display server those backends will be wanted
