#ubuntu-mir 2013-04-01
<arsson> sooo how do i get mir working?
<arsson> now i get only black screen when running mir
<alf_> arsson: http://unity.ubuntu.com/mir/
<arsson> already done that
<arsson> i have nvidia card geforce gt420 and nouveau drivers. maybe it's that.
<alf_> arsson: could be... do you get a black screen when running a sample client, or are you trying to run an X session over mir?
<arsson> i go to lightdm and press ctrl+alt+f1 login and run mir
<arsson> i don't know how to run any demos
<arsson> but if i run mir in terminal it says like this  ERROR: /build/buildd/mir-0.0.2bzr543raring0/src/server/graphics/gbm/gbm_display_helpers.cpp(278): Throw in function void mir::graphics::gbm::helpers::EGLHelper::setup_internal(const mir::graphics::gbm::helpers::GBMHelper&, bool)
<arsson> Dynamic exception type: boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >
<arsson> std::exception::what: Failed to choose ARGB EGL config
<arsson> n i don't understand any of that jiberish
<arsson> alf_ any idea?
<alf_> arsson: sounds like a nouveau issue
<alf_> arsson: I haven't had this on either radeon or intel
<alf_> arsson: can you build https://github.com/robclark/kmscube and see if that works in a VT?
<arsson> http://www.phoronix.com/scan.php?page=news_item&px=MTMxNzg  Right now Mir is said to only work with the Intel and Radeon open-source graphics drivers, but evidently is not yet working for Nouveau. In terms of binary drivers supporting Mir, Canonical claims to be pressuring AMD and NVIDIA to support it, but that will likely be quite some time until those blobs make the changes to fully support EGL and other requirements.
<arsson> i really don't how to succesfully build anything if there is no good instructions and i'm finnish so english is a bit hard for me.
<arsson> and when i install close source drivers unity disappears and other desktops too. only wallpaper is visible
<hikiko> hello
<hikiko> I was trying to write an example program using gbm to get sure that it can be used under X and I was getting compile errors from libdrm (drm.h) I've done some modifications (added some parts of the freebsd drm.h that were missing) and now it works but I don't know where to submit my patch... any ideas?
<alf_> hikiko: can you pastebin the diff?
<hikiko> alf_, i just saw that the latest version has a fix
<hikiko> in drm.h you need to use an #if defined(_cplusplus) in drm_buf_map because void *virtual; will give you a compile error
<hikiko> #if defined(__cplusplus)
<hikiko> 	void __user *c_virtual;
<hikiko> #else
<hikiko> 	void __user *virtual;		/**< Mmap'd area in user-virtual */
<hikiko> #endif
<hikiko> something like that
<hikiko> but latest libdrm here: http://dri.freedesktop.org/libdrm/
<hikiko> has the macro
<hikiko> which version of libdrm you use?
<hikiko> I wonder if it is safe to compile the 2.4.43
<hikiko> http://paste.ubuntu.com/5667425/ alf_ that's the error without the change (using the installed drm.h)
<alf_> hikiko: We are using whatever comes with raring devel (currently 2.4.43)
<hikiko> :s
<hikiko> I should have the same version then :s
<alf_> hikiko: I wonder why we don't get a build error for that in mir...
<hikiko> maybe because mir includes the xf86drm.h
<hikiko> ah no it includes drm.h as well so we should get the error
<hikiko> but we don't :s
<hikiko> the most strange is that if I do apt-get source libdrm-dev I get the latest fixed drm.h but my /usr/include/drm/drm.h is different
<hikiko> :/ it seems that there are 2 drm.h :p my mistake... drm/drm.h has the bug and libdrm/drm.h is the correct from libdrm-dev :p i was using the system's drm.h
<hikiko> ok alf_ my mistake... there are 2 drm versions but mir uses pkg-config and gets the libdrm which doesn't have the bug :) i used pkg-config in my makefile and now my test uses the non-buggy header, sorry :)
<alf_> status: Finished iteration-0 of vt-switching, have hacky working code locally... up next proper design for this
<kdub> status, finishing up the hwc 1.1 branch and starting work on the framebuffer native window for android (deprecating the code we're using now)
<kdub> alf_, what if i rename mga::FBFactory to mga::DisplayFactory and rename mga::DisplayFactory to mga::DisplayAllocator
<alf_> kdub: The confusion comes from "Display", so I am not sure if this is going to be any clearer
<alf_> kdub: Is there a different way to express (HWC|Android)Display?
<kdub> those classes implement mg::Display though
<alf_> kdub: ahh, you are right
<kdub> i do agree though that the mga::FBFactory just uses "FB" because its a word that just sort-of fits there
<alf_> kdub: in light of this, DisplayAllocator seems much better
<alf_> kdub: although, I guess its only purpose is for testing? (e.g. your comment in the MP)
<kdub> cool
 * kdub goes to change it
<racarr> Morning
<racarr> status: *squitns at monitor while holding one hand over light*
<racarr> actual status: Iterating on inprocess-egl soon, reviews, etc.
<kgunn> racarr: homeless guy was wrong...i heard Easter happened yesterday
<ogra_> depending on your country it is also happening today :)
<ogra_> (i.e. germany has  easter monday ... national holiday ...)
<smspillaz> ditto australia
<racarr> kgunn: I'll let him know ;
<racarr> )
<kgunn> racarr: i saw kdub/alang gave a pretty exhaustive review...think this will be the week for inprocess egl to land once those are addressed?
<kdub> alf_, name changes pushed
<alf_> kdub: ok
<racarr> kgunn: Should be :)
<kgunn> racarr: awesome!
<kgunn> racarr: so do you have (or plan to have a test) that runs 2 clients at once...one with its own buffs vs mir provided? (just thinking of a nasty test)
<racarr> kgunn: With it's own buffers?
<racarr> What kind of client do you mean
<kgunn> was thinking shell-like
<racarr> they get mir provided buffers just via
<racarr> inprocess communication
<racarr> hmm testing 1 in process and 1 out of process though...no...it has been tested but we don't really have any
<racarr> integration tests that call in Mesa as well
<racarr> ICE's...ugggh
<racarr> iterated on enable-inprocess-egl
<racarr> making tea then back to receive-input-in-clients
<kgunn> racarr: is it worth it to add such a in/out of process simultaneous test...guess, with qt everything should be in process...so, not that interesting
 * kdub just discovered you can link blueprints to branches...
<kdub> kgunn, is that something that's helpful to do?
<kgunn> kdub: i like linking stuff....i think more helpful than not
<racarr> Let it grow is the best song for test driven refactoring: https://www.youtube.com/watch?v=hxUD2IX1UfM
<racarr> (just to settle that question ;))
<racarr> (https://www.youtube.com/watch?v=8KbW6UWFrCk of course being the second best song for refactoring)
<racarr|lunch> Back soon!
<racarr> Cleaned up and iterated on receive-input-in-client and enable-inprocess-egl did some reviews and doxygen and blabla
<racarr> Guess I am going to work on a non hacked together branch of Qtubuntu with input that works on Mir :)
<racarr> kdub: Is      bzr branch lp:~kdub/aal+/ubuntu-platform-mir  the most current version of ~kdub/ubuntu-platform-mir
<racarr> I need ubuntu-platform-mir now XD so I was going to do it
<racarr> and was trying to find wher ethe launchpad branches moved and found this
<kdub> racarr, yeah, thats how I switch out surfaceflinger from the ubuntu touch demos
<racarr> Ok great!
<kdub> i won't say its perfect though :)
<racarr> I have a likely even more hacked together version
<racarr> for running qtubuntu to test input
<racarr> so I will combine them and make something
<kdub> racarr, cool. the branch you reviewed there (thanks btw) should run on nexus 4 with no screen problems
<racarr> :D
<racarr> I wish I could test it...nexus 4 had an incident with the washing machine
<racarr> down to nexus 7 atm
<thomi> Hey everyone
<robert_ancell> thomi, hello
<thomi> building glmark for mir....
 * thomi crosses fingers
<RAOF> Woot
<thomi> ugh
<thomi> now I'm super-confused, perhaps someone can un-confuse me a bit...
<thomi> the branch alf_ mentioned in his email (lp:~mir-team/glmark2/mir) doesn't contain the mir-* flavours he mentioned.
<thomi> but lp:glmark2 does.
<thomi> yet his email seems to indicate that active development is happening in the mir-team branch.... and it doesn't merge cleanly with glmark2 trunk either
<thomi> so.... which branch am I supposed to be building?
<poseidon> http://unity.ubuntu.com/mir/md__h_a_c_k_i_n_g.html says mir won't work on systems with nvidia cards (under running mir), is this correct?
<RAOF> poseidon: No, that's incorrect, although you do need to be using the (default) nouveau drivers. *XMir* won't currently work on nvidia systems because we haven't patched nouveau for it yet, but XMir's not currently working anyway :)
<RAOF> thomi: WHere's lp:glmark2?
<RAOF> Oh, whoops. Missed the '2'
<thomi> oh good, that makes sense then :)
<thomi> my current strategy is to try and build lp:glmark2 and ignore the other branch
<RAOF> Looks like alf_'s Mir work is already merged into lp:glmark2
<Darxus> Yup.
<thomi> which is odd, since that was merged *before* he sent the email on mir-devel
<thomi> ahh well
<thomi> I'll just ignore it, and build trunk
<Darxus> RAOF: Are you doing some of the work on xmir?  Do you think that's likely to be a useful reference for finishing the xwayland stuff?
<RAOF> Darxus: It's in the same problem-domain as XWayland, yes. At the moment we're targetting a full root-window-full server, though, so I don't think we're (yet) hitting the most difficult bits.
<RAOF> Although we might run into and solve system-compository problems before xwayland.
<Darxus> That makes sense, thanks.
#ubuntu-mir 2013-04-02
<thomi> RAOF: I'm having problems building glmark2 in a chroot - it complains about not being able to find the 'gl' package - that should be provided by libgl1-mesa, right?
<RAOF> thomi: Which mesa are you using? There was a version of mesa in the PPA which was broken. You need libgl1-mesa-dev installed.
<RAOF> thomi: (It's been brought to my attention that not everyone knows about apt-file - if this describes you, then âapt-file search gl.pcâ will tell you what package contains gl.pc)
<thomi> RAOF: that's what it's installing...
<thomi> RAOF: I wonder if you could scan over this? http://pastebin.ubuntu.com/5669187/
<thomi> I'll try and get that waf log
<RAOF> You might need the newer mesa - I take it the PPA hasn't yet managed to build the mesa branch?
<thomi> no, I think Martin sent you an email about that?
<thomi> RAOF: I tell a lie - I built and pushed it manually last week
<thomi> so there's a a mesa package in the PPA from 28/03
<RAOF> thomi: Oh, right. It just doesn't have the version I expected
<RAOF> Hm
<thomi> RAOF: it's using the version I built last Friday
<RAOF> Yeah. I just expected that to be called +mir3
<thomi> RAOF: so it turns out that gl.pc exists in the chroot
<RAOF> thomi: Are you able to get /tmp/buildd/glmark2-2012.08+266+13/build/config.log ?
<thomi> RAOF: yeah, just figured out what the issues is:
<thomi> it needs the xcb-dri2 package
<thomi> which isn't a build-dep
<thomi> :-/
<RAOF> Hm. That would be a bug in libgl1-mesa-dev, then.
<RAOF> A development package should always depend on all the other development packages required to use it.
<thomi> want me to file a bug?
<RAOF> thomi: Yeah, thanks. It's probably only a problem in the Mir mesa package so far, though.
<RAOF> Bah! GCC's libstdc++ doesn't implement list.erase(const_iterator it) as specified by C++11.
<duflu> RAOF: It does implement that erase. I have used it for years. You mean the version that returns an iterator? That one is uncommon
<RAOF> duflu: Hm. My g++ failed to find it, and http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011 suggests that it's not implemented.
<RAOF> duflu: Perhaps you're thinking of list.erase(iterator it)?
<duflu> RAOF: Maybe
<duflu> Though it would make sense to use a non-const iterator, kinda
<RAOF> Yeah, kinda. C++11 standard says it takes a const_iterator, though.
<RAOF> (As does list.insert(const_iterator it))
<RAOF> Which also makes sense, as they don't modify any list elements.
 * RAOF wonders whether the valgrind tests _really_ need to take 7 minutes
<robert_ancell> racarr, hey, got an input question. How do I intercept alt+ctrl+Fn in the current server? Is that possible?
<RAOF> I'm unsure...
<RAOF> duflu: When you throw() in the edge-types merge proposal, is that caught somewhere sane?
<duflu> RAOF: Yeah it's caught well below that. In an existing location at above the frontend. I forget where. The tests cover it
<RAOF> Cool. That merge looks reasonable to me, then.
<duflu> RAOF: It's usually a good indicator of efficiency, how well your code runs under valgrind. Valgrind is a good analog of a "slow machine" which we should be able to support. So yeah, 7 minutes is way too much
<duflu> Valgrind, particularly, shows you where your code is CPU-bound.
<smspillaz> RAOF: duflu the only reason why those valgrind tests would take 7 minutes is because you have to set up and tear down valgrind all the time
<smspillaz> code under valgrind is supposed to run about 5x slower in the best case
<RAOF> Doesn't valgrind interact poorly with highly threaded code, too?
<smspillaz> *shrug* maybe
<smspillaz> but I know that tests taking forever under valgrind is likely to be a direct product of the valgrind startup cost
<smspillaz> considering the fact that your unit tests probably run in half a second and your integration tests maybe run in 20 seconds tops
<smspillaz> add n * valgrind startup and it gets expensive fast
<duflu> 5x slower would be fine. But the several orders of magnitude we see, not so fine
<smspillaz> I've been thinking recently the maybe the best way to do the tests is to create static libraries linked to libgtest with all of your tests and then link them together into a single binary for each main () that you wish to provide (eg gtest_main, xorg_gtest_main etc)
<smspillaz> if you want to valgrind / callgrind / whatever your tests, it means that you only need to run valgrind once per binary as opposed to once per test
 * smspillaz has been working on a little thing that would effectively do just that
<duflu> Ooh, sorry. Yes. Valgrind startup is an artificially slow bottleneck. We should ideally not be starting new processes all the time
<smspillaz> yeah
<smspillaz> its my one gripe with ctest's ExperimentalMemCheck target
<robert_ancell> RAOF, you should probably approve your use-dma-buf MP - it's marked as needs fixing by you
<RAOF> robert_ancell: No-one else has reviewed it.
<RAOF> Oh, ahem.
<duflu> smspillaz: I still intend on resolving that Compiz branch madness when didrocks says I can
<duflu> Last I checked, the diff was small
<smspillaz> duflu: didn't didrocks say you could ?
<duflu> smspillaz: He said wait a little
<smspillaz> I'm pretty sure you got the "go for it" like a month ago now :p
<duflu> He was "busy"
<RAOF> robert_ancell: And to answer your question, no, I don't think you can get alt+ctrl+Fn in the X server.
<duflu> It's ridiculous because the diff was only 160 lines when I last checked
<smspillaz> duflu: why would there be a diff for changing a branch name ?
<RAOF> robert_ancell: Except it just occurs to me that this is not what you were actually asking :)
<robert_ancell> RAOF, in X? I mean intercept it inside /usr/bin/mir
<duflu> smspillaz: You need to merge the "raring" and "0.9.9" branches first. They differ
<smspillaz> oh right. I believe that was intentional
<robert_ancell> RAOF, I was trying to work out why I wasn't getting the VT signal on my VT branch, then I realized that of course nothing would be grabbing the key combination
<smspillaz> the diff is much larger now
<duflu> Awesome-bloody-tastic
 * duflu -> coffee
<smspillaz> duflu: the "raring" branch was basically the great-distro-strategy to cut off myself and mc-return so they could cherry pick everything
<smspillaz> because you know
<smspillaz> cherry picking always results in more stable code
<robert_ancell> duflu, can you see if https://code.launchpad.net/~robert-ancell/mir/frontend-class-renaming/+merge/156430 seems like an improvement to you?
<smspillaz> I don't understand it when people think they know better than the maintainers ...
<RAOF> Because the common case is that we _do_ know better than the maintainers :)
<bschaefer> smspillaz, welll we are suppose to fix that raring branch, as it was a mistake from what I understand...
<RAOF> (Because we often have significantly different goals to the maintainers)
<smspillaz> RAOF: sure, you have different goals
<smspillaz> my point is that cherry-picking tends to do more harm than good, especially the kind of cherry picking focused on "lets get the fix without the refactoring"
<smspillaz> unless you have a very detailed knowledge of that codebase to understand why that might be a good idea
<duflu> bschaefer, smspillaz: Yeah no need for anyone to get angry or worry about it. We have consensus that it should and will be resolved
<smspillaz> I'm not angry at all :)
<bschaefer> duflu, yeah, its on the heap, but someone has to do it, and Ill be poking around to see what needs to be done soon ...
<duflu> bschaefer: I'll do it as soon as didrocks says I can. In fact, I might do the parts that don't interfere with anyone's work soon
<bschaefer> duflu, well its always nice to learn :), I just got caught up with that 100 scopes thing last week and didn't get around to it
 * bschaefer thinks its green lighted atm
<duflu> smspillaz: Also, it's not about who knows best or being picked on. It's a matter of we should have branched earlier to give distro stabilization time and you somewhere to land new stuff without worrying distro
<duflu> bschaefer: It was agreed by everyone but didrocks explicitly asked me to wait
<smspillaz> duflu: I wasn't interested in landing anything new that wasn't going to affect distro
<smspillaz> why would I work on a dead end?
<bschaefer> duflu, oo, didn't know that, I can poke him tomorrow morning as well about it :)
<bschaefer> smspillaz, to learn!
<smspillaz> I have other projects where I can do that
<duflu> smspillaz: That dead end is the only complete and functional desktop we have for now. It's no dead end (yet)
<bschaefer> smspillaz, very much so :)
<smspillaz> *shrug* if distro wanted to branch early ... they really could have just asked
<smspillaz> that being said, they've already done it
<duflu> Yeah, just /wrong/
<duflu> Never mind. I'll fix it
<smspillaz> and needless to say, upstreams should be following the freeze process anyways
<smspillaz> so there shouldn't even be a need for a branch
<duflu> robert_ancell: Looks like some things I was thinking about. Will get to it
<robert_ancell> duflu, ta
<RAOF> Urgh. Git's UI is a fractal of horibleness.
<RAOF> When can I stop caring about Quantal?
<duflu> RAOF: When you absolutely have to...
<duflu> RAOF: Or after I upgrade my desktop ;)
<tvoss> alf_, ping
<alf_> tvoss: pong
<tvoss> alf_, did you see thomi's mail to mir-devel? Is the branch he is looking at the current one?
<alf_> tvoss: hmm, I thought I pushed the right branch, trying to push again...
<tvoss> alf_, ack
<alan_g> tvoss: ping
<tvoss> alan_g, pong
<tvoss> alan_g, no invite arriving in my inbox
<alan_g> tvoss: looking...
<alan_g> tvoss: ... - it says you've been invited. Hang on.
<tvoss> alan_g, thx
<alan_g> tvoss: just removed and re-added you
<tvoss> alan_g, thx
<arsson> is there any other packages that needs to install manually that mir require?
<alan_g> arsson: is your context not covered by http://unity.ubuntu.com/mir/?
<arsson> i have done everything what told there but i only get black screen when running mir
<alan_g> arsson: That's what I'd expect - unless you also start a client application that puts something on the screen
<arsson> ok... i'm stupid so how do i do that?
<arsson> example?
<alan_g> arsson: something like: ./mir & sleep 1 && ./mir_egltriangle & sleep 8 && kill $(pidof ./mir_egltriangle) & sleep 1 && kill $(pidof ./mir)
<arsson> i have only run command ($~ mir)  do i need to type something else that start unity desktop with mir?
<alan_g> arsson: are you thinking that mir is a finished product? It is a library in development and will be used by a *future* version of unity.
<arsson> no but i'm exited and anxious
<racarr> Morning
<alan_g> racarr: afternoon
<racarr> alf_: Re: enable-inprocess-egl
<racarr> did you apply the mesa patch mentioned in the comments for the branch
<racarr> err
<racarr> this patch is incorrect
<alf_> racarr: I didn't apply it
<racarr> alf_: Posted a new one
<racarr> it's necessary otherwise the
<racarr> DRM EGL backend conflicts with the mir one
<alf_> racarr: thanks, I will try it out
<racarr> alan_g: Left some comments on receive-input-in-client (+ updates)
<alan_g> racarr: will look...
<alf_> racarr: It doesn't seem mir_toolkit/mesa/native_display.h is installed by make install
<dharmaone> missed the session :( this might have been answered already - will existing ubuntu apps work on new versions of ubuntu that use QT and mir - or will they have to be rewritten?
<tvoss> dharmaone, depends on the toolkit support for Mir, but in general: you don't need to rewrite your app to run against Mir
<tvoss> dharmaone, I think the session was recorded and you can watch it on youtube
<kdub> morning folks, status, began working on our own framebuffer native window for android
<dharmaone> ok :) what about current apps that are not written with QT - will they have to be rewritten? (not really mir related)
<tvoss> dharmaone, again, toolkit dependent, but in general no :) the point is that an app hardly ever should know about the underlying display server
<alf_> status: reviewing, bug fixing, thinking about main loop
<tvoss> dharmaone, there might be some apps that are tightly coupled to X for one or the other reason. Those will be supported by an in-session, on-demand rootless X server that talks to Mir (much like in OS X)
<tvoss> dharmaone, http://youtube.com/ubuntuonair
<racarr> status: Made some updates to branches. Did some review
<racarr> worked on new version of qtubuntu and ubuntu-platform-api-mirclient yesterday and produced some working code
<racarr> going to go through and see if there is anything else I need to do right now and if not work on those some more
<racarr> (goal: Qt backend against Mir with input:))
<racarr> Anybody need some help or review or anything?
<alan_g> racarr: quick hangout?
<racarr> alan_g: Sure
<racarr> gcalling you
<racarr> alan_g: I can hear you just a sec
<racarr> tvoss: Made some comments on QtUbuntu stuff and input/platform-api, etc here https://bugs.launchpad.net/mir/+bug/1163393
<ubot5> Launchpad bug 1163393 in Mir "qmir does not support input" [Undecided,Confirmed]
<racarr> (we talked about this briefly in the past and you said you would think about it :))
<racarr> talked about using this approach of abstraction through the platform api
<tvoss> racarr, will look into it, thanks for the pointer
<kdub> alf_, updated hwc-integration :)
<kdub>  sorry to be a bother about it :P
<alf_> kdub: no worries, unfortunately I found a couple of naming nitpicks (see comment), but I will pre-approve to unblock you since I don't have anything else
<kdub> alf_, thanks, will take care of those
<racarr> going to make android input stack compile in clang
<racarr> many of the more confusing errors seem to be about the boost asio based looper which we are dropping anyway :)
<racarr> /home/augustwest/src/mir/mir/fix-input-build-clang/cmake/src/mir/mir_discover_gtest_tests.cpp:(.text+0x12b3): undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)'
<racarr> infinite erros around this line now...
<racarr> libandroidinput.so actually links :)
<racarr> ok er building clang from trunk doesn't work either for me
<racarr> -DCMAKE_CXX_COMPILER=/usr/bin/clang -DCMAKE_C_COMPILER=/usr/bin/clang -DMIR_DISABLE_INPUT=true
<racarr> how should it work?
<racarr> How can I see the options that the jenkins clang build uses?
<racarr> MIR_DISABLE_INPUT=true does not seem to be the same as MIR_DISABLE_INPUT=ON but both will stop libandroidinput.so from building ;)
<racarr> oh maybe that wasn't it. Looks like clang behaves differently invoked as clang++
<mpt> tvoss, hi. The phone calls for "Accessibility controls for visually impaired". So for starters, I'm thinking of speccing an "Invert black and white" setting. Does that sound feasible for Mir on the phone?
<racarr> alan_g: https://code.launchpad.net/~robertcarr/mir/fix-input-build-clang/+merge/156634
<racarr> It turns out it was trivial :)
<racarr> I mean unit-tests fails but it builds!
<racarr> and I think unit-tests failed anyway
<mpt> tvoss, i.e. composit (composite?) such that for every pixel, the value is reversed, while the hue and shade stay the same.
<mpt> (Compose!)
<tvoss> mpt, hey there :) I think it's better if you check with kgunn and robert_ancell on Mir specifics, but in general, I think it should be possible to apply a custom shader to the final composited image that inverts colors
<mpt> ok
<kdub> mpt, right. mir can do it, its more a matter of feature scheduling as to when
<mpt> kgunn, what do you think? ^^^^
<kdub> although mpt, contributions are welcome :)
<mpt> kdub, the contribution I am instructed to make is to design the settings :-P
<alan_g> racarr: do you understand the need for "mt::" in tests/integration-tests/input/android/test_android_input_manager.cpp? The rest looks obvious
<kdub> mpt haha, just trying to remind the rest of the channel that we are open :)
<mpt> kdub, fair enough. I've had good, though unpredictable, results from publishing UI designs for wishlist features.
<kgunn> mpt: i'd say let's capture it in a bp...
<kdub> mpt, yeah... i can see that they would be tricky to convey widely
<mpt> hmm
<kgunn> mpt: is this a "just capture it" query....or is there a pressing thought behind it
<mpt> kgunn, the comically misnamed "Unity API" team has the job of implementing settings UI. So in designing that UI, I need to find out which settings are likely to actually exist. Bad to have UI for a setting without the setting, and (to a lesser extent) vice versa.
<kgunn> mpt: :) sure
<racarr> alan_g: Yes the namespace {}
<mpt> kgunn, excuse the ignorant question, but is display brightness handled by the display server, or is that at a lower level?
<racarr> makes it a seperate instantiation of the function for each
<racarr> include
<racarr> so the functions become "unused"
<racarr> which is an error with our clang settings
<racarr> well they become unused by people who include mock_event_filter but don't use the matcher
<racarr> translation units blablablabla
<racarr> :p
<alan_g> racarr: Great
<kgunn> mpt: great question actually....brightness for sure will have a low level element to it...but the question is, should mir abstract that sort of thing away
<kgunn> tvoss: ^   my gut says...probably a server side shell interaction w mir?
<tvoss> kgunn, I think it's partly a setting but there needs to be a post-process step for the compositor ... at least htat's my gut feeling
<mpt> The only reason I ask is to know whether it should be in the same blueprint
<racarr> alan_g: Fixed the whitespace here too https://code.launchpad.net/~robertcarr/mir/receive-input-in-client/+merge/155368 (r619 will take a sec to refresh)
<alan_g> racarr: seems like a conflict now. But I'll change my vote anyway
<kgunn> tvoss: post process for brightness?...hmmm, i suppose you could have both true hw (backlight) brightness & sw (backlight compensation)
<kgunn> mpt: i'll capture both
<racarr> alan_g: Thanks :) fixing conflict now
<kdub> racarr, fix-input-build-clang reminded me that if we need to disable input, we could do that via a server config
<kdub> still trying to get rid of compile options :)
<racarr> kdub: That's the goal for fix-input-build-clang!
<racarr> will propose a branch to disable MIR_DISABLE_INPUT later today
<kdub> racarr, great :)
<tvoss> kgunn, hmmm, I was more or less thinking about color inversion
<racarr> alan_g|life: Have a good evening :)
<kgunn> tvoss: just to make sure we're talking about the right things...mpt had 2 distinct questions...
<kgunn> 1 about color saturation (like an effect)
<kgunn> 1 about brightness
<racarr> I think, from the perspective of what we can do, we can say that we can apply any sort of shader effect to any subset of the scene graph (including the final image)
<racarr> but it doesn't necesssarily mean postprocessing
<racarr> for example, color inversion, should likely be done in the first rendering pass, rather than say rendering to an FBO and postprocessing
<racarr> oh just saw the original question now
<kgunn> racarr: well....maybe, it might actually be cheaper to post process (depending on # of layers etc)
<racarr> is it feasible for mir on the phone
<racarr> Sure!
<racarr> kgunn: No. You always have to render each visible thing once
<racarr> so the question is, do I render it once directly onscreen with a shader to invert the colors
<kgunn> racarr: dirty region tracking?
<kgunn> racarr: i was thinking setting changed...you got lots of surfaces
<racarr> or render it offscreen, then take the final composited image and render it with a shader to invert the colors
<kgunn> racarr: but those surfaces might be visually static
<racarr> oh maybe, that's true when the setting
<racarr> changes
<racarr> we don't want to be rendering offscreen for postprocessing in anticipation of settings changing though
<kgunn> racarr: no not at all
<racarr> if we already are rendering offscreen though! the effect probably should be postprocessing
<kgunn> racarr: keep it all dynamic....but build it in such a way you could "postproc" conceptually
<racarr> Mm
<kgunn> racarr: and...i consider semico hw goodies as postproc conceptually
<kgunn> e.g. they might give you a slick way to do this to the fb
<kgunn> for cheao
<kgunn> oops/cheao/cheap
<racarr> mm
<racarr> some are.
<racarr> I think of the line where postprocessing begins as when the fragment shader emits a fragment
<racarr> but who knows why :) thats just something I made up
<racarr> XD
<kdub> kgunn, i think there are, but they'd have to move to support it in hwc if they want it
<kgunn> kdub: yep
<kgunn> kdub: racarr ....for sure, either gles or hwc would be the postproc houses....and no we shouldn't build ineffeciency in just in case of a potential savings, but we shouldn't prevent using something cool either, e.g. keep it dynamic (not just flexible)
<racarr> I understand :)
<racarr> mpt: It's interesting to think about what to support perhaps besides
<racarr> inversion...I know it's not unheard of for windows/osx users (and some people through a compiz plugin)
<racarr> to use a few other kind of color filters for various forms of color blindness
<racarr> or i.e. I remember someone in the compiz forums ages ago worked in astronomy of some such and requested a red light only filter (to not affect his night vision as strongly)
<racarr> ...apparently I am in full on attention-deficit-mode this morning. *runs around*
<kgunn> mpt: racarr this was a good topic....made me think about backlight compensation....a very big deal in mobile
 * kdub thinks we could root ID out of mc::BufferSwapper
<kdub> with the post processing effects, i think its safer to rely on gles for them primarily, and then build it dynamic enough that we can use either gles or a special route
<kdub> with alpha being the quintessential effect with 'special routes'
<kgunn> kdub...ack...gles is the fundamental functional baseline, makes sense
<tvoss> kgunn, ah, for brightness, it's a system/shell setting
<racarr> kdub: I feel like I flipped back and forth maybe on whether rooting ID out sounded like a good idea
<racarr> but it sounds good today!
<kdub> racarr, we did, i remember the situation pointedly :) the last thing that I remember was that the interface was something to fix later
<kdub> and my android server window work is making me rethink the interface a bit
<kdub> i'll mp separately so it can get a thorough review though, once thats done
<racarr> ok
<racarr> kdub: Is resizing still in your head?
<kdub> it is! i was just going to suggest a blueprint related to it to kgunn actually
<kgunn> kdub: like a new one....or just add to an existing...i was going to put a couple of bullets in mir-converged
<kdub> kgunn, i prefer new blueprints with 2-4 day long task segments... makes me feel like i'm reporting enough :) resizing will be a multiple-landings-required sort of task
<racarr> kdub: Oh great :)
<kgunn> kdub: what a good title? supposing its more than just resizing?....i need to check the other bp's as we might have had this already
<racarr> early morning -> early lunch bbs
<thomi> morning
<UbuPhillup__> thomi: hi
<racarr|lunch> Morning thomi
<thomi> hey everyone, what's up?
<racarr> Man I love lunch
<kgunn> kdub: sorry if you answered...my network has been blinking today
<kgunn> kdub: but what would be a good title for the resize work?
<kgunn> meaning, does it cover rescale? surface moves etc ?
<kdub> kgunn, hmm.. maybe something like
<kdub> "fixed client buffer resize" where fixed is added to emphasize that we resize buffers to a known size
<kdub> and provide feedback much like we do now with the box outline of the size the client will be resized to
<kgunn> kdub: so is it more like resize to a phys dev/screen? rather than an app-window resize ?
<kdub> kgunn, no, we're talking client resize
<kgunn> kdub: got it, sorry, to keep digging...what about rotate? & moves? or are those seperate topics
<kdub> kgunn, its something a bit down the road
<kdub> but i consider those separate topics
<kdub> my fbnativewindow work led me to want to refactor a funky interface we have
<kdub> and i'm refactoring in a way that is friendly to the future of mir resizing client buffers
<thomi> woooo! got glmark2 running on mir :)
<thomi> hmmm, either my brain is broken, or some of these tests aren't too happy on mir
<kgunn> thomi: what are you running them on ? hw wise?
<thomi> it's the QA testing laptop, which has 4GB ram, and an intel graphics chipset... when glmark2 finishes I can get the exact specs
<thomi> it's an "Intel Ivybridge mobile" - whatever that means
<kdub> racarr, quick review when you have a chance? https://code.launchpad.net/~kdub/mir/fix-hwc-test/+merge/156669
 * thomi needs more coffee, brb
<racarr> kdub: Will soon :) Just finishing up some refactoring on inprocess-egl
<racarr> kdub: +1
<kdub> racarr, thx
<kgunn> robert_ancell: morning
<robert_ancell> kgunn, hello
<kgunn> robert_ancell: we had a couple of interesting topics...
<kgunn> mpt pointed out a feature to have settings (as in system) to put your composed fb in a "color mode"
<kgunn> think saturation or sepia or some such
<kgunn> then we started talking brightness....which lead to a discussion on hw vs sw, and fb post processing
<kgunn> at any rate...i added about 4 work items to mir-converged
<kgunn> altho conceivably we'll need brightness control on phones
<robert_ancell> kgunn, ok cool. What's the use case for the "colour mode"?
<kgunn> robert_ancell: visually impaired
<kgunn> so like black / white invert
<kgunn> or no blue/grey combos
<kgunn> red/green
<robert_ancell> kgunn, ah. Traditionally that's been done via themes - is a global method considered better?
<kgunn> color blindness
<kgunn> global - i guess so, that way nothing gets thru
<racarr> kdub: I can't crosscompile anymore because the chroot creator can't find a package for libhybris
<racarr> where am I supposed to be getting it from?
<kgunn> you have a more uniform experience
<robert_ancell> yeah, sounds like the easiest method.
<kdub> racarr, the phablet-ppa . i sent out the line in the email about the hybris update
<kgunn> then kdub & i have been talking about addressing client resize....
<kgunn> i thot we already had that in a bp (was just looking now)
<kgunn> if not, he was wanting to tackle...anativewindow stuff allowed him to potentially refactor for resize in mind
<kgunn> (but i wondered if duflu might have had it on his plate?)
<racarr> kdub: Got it :)
<robert_ancell> kgunn, should be in mir-converged I think. I think we decided it wasn't needed on a phone
<kdub> i guess mir-converged is what i meant by 'down the road' earlier
<kgunn> kdub: and yes, it is in there
<kgunn> kdub: robert_ancell ...will we really not need it for phone ?
<kgunn> i suppose any resize due to a ui animation/transition would be hidden from client
<robert_ancell> kgunn, In San Mateo we couldn't come up with a case where it was required, but we should revisit that if we can think of one
<kdub> i agree with robert_ancell that its probably not critical for phone for a while
<robert_ancell> kgunn, kdub, I think it is a good target of opportunity to implement early if there's no higher priority work
<kgunn> kdub: is there a convenience factor to it for you....e.g. you're mucking around it, may as well address it?
<kgunn> robert_ancell: kdub is so awseome he completed the nexus4 bp :)
<kdub> kgunn, not really, i'll just leave the door open for resize in what i'm doing now
<robert_ancell> kdub, \o/
<kdub> yay :) i'll try to make a video for our weekly email
<kgunn> kdub: cool!
<kdub> robert_ancell, kgunn, in mir-converged, can I assign 'window resizing' and 'mir on mir' to myself?
<kgunn> kdub: if you're feeling froggy :)
<robert_ancell> kdub, absolutely
<kgunn> racarr: so i was thinking (danger)...
<kgunn> if you get qt backend w. input working...could we sloppily put unity next on it?
<kgunn> maybe a trimmed version
<racarr> well thats the plan eventually but this is out of process Qt
<racarr> in process Qt is working too but no
<racarr> in process Qt with input yet (thats kind of nextish after all the existing stuff lands...i.e. thursday?)
<racarr> Then there is the branch for running the unity stuff out of proces that kevin did
<kdub> which is just client side qt
<racarr> mm
<racarr> using
<racarr> Well using all the phablet input stuff
<racarr> not the mir stuff
<racarr> kdub: https://code.launchpad.net/~robertcarr/mir/remove-mir-disable-input/+merge/156696 exists :)
<racarr> kdub: Want to talk about prepare-for-inprocess-egl soon?
<racarr> hoping for RAOF to show up
<racarr> RAOF: Ping?
<racarr> err by prepare-for-inprocess-egl I mean
<racarr> enable-inprocess-egl
<racarr> flashbacks
<racarr> kdub: Pushed changes to prepare-for-inprocess-egl to use Platform as you suggest
<kdub> racarr, cool
<racarr> kdub: Do you have an idea of how hard it will be to implement for android/a plan? Should I start thinking about it
<racarr> branch as it stands returns (EGLNativeDisplayType)0 ;)
<racarr> oh I guess
<racarr> the native display is the same on android EGL_DEFAULT_DISPLAY
<racarr> but a native window abstraction is needed.
<kdub> racarr, that's sort of what i'm getting into place now with the framebuffer native type
<racarr> ohhhh
<kgunn> robert_ancell: btw...https://blueprints.launchpad.net/ubuntu/+spec/mir-beyond-converged
<kgunn> for stuff that's fringe
<robert_ancell> kgunn, awesome
<robert_ancell> kgunn, check out that dependency tree :)
<kgunn> borg like
<RAOF> racarr: Pong!
<racarr> brb being non violently mugged by the garage door repairmen
<racarr> ok
<racarr> RAOF: Two things I was pinging you abobut actually! need another round of review on receive-input-in-client
<racarr> and enable-inprocess-egl should be almost ready to land so I wanted some feedback on the mesa changes
<racarr> and perhaps to land them in sync
<RAOF> racarr: What are the mesa changes needed to land enable-inprocess-egl?
<RAOF> I thought we'd already landed them?
<racarr> RAOF: https://code.launchpad.net/~robertcarr/mir/enable-inprocess-egl/+merge/155888/comments/342488
<racarr> err that patch is slightly backwards due to git failure the - if (mir_connection_is_valid
<racarr> is against the wrong branch
<racarr> we had landed that as the client library function, mir_egl_native_display_is_valid but then
<racarr> that needs an inserver implementation too and I wasn't sure about
<racarr> implementing client library symbols in the server
<racarr> so there is that
<racarr> then the second two bits are about letting mesa load multiple instances of the dri2 driver
<racarr> for multiple platforms
<racarr> shockingly it seems to work
<RAOF> We've already landed that change, haven't we?
<racarr> I don't think so
<racarr> unless
<racarr> nope doesn't look like it
<RAOF> Ah, right. We've got *some* of that landed.
<racarr> I blogged a blog about what I have been doing lately in mir: http://racarr.me/wordpress/?p=17
<racarr> probably uninteresting to mir team members :p
#ubuntu-mir 2013-04-03
<RAOF> I'm *sure* I've added close() to drm_fd_handler before...
<RAOF> Interesting: http://kentonv.github.com/capnproto/index.html
<duflu> kgunn: Isn't your day long enough already? :)
<duflu> robert_ancell: Can we please have milestones and code on the same series? https://launchpad.net/mir
<duflu> ... one way or the other
<robert_ancell> duflu, as kgunn said, Launchpad won't let us delete the 13.05 milestone. I did manage to delete the 14.04 series by moving the milestone
<robert_ancell> duflu, I've set the 13.05 milestone to inactive, so that seems to workaround LP being confused
<robert_ancell> duflu, solved?
<duflu> robert_ancell: OK, ta. Still need an active milestone > 0.0.2 to link our Fix Committed bugs to
<robert_ancell> duflu, ok, I'll open a 0.0.3
<robert_ancell> duflu, done
<robert_ancell> brb
<tvoss> RAOF, cap'n'proto is indeed interesting, but I have had difficulties figuring out if it's done, yet
<smspillaz> tvoss: oh yeah, I was going to mention that one to you
<smspillaz> saw it on reddit the other day
<RAOF> tvoss: It's not done yet.
<tvoss> RAOF, that's what I thought, too. However, it looks pretty promising. Do we know the author?
<RAOF> I don't, except that he's also the primary author of Google Protobuf
<RAOF> racarr: There doesn't seem to be anything in the EGL specification that prohibits the behaviour your inprocess-egl patch introduces (which is good âº). I'll check that it doesn't indirectly break something.
<tvoss> RAOF, do we have a video of racarr's in process egl work, yet?
<RAOF> tvoss: not afaik
<duflu> mmrazik: Looks like Mir no longer needs -DMIR_DISABLE_INPUT=ON for clang. And we're about to remove that option too. Can we update CI?
<mmrazik> duflu: sure. removing it....
<duflu> mmrazik: Thanks
<mmrazik> duflu: done
 * tvoss thinks that the CI jobs should do twitter, too :)
<duflu> Well, CI output is useful. Twitter is not usually used for useful things...
<duflu> I suppose it could be
<tvoss> duflu, but given jenkins' karma on launchpad, it might be considered a conscious being, and nowadays it's tweeto ergo sum :)
<duflu> Codito ergo sum
<tvoss> duflu, ;9
<tvoss> probaro ergo sum
<smspillaz> duflu: thanks for updating the other mps :)
<duflu> smspillaz: No problem. Accurate MPs and bugs are useful
<smspillaz> alan_g: tvoss: question about unique_ptr. Is doing something like std::unique_ptr <Derived> d (new Derived); std::unique_ptr <Base> b (d); known to work ?
<tvoss> smspillaz, at least, d would need to be moved to b
<smspillaz> tvoss: does that need to happen explicitly? eg std::move () ?
<alan_g> smspillaz: give or take a std::move, yes
<smspillaz> I'm getting this weird problem where even if I do std::unique_ptr <Derived> d (new Derived); std::unique_ptr <Base> const &b (d); seems to not work either and tries to just move it
<smspillaz> which fails
<tvoss> smspillaz, yes, a move has to be explicit
<tvoss> smspillaz, it would need to be std::unique_ptr <Base> b(std::move(d));
<smspillaz> hm
<smspillaz> well, I guess my main problem at the moment is that I can't take a const ref either, and I thought it was something to do with the fact that moving wasn't supported
<smspillaz> hmm, seems to work if I use std::move although that certainly feels wrong
<RAOF> Why does that feel wrong?
<smspillaz> std::unique_ptr <MockFoo> mock;
<smspillaz> * set some expectations
<smspillaz> bar (std::move (mock)) <- expects a std::unique_ptr <Foo> const &
<smspillaz> * how do you set more expectations ?
<smspillaz> the function wants a non-owning reference to the pointer, yet you have to give it the whole pointer
<RAOF> Start with a std::shared_ptr<MockFoo>?
<RAOF> I mean, if you're going to hand references out to it, it's not a unique_ptr.
<RAOF> Oh, whoops.
<duflu> Surely that's why you can only "swap" unique_ptrs. If you could assign them (or even copy by initializer), they'd no longer be unique
<smspillaz> RAOF: well, I don't want shared *ownership*
<smspillaz> duflu: you can move them
<smspillaz> which is effectively like swapping
<duflu> Fairy nuff
<smspillaz> the point is that I don't want to copy or move it
<smspillaz> I want to give a reference to its base
<RAOF> Get a raw pointer out of it and send that?
<duflu> RAOF: That's violating the uniqueness too
<smspillaz> duflu: I want a const &
<alan_g> smspillaz: a reference to base is spelt "Base const&" not "std::unique_ptr <Base> const &"
<smspillaz> alan_g: reference to the unique pointer to the base
<smspillaz> so I should be able to go from
<smspillaz> std::unique_ptr <Derived> d (new Derived)
<smspillaz> to std::unique_ptr <Base> const &b
<smspillaz> because you can do that with shared pointers and it doesn't give out any new ownership
<alan_g> smspillaz: not within the language rules - smart pointers to different types cannont be covarient
 * smspillaz wonders why it worked with boost
<alan_g> or contravarient
<smspillaz> ... probably because there was an implicit copy
<alan_g> smspillaz: c++03 doesn't have move semantics
<alan_g> alf_: Looking at enable-inprocess-egl again got me wondering how(if) we are managing dependencies on bespoke mesa. Should we be ensuring that mesa patches are in the ppa before landing branches that need them?
<alf_> alan_g: I would say the other way around, since mesa depends on the mir API and there is a chance it won't build if we land the mesa change first
<alf_> alan_g: (depends on the details of the change, of course)
<alan_g> alf_: Yeah. Why can't things be simple. ;)
 * alan_g wishes for one big source tree with everything in it . (That also builds quickly.)
<duflu> Hey lp:omniverse doesn't exist yet ;)
<smspillaz> alan_g: hmm, I guess the best option then is to just pass the object by const reference
<smspillaz> and don't make any functions that want a reference to the object a const ref to the unique_ptr
 * smspillaz wishes C++ had rust-like pointers
<tvoss> alan_g, ping
<alan_g> tvoss: pong
<kgunn> alf_: reading you control loop thread again...was thinking, would rotate be an event? (think phone/tablet)
<kgunn> alf_: its sort of like a display reconfig event
<kgunn> anyway....more arguments/use cases for your idea
<alf_> kgunn: thanks, it could be... it depends on how we need to react to it. Perhaps it is just part of the reconfiguration process as you said, but I haven't thought this through.
<kdub> morning
<tvoss> kdub, good morning :)
<alan_g|tea> kdub: morning
 * alan_g remembers to change nick
<alf_> status: Thinking about main loop, working on a main loop prototype (see message in mir-devel thread), reviewing
<kdub> oh yeah, statuses! your nexus 4's now work :) working still on the framebuffer native window type, improving things in the core as I go
<kdub> so if something weird now happens on the nexus4, file a bug about it (in case its been getting a pass on funny functionality until now)
<tvoss> kdub, \o/
<alf_> kdub: now that you mention it, using the latest lp:mir I don't get any screen updates on the nexus 4 :/ I see only the first frame
<alf_> kdub: I will file a bug
<kdub> alf_, thats a good bug :) let me see  if i can reproduce
<kdub> alf_, if you remember, put the version of the phablet image you're using
<alf_> kdub: hmm, perhaps I should update to the latest image first and try again?
<kdub> alf_, the other thing is, make sure surfaceflinger is not running... its very aggressive about restarting
<kgunn> kdub: not if you rename it :)
<kgunn> its your trick....and fool proof
<alan_g> status: reviewing, trying to understand enough bits to spike "hardware cursor"
<racarr> Morning
<alf_> alan_g: @hardware cursor, anything I can help with?
<alan_g> alf_: can we hangout in the morning?
<alf_> alan_g: sure
<racarr> alan_g: Pushed some updates to receive-input-in-client (r622, r623)
<kdub> alf_, i just tried with ubuntu-touch-image 56 (latest build i could find) and lp:mir. seems ok to me
<alan_g> racarr: looking...
<kdub> alf_, actually, i see render_surfaces being weird, but the server seems ok to me. i'll file a bug on that
<racarr> kdub: Processed your comments on inprocess-egl will wok on them later today (maybe we can talk some about names, etc...)
<kdub> racarr, sure, before you set down to change the names, lets figure out what they should be... its annoying to change 2x
 * kdub has been wanting to improve 'inprocess egl' as a name for a while
<kdub> all egl is in a process! :P
<racarr> Except for the great cosmic background EGL that surrounds and binds us all
<racarr> (All praise *3 quick bows*)
<alan_g|EOD> Goodbye all!
<racarr> Good Evening :)
<kgunn> evnin'
<alf_> alan_g|EOD: goodbye
<alf_> kdub: I am still getting the problem with latest image, will check more tomorrow
<kdub> racarr, with input enabled on android, do these errors look sensible for the state of the code? https://pastebin.canonical.com/88338/
<racarr> kdub: Those errors are pretty good yeah
<racarr> I want to work on reporting for droidinput but it's
<racarr> difficult
<racarr> We need a different pattern
<racarr> the Reporter interface for say EventHub alone
<racarr> would have like
<racarr> 40 methods
<racarr> status: Doing a final self review round, etc on receive-input-in-client
<racarr> so hopefully it can land this afternoon?
<racarr> Can someone approve https://code.launchpad.net/~robertcarr/mir/dedupe-null-input-managers/+merge/156645
<racarr> so I can approve https://code.launchpad.net/~robertcarr/mir/remove-mir-disable-input/+merge/156696
<racarr> so I can avoid
<racarr> merging it in to remove-mir-disable-input
<racarr> or a merge conflict later
<racarr> well not a conflict actually
<racarr> just something we have to remember to fix XD
 * kdub is unaware of a rule that you can't tick to approve, granted all the review comments are addressed and you have an approve with no blocking reviews
<kdub> surfaceflinger's rendering portions sometimes looks like a big switch statement based on hwc version
<kgunn> kdub: was just thinking about yesterday - you were wanting to look into resize
<kgunn> i was looking at the bp for mir-phone-iteration-0
<kgunn> seems duflu is doing "client  initiated maximize/fullscreen"
<kgunn> might want to ping him or g+ hangout w him later and see what he's up to exactly
<kdub> kgunn, one can be a dependency of the other
<kdub> i'd imagine that task is more negotiating the request over ipc
<kdub> and then the other half is doing the allocation/deallocation on the server side
<kgunn> kdub: agreed its a subset...just worthy of a 2 minute chat
<kdub> kgunn, sure.. maybe before the mir2 meeting?
<kgunn> kdub: might be early for him
<kdub> i kinda want to write a doc explaining the sometimes-annoying display infrastructure that android has... should that go in our doc/ folder or somewhere else?
<kgunn> our docs, in so far as our implementation accounts for it
<thomi> Hi everyone... Is there an alternative to switching to VT1 to run mir? That's reasonably difficult to automate in a jenkins slave
<thomi> if I don't care that my X session will die afterwards, is there some other way?
<robert_ancell> kgunn, are you meeting today?
<kgunn> kdub: is this that hybris branch https://code.launchpad.net/~rocket-scientists/aal+/ubuntu-platform-api_replace_hybris_hardcoded_path
<kdub> kgunn, https://code.launchpad.net/~kdub/aal+/shared-pthread-poc
<kgunn> kdub: thanks...
<kdub> but we shouldn't be pointing people to it i think, its not really production quality
<kdub> in public docs, i'd say
<kgunn> kdub: right...i was going to pester pat's team :) just needed the stick to poke with
<RAOF> racarr: Ok, EGL. Are you sure that all your changes are necessary? Specifically - the change to src/egl/main/egldriver.c seems both unnecessary and results in a leak.
<RAOF> racarr: Alternatively, could you point me to code that I could test in-process-egl against?
<RAOF> Ok. The fact that our unit-tests now terminate part-way through more often than not is getting annoying.
<kdub> RAOF, what unit tests?
<RAOF> The unit-tests binary.
<kdub> sure :) i mean, which test, within the unit-tests binary is causing trouble?
<RAOF> It's not deterministic; it often crashes between â[==========] 361 tests from 79 test cases ran. (443 ms total)â and listing the total number of passed tests.
<RAOF> I suspect this might be related to why clang-built unit-tests die immediately.
<kdub> hmm, very strange... i haven't seen that behavior on android (yet)
<RAOF> It's almost certainly going to be something thread related.
<RAOF> And, obviously, gtest makes it hard to find because it's a sub-process dying
<RAOF> After I finish addressing these merge reviews I'll see if I can hunt down why clang-built unittests die, and whether fixing that fixes this annoyance.
#ubuntu-mir 2013-04-04
<racarr> RAOF: The second changes are necessary or it only makes one instance of the dri2_drv and the function pointers get overridden between the drivers
<racarr> RAOF: You can test the changes with enable-inprocess-egl and the new example (bin/mir_demo_inprocess_egl)
<RAOF> racarr: Aaah, thanks. Right, yeah, now I can see why the second change.
<RAOF> I think the second change is still wrong, or rather needs additional changes to make it not-wrong :)
<RAOF> But I'll start poking at them now.
<racarr> RAOF: Thanks :)
<thomi> Hey guys - the newer mir packages link to libandroid-input.so, which I don't have. Is this intentional? If so, where do I get that library from, and can we update the mir package to depend on that library please?
<thomi> RAOF: any ideas? ^
<RAOF> thomi: Mir builds that library.
<RAOF> thomi: Oh, but we probably don't install it properly.
<thomi> ahhh, that would explain it.
<robert_ancell> duflu, yay, -zdefs works a treat. Thansk
<duflu> robert_ancell: Cool np
<robert_ancell> thomi, oh, I'm tracking that down right now
<robert_ancell> thomi, it also doesn't link against glog
<duflu> thomi: Yeah barely half the dev team knows how to and does test package builds :/
<duflu> thomi: Bug against mir project please!
<thomi> duflu: sure
<RAOF> GRARGH!
<RAOF> What the hell is causing the tests to abort part-way through with exit status 0?
<RAOF> RUN_ALL_TESTS() is returning prematurely, but successfully.
<thomi> duflu: https://bugs.launchpad.net/mir/+bug/1164253
<ubot5> Launchpad bug 1164253 in Mir "mir links to libandroid-input.so, but does not package it or Depend on a package that provides it" [Undecided,New]
<duflu> RAOF: grep exit ;)
<duflu> RAOF: Or maybe we're handling _too_many_ exceptions
<RAOF> duflu: I broke in exit(); it's getting called at the end of main, after RUN_ALL_TESTS() has returned 0.
<duflu> RAOF: Maybe we just need fflush(stdout)
<duflu> Hmm, no that will be done at exit
<duflu> Bisect!
<robert_ancell> racarr, ping
<duflu> robert_ancell: Forgot to mention I have an appointment after lunch in a few hours. Should not take too long
<robert_ancell> duflu, np
<duflu> robert_ancell: I am also eager to see and approve -zdefs
<robert_ancell> duflu, yeah, will propose once I get it linking to glog correctly
<racarr> robert_ancell: Pong
<robert_ancell> racarr, hey, was wondering why libandroid-input is a shared library?
<racarr> robert_ancell: client and server both use it
<robert_ancell> racarr, but why not just statically link it to both?
<racarr> besides potential difficulties with two copies in the test binaries
<racarr> No reason
<racarr> it feels like it should be a shared library though the way its used between the client and server
<robert_ancell> racarr, it's opened up a number of problems having it installed shared - it doesn't have a unique name, it doesn't have a library version. We'd have to package it separately to the other library packages. We'd have to manage different versions being used potentially by the client and the server
<RAOF> Hm. Something's playing silly buggers with file descriptors.
<RAOF> #4  0x00007ffff6466cab in android::InputChannel::InputChannel (this=0x15580a0, name="TODO: Name", fd=2)
<RAOF> Is unlikely to do anything sensible.
<RAOF> duflu: Do you know offhand what happens when someone close()es stdout under gtest?
<RAOF> :)
<robert_ancell> racarr, what's the two copies in test binaries that you're referring to?
<RAOF> Ah. So, TEST(AndroidInputWindowHandle, update_info_uses_geometry_and_channel_from_surface) first sets stderr to non-blocking mode, then closes it. With, apparently, hilarious consequences!
<duflu> Wow, stupid mistake and also not a test failure
<duflu> Cool
<RAOF> Now I curse C++ for not having a mkstemp-alike.
<duflu> I suspect it does but you really don't want to see it
 * duflu --> doctor
<tvoss> RAOF, ping
<RAOF> tvoss: Pong.
<tvoss> RAOF, good morning :) did you have a chance to have a look at: https://code.launchpad.net/~robertcarr/mir/receive-input-in-client/+merge/155368
<tvoss> RAOF, you are the remaining "needs fixing" :)
<RAOF> I'll do so now.
 * RAOF was working through the mesa changes needed for in-process EGL, but I guess input can preempt that.
<tvoss> RAOF, sorry for pulling you out of something else, but I think we should land the mp, it has been up for so long and Robert has been addressing almost all reviewer comments :)
<RAOF> This is a fair call.
<RAOF> I know how that is :)
<duflu> "almost all" is probably sufficient. We will make better progress if we don't try to reach 100% perfection on every proposal. Just iterate
<tvoss> agreed, the important part of the mp is the end-end test of input
<tvoss> which allows us to pick up pace on integrating input
<duflu> It would be cool to be able to finally write clients that use the mouse ;)
<tvoss> duflu, it works with a mouse :) however, no cursor is rendered ;)
<duflu> Hah. Yeah forgot that part
<duflu> See also https://bugs.launchpad.net/mir/+bug/1109921
<tvoss> duflu, any input device that does not require a screen setup to be present is working :)
<ubot5`> Launchpad bug 1109921 in Mir "Mouse pointer flickers in xmir. Looks like "HW cursor" is not in HW." [Medium,New]
<duflu> tvoss: So we can write the first Mir game :)
<tvoss> duflu, of course, or better: integrate with sdl 2.0 to unblock all the fancy game engines
<duflu> What game engines depend on SDL?
<duflu> Aside from amateur ones?
<duflu> Never mind. SDL is pretty widely used. I might have overstepped the mark there
<tvoss> duflu, :)
<duflu> I know that QEMU used SDL exclusively for a long time
<tvoss> duflu, I wasn't aware of that
<duflu> And QEMU is one of the many definitions of "awesome"
<tvoss> yup
<duflu> Another definition is "Fabrice Bellard"
<tvoss> alan_g, can I get you to do another review of https://code.launchpad.net/~robertcarr/mir/receive-input-in-client/+merge/155368
<tvoss> ?
<alan_g> tvoss: OK when I get off call
<tvoss> alan_g, ack :)
 * RAOF wonders whether eglGetProcAddress makes in-process-egl any harder.
<RAOF> Then decides that it's 7:45pm, and that can wait for tomorrow.
<alan_g> tvoss: approved
<tvoss> alan_g, thx
<tvoss> alf_, can you have a look at https://bugs.launchpad.net/mir/+bug/1116452
<ubot5`> Launchpad bug 1116452 in Mir "gbm returns byte unit stride, android returns pixel unit stride" [Medium,New]
<tvoss> alf_, I remember some discussion around it, is it fixed?
<alf_> tvoss: no, the decision was to change Android to return byte unit stride too, but I don't think anything has been done. I will ping kdub, though. He may have started working on it.
<tvoss> alf_, ack, fine with you if I assign the bug to you and you change to kdub if appropriate?
<tvoss> ah, already assigned :)
<tvoss> alf_, setting the status to confirmed, though
 * duflu falls off chair
<alan_g> "* duflu falls off chair" - what was that about?
<ogra_> cheap chairs ?
<smspillaz> it happens
<kgunn> tvoss: thank you for pushing the mp on client input...
<tvoss> kgunn, yw
<thiagoandrade> I'm try
<thiagoandrade> I'm trying to compile Mir but I'm getting the error "/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libEGL.so: undefined reference for `mir_egl_native_display_is_valid'". Anyone knows how to solve that?
<thiagoandrade> Anyone here who can help me?
<smspillaz> thiagoandrade: you probably need to compile mesa with the mir patches. Ask racarr when he's around
<thiagoandrade> smspillaz, isn't there a way of using their repositories to install Mesa?
<alan_g> smspillaz: thiagoandrade the PPA should have a mesa that supports compiling
<smspillaz> yeah, that :)
<thiagoandrade> I've added the PPA to my system but waht shoul I do after adding the PPA?
<smspillaz> thiagoandrade: sudo apt-get update && sudo apt-get dist upgrade
<smspillaz> you'll just need to make sure you don't have a locally installed mesa in your PKG_CONFIG_PATH or LD_LIBRARY_PATH
<smspillaz> (eg, through compiling)
<thiagoandrade> smspillaz, Let me try that. Thanks
<alan_g> thiagoandrade: http://unity.ubuntu.com/mir/installing_prebuilt_on_pc.html
<kdub> good morning, status reworked some sizing for hwc devices in the process of getting the fb native window out of 3rd_party
<alan_g> good afternoon, status: reviewing and chasing down memory leaks in use of glog/gflags
<alf_> status: more main loop work and discussion, reviewing
<alf_> kdub: @display-sizing, l289, is the first expectation targeted for the HW11Device constructor, and the second for the display_size() call?
<alf_> kdub: or is the first one just to set up the environment, not actually part of the test?
<kdub> alf_, yes
<kdub> alf_, i guess that expectation could be removed
<alf_> kdub: it's ok, I was just wondering if it makes sense to put a Mock::VerifyAndClearExpectations() before the second expectation
<alf_> kdub: to ensure that getDisplayConfigs_interface is called in the constructor, but since it's more of an environment setup it doesn't matter
<kdub> kgunn, tvoss https://www.youtube.com/watch?v=iZ_iIZg4Xbw
<thiagoandrade> I followed this http://unity.ubuntu.com/mir/installing_prebuilt_on_pc.html and then thishttp://unity.ubuntu.com/mir/using_mir_on_pc.html. But When I try to run Mir on VT1 I get an error "mir: error while loading shared libraries: libandroid-input.so: cannot open shared object file: No such file or directory"
<kgunn> kdub: freaking awesome!!!
<thiagoandrade> The problem is that I can't find such package in the repositories.
<kdub> kgunn, :) sorry for the shaky camera, bad lighting and narration :P
<tvoss> kdub, epic :)
<kdub> thiagoandrade, build system bug, let me try to find the number
<tvoss> kdub, is this using the hwc :)
<kdub> thiagoandrade, https://bugs.launchpad.net/mir/+bug/1164253
<racarr> morning
<ubot5`> Launchpad bug 1164253 in Mir "mir links to libandroid-input.so, but does not package it or Depend on a package that provides it" [High,In progress]
<kdub> tvoss, hwc 1.1 with gpu composition
<tvoss> kdub, so the composition is accelerated?
<kdub> well, its always been accelerated, now it just doesn't flicker and tear and look bad
<tvoss> kdub, cool :)
<tvoss> kdub, let me share on google+ :)
<kgunn> kdub: dude...you realize everyone's gonna want play with that config...like, now :)
<kdub> they can play with our egltriangle demo much more easily :)
<kgunn> kdub: i just shared with unity ui guys...everyones pumped!
<kgunn> kdub: look so nice...like buttah!...no jank or tears...nice work man
<thiagoandrade> kdub, Sorry had to do something. Let me check that bug.
<kdub> kgunn, thanks!
<thiagoandrade> kdub, Basically that means I can't build Mir?
<kdub> thiagoandrade, its built, it just doesn't install one of the .so's in the right place
<thiagoandrade> kdub, I don't know if I'm gonna be of any help, but I was hoping I could help in the development of Mir. The problem is that until now I've not been able to build and run Mir.
<kdub> thiagoandrade, well, hopefully its easier when there aren't bugs. if you're using our guides, and something doesn't make sense, a good way to help would be to submit a patch (once you've figured it out) to the doc/ folder in lp:mir
<racarr> It should work fine it built from source yes?
<kdub> yes, i think so... but there's gotchas that I'd guess aren't documented
<thiagoandrade> So building from source I should not get that error, right?
<racarr> Right :)
<thiagoandrade> So I'm trying that. Let you know if I got any problem ;)
<racarr> Great.
<thiagoandrade> racarr, I got this error on 51% of the build: "Built target mir_demo_client_unaccelerated /usr/lib/gcc/x86_64-linux-gnu/4.6/../../../x86_64-linux-gnu/libEGL.so: undefined reference of `mir_egl_native_display_is_valid'"
<racarr> thiagoandrade: Hrm maybe something landed that wasn't supposed to
<racarr> looking
<racarr> thiagoandrade: I don't know whats going on. my guess is we need to remove the mesa in the ppa
<racarr> rebuild*
<racarr> though I'm not sure how it could be broken like that...
<thiagoandrade> racarr, Is there a manual or guide to compile the custom mesa I need?
<racarr> thiagoandrade: https://github.com/RAOF/mesa
<racarr>  ./configure --disable-gallium-egl --enable-gles2 --with-egl-platforms=x11,drm,mir,wayland --enable-gbm --enable-shared-glapi --with-gallium-drivers=r300,r600
<racarr> perhaps change --with-gallium-drivers
<racarr> thiagoandrade: In this case...you might need to install
<racarr> libmirclient from your partial build (so you can build mesa)
<racarr> i.e. go to build/src/client. make install
<racarr> then will be enough to build and install mesa
<racarr> then I bet mir build will finish
<racarr> will try and make sure the ppas are updated this afternoon :)
<thiagoandrade> Ok, I'll try. Let you know. ;)
<racarr> Got a qml terminal emulator (https://github.com/jorgen/yat) running with input
<racarr> was able to type and initiate tab completion (and modifiers and stuff work!)
<racarr> somehow enter doesn't work though
<racarr> not sure where the problem is
<kgunn> racarr: weird....like the button(ui) depresses...but nothing handles it?...or you literally don't even see the event?
<racarr> kgunn: Like the terminal emulator relied on an old Qt behavior
<racarr> where translating Key_Enter to string would produce \n
<racarr> now it seems it doesnt
<racarr> thats my best guess :) I got it working
<kgunn> cool
<kgunn> nice to see stuff falling together
<racarr> hmm
<racarr> not enough keys work for emacs to work
<racarr> Im going to try and get enough key mapping to work to make emacs work
<racarr> then write a demo shell that can alt tab then I can uninstall X11
<tvoss> racarr, that needs to go to the quotes wall :)
<racarr> :D
<thomi> morning folks
<racarr> Morrrnin!
<thomi> racarr: are you able to comment on this please? https://code.launchpad.net/~robert-ancell/mir/shared-android-input/+merge/157017
<thomi> I need the mir packages to work before I can complete my glmark work :-/
<thomi> robert_ancell: are you around?
<robert_ancell> thomi, yes, otp at the moment
<robert_ancell> thomi, free now
<thomi> robert_ancell: OK, when you get a minute, do you mind if I approve this MP of yours to fix the packaging? https://code.launchpad.net/~robert-ancell/mir/shared-android-input/+merge/157017
<racarr> There was a reason it was shared originally but maybe it has mysteriously resolved itself
<robert_ancell> thomi, sure, I'm not sure what Jenkins is complaining about
<robert_ancell> thomi, I just merged to see if that would help but it has now
<robert_ancell> not
 * thomi pushes the big red button
<robert_ancell> :)
<thomi> done
<racarr> We merged it with failing jenkins?
<racarr> I dont think that was a good idea -.- the merge fail is probably like
<racarr> jenkins fail*
<racarr> well how is anything else going to pass jenkins now?
<thomi> racarr: jenkins will do a proper merge, build, test before merging it into trunk
<thomi> autolanding != CI
<racarr> oh
<racarr> I thought when you said the big red button
<racarr> you meant you were just like
<robert_ancell> big red override :)
<racarr> pushing ;)
<thomi> sorry, I meant "I'm approving the MP"
<thomi> words 'n stuff
<thomi> robert_ancell: So your branch didn't land, and I think the problem is that g++ segfaults :-/
<robert_ancell> thomi, ech!
<thomi> at least, on my machine, I'm unable to build your branch due to g++ segfaulting
<RAOF> thomi: Segfaulting, or suffering an Internal Compiler Error?
<robert_ancell> thomi, is it a memory issue?
<thomi> robert_ancell: segfaulting
<robert_ancell> thomi, yeah but due to running out of memory?
<thomi> robert_ancell: I have 16GB or memory, so I sure hope not ;)
<robert_ancell> I don't think so then :)
 * robert_ancell rebuilds again to check here
<thomi> will go make coffee while this build chruns through
<thomi> *churns
<kgunn> thomi: it might chrun...you never know
<RAOF> kgunn: Oh, StevenK (A launchpad guy) told me that the issue that was preventing you from deleting a bunch of milestones has been resolved now, so you can go ahead and do whatever deletion takes your fancy.
<kgunn> sweet...now duflu will be less annoyed
<kgunn> hmmm....it remembered....already deleted
<robert_ancell> thomi, hmm, it fails here now
<robert_ancell> kgunn, oh, I worked around the LP issue by moving the milestone then disabling it
<racarr> hmm
<racarr> I can't figure out how Shift+4 is becoming $ on the phablet.
<robert_ancell> racarr, thomi, does this segfault mean anything to you? http://paste.ubuntu.com/5678081/
<thomi> robert_ancell: ahhh, I just noticed that it is indeed the acceptance tests failing. Not sure how I missed that before
<thomi> robert_ancell: so we're trying to destroy an android::KeyCharacterMap at program exit, and that fails for some reason
<thomi> robert_ancell: maybe we can try without the global data..?
 * thomi looks through the source code
<thomi> robert_ancell: this is really odd - trunk works fine, something about building the input library as a static lib is causing the acceptance tests to fail, and then segfault.
<thomi> I think I'll leave this in your more capable hands :)
<robert_ancell> thomi, lucky me! :)
<thomi> heh
<racarr> thomi: I think it has to do with the binary linking against both libmirserver
<racarr> and libmirclient
<racarr> and libandroidinputtransport
<racarr> and some sort of
<racarr> static initializer double something scenario
<racarr> I dunno I saw it and was like "Oh this needs to be a shared library"
<racarr> and thats why its a shared library ;)
<racarr> thats as deep as I went
<racarr> im tired of fiddling with the (due to be replaced)
<racarr> android keymapping system
<racarr> so I am going to go ahead and just replace it with libxkb-common
<racarr> eta ~1 day
<RAOF> racarr: Woo!
<RAOF> racarr: Remember to badger daniels (in #xorg-devel or elsewhere on freenode) about any limitations/problems in libxkbcommon you find. :)
<racarr> RAOF: It seems really easy
<racarr> the only question is where exactly to do it
<racarr> oh
<RAOF> We do it client-side, right?
<racarr> I think just qtubuntu is fine for now.
<racarr> yeah
<racarr> The thing is
<racarr> is it part of MirEvent
<RAOF> (Possibly with an optimisation to build the mapping-table server-side and share it with clients)
<racarr> or is it double client side
<RAOF> Do you mean - do we make clients manually apply the keymap?
<racarr> I guess right, is it part of the toolkits job
<RAOF> Or do we show them shiny pre-processed, gleamingly mapped keys?
<racarr> or does MirKeyEvent include like
<racarr> uint32_t unicode or whatever
<racarr> yeah
<racarr> I guess
<RAOF> My feeling is that MirKeyEvent should emit fully-processed unicode.
<racarr> why be a jerk and make every toolkit do it
<racarr> yeah
<RAOF> Anything that wants to preprocess the stream (input methods, etc) has to go through the shell.
<RAOF> Because the *shell* gets to see raw scancodes, right?
<racarr> well
<racarr> presumably KeyEvent has like
<racarr> uint32_t keycode, uint32_t unicode
<racarr> in the case of
<racarr> evdev->xkb
<racarr> the distinction between the scan and key code is kind of weird/unclear
<racarr> and mostly involves adding 8
<RAOF> Heh.
<RAOF> So, question - composing characters. I've got <menu> set as the compose key, so when I hit <menu>e" I get Ã«.
<RAOF> Here we have three key events turning into a single uint32_t unicode.
<RAOF> What does Mir send?
<racarr> a KeyEvent but instead of action
<racarr> down or up
<racarr> EVENT_ACTION_MULTIPLE
<racarr> keycode is 0
<racarr> and unicode is the only useful field
<racarr> it's the same sort of thing as when
<racarr> hey wait
<racarr> eh nvm
<racarr> thinking about weird onscreen keyboard things :)
<RAOF> evdev is sending you three complete down+up pairs, plus modifiers - <menu>down/up, <e>down/up, <shift>down, <'>down/up, <shift>up.
<RAOF> The client probably only wants to see Ã«.
<RAOF> (*Most* clients; games and maybe other things want to see the full event stream)
<RAOF> Or, I guess more accurately - most clients do *not* want to act on the <e>down/up and shift+<'>down/up.
<RAOF> racarr: We should probably ask desrt about what he thinks would be maximally awesome.
<racarr> Mm
<racarr> Why isn't he here
<racarr> difficult to write test this xkbcommon stuff...
<racarr> the tests for*
<racarr> code is pretty straightforward I think
<RAOF> Would a change to xkbcommon make the tests easier?
<racarr> If it were all mockable XD I dunno
<racarr> ill think about it
<racarr> there are so many options rather than take 2 days and try and figure it all out myself
<racarr> I am going to take 2 hours and make a prototype branch
<racarr> and ask for comment :)
<RAOF> racarr: I mention this because Daniel has explicitly asked me to be notified of any annoyances we have with using xkbcommon; if there's something that would make our lives easier...
<racarr> Good to know :)
<RAOF> So, I think my solution for mesa's in-process-egl changes is to have a EGLPlatformTypeâDrv map in EGLModule, and construct a new driver iff there's not currently a driver for that platform.
<RAOF> I don't believe that violates any spec, won't leak drivers, and we should even be able to have it transparently unload drivers if the last-using display gets closed.
<racarr> RAOF: Seems like the right thing to do
<racarr> RAOF: Do you have some time to work on it or do you want me to plan on it?
<RAOF> I should be able to do it today.
<racarr> oh great :)
<RAOF> We can land that and use-dma-buf at the same time :)
<RAOF> (Incidentally, feel like reviewing that? You're the last "needs fixing")
<racarr> RAOF: Will in 15-20 minutes
<racarr> feel like I am close to unwinding my thought and getting a solid plan on key-mapping
<RAOF> Woot!
<RAOF> No huge rush, unless you plan to land changes that conflict again :P
#ubuntu-mir 2013-04-05
<racarr> not today!
<desrt> RAOF: hi
<RAOF> desrt: Yo!
<RAOF> racarr and I were just talking about what sort of input events would make clients most happy, and we thought you'd have useful input.
<desrt> what sort as in what different types or as in what sort of delivery mechanism?
<RAOF> Specifically - what type of key events. Whether you want something like "<menu>down, <menu>up, <e>down, <e>up, <shift>down, <'>down, <'>up, <shift>up" or "Ã«"
<desrt> for compose sequences...
<RAOF> For keyboard(ish) events.
<desrt> that's sort of tricky
<RAOF> Compose sequences being an obvious edge case.
<desrt> because there are things like games that are basically going to want the keyboard in raw mode
<RAOF> Yeah, I'm thinking that there are actually two modes here.
<desrt> so here's a more interesting question then: how do you imagine input methods will work?
<desrt> so here's a more interesting question then: how do you imagine input methods will work?
<desrt> because the compose key is basically like the ultimate poormans input method, really
<RAOF> Indeed
<desrt> is the IM in the display server?  separate process?  plugin-based?
<desrt> figure out the answer to these questions and the rest will be pretty obvious...
<RAOF> The IM is a problem for the shell. Which means the IM does *not* need to consume these events.
<desrt> what i mean is that the interface between the display server and the toolkit needs to be designed with attention given to where the IM is
<desrt> if the IM is in the shell then you want the toolkit seeing what happens _after_ the IM
<desrt> ie: send unicode
<desrt> and then i see compose as just a special case of that
<desrt> keeping in mind, of course, some clients will want a bypass
<RAOF> Yeah. But the common case is just seeing a stream of characters.
<RAOF> No, that's not quite true; things care about more than the character stream (hello, keyboard shortcuts!)
<desrt> i think keyboard shortcuts should probably work by way of explicit registration
<desrt> although a lot of toolkits would probably get quite annoyed by that
<desrt> since they don't internally work that way
<RAOF> That would be particularly pleasant.
<RAOF> Right.
<desrt> but when you really think about it, it would solve a lot of annoying issues
<RAOF> *Global* keyboard shortcuts have to be explicitly registered; you think that app-local shortcuts should be too? It doesn't seem unreasonable to me.
<desrt> yes.
<RAOF> Hm. What about shortcut-highlighting on holding <Alt>?
<desrt> that's just a modifier watch
<desrt> (again, you'd want an explicit subscribe to receive those)
<desrt> i guess an interesting question is what happens to ctrl+s when nothing at all is watching for it
<desrt> do you drop it?  do you deliver it to the focused window as a last resort?
<RAOF> ie: do we emit an 's'?
<desrt> no.  never that.
<desrt> at least not without the modifier also being on it
<desrt> this would also be kinda convenient for toolkits that want to handle this stuff themselves
<desrt> maybe explicit (local) shortcut registration is dumb
<desrt> but i think i prefer viewing the input stream more as a sequence of user intents rather than raw hardware events
<RAOF> Yeah, that would be great.
<desrt> the extreme example of this is receiving touch gestures
<desrt> which we obviously plan on doing....
<desrt> from my gaction-based world i think it would be kinda neat to tell the system that <ctrl>s means 'win.save'
<RAOF> Right. (In addition to allowing clients access to raw touch sequences if they want,) We need to emit some form of intent event there.
<desrt> and have that action invoked
<desrt> that's how you do it now in gtk apps, but it's gtk that's doing the decoding of <ctrl>s
<desrt> i dunno
<desrt> obviously the API is more important than the interaction of the toolkit with the display server
<desrt> and following existing paradigms will make your life easier for obvious reasons
<desrt> the question is: are there any truly nasty edge cases caused by the way things are handled now?
<desrt> fun case to imagine: save is <ctrl>ÃÂ
<RAOF> You need to replay some events on window focus?
<RAOF> That's kinda annoying (but not exactly terrible)
<desrt> you mean like how the WM intercept the click events for click-to-focus and needs to retransmit them?
<desrt> here's an interesting thought experiment, meanwhile
<RAOF> I mean: you need to synthesise a keypress for any key that's down when the window is focused.
<desrt> the unity menubar shows when the user holds down alt, right?
<RAOF> This is currently the case, yes.
<desrt> what should happen the user holds down alt when a popup menu is open?
<desrt> should it show, or not?
<desrt> same question applies to showing underline on alt
<RAOF> I think the expectation is that the menubar *should* show when a popup menu is open.
<RAOF> Or, at least, I can't think of a situation when that would be an incorrect behaviour.
<desrt> it seems weird to me for the menu to show when a popup menu is open
<desrt> because that implies that if i add an 'f' to my already-held-down-alt that the file menu might open
<desrt> which i would find quite odd if a popup was already up
<RAOF> Really?
<RAOF> That would seem to be natural behaviour to me - the old popup is dismissed, the file menu opens.
<desrt> i might expect the mnemonic 'f' from the popup to fire
<desrt> like, maybe i'm pressing alt to get the underlines showing in that menu
<RAOF> Incidentally, I'm playing around with this right now in GTK. What the hell is it doing?
<RAOF> Hm, fair point.
<desrt> anyway
<RAOF> This is actually a special case of a more general problem, really.
<desrt> that's a bit of an argument for delivering alt to windows with respect paid to focus
<desrt> and not just using some global modifier monitor
<desrt> but....
<desrt> the way it works now is also very crappy
<desrt> because even to this day i find myself getting into stupid situations where somehow a modifier gets stuck on an app
<desrt> and i have to tap alt or ctrl or whatever to turn it off again
<RAOF> Right.
<desrt> so it should not be a simple press/release type of thing
<desrt> or rather: the release should always be reliably delivered, even if the window no longer has focus when the release occurs
<RAOF> That's one way of doing it, yes.
<desrt> which suggests more statefulness than i think we have now
<desrt> where the press and release are just two different events
<desrt> anyway.... beer o'clock :)
<RAOF> Heh. Have fun!
<desrt> g'night
<tvoss> RAOF, ping
<RAOF> tvoss: Pong
<tvoss> RAOF, just stumbled across http://www.phoronix.com/scan.php?page=article&item=nvidia_tegra_3d&num=1
<tvoss> RAOF, did you have a chance to take a look at it?
<RAOF> I've not taken a look at it, no.
<RAOF> I actually *do* have a Tegra device, don't I! The N7 is a tegra, right?
<tvoss> RAOF, might be interesting, especially as we have a lot of nexus 7 hw lying around
<tvoss> yup
<RAOF> Sounds like it's not _currently_ interesting though, as it doesn't actually do any 3D :)
<tvoss> RAOF, hmmm, I thought I read that NVIDIA open-sourced the 2D drivers, too
<RAOF> They did; the 2D driver + kms has been open-sourced for... a while? A year or so?
<tvoss> RAOF, s/2D/3D/g
<RAOF> Oh, yeah. The operative part of that phoronix article however is ââ¦is basically a stub driverâ and ââ¦is enough to get Wayland running with the Weston compositor, but not with any actual outputâ.
<tvoss> RAOF, :) okay, I got that impression, too
<tvoss> jono, good morning?
 * RAOF goes to test the mesa in-process-egl changes
<alf_> RAOF: Are you ready (i.e. mesa) for ~raof/mir/use-dma-buf to land?
<RAOF> alf_: Yes*
<RAOF> *For intel.
<alf_> RAOF: Do you mean you have just checked on intel, or that you know that e.g. radeon doesn't work?
<RAOF> radeon and nouveau will require additional patching, which shouldn't take long, but I haven't yet done.
<RAOF> I should probably fix them before we land dma-buf, I guess :/
<alf_> RAOF: ok, since this will break things for me, I vote for postponing the final approval
<RAOF> Fair enough. I'll have fixes for radeon and nouveau prepared before marking it as approved.
<alf_> RAOF: ok, I have marked the branch as needs fixing to discourage others from merging
<alf_> RAOF: feel free to ignore it and Approve when the mesa side has been fixed
<RAOF> Hm.
<RAOF> Why doesn't in-process-egl work for me.
<RAOF> It doesn't _seem_ to be a bug mesa-side; mir_egl_native_display_is_valid(nativeDisplay) is being called on something when valid_displays is an empty unordered_set.
<RAOF> BigWhale: You wanted to annoy some Mir developers? :)
<BigWhale> RAOF, indeed! :)
<BigWhale> ;)
<BigWhale> RAOF, I'm working on Kazam screencaster which is used for capturing screen. Surprisingly. ;) Now, because I am using GStreamer and ximagesrc which is a plugin that takes care of capturing, I know already that this will not work in Mir. :) I am looking for alternatives. :)
<BigWhale> If I got Mir specs, correctly, this will not be a trivial thing to do. With all the security restrictions.
<RAOF> BigWhale: That's going to be the province of the Shell (ie UnityNext); I don't think we'll be offering a generic way to do that.
<RAOF> Once everything's done it probably shouldn't be too hard; you'll just need to include MIR_CAPTURE_OUTPUT or whatever we call the requisite permission in your app manifest.
<RAOF> Wherever those app manifests go :)
<BigWhale> Ok.
<RAOF> It shouldn't be terribly difficult to write a mirimagesrc once the requisite infrastructure is in place, but I've no idea when we intend to put that infrastructure in place.
<tvoss> BigWhale, RAOF when we talked about this last time, we basically thought about the ability to add custom post processors to mir Displays (server side)
<RAOF> tvoss: Eh, just export the framebuffer as an EGLImage.
<tvoss> RAOF, yeah, that was the idea then :) iirc
<BigWhale> Ideally, I'd like to have something that I'll be able to feed into GStreamer.
<tvoss> RAOF, makes sense to file a bug at least?
<RAOF> BigWhale: You'll likely get a dma-bufish interface, maybe an EGL stream interface; it'll be pretty easy to feed that into GStreamer.
<RAOF> tvoss: It's probably a blueprint/series of work items.
<tvoss> RAOF, sure, just to make sure that we have it tracked somewhere
<BigWhale> RAOF, if I ask about an estimate, when I'll be able to start playing with this stuff, I'd be pushing it, right? :)
<RAOF> Maybe :)
<RAOF> BigWhale: Actually, you could probably do this yourself if you wanted. I don't think it's going to be a high priority for the Mir team.
<BigWhale> I'd love to have Kazam ready when Mir is ready. So that people can capture the awesomeness of Mir and Unity Next. ;)
<RAOF> Yeah, that'd be great.
<BigWhale> RAOF, offering my help with this, was the next step, yes. :)
<RAOF> I think it'd probably make more sense to do after the Big Display Refactor that I want to do, but I don't have an ETA for that.
<BigWhale> I'll start with setting up the dev environment and brushing up my C skills... :>
<RAOF> C++, actually.
<RAOF> C++11, specifically. Much more expressive.
<RAOF> You have such modern affordances as lambdas!
<BigWhale> Now you gave me two heart attacks ... :>
<BigWhale> C++11 actually makes C++ good. Well, better... :)
<RAOF> It suffers from adding yet another mechanism for doing things to the plethora of mechanisms already available, but at least the new mechanisms are really quite nice :)
<thiagoandrade> racarr, Spent the rest of the day yesterday downloading & compiling Mesa and then Mir. Done it and now it gives me a different error.
<thiagoandrade> In function open_drm_device() line 118 of file gbm_display_helpers.cpp it throws an exception saying "Problem opening DRM device" and then "Operation not permitted"
<thiagoandrade> racarr, "sudo pmap `pidof X` | grep dri.so" gives me back 4 times /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so . Does it means I need to change anything n the configure process of Mesa?
<thiagoandrade> racarr, Used this command ./configure --disable-gallium-egl --enable-gles2 --with-egl-platforms=x11,drm,mir,wayland --enable-gbm --enable-shared-glapi --with-gallium-drivers=r300,r600
<kdub> goood morning folks, still plowing ahead towards that fb native window type
<alf_> status: working on introducing the mir main loop
<thiagoandrade> kdub, Can you help  me with running Mir?
<kdub> thiagoandrade, on android i can
<thiagoandrade> kdub, Unfortunately I'm running on raring inside VirtualBox
<thiagoandrade> Thanks anyway ;)
<racarr> and ask for comment :/win goto 10
<racarr> ...woah what was that
<racarr> good morning
<racarr> the keymapping interfaces I am coming up with look laughably incorrect
<racarr> due to the duplication of droidinput::InputEvent and MirEvent
<racarr> so I am going to rip out droidinput::InputEvent and synthesize MirEvent directly
<racarr> thiagoandrade|af: Did not realize you were in virtual box...-.-
<racarr> would not expect it to work inside VB atm.
<thiagoandrade> racarr, That's a shame. I don't have a machine to spare and I'm not willing install raring and run possible unsafe code on my desktop ;(
<kgunn> thiagoandrade: partition & dual boot
<kgunn> ?
<thiagoandrade> kgunn, I already have a lot of troubles with Win8 and 12.04 on dual boot. It seems like I have an ability to attract problems ;p
<thiagoandrade> kgunn, But I'll think about it. The only downside is that I'll not be able to play with Mir on work.
<kgunn> mmm
<kgunn> i may have just bricked my galaxy s3 :-/
<kdub> my poor nexus4 spends its entire life panicking about not being able to find surfaceflinger
<kdub> kgunn, how so?
<kgunn> back
<kgunn> kdub: well...i loaded the CM recovery kernel...but now rebooting endlessly at splash screen
<kgunn> kdub: i'm seeing lots of complaints about the same
<kdub> sounds like its at least loading the kernel though, thats a good sign
<kgunn> kdub: freaky as all get out....loaded a recovery.img....it rebooted a couple of times from the CWM screen...but now stable
<kgunn> kdub: do you know if Thomi got glmark2 up on jenkins?
<kdub> kgunn, don't know
<kgunn> racarr: just checking...should someone else take on [robertcarr] Client focus notification (likely depends of notifcation work vanvugt is doing): TODO
<kgunn> racarr: can you also move (not copy)
<kgunn> racarr: your items in the iteration-0-mir blueprint ?
<kgunn> racarr: and mark them as INPROGRESS rather than POSTPONED
<kgunn> racarr: ....or...even DONE if you can land :)
#ubuntu-mir 2013-04-06
<racarr> kgunn: Sure. I think the difficulties of it are covered by vanvugts work
<racarr> kgunn: ?
<racarr> kgunn: Err I feel like I missed something sorry (netsplit earlier)
<racarr> to where?
<racarr> kgunn: Ok I see :)
<racarr> client input events for keyboard is done though :)
<racarr> added one about keymapping that I am working on no
<racarr> input landed :) inprocess-egl is still hanging out
<thomi> kgunn: it's up, but until the mir packaging issues are resolved I'm blocked
<Cheery> I try to collect some info on how ubuntu-mir or wayland may affect linux desktop
<Cheery> http://bpaste.net/show/89388/
<Cheery> if you have anything to add, could you send a message?
#ubuntu-mir 2013-04-07
<hk_> where can I get the Mesa source code used by mir
<thomi> morning
#ubuntu-mir 2014-03-31
<RAOF> Oh, what? We don't have an event time in all our events?
<bschaefer> kgunn, hey, so that stacktrace you sent me on friday was a bit strange....as it was under the assumption that OPENGL was available on the phone?
<bschaefer> kgunn, ill have to get my N7 flashed, and hope it still works with unity8
<bschaefer> thanks for testing it out!
<kgunn> mterry: did we fix your osk not catching events bug with latest mir-devel ?
<kgunn> (assuming you've got a rebuilt mir-dev branch in the silo...)
<mterry> kgunn, uh, haven't tested whole stack yet, we haven't rebuilt everything in silo
<kgunn> mterry: i figured...
<kgunn> still trudging through build order and mir api changes i suppose
<kgunn> racarr: ^
<kgunn> mterry: did you need a hand updating u-s-c to latest mir api ?
<mterry> kgunn, no, I think I did
<mterry> just took a while to rebuild everything on my phone so I could confirm it built right
<racarr> Ok!
<racarr> ust making sure it doesnt get lost
<kgunn> bregma: i recall you had a local fix for the qt5.2 shader trouble to render...but did you have yet another problem ? (for desktop preview ?)
<kgunn> robert was just asking if the cursor changes worked...but i'm thinking we still don't knwo
<bregma> kgunn, everything is fine (mir-wise) in the desktop preview, cursor works swimmingly on one of my machines (not the other, but it appears to be a bizarre packaging problem not a software problem)
<racarr> Yay
<RAOF> Woot!
<racarr> demo render surfaces is kind o insane...
<racarr> I guess not insane there is just a lot of stuf
<racarr> f
#ubuntu-mir 2014-04-01
<RAOF> Hey, would anyone have any objection to putting an event_time member in the MirEvent union?
<racarr> RAOF: I tried to think of reasons to object and cant
<duflu> RAOF: I have wanted that myself too. Just feared the necessary client ABI break. Maybe first thing next cycle?
<duflu> Although we're still at a point where breaking the client ABI isn't a huge deal
<RAOF> duflu: I'll queue it up; I'd like it for some testings.
<duflu> Votes wanted: https://code.launchpad.net/~vanvugt/mir/frontend-server/+merge/207602
<RAOF> duflu: Given that we agree that the code itself is bad, is renaming it worthwhile?
<duflu> RAOF: Yes I think so. Less bad :)
<RAOF> That's my 2Â¢; it's after 6 here, so tootleooo!
<duflu> RAOF: Night
<alan_g> anpok: has you "Needs Information" been answered? https://code.launchpad.net/~alan-griffiths/mir/introducing-SurfaceObserver/+merge/213431
<anpok> not really, but looking at the question it is not something that we can answer now..
<anpok> users will tell us
<anpok> alf__: final opinions on https://code.launchpad.net/~andreas-pokorny/mir/no-initial-display-configuration-sent-to-hosting-server/+merge/213126?
<alf__> anpok: I think creating the surfaces with the changed configuration is problematic
<alf__> anpok: without applying the configuration
<alf__> anpok: for example, what if the changed configuration says two outputs, but the host configuration is a single output, or outputs of different sizes etc?
<alan_g> alf__: there are already problems in that area. Try running a host as sidebyside and a nested render_surfaces with the defaults
 * alf__ tries
<anpok> hm tried the new greeter without applying the policy
<anpok> it still works
<anpok> it also seems to still get a transparent surface
<alf__> anpok: is this on android?
<anpok> yes
<alf__> anpok: it could be that the host configuration pixel format is RGBA (instead of RGBX)?
<anpok> ah yes the first (default) one it is..
<alf__> anpok: alan_g: I think that since we are not using the initial display configuration for nested any more, we should change to use other information. For example a bool prefer_translucent_formats?
<alan_g> alf__, anpok: I don't know the "right" answer - we have a design choice as to how the control (and any negotiation) splits between the host and nested systems.
<anpok> we could also look at the other side - should focus changes apply the complete configuration?
<alf__> anpok: alan_g: My understanding is that we have made the decision that the nested server won't touch the host configuration by default. This also means that we need to keep it in sync with it.
<anpok> alf__: what if the nested seat only wants to use a single diplay, while the other display should be reserved for another user?
<alan_g> My understanding is that we have made the decision that the nested server won't touch the host configuration *on startup*
<anpok> but it is still alowed to make changes to that configuration
<alf__> alan_g: anpok: right, on startup, that's what I actually meant
<anpok> i.e. we want full screen applications run with different modes?
<anpok> ok
<anpok> and that I consider to be only a band aid
<anpok> short lived..
<anpok> because this discussion will take a few roundtrips and will lead to some rework..
<anpok> i assume
<alf__> anpok: band aid == proposed MP?
<anpok> yes
<anpok> just what split greeter needs for now
<alf__> anpok: alan_g: I am just worried that we are pushed into a lot of band aid solutions lately, and gathering tenchnical debt.
<alan_g> alf__: agreed. (Although I'm trying to fix the Surfaces debt ATM)
<alan_g> anpok: are you able to drive a discussion about nesting and display configuration? E.g. Write down some key scenarios?
<anpok> ok
<alan_g> In that case, how about circulating those and scheduling a hangout?
<alan_g> alf__: We ought to start putting debt items where we (and especially kgunn) will be reminded of them. I know some are in the bugs.
<anpok> alan_g: google drive document?
<alf__> alan_g: anpok: [technical-debt] bug tag?
<anpok> for the scenarios to discuss..
<alan_g> Whatever works
<anpok> alf__: so yes both ways turn out to provide a transparent surface format, so no need to call initial policy inside that (temporary) fix
<alf__> anpok: both ways?
<anpok> yes, with and without applying the initial policy in the greeter and unity8 nested shells
<alf__> anpok: that will not work on mesa though, because it uses an rgbx format for the host server
<anpok> cannot test, thought the array of supported formats might also be led by a transparent format..
<kgunn> greyback: alf__ got to thinking in my slumber...it might not matter what mir does wrt egl, since qt is interfacing directly, we can effect the u-s-c
<kgunn> but i don't even think we'll be able to effect the session compositor
<kgunn> esp with our effort to plug in qt sg
<anpok> alf__: you are right
<greyback> kgunn: you lost me. Can you rephrase please?
<kgunn> greyback: egl is a hw vendor specific implementation (unfortunately eglswapbuffers is up for interpretation)
<kgunn> so whomever is interfacing with egl directly can be effected by those choices, and blocking might be occuring anyway
<kgunn> or "other errors"....context lost could be one
<greyback> kgunn: I see what you mean
<kgunn> greyback: i was thinking mir could arbitrate for qt, but that's only really true for the compositor...not the the apps
<kgunn> right ?
<kgunn> and even the compositor...we're looking at using qt sg
<anpok> i thought we can decide about the behavior of eglswapbuffers in every system mir will be shipped?
<kgunn> anpok: we can decide as long as we're the ones dealing with swapbuffers, but if the app is native (which think of toolkits as native gl apps)..they're dealing with egl directly
<greyback> I guess there's no way to prevent that
<alf__> kgunn: We are implementing the EGL platform though, so we do have at least some control of what's happening, although perhaps not full control.
<kgunn> alf__: the egl platform, but not the egl driver per se
<kgunn> right ?
<greyback> and since it is vendor specific, there's little we can do other than document that we recommend people use Mir's client API, which does what we want
<kgunn> alf__: anpok greyback happy to be proven wrong...
<kgunn> morning duties, bbiab
<dandrader> should I feel bad about casting a shell::Surface to a scene::Surface?
<alan_g> dandrader: maybe
<dandrader> on the QPA, MirSurfaceItem has a shell::Surface and it uses the shell:Surface::lock_compositor_buffer()  hack
<alan_g> The usual rule is that "if you destroy type information you can restore it".
<dandrader> but that hack is to be removed in favor of the new scene::Renderable::buffer
<dandrader> which is implemented only by scene::Surface
<alan_g> I think it would probably be better to have a scene::Surface in the first instance
<alan_g> But I've not looked at what that involves
<dandrader> the qt compositor QPA is getting surfaces from shell::SessionListener::surface_created
<dandrader> which gives shell surfaces, not scene surfaces
<dandrader> naturally
<alan_g> dandrader: yeah, that hasn't been fixed (yet)
<alan_g> I'm still fixing scene::Surface et al. scene::Session comes next
<dandrader> alan_g,  hmmm, so in the meantime I can just do the cast from shell::Surface to scene::Surface because later mir interfaces will change in a way that I won't have to do it anymore?
<alan_g> dandrader: there ought to be a scene::Session and a scene::SessionObserver and we'll obsolete the shell stuff
<dandrader> alan_g, ok, sound good
<alan_g> At least that's the current "vision"
<alan_g> *that shell stuff (there's still a role for shell)
<dansuf> Hello once again. I still have got this error in mir that it fails to bind buffer to texture and also in logcat W/Adreno200-EGL( 1576): <qeglDrvAPI_eglCreateImageKHR:4526>: EGL_BAD_PARAMETER
<dansuf> Is there any possibility to see more exactly what is the problem?
<dansuf> Surfaceflinger also doesn't work so it may be also something device-specific, but I still don't know what.
<kgunn> dansuf: judging from this...
<kgunn> https://bugs.launchpad.net/mir/+bug/1272041
<ubot5> Ubuntu bug 1272041 in mir (Ubuntu) "mir nested server failure: what(): error binding buffer to texture" [Critical,Fix released]
<kgunn> most likely a color buffer mismatch ?
<dansuf> kgunn: i don't have this unsupported buffer format line
<kgunn> AlbertA: ok..so, i'm a little confused...
<AlbertA> kgunn: ?
<kgunn> so looking at qtubuntu...i 1/2 expected to find some code
<kgunn> that said something like qt->mir.swap_buffers, that would in turn call the eglSwapBuffers....
<kgunn> but instead...i only find
<kgunn> qtubuntu/src/platforms/base/context.cc
<kgunn> calling it direct...
<kgunn> am i searching wrong?
<dansuf> kgunn: there's this bad_match like in the bug report, bad_context in eglSwapInterval and also
<dansuf> W/Adreno200-ES20( 3349): <get_simple_queries:1360>: GL_INVALID_ENUM
<dansuf> kgunn: this one appeared amongs other errors when running lightdm
<AlbertA> kgunn: no I think that's expected
<AlbertA> kgunn: because then the egl will foward the call to the native window type
<AlbertA> kgunn: which is where the mir platform will get hooked on
<kgunn> dansuf: so in all this instance are you using the mir qt plugin ?
<dansuf> kgunn: I'm not sure but if you mean if the variable QT_QPA_PLATFORM contains ubuntumirclient then yes
<kgunn> dansuf: can you share your exact device name once more ? i recal you said Sony....but model #?
<dansuf> kgunn: live with walkman, a'ka coconut
<dansuf> kgunn: but I'm not using official cyanogenmod repos as they dropped support for the device
<kgunn> dansuf: so where do you get your gpu drivers from ?
<dansuf> kgunn: I got gpu drivers from adreno's site
<kgunn> dansuf: so binary i assume ? your not building from source?
<dansuf> kgunn: generally, w-flo who ported desire z also did an update of his drivers and in a commit wrote it helped him with some issues
<dansuf> kgunn: yes, a binary
<kgunn> dansuf: so this is only a guess...but you might be careful of binaries compiled on differing kernel & android versions vs what you have...e.g. do you know which android version those were compiled against ?
<dandrader> Have you guys seems this error before? http://paste.ubuntu.com/7191321/ this is a symbol from libboost_program_options.so.
<kgunn> AlbertA: so even tho it looks like qtubuntu calls eglSwapBuffers directly...this call actually gets rerouted ? (i don't see how)
<AlbertA> kgunn: right because mir is the one providing the egl native display
<dandrader> so it seems libmirplatformgraphics.so should have a depencendy on it but ldd says there's none..
<dansuf> kgunn: adreno says its for Android 4.2 Jelly Bean MR1 and also in logcat there's some info that suggests it was compiled for mako
<dansuf> kgunn: and before w-flo updated his drivers he needed to make changes in mir's source to make it working
<kgunn> dansuf: hmmm sounds fishy (no pun intended :)
<kgunn> dandrader: are you changing mir config? or is it bombing out even on the default ?
<dandrader> kgunn, you mean the DefaultServerConfiguration class?
<kgunn> gotta run...
<kgunn> kdub: ^ can you assist dandrader
<kdub> you mean dansuf?
<kgunn> kdub: dandrader
<kgunn> dansuf: i think we're on to android 4.4.2...dunno if that might be an issue
<kdub> okay :) lets see
<dansuf> kgunn: we're on cm10.1 which i believe is 4.2
<dansuf> kgunn: 4.4 is kitkat, the newest
<kdub> dandrader, there was a MP that added a boost dependency to mirplatform graphics
<dandrader> kdub, still under review?
<dansuf> kgunn: anyway, thank you
<kdub> dandrader, merged yesterday
<kdub> to devel
<dandrader> hmm
 * dandrader checks
<dandrader> because I just rebased my stuff on top of latest devel...
<kdub> dandrader, although, that looks more like a build time problem that was being averted
<kdub> yours looks a bit different
<kdub> dandrader, but I don't see the packages listing program-options as a dependency though too
<kdub> dandrader, does installing program-options fix the error?
<dandrader> kdub, no it was already installed. I'm now trying this http://paste.ubuntu.com/7191409/
<dandrader> kdub, but I have  a feeling I might have messed up my installation somehow....
<dandrader> because the problem only happens when running unity8. mir examples work fine....
<kdub> dandrader, i'll see if I can reproduce the problem today
<racarr> dandrader: I ran in to this
<racarr> I worked around it by LD_PRELOADING libmirserver
<racarr> becuase it wasnt ust boost option stuf (LD PRELOADING boost options give
<racarr> other errors)
<racarr> hoping the
<racarr> inflight MP would fix it
<racarr> I cant figure out what caused it to happen though so dont really understand
<racarr> maybe libmirplatform graphics needs to be explicitly linked against libmirserver...I dont think it is? but since we load it dynamically its been fine
<racarr> and that stopped working because <some explanation goes here>
<dandrader> racarr, true. After I added boost options I get miroptions missing symbols. after I also add miroptions I get missing _ZN3mir21default_server_socketE and so on
<dandrader> will try your workaround now
<racarr> I cant remember in the end if I ended up LD_PRELOADING libmirserver or linking in CMake but either should work
<dandrader> racarr, yeah LD_PRELOADING libmirserver works!
<racarr> dandrader: Ok ill send an email to the list or make an MP or something in ust a few thanks.
<racarr> I originally thought maybe it was ust an isolated issue on my phone
<racarr> because of something dumb I did :p
<racarr> about 9/10 times its that.
<racarr> 17 conflicts encountered.
<racarr> ...lovely
<kdub> I'll look into that program options today, getting my stuff out the door
<kdub> dandrader, racarr is there a bug about that program options stuff? (if not, ill file one)
<dandrader> kdub, not that I'm aware of
<kdub> okay, i'll file
<dandrader> kdub, thanks!
<kdub> no problem
<kdub> hey racarr, if you can still repro that symbol problem, I posted a fix here https://code.launchpad.net/~kdub/mir/fix-1301040/+merge/213739
<racarr> kdub: Not sure if I can reproduce it still...will check in a sec...should be able to
<racarr> I dont think that will fix it though because
<racarr> if you LD_PRELOAD boost options
<racarr> you then go on to get missing symbols in mir options
<racarr> i you link mir options as well
<racarr> you go on to get missing symbols in default server conf
<kdub> racarr, ack, i'll keep seeing if i can get a build
#ubuntu-mir 2014-04-02
<alan_g> alf__: happy with the latest renames in https://code.launchpad.net/~alan-griffiths/mir/extending-SurfaceObserver/+merge/213516?
<alf__> greyback: Hi! Do you know which component in our stack handles the display-off signal from powerd and sets the new Mir display configuration?
<greyback> alf__: I believe unity-system-compositor does that job. powerd does a dbus call, which USC receives and sets the display config
<alf__> greyback: great thanks
<anpok> kgunn: https://code.launchpad.net/~andreas-pokorny/mir/no-initial-display-configuration-sent-to-hosting-server/+merge/213126 do we need this to land soon - necessary for split greeter, but just a workaround - we are still discussing alternatives
<kgunn> anpok: for split greeter...yes sir! i'd really like to get split in asap
<alan_g> kgunn: it is a shame it didn't get into the 0.1.8 MP then.
<kgunn> alan_g: drat....altho we can cherry pick
<kdub> do we have any relatively recent build silos with the unity stack handy?
<racarr> nnn
<racarr> whoops
<alan_g> Missing ffe?
<anpok> 0xAFFE?
<anpok> a C0
<alan_g> Focus Follows Eyes
<anpok> ah ok .. I thought you meant FFE in c0ffe
<anpok> for some people coffee is like 23 .. you can find it everywhere
<kdub> we store an address of a reference and use it as an ID in GLRenderer -_-
<alan_g> kdub: you can't take the address of a reference. Only the address of what it references.
<alan_g> That sort of trick breaks badly if the reference is bound to a temporary.
<kdub> right, and the renderlist is about to become a temporary, so have to detangle that
<kdub> unexpected surprises, all part of refactoring :D
<anpok> kdub: I think input dispatch wants the same from the scene..
<anpok> a list of things-on-screen that can take input
<kdub> anpok, but the input stuff shouldn't really be taking a Renderable :)
<kdub> anpok, that makes sense though, there's a for-each-if for input too
<anpok> hm I wonder if it is worth to have something different than renderable
<kdub> from an interface perspective, I'd say it would be better to have a Renderable and an InputTarget (or similar name)
<anpok> I mean touch input dispatch is all about graphical items on screen
<kdub> well, even at that there's a delta between what they're doing, like renderable has 'number_of_uncomposited buffers' and 'alpha'
<anpok> yeah that part
<kdub> whereas the input stuff would just need transform and 'input targettable'
<anpok> well alpha == 0 means I dont care..
<anpok> true
<kdub> right, so basic surface could condense all the compositor reasons for not being onscreen into something simpler for input
<kdub> If you have a reason to target the for_each_if (for the input-based iteration over the stack) for elimination, I'd be happy about that :)
<anpok> I think I want to get a condensed from the scene, copies. of the current scene status.. so that no locks are needed.. so this part is similar to gettign a renderlist from scene.
<kdub> sounds good to me, i'm doing something similar in lp:~kdub/mir/kill-scene-lock
<kdub> you'd still need a lock on the scene... just for a shorter period of time
<kdub> while the 'light' data is copied
<anpok> hm and for all involved surfaces?
<anpok> is basic surface still a Renderable?
<kdub> it is currently, but it doesn't have to be moving forward
<kdub> I see something like Renderable(BasicSurface) and InputTargetable(BasicSurface) in the future
<kdub> like, Renderable is really what the compositor/displaybuffer needs to do its stuff, its unfortunate that its a lot of handy info in one place :)
<anpok> hmm I see something like Renderable(SceneNode) InputTargetable(SceneNode) and SceneNode having a position/orientation/alpha/dunno and a reference to BasicSurface
<anpok> BasicSurface only has the buffers a size and what is needed to talk to the clients..
<kdub> sure, I think we mean the same thing, except SceneNode would be an interface that BasicSurface implements (in your case) and in mine, I wasn't specifying an interface
<anpok> kdub: I asked because it is possible that you distill a list of renderables now, and someone moves the basic surface around afterwards..
<kdub> but yeah, right :)
<anpok> nope I mean SceneNodes are instances that refer to BasicSurfaces
<kdub> 'moves' meaning what? like moves the object?
<kdub> or moves the position on the screen
<anpok> yeah new pos
<anpok> I would like to be able to have one client surface shown in different places on screen..
<anpok> so yeah SceneNode would be an indirection towards BasicSurface
<kdub> sure, still not seeing the problem yet though
<anpok> maybe also towards (BasicSurface|DecorationSurface)
<anpok> with moving?
<kdub> whichever problem is being posited :)
<anpok> hehe
<anpok> hm you might be drawing a frame with surface in State X+1 with occlusion filters applied to surfaces while they were in State X
<anpok> *surfaces
<anpok> thats why I thought copying would be better, and Renderable not being SceneNodes/BasicSurfaces(for now)
<kdub> right, i think copying is better too
<kdub> the Renderable(SceneNode) constructor does a copy (or lazy copy, where appropriate/feasible)
<anpok> ok
<kgunn> bregma: do you wanna approve
<kgunn> https://code.launchpad.net/~robertcarr/unity-system-compositor/add-cursor-option/+merge/213896
<kgunn> https://code.launchpad.net/~robert-ancell/lightdm/usc-hardware-cursor/+merge/213897
 * bregma looks
<anpok> racarr: what editor are you using, some of the n's ended up in a different window, I guess.
<racarr> yes they were just accidental nns lol
<racarr> keyboard drumming while thinking + accidental enter key
<anpok> because one n might have made it to a MP
<greyback> racarr: stupid question here, but is the "hardware cursor" a real overlay/plane cursor drawn by the driver, or is it drawn by Mir's Renderer/Compositor?
<racarr> greyback: driver
<greyback> racarr: nice, thanks
<racarr> lunch back in a flash
<racarr> back
<dansuf> kgunn: I built touch system with old driver and when I run unity8 now I get the start screen but only that and I got repeating messages in the logcat
<dansuf> E/qdgenlock( 1349): perform_lock_unlock_operation: GENLOCK_IOC_DREADLOCK failed (lockType0x1,err=Connection timed out fd=80)
<dansuf> W/Adreno200-EGLSUB( 1349): <GetBackBuffer:2121>: genlock_lock_buffer GENLOCK_WRITE_LOCK failed
<dansuf> W/Adreno200-EGL( 1349): <qeglDrvAPI_eglSwapBuffers:3477>: EGL_BAD_ALLOC
<dansuf> which appear randomly or when I touch the screen
<dansuf> w-flo, who inspired me to update my drivers, wrote in his commit that before using new drivers some changes to mir code and genlock fixes in hardware_qcom_display were needed
<dansuf> I'll try to solve the problem of genlock on my own
<kgunn> dansuf: yeah..sorry, i'd not have an idea on that one...
<kgunn> dansuf: curious...when you say start screen? you mean...like this http://www.blogcdn.com/www.engadget.com/media/2013/02/ubuntu-hands-on-620-ces2013.jpg
<dansuf> kgunn: it's more ugly because the fonts are too big, not in proper place with no smaller circles arond the big one and with no top panel (there is just a black space)
<dansuf> kgunn: despite this, yes
<dansuf> :D
<kgunn> dansuf: ok...so at least _some_ progress
<dansuf> kgunn: yeah, I have to leave now, If I have no clues about it I'll conbtact w-flo or developer who is providing unofficial support for my device
<racarr> sometimes the put things in the namespace htey are used rule is difficult to follow...the cursor controller needs to use the change callback from scene, so I had to extend the change callback mechanism to support multiple change targets
<racarr> so the thing is the compositor uses like set_change_callback(null callback) tl clear it, so when having multiple callbacks you need to have some sort of add_callback -> id
<racarr> remove_callback(id) sort of system.
<racarr> so mi::InputTargets and mc::Scene and ms::SurfaceStack gain like unsigned add_change_callback(unction) remove_change_callback(unsigned callback_id)
<racarr> and you want to typedef unsigned CallbackID, or maybe even use RAII or something
<racarr> but what namespace
<racarr> can you put that return type in?
<racarr> you have to put it in ms:: and in its own header...like say we do with depth id
<racarr> which breaks the namespacing rule and contains license header to code in a ratio of 40:1 lol
<racarr> cest la vie
<racarr> nevermind im silly
<racarr> if you use riaa and a unique_ptr+std::function deleter for
<racarr> the type
<racarr> you only need a forward declaration
<racarr> in headers
<racarr> its still breaks the namespace rule but eh
<AlbertA> std::function deleter?
<AlbertA> so add_change_callback will return what?
<AlbertA> a unique_ptr<SomeType>?
<AlbertA> racarr:^
<racarr> AlbertA: Yes. i.e. unique_ptr<ChangeCallbackInterest, std::function<void(ChangeCallbackInterest*)>>
<racarr> so you dont need a definition
<racarr> for ChangeCallbackInterest
<racarr> ID, Registration
<racarr> something
<racarr> I dont know the name yet
<AlbertA> and the custom deleter is for unregistering automatically?
<racarr> Yes
<AlbertA> cool
<AlbertA> I was looking into it briefly
<AlbertA> because I want to also hook into the scene change
<racarr> Ah
<AlbertA> for screencast purposes
<racarr> well I have a branch to do it, i just need to comment it
<racarr> and look at the diff
<racarr> but will have it mped by EOD
#ubuntu-mir 2014-04-03
<duflu> alan_g: Is there a rule of thumb for what to do in place of "static virtual"?
<duflu> It's been years since I needed one
<alan_g> What do you want it to do?
<duflu> alan_g: Return a constant value. But that is configurable based on the class you ask
<duflu> Hmm
<duflu> Not static
<alan_g> Determined at runtime or compile time?
<duflu> alan_g: Compile time
<duflu> But the implementation class isn't known till run time
<duflu> I know it's theoretically reasonable but maybe not possible in C++
<duflu> It's just like querying RTTI in a way
<alan_g> virtual Value value() const = 0;
<alan_g> didrocks: is there a CI problem? Jenkins doesn't seem to have done anything for 10 hours or so: https://code.launchpad.net/mir/+activereviews
<didrocks> alan_g: you should ping the vanguard from the CI team for that I guess
<didrocks> on #ubuntu-ci-eng
<didrocks> (we are only doing the landings)
<kgunn> alf__: hey, so josharenson is working on getting glmark2 running as part of our ci...however, glmark2 that's in archive for arm is only for x11
<kgunn> my understanding is that there is a glmark2_es2_mir
<kgunn> that can be built, but its not in the archive
<kgunn> so i was hoping to add it, do you see any problem there ?
<kgunn> mir is in universe as well, so should be fine...right?
<kgunn> (need to do this in order to have the ability for the jenkins job to apt-get install glmark2-es2-mir as part of the ci run)
<alf__> kgunn: when I released 2014.03 I also updated a packaging branch so that it produces packages for all variants https://code.launchpad.net/~glmark2-dev/glmark2/glmark2-package
<Cimi> hello guys
<Cimi> I import Unity.Application 0.1 in my qml
<Cimi> I start this when unity8 is not running
<Cimi> but still, my app crashes with this error
<Cimi> [libprotobuf ERROR google/protobuf/descriptor_database.cc:57] File already exists in database: unityrpc.proto
<Cimi> [libprotobuf FATAL google/protobuf/descriptor.cc:954] CHECK failed: generated_database_->Add(encoded_file_descriptor, size):
<Cimi> terminate called after throwing an instance of 'google::protobuf::FatalException'
<Cimi>   what():  CHECK failed: generated_database_->Add(encoded_file_descriptor, size):
<kgunn> Cimi: so you start before unity8...but are you using unity-mir ? or...rather...are you trying to launch the mir server ? or going through  u-s-c's instance of the mir server ?
<Cimi> kgunn, just running the app with upstart...
<Cimi> kgunn, don't know the internals
<Cimi> kgunn, so probably mir is already running
<kgunn> Cimi: mmm...do you see the greeter ?
<Cimi> kgunn, I'm starting on xsession-init
<Cimi> nope
<kgunn> Cimi: yeah...something needs to get you a mir server fired up...
<kgunn> Cimi: are you just doing this for testing ? or is this actually how you're planning on doing it ?
<kgunn> e.g. does the user see the greeter first? then dismiss into the welcome wizard ?
<Cimi> kgunn, I suppose the welcome wizard needs to be before unity
<kgunn> Cimi: sure...
<Cimi> before everything
<kgunn> it can be..
<kgunn> Cimi: well....there's some effort there tho...
<kgunn> wonder if you can just glom onto greeter ?
<kgunn> mterry: ^
<kgunn> seems Cimi needs a mir server....but wants to be "before everything else"
<kgunn> should he start his own mir server ?
<mterry> kgunn, Cimi: my plan was to insert it right before greeter
<kgunn> Cimi: you're suffering since split hasn't landed yet
<kgunn> Cimi: today there is only 1 mir server....shared by unity8 (session) & greeter (system)
<mterry> kgunn, Cimi: well, with split greeter, you'd have same problem
<Saviq> kgunn, mterry, Cimi, he doesn't need a mir server, thouhg
<mterry> Why do we need a mir server?
<Saviq> it could be just a client
<mterry> This is for notifications?
<Saviq> mterry, no, no need for a server
<Saviq> mterry, we can be just a client
<kgunn> Saviq: client to u-s-c's server ? or a 3 rd instance?
<Saviq> kgunn, client should be good
<Saviq> the current issue is that Cimi loads the Unity.Application API , which probably requires to be a mir server
<Saviq> or well, wait
<Saviq> I think he needs to be a server for the OSK
<Saviq> we don't want the OSK to go directly to u-s-c do we
<kgunn> mmm
<kgunn> how is it handled in greeter for pin code before unity8 is started ?
<kgunn> same case isn't it?
<Saviq> yeah
<Saviq> mterry, â ?
<Saviq> in split greeter, that is
<mterry> kgunn, Saviq: in split greeter, maliit talks to split greeter, which is a server
<greyback> The unity.Application  plugin can only be used by an application that instantiates a QMirServerApplication. Here's a simple example: lp:~gerboland/+junk/qml-demo-shell/
<mterry> Saviq, out of curiosity, what is wrong with OSK talking to USC?
<Saviq> mterry, you tell me :)
<greyback> different users could have different OSKs...
<mterry> I don't know enough about differences between mirservers, but I'd guess nothing
<Saviq> mterry, I think at least one thing is that shell, greeter, wizard needs to control the input routing
<mterry> greyback, yeah but this is a very special case (first boot wizard)
<greyback> mterry: ah I was missing context, sorry
<Saviq> mterry, greeter is not as special, though
<Saviq> greyback, that would include the input areas and such, right?
<mterry> Saviq, sure.  But greeter acts like unity8
<greyback> Saviq: for USC, yes
<Saviq> mterry, in that sense welcome wizard does, too, 'cause it's the only "shell" running at the time, even if the only client would be the OSK
<Saviq> greyback, I mean if the welcome wizard wants to use import areas (which it needs for OSKController), it needs to be a QMirServerApplication?
<mterry> Saviq, yeah...  but it's not a shell.  It's just a client itself
<mterry> I mean, we can change it to be a server too.
<Saviq> mterry, yeah, as long as it can control the input area of the OSK...
<kgunn> but wait...isn't Cimi finding out he alreaday needs more clients (following the shell argument...like notifications, settings app)
<greyback> Saviq: yes
<mterry> kgunn, I don't think notifications are clients...  I think shell renders those
<Cimi> kgunn, they are within the app
<mterry> (Or whomever loads the Notifications plugin, which maybe could be wizard)
<Saviq> notifications is in-surface
<Saviq> settings? why?
<Saviq> anyway, gtg for a bit
<Saviq> actually, bringing the laptop with me...
<kgunn> Cimi: do you launch settings ? or just pirate pieces of it ?
<Cimi> kgunn, I import the plugins I need
<Cimi> kgunn, it's standalone app
<mterry> So looks like only client needed is OSK so far
<kgunn> ok...so sounds like we're settled.... mir client ? mterry ?
<kgunn> ;)
<mterry> But sounds like it needs to be a server to manage the OSK
<mterry> Cimi, we night need to make the wizard a little server...  greyback, do we have any experience with OSK and servers that aren't unity-mir?  Or should we just use unity-mir here too
<greyback> the server needs logic to show/hide the OSK surface, and do a little input filtering (top of OSK surface transparent, so should not steal events)
<mterry> greyback, is that stuff we get magically for being a server, or do we have to reimplement that logic?
<greyback> mterry: you'll have to re-implement, if your server is not using unity-mir
<greyback> which it isn't, it's using mostly default mir stuff, isn't it?
<mterry> greyback, do you remember how closely tied unity-mir is to the unity8 shell?  Last time I remember looking, it was checking surface names and such
<mterry> greyback, right now the wizard isn't a server at all
<mterry> greyback, we were hoping to get away with just being a client
<greyback> mterry: but the wizard is a client, and should stay that way
<greyback> mterry: what is the server here?
<greyback> unity-mir needs one thing from a shell, that it names its surface something particular. That's all.
<mterry> greyback, well this is all up for debate.  But the plan I was envisioning was having wizard run under USC as a client with maliit server running beside it
<greyback> mterry: that's fine. So USC needs logic to handle the OSK surface
<mterry> Hrm
<mterry> greyback, and that logic is stealable from unity-mir?
<mterry> I don't know if I like USC adding that feature just for this one time wizard
<greyback> mterry: it's mostly implemented in QML, but it's pretty easy
<mterry> Ugh or gaining QML
<greyback> 1) try to detect the OSK surface by its name
<mterry> right now USC doesn't need to bother with the UI parts of Qt
<greyback> 2) listen for maximize/minimize evnets from that surface, and when they happen, show/hide the surface
<greyback> 3) set an input area on the OSK surface so the transparent part does not take events
<mterry> greyback, out of curiosity, why doesn't OSK just show/hide itself and such?
<mterry> And set it's size itself
<greyback> mterry: because surfaces cannot do that. That's a shell's decision
<mterry> Instead of needing to have a transparent part
<greyback> ah the transparent part for hte top row of keys, when you press them, the letter pops up higher
<mterry> Ah OK
<mterry> Details details everywhere
<greyback> indeed
<greyback> some keyboard too, a long press pops up a accent selector, which needs to receive events
<mterry> greyback, if we add those features to USC, I'd want to avoid QML.  How easy is it to do that input filtering without a nice Qml input area?
<greyback> input filtering a Mir concept, I've just wrapped it for use in QML
<mterry> Yar, just hoping it was easy
<mterry> Still, feels weird to add this complexity to USC just for the wizard
 * mterry wishes wizard didn't need OSK
<greyback> think mir::shell::surface has a  installInputArea method, which takes a rectangle.
<mterry> greyback, how ugly do you feel it would be to make wizard use unity-mir?
<greyback> inside that rectangle, the surface gets the events. Else it doesn't.
<greyback> mterry: then you're making the wizard a mir server. Which would work, yeah
<mterry> greyback, we'd have to name the wizard surface like the shell does.  But it sounds like besides that, it'd work?
<greyback> mterry: think so, yes. Maliit needs to connect to the wizard's mir socket, Then all should be good
<mterry> Cimi, ^ what do you think?
 * Cimi reads
<Cimi> mterry, I like your simpler solution :D
<mterry> Cimi, "simpler"  :)
<mterry> Cimi, so to do that...  unity8 has src/main.cpp which dlopens unity-mir
<Cimi> mterry, already saw it
<mterry> Cimi, we probably don't need all the complexity it has (in particular, we don't need to worry about non-mir instances)
<mterry> Cimi, and check unity-mir source.  Somewhere in there, it checks a surface name that we'll want to match to unity8
 * Cimi looks
<alf__> kgunn: greyback: https://code.launchpad.net/~afrantzis/mir/non-blocking-swap-buffers-spike , it's a spike not ready for an MP just yet, but it should work.
<greyback> have a look at lp:~gerboland/+junk/qml-demo-shell/ for a simple exmaple
<greyback> alf__: wow nice! Will test straight away
<kdub> jenkins traffic jam
<kdub> anyone know what's going on with autolanding?
<alan_g> kdub: yeah, there's problems with the phones
<kdub> alan_g, thanks
<alan_g> I asked on #ubuntu-ci-eng and found that it had been announced on a mailing list I didn't know about
 * mterry is seeing odd input bug with mir/devel + unity8...
<mterry> I'm testing further, but if anyone has played with full stack lately, let me know
<kgunn> mterry: got a description ?
<kgunn> racarr: anpok ^
<mterry> kgunn, I was seeing the greeter session come up but wasn't able to interact with it
<mterry> kgunn, still not sure which component's fault it is yet.
<kgunn> mterry: so like osk wouldn't invoke ? as well, you couldn't swipe?
<mterry> kgunn, right, couldn't swipe.  didn't get as far as OSK
<mterry> kgunn, nm, can't reproduce now...  :-/
<mterry> kgunn, I have some updates for silo 002 if you have time
<kgunn> sure
<kgunn> hey...crap, meant to ask you mterry about
<kgunn> https://code.launchpad.net/~mterry/gsettings-ubuntu-touch-schemas/volume/+merge/209158
<kgunn> i have it in the landing sheet...but, i can't recall...did you want it landed in isolation or not ?
<anpok> wasnt that one of the issues that crept in and got fixed with the surface restructuing? the thing that racarr looked at?
<anpok> +r
<anpok> hm most current greeter stuff is now in a different silo?
<mterry> kgunn, it landed with indicator-sound in trusty already.  We can drop it
<mterry> kgunn, for silo 002... add ~mterry/platform-api/mir-changes & ~alan-griffiths/unity-mir/compatibility-with-mir-changes & rebuild platform-api, unity-mir, and ubuntu-touch-session
<mterry> kgunn, we can remove any indicator-sound or schema stuff in silo 002 now too, if any are lfet
<mterry> anpok, we moved to silo 002 yeah
<mterry> (from 004)
<anpok> k
<mterry> anpok, silo doesn't work right now due to mir churn, but it's about to because kgunn is a silo wizard
<kgunn> mterry: building now
<kgunn> gotta reboot..
<mterry> racarr, do you know about any changes that would affect raising/focusing sessions?
<mterry> Or anybody really
<kdub> mterry, yeah, SurfaceRanker is gone
<kdub> the raise() method moved to SurfaceConfigurator
 * kdub always thought "surface rancor" when reading that one
<racarr> mm
<mterry> My USC changes to raise the spinner session don't seem to be working anymore
<racarr> someone must have landed unity-mir/usc updates or it just wouldnt build right
<mterry> hmm
<mterry> racarr, my copy of mir/devel must be between re-organizations then
<mterry> racarr, I don't see raise() in SurfaceConfigurator in mir/devel
<racarr> maybe
<racarr> I think kdub is right with investigate SurfaceRAnker...lots landing so might be easier to just try and see what is going on with GDB rather than guess at what change could have caused it
<anpok> surface wanker removal has not landed yet
<racarr> I can help tomorrow but right now am reloading chromium in to my head and doing updates etc
<mterry> racarr, no worries
<anpok> https://code.launchpad.net/~alan-griffiths/mir/make-use-of-scene-Surface/+merge/213894
<racarr> anpok: Top 10 typos of 2014
<racarr> Mm
<anpok> :)
<racarr> maybe something doesnt work
<racarr> in the intermediate state
<racarr> though
<anpok> now i see it .. oh dear..
<racarr> Hahahahaha
<anpok> mterry: but it could also be related to other changes..
<kdub> well, landing soon then :)
<kgunn> bregma: so...i'm sure i did somethin' wrong...but, i added your unity8 desktop ppa, but i only installed indicator-session....as i wanted to test the usc thingy...
<kgunn> and i am working off the assumption/knowledge that qtubuntu got update
<kgunn> d
<bregma> I believe it did, let me check on my most updated machine....
<kgunn> and that lightdm is fixed for cursor
<kgunn> bregma: yeah...i just didn't have an "option" on the greeter ?
<kgunn> ( i assume its not guest...but that it would say "unity8 desktop" or some such)
<bregma> is unity8-desktop-session-mir installed?  The one in universe is current
<bregma> I have the qtubuntu-desktop installed from universe (0.54+14.04.20140402-0ubuntu1) and it's working for me
<bregma> lightdm is from main 1.9.14-0ubuntu1
<bregma> unity8-desktop-session-mir is from universe 1.0.10+14.04.20140402-0ubuntu1
<kgunn> bregma: well i feel stupid....
<kgunn> just installed
<kgunn> bregma: still no luck...here's my usc log
<kgunn> https://pastebin.canonical.com/107762/
<kgunn> i gotta run...
<kgunn> but you might want to give usc from the silo ppa a shot
<kgunn> https://launchpad.net/~ci-train-ppa-service/+archive/landing-011
<kgunn> if it works for you...then its me
<kgunn> if it doesn't then something else went wonky with usc
<bregma> good old "Failed to set DRM crtc"
<kdub> unrelated :) but, its a real benefit for our interfaces that we have to look at things from the two platform's perspectives
#ubuntu-mir 2014-04-04
<RAOF> BAH! How am I failing at geometry?
<dholbach> hiza
<dholbach> hiya
<dholbach> can anyone please comment on my mail to the mailing list?
<alan_g> dholbach: I'm totally unfamiliar with that library, what it does and how we use it. What would constitute a useful "quick look"?
<dholbach> alan_g, I don't know what mir's dependency on libxkbcommon is and how an update would affect mir
<dholbach> maybe we could use the updated package and just test on desktop and phone?
 * alan_g Wonders if a keymapping library is relevant to phone - it sounds more like something XMir uses. Starts digging.
<greyback> alan_g: hey, just a note: platform-api uses mir::DefaultServerConfiguration::the_shell_surface_factory which you're removing...
<alan_g> greyback: Oops. Thanks for the warning.
<alf__> greyback: Hi! Any experimental results for non-blocking swapbuffers?
<greyback> alf__: I'm like 95% ready to test, you just chose a mir version to branch which makes changes unity-mir needed updating for.
<greyback> so just getting the bits to all worth together is tricky
<alf__> greyback: ok, I can rebase to some other version if it's easier to test
<alf__> greyback: which version is easier for you?
<greyback> alf__: so can I :) Gimme 20 mins and I should be there
<alf__> greyback: ok, np :)
 * alan_g realizes he needs to set ENABLE_MIRSERVER_IMPLEMENTATION
<dholbach> alan_g, do you know of anyone who knows how libxkcommon is related to mir?
<alan_g> alf__: ^
<alf__> dholbach: alan_g: I would guess racarr, xkbcommon seems to be used only in src/shared/input/xkb_mapper.cpp which was written by him
<dholbach> racarr, if you could reply to my mail on the list, that'd be great
<dholbach> thanks alf__
<alf__> dholbach: np
<greyback> alan_g: question - how does one convert a mir::scene:Surface to a mir::shell::Surface?
<greyback> oh, shell::Surface eliminated in your MR
<greyback> never mind
<alan_g> greyback: If mir::shell::Surface exists on the branch then it is one
<alan_g> Wow! You're ahead of development-branch?
<greyback> alan_g: you're changes were not insignificant, so best ot be ahead of the curve
<alan_g> greyback: I hope they'll make things easier for you in future.
<greyback> alan_g: you'd be hearing from me if I disapproved :) Yes I think they'll suit us fine
<greyback> alan_g: I've thrown together the platform-api fix:  lp:~gerboland/platform-api/mir-SurfaceFactory-to-SurfaceCoordinator
<alan_g> greyback: so have I lp:~alan-griffiths/platform-api/compatibility-with-proposed-mir-changes
<alan_g> ;)
<greyback> heh, you won :D
<alan_g> I did?
<alf__> greyback: So looking at USC code, it seems that it completely stops the compositor if screen is off, however my fix depends on the compositor running and consuming frames
<alf__> greyback: that's probably why things still get stuck
<greyback> alf__: aha, so USC also needs changing
<greyback> alan_g: is lp:~alan-griffiths/unity-mir/compatibility-with-mir-changes supposed to allow unity-mir build with Mir's developer branch, as it is right now?
<alan_g> greyback: that's the idea. I've not checked today
<alf__> greyback: yes, although we should provide a better interface for USC to interact with the display configuration
<greyback> as last night it wasn't enough,  I had to pull in your compatibility-with-proposed-mir-changes & the corresponging mir branch to get all to work
<alan_g> greyback: so if we can land the Mir branch I don't need to fix it. ;)
<greyback> alan_g: indeed :)
<greyback> works for me
<greyback> alf__: I'll hack USB to not explicitly stop/start the compositor, and let you know the results. Will take ~45 mins, had to reflash phone as upstart died
<alan_g> greyback: alf__ anpok can we have some "approves" on https://code.launchpad.net/~alan-griffiths/mir/eliminate-shell-SurfaceFactory-and-Surface/+merge/214041 ^^
<alf__> greyback: something like this should work http://paste.ubuntu.com/7202738/ (haven't tried)
<greyback> alf__: why stop/start it at all?
<greyback> oh, because you switch btween 2 compositor things
<alf__> greyback: it may not be needed with the current state of things. Ideally if a screen is off the mg::Display shouldn't even produce a DisplayDuffer for it. Any change in DisplayBuffers needs a compositor restart.
<alf__> greyback: actually we need to do it for mesa at least
<kgunn> bregma: this ended up being the problem...
<kgunn> https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1302270
<ubot5> Ubuntu bug 1302264 in systemd (Ubuntu) "duplicate for #1302270 systemd-logind assert failure: error.c:319: Assertion failed in nih_error_get: context_stack != NULL" [Critical,Fix released]
<bregma> kgunn, so now you're using Unity 8 on the desktop for all your day-to-day needs/
<anpok> mterry: the issue from yesterday
<anpok> did that one disappear?
<anpok> ok just experienced it
<alf__> alan_g: greyback: Is there a reason we don't have MP for platform-api and unity-mir compatibility-with-proposed-mir-changes branches?
<alan_g> alf__: I was going to MP when the changes land on development-branch
<alf__> alan_g: ok
<anpok> mterry: that issue from yesterday - greeter is visible but not reacting to input - what where your steps to reproduce it? So far it only happens for me once on start up
<anpok> and it disappears when display is turned off/on again..
<mterry> anpok, I can't reproduce yeah
<anpok> maybe I have a broken combination of mir related packages..
<anpok> but I get it quite frequently - restart lightdm - > display turns off and greeter is frozen..
<anpok> *display turns on
<anpok> EventHub does not seem to wake up on touch presses
<mterry> anpok, then maybe I lucked out in my combination of mir packages....
<mterry> anpok, ah....  I think I know what it was -- it was more of the raising-sessions regression I saw.  The transparent spinner session must have been on top
<mterry> anpok, are you using my split greeter branches?
<bregma> kgunn, the u-s-c in landing-011 tests out OK for me: I'm not sure if it needs phone testing but I'm keen to see it land if you're ready to pull the trigger
<kgunn> bregma: i did test phone it was fine....
<kgunn> just hadn't had time to sort the desktop this morning...after recovering from the bad xorg pkg issue last night...let's land it :)
<bregma> kgunn, it's time to release it to the wild then
<kgunn> bregma: i''m on it
<anpok> mterry: yeah .. still your usc branch and mir-devel from today
<mterry> anpok, OK yeah.  So session-raising got broken somehow.  And the (transparent) spinner session is on top of the greeter
<mterry> anpok, set_focus_to() no longer raises a session and even manually calling raise on the individual surfaces doesn't seem to do the trick
<anpok> yeah that was working with devel
<mterry> anpok, it was?  Ever since latest devel it seems to have stopped working for me
<mterry> "latest devel" -- I'm not actually sure when
<alan_g> mterry: which -r are you at?
<mterry> alan_g, that's a great question...   something from Wednesday
<mterry> (the silo 002 PPA built it and it doesn't make it obvious which revision was used)
<anpok> -r 1528 seems to work
<mterry> anpok, but you said you were having the same input problem with the greeter?
<mterry> anpok, that means whatever devel version you are using has the session-raising problem
 * alan_g has touched the codepath - but there were no test breaking. Will write one. So: create a couple of sessions with surfaces and try to raise the 1st one?
<kgunn> mterry: want me to rebuild mir ?
<alan_g> Has a bug been filed?
<mterry> alan_g, yeah I guess.  I'm using both raise on surfaces and set_focus_to, neither seems to do the trick
<mterry> alan_g, no I wasn't sure until today what was even wrong
<mterry> kgunn, I'm not sure devel is fixed yet
<mterry> alan_g, I can file a bug, give me a sec
<kgunn> mterry: ok...was just thinking if you wanted to get to the tip
<anpok> mterry: no session raising issues, just user input not working
<mterry> anpok, right.  But that is (I believe) a symptom of the transparent spinner session sitting on top of greeter when it shouldn't be, stealing all the input
<mterry> anpok, because the greeter wasn't being raised properly
<mterry> kgunn, not yet, I don't think
<kgunn> ack
<mterry> alan_g, bug 1302689
<ubot5> bug 1302689 in mir (Ubuntu) "Session raising problems" [Undecided,New] https://launchpad.net/bugs/1302689
<alan_g> ta
<mterry> kgunn, actually...  it looks like there are quite some API changes in mir/devel recently that will affect my branches.  So maybe a respin of mir now would give me an easier time of updating to deal with them
<mterry> I'll still need a respin later for the raise bug fix, but I can update to API now anyway
<didrocks> mterry: hey, nothing related to that, but you are putting my laptop at risk! :)
<mterry> didrocks, did you see a deja-dup CPU craziness?
<didrocks> mterry: not more than usual: more seriously deja-dup (surely duplicity) is trying to backup, but I'm getting:
<didrocks> Invalid data - SHA1 hash mismatch for file:
<didrocks>  duplicity-full.20140327T181132Z.vol1.difftar.gpg
<didrocks> everytime
<didrocks> so I don't have backup! zomg :)
<didrocks> (the computed and real fingerprints are indeed different)
<mterry> didrocks, that reminds me of an old old bug that was fixed years ago
<didrocks> mterry: I moved my backup server to a rasperry in case the backup server impacts itâ¦
<didrocks> (but I thought the compression was client-side)
<mterry> didrocks, and if you backed up 03/27, you should have a presumably-bug-free version of duplicity
<mterry> didrocks, correct
<didrocks> mterry: I didn't, my server went down and that's why I bought a rasperry
<didrocks> so, it was my first new "full" backup
<didrocks> mterry: oh no, I have one from 27/03
<didrocks> which was the one shown
<didrocks> mterry: is there any logs I can throw your way?
<kgunn> mterry: rebuilding
<mterry> didrocks, not especially...  What I need is to go back in time to 03/27 and fix it there
<mterry> didrocks, find out what happened I mean
<kgunn> mterry: so for usc, will you have a seperate branch i can land fo' real if we promote mir-devel ?
<didrocks> mterry: so, I can remove this backup? it doesn't seem to be complete anyway
<kgunn> gotta run for lunch..bbiab
<mterry> didrocks, yeah
<didrocks> like having 9 volumes instead of 1800+
<didrocks> mterry: ok, will do that and relaunch a backup, thanks!
<mterry> didrocks, sorry man
<didrocks> no worry, thanks you for unblocking me :)
<kdub> bzr!
<davmor2> kgunn: has anyone on the team got a manta
<kgunn> davmor2: everyone i think
<davmor2> kgunn: update to latest proposed open the weather app and hit the bottom date on the right hand side apparently in the desktop version scrolling is smooth and fast
<davmor2> kgunn: I've filed a bug against the weather app https://bugs.launchpad.net/ubuntu-weather-app/+bug/1302728 but it is on the off chance that it is actually mir/qt/qml that is the issue I thought I'd give you guys a heads up
<ubot5> Ubuntu bug 1302728 in Ubuntu Weather App "extremely slow scrolling between days on manta" [Undecided,Confirmed]
<kgunn> mterry: uh-oh, merge conflict on the mir rebuild in split greeter silo....for https://code.launchpad.net/~mterry/mir/no-initial-display-configuration-sent-to-hosting-server-merged
<kgunn> https://ci-train.ubuntu.com/job/landing-002-1-build/25/console
<kgunn> davmor2: sure
<mterry> kgunn, you can drop that branch, it made it into trunk
<kgunn> mterry: ack
<kgunn> mterry: ...so you have no mp on mir-dev ?...e.g. i need to pick or gen one to rebuild?
<mterry> kgunn, oh right.  I'll make a fake one
<kgunn> mterry: oh wait...you have this one
<kgunn> https://code.launchpad.net/~mterry/mir/missing-links/+merge/213906
<mterry> kgunn, that made it in too.  But probably won't conflict, just will be a no-op
<mterry> kgunn, so try that alone
<kgunn> roger that
 * mterry goes afk for a little bit
#ubuntu-mir 2014-04-06
<dansuf> kgunn: Hi, I discovered something interesting. When I launch mir server demo shell and then "turn off" the display by clicking power button then launch some of the client demos it doesn't have this genlock error
<dansuf> kgunn: I forgot to say that it normally renders everything after turning on the display
<kgunn> dansuf: that's interesting....i wouldn't have thot that...
<dansuf> I still don't know how to turn off the display on unity8
<kgunn> so you turn the display off with pressing the pwr button, but then it "comes back on" upon mir demo rendering ?
<dansuf> no, i turn it off then launch demo then turn on
<dansuf> and it also worked when i turned off then on when an app is running but I'm not sure it always works
<kgunn> dansuf: are you looking for a way to control the display ?...if you are...then check this out
<kgunn> https://wiki.ubuntu.com/powerd
<kgunn> you can simply (from another terminal) get on the device shell (adb shell)...and then run those cli commands
<kgunn> dansuf: i would say that the display interaction is really kind of undefined
<kgunn> we're controlling display state with unity-system-compositor
<kgunn> well...
<kgunn> maybe it is that mir is at least turning on in the render case...so not completely undefined
<dansuf> kgunn: I'm trying to figure out how to turn off the display with these commands. On the other hand pressing pwr in demo just makes the screen blank, not powered off completely and with genlock error only first frame is shown with 1 FPS
<kgunn> dansuf: sorry, what is your goal of "turning off" the display ?
<dansuf> kgunn: with mir launched (which is giving me genlock error) I wanted to turn the creen off then on with hope it will magically work
<dansuf> kgunn: running unity8 with --offscreen seems to run fine
<dansuf> so it's definitely sth with the display
<kgunn> dansuf: problem is, if the display is off then you won't have a vsync...which you need to "consume buffers", and pump the rendering
<kgunn> unless you configure mir to ignore vsycn (swapinterval 0)
<dansuf> kgunn: I'm afraid my hardware drivers doesn't support vsync
<kgunn> dansuf: even if its not a "real" vsynch...it must be providing some sort of heartbeat or swapping buffer scenario
<kgunn> e.g. even if your display is "command mode"
<dansuf> kgunn: So how can I configure mir to set swapinterval to 0?
<kgunn> dansuf: which i guess is _exactly_ what you're trying to tell me :)....you get a genlock error...but the genlock is exactly the thing mimicking vsync
<kgunn> actually...right after i typed swapinterval 0...i'm thinking we don't have that functinoality in our mobile(android) platform...only mesa
<kgunn> dansuf: plus, i guess the real answer is to determine what might be the issue with genlock to begin
<kgunn> dansuf: https://github.com/lgics/cm_device_lge_p350/issues/2
<kgunn> might check the post from RonGokhale about a year ago
<kgunn> only a guess...but kind of sounds like what you're experiencing
<dansuf> kgunn: my error is different if it does count
<dansuf> E/qdgenlock( 1612): perform_lock_unlock_operation: GENLOCK_IOC_DREADLOCK failed (lockType0x1,err=Connection timed out fd=73)
<dansuf> if not, I can try applying the patches
<dansuf> kgunn: I will leave the chat soon, thank you for your help, I'll try to find the problem either in genlock or in mir or maybe do some hacks in mir
<kgunn> ack
#ubuntu-mir 2015-03-30
<greyback> hey folks, anyone recall the recent "std::exception::what: Attempt to set swap interval on screencast is invalid"
<greyback> error?
<MacSlow> greetings everybody
<greyback> MacSlow: I've already asked
<MacSlow> for a  autopilot-test on a nexus4 I sometimes get this mir-exception...
<greyback> I can't find a bug for it in mir's bugtracker however
<MacSlow> ah... ok thanks... still need the pastebin-line?
<MacSlow> link
<greyback> http://pastebin.ubuntu.com/10707193/
<MacSlow> yup that's the one
<MacSlow> I get this failure ~50% of the time I run my autopilot-test
<greyback> alan_g: alf_ ^^ ideas?
<alan_g> greyback: opt - 10min
<alf_> greyback: MacSlow: I wonder if this exception is really the root cause. The exception is emitted by phablet-screenshot and should be non-fatal. Doesn't phablet-screenshot only get run if a test fails?
<MacSlow> alf_, hm... I'm not sure
<greyback> "Introspect error on :1.147:/com/canonical/Autopilot/Introspection: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)" <- usually means AP cannot connect the unity8 process
<MacSlow> alf_, from the output I'd say: yes
<greyback> MacSlow: can you get more verbose output please. the unity8 output
<MacSlow> greyback, from ~/.cache/upstart/unity8.log ?!
<greyback> MacSlow: yeah
<MacSlow> greyback, one sec
<MacSlow> argl... now it doesn't fail ;)
<alan_g> Wonders if this is lp:1425307
<MacSlow> it worked five times in a row... *sigh*
<MacSlow> greyback, alan_g, alf_: http://pastebin.ubuntu.com/10707364 that's the unity8.log of a failed run
<greyback> MacSlow: might be another issue entirely: Caught runtime exception from mediascanner:  Could not find media ///system/media/audio/ui/camera_click.ogg
<greyback> MacSlow: a "()" is printed when a unity8 process is started
<greyback> so unity8 died the line before
<MacSlow> greyback, I wiped ~/.cache/upstart/unity8.log before running the aP-test
<greyback> MacSlow: the log says the unity8 process restarted
<greyback> why it did requires investigation, but *should* be unrelated to your change
<greyback> MacSlow: maybe try deleting ~/.cache/mediascanner-2.0/mediastore.db, run "restart mediascanner-2.0" and try the AP test again
<MacSlow> greyback, "initctl restart mediascanner-2.0" I assume
<greyback> MacSlow: probably yeah
<MacSlow> greyback, alan_g, alf_: So that's the output to ~/.cache/upstart/unity8.log after wiping mediascanner.db and restarting the mediascanner-service http://pastebin.ubuntu.com/10707428/
<greyback> MacSlow: same thing, unity8 is restarting (probably a crash)
<greyback> MacSlow: is /system/media/audio/ui/camera_click.ogg missing on your phone?
<MacSlow> greyback, indeed...
 * MacSlow checks on krillin
<greyback> well done, no idea how you managed that ;)
<greyback> it's there on my mako anyway
<MacSlow> greyback, I certainly did not do that intentionally
<greyback> I know, just kidding !
<MacSlow> if that's the issue causing me all the AP-troubles I'm going to...
<MacSlow> I better don't :)
 * alan_g wonders how a quick fix to add a one-line "surface->configure()" call turned into a week long review and 264 line diff.
<greyback> MacSlow: tbh it probably isn't the main issue, since 1/2 of your test runs work just fine
<greyback> MacSlow: you might want to try the AP tests with trunk unity8, just to see if the same error appears
<MacSlow> krillin battery is empty... "best" timing
<racarr> Oh hai
 * racarr returns from utah
<attente> greyback: hi, have you had a chance to look at https://bugs.launchpad.net/ubuntu/+source/qtmir/+bug/1426443?
<ubot5> Ubuntu bug 1426443 in qtmir (Ubuntu) "Add QPA support for input method candidate windows" [Undecided,New]
#ubuntu-mir 2015-03-31
<MacSlow> greetings...
<alan_g> hello
<MacSlow> Is it to be expected that "DisplayServer: Mir version 0.11.0" is logged into ~/.cache/upstart/unity8.log although all mir-related packages are of version 0.12.1+15.04.20150324-0ubuntu1 ?
<alan_g> Not in theory, but in practice: yes
<MacSlow> alan_g, so this does not indicate a package or setup-flaw?!
<alan_g> Someone forgot to bump some macros in the 12 series. We noticed a few days ago
<MacSlow> alan_g, ok... wanted to verify that
<alan_g> yw
<alan_g> anpok: In looking at lp:1438702 I've discovered that mir::DisplayServer::Private has input_manager and new_input_manager - is this something you know about?
#ubuntu-mir 2015-04-01
<alan_g> duflu: your "Needs Info" answered? https://code.launchpad.net/~alan-griffiths/mir/death-to-SurfaceConfigurator/+merge/254796
 * duflu looks
<duflu> alan_g: Approved
<alan_g> thanks
<duflu> 2015 might be the year I start using C99 for everything instead of C89
<duflu> Although that might have happened in 2010
<duflu> Hmm
<greyback> where can I find the instructions for the proving shell? i.e. how to resize something
<alan_g> greyback: Alt+middle button
<greyback> bah, no middle button on my trackpad
<greyback> alan_g: thanks
<alan_g> greyback: three finger gesture?
<greyback> alan_g: perfect, ta
<duflu> greyback: For the latest: http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/doc/demo_shell_controls.md
<duflu> If anything works with multi-touch-pads, that's partly by accident. Mir doesn't really know about touchpads directly
<greyback> duflu: still here? (thanks for the link, always fail to locate that file)
<duflu> greyback: Off to make dinner now
<greyback> duflu: fair enough, bon appetit
<MacSlow> alan_g, greyback: I've sent you an email with the unity8.logs of the (mir-)failures I see (and a comparison for non-failure) in the hope you'll be able to find anything odd that might help in my search for the culprit of the crash.
<greyback> MacSlow: did you ascertain if unity8 crashes or not?
<greyback> if it does, why not attach gdb with "gdb -p `pidof unity8`"
<greyback> that should give you a stacktrace when it crashes
<MacSlow> greyback, didn't manage to catch it yet that way
<MacSlow> greyback, so I assumed there has to be another way
<greyback> MacSlow: none that I know of. Could set any coredump to end up in your $HOME with:
<greyback> sudo bash -c 'echo "$HOME/core.%e.%p" > /proc/sys/kernel/core_pattern' && ulimit -c unlimited
<MacSlow> greyback, *sigh* when I want it to crash it doesn't :)
<MacSlow> greyback, no core file
<greyback> MacSlow: can you watch "ps ax" to see if unity8 is indeed restarting?
<MacSlow> greyback, one sec...
<MacSlow> greyback, no... on /lib/modules is 99% full all other partitions provide still enough free storage
<greyback> MacSlow: so unity8 is not restarting during the test case. ok
<MacSlow> greyback, I don't get any core dump files... but /var/crash gets some files...
<MacSlow> but these are prefixed with _usr_bin_unity8 which is not what I would expect from the AP-test...
<MacSlow> as it should run the local unity8 from the source-tree
<greyback> MacSlow: I didn't think AP did that
<greyback> but I'm not certain
<MacSlow> greyback, what start local unity8 or dump to /var/crash ?
<greyback> MacSlow: from local unity8
<greyback> again, I'm unsure
<MacSlow> greyback, I hope you're wrong... otherwise I've been wasting some time
<greyback> well it's easy to verify
<MacSlow> greyback, just moved /usr/bin/untiy8 and re-ran the AP-test... still works
<greyback> MacSlow: ok good
<MacSlow> greyback, I would have been very surprised, if that would not have worked
<MacSlow> greyback, it failed but did not produce any core or crash-file (in /var/crash)
<greyback> MacSlow: ok, it's not a crash, good
<MacSlow> I've /usr/bin/unity8 still moved aside
<MacSlow> greyback, I wonder if the issue is a DBus one... looking at the failure-output there's an error from DBus right after the autopilot process-helper reported unity8 started/running...
<greyback> MacSlow: DBusException: org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)  <- that does indicate to me AP asked something of unity8, but unity8 has not replied
<greyback> does the UI lock up?
<greyback> but we're in "launch_unity"
<greyback> so unity8 is being launched, but AP unable to contact it on the bus
<greyback> "Unable to register object on D-Bus! Testability interface will not be available."
<greyback> ok that's a problem
<greyback> next question is _why_ it's unable to register on the bus
<greyback> is there a previous unity8 instance still alive?
<MacSlow> greyback, you see the question-marks above my head get bigger and bigger
<MacSlow> greyback, it should not... but let me try soemthing else...
<greyback> MacSlow: dbus-monitor show you useful info?
<greyback> Testability driver loaded. Wire protocol version is "1.4".
<greyback> Testability driver loaded. Wire protocol version is "1.4".
<greyback> Unable to register object on D-Bus! Testability interface will not be available.
<greyback> why the first line printed twice?
<greyback> is hte testability plugin being loaded twice somehow?
<greyback> and the second time it fails, as the first time succeeded
<greyback> dbus is available, as the clipboard registers ok
<MacSlow> greyback, dbus-monitor dumps too much...
<greyback> "Signal caught by Mir, stopping Mir server.."
<greyback> this log is full of oddness
<MacSlow> greyback, one of the AP-folks is currently also looking over this... I hope he's able to make more sense of this
#ubuntu-mir 2015-04-02
<duflu> alan_g: Is Jenkins usually present or need to be requested on devel-mir-next? Seems it was present on one proposal but not the other
<alan_g> duflu: it isn't set up for devel-mir-next
<alan_g> maybe it ought to be
<duflu> alan_g: Might be handy, but the process is already pretty indirect. Jenkins will always be gatekeeper in the end as things eventually get proposed to lp:qtmir
<duflu> In the branches prior to that, less important
<duflu> greyback_: Hey did U8/QtMir get its own screencasting tool?
<greyback_> duflu: qt has it built-in
<duflu> greyback_: Handy. Got a bin name?
<greyback_> duflu: http://doc.qt.io/qt-5/qscreen.html#grabWindow is the method, is platform dependent. It's not a standalone tool tho.
<duflu> greyback_: Kay nevermind. Just noticed the output format of mirscreencast has changed and I thought that might be to support some tool/script that can use it
<greyback_> duflu: of that I've no idea. It wasn't done for Qt's sake anyway
<duflu> The new format is theoretically less awkward but I don't know any mplayer/vlc incantation that can use it
<duflu> Unlike the old format
<duflu> greyback_: In other news, I've been playing with input resampling again, on the client side this time. Seems there's reasonable gain to be had if you implement app-specific resampling. If Qt has this, we should try it
<greyback_> duflu: qt has it's own input resampling indeed
<duflu> greyback_: Great. But if it's not turned on then turning off Mir's would be bad
<greyback_> but as unity8 written in qt, it means unity8 will be doing the resampling
<greyback_> it's turned on by default I believe (I don't think it can be turned off actually...)
<duflu> greyback_: Oh, so it just didn't exist back when Mir got resampling?
<greyback_> duflu: correct, it only appeared in qt5.4
<duflu> That definitely needs testing then.
<duflu> greyback_: Oh. It's not in RTM then
<duflu> Yet
<greyback_> yeah
<greyback_> rtm on 5.3 still
<duflu> greyback_: It's not in the 5.4 release notes... (?)
<greyback_> hmm, let me check I'm talking out of my ass
<duflu> afk
<greyback_> https://qt.gitorious.org/qt/qtdeclarative/commit/6dc8f47bb05a8acb3cbcc697e0dc05356a01d4cf <- there's the commit anyway
<greyback_> seems it wasn't noteworthy enough to mention in the release notes
<duflu> greyback_: How do you know that was the 5.4 branch? It was committed before the 5.3 release.
<greyback_> duflu: it was a guess
<duflu> Actually committed around the same time as 5.3 released. So probably 5.3
<duflu> Probably 5.4
<greyback_> duflu: found the branch in the qtdeclarative repo, it landed in 5.4
<duflu> greyback_: OK, retesting on a phone now
<duflu> greyback_: Yeah I think there is some benefit. At least scrolling is smoother than the default 55Hz. But we already knew that was a problem and fixed it in 0.13. Still, I think when Mir gets a client function to toggle resampling it's probably time to default to off
<greyback> bloody wifi
<greyback> duflu: what situations would a client want non-sampled input?
<duflu> greyback: If it can do a better job by virtue of its own multi-layered design (e.g. fingerpaint and coming soon: mir_demo_client_target).
<duflu> And games no doubt
<greyback> okies
<duflu> greyback: Basically anything that can process multiple input events (well) per frame
<RAOF> Such as Qt :)
<duflu> RAOF: Isn't it Easter for you already?
<kgunn> kdub: alf_ worth reading greyback_ and duflu's scrollback ^^
<kgunn> drives me crazy, we need to stop saying "that looks better" and measure
<greyback_> +1
<greyback_> QML_NO_TOUCH_COMPRESSION=1 will disable Qt's input "compression"
<kdub> yeah, it seems its valuable to configure mir's input sampling
<kdub> and also, +1 to quantified discussions of course
<alf_> kgunn: +1 for measure, but... there is still the unknown factor of things actually getting to the screen which we don't have a good way to measure, and essentially that is what counts
<kdub> alf_, I guess thats what that python+lttng stuff was intended to make easier?
<alf_> kdub: we can get closer with these, but there still may be issues in the display stack/hardware that we don't control
<tvoss> alf_, not sure we should block on that bit
<alf_> kdub: bottom line I guess is that "looks/feels better" is a valid, though subjective, metric
<kdub> alf_, sure, but we won't ever control that, and we have to start measuring somewhere :)
<alf_> tvoss: not saying that we should
<tvoss> alf_, if there is a significance difference between what is visible and what the numbers tell us -> big issue
<tvoss> alf_, kdub is Mir's resampling code instrumented such that we can do measurements on that?
<kdub> anpok?
<anpok> hm
<anpok> the resampling itself has not clear enter exit points afaik
<anpok> s/not/no
<tvoss> alf_, kdub I also noticed that we introduced a magic constant 55 Hz there. The original android approach allows the client to pass in the timestamp of the start of the last render pass, which makes a lot more sense
<tvoss> anpok, I'm pretty sure it has on the client side
<anpok> tvoss: well there is one point where it starts, to accumulate and another where it will send stuff.. I belive either of the points is missing
<anpok> but I might be wrong
<tvoss> not sure I understand that statement
<tvoss> anpok, mind pointing me to the tests for the resampling?
<anpok> we only have received_event .. and not event_passed_to_event_delegate
<anpok> as a trace point
#ubuntu-mir 2016-04-04
<Someone_Else> RAOF: Are you around?
<zzarr> will it be possible to get Mir up and running on a Dragonboard 410c in snappy core?
<zzarr> (in Xenial I should add)
<ogra_> at some point
<ogra_> (the kernel snap would need the necessary libs etc)
<bregma> zzarr, we have someone working on it, he says it's very close to functional but just not quite there yet -- maybe this week, maybe not
<zzarr> bregma, thanks for your response, sounds nice
<zzarr> I feel like Ubuntu is really moving in every way possible (it's a fast OS, it's a fast growing OS and the development is fast as well)
 * kdub wonders about the value of exposing Server::the_buffer_stream_factory
<kdub> when things fit together better if we just make the server api user open a session and then create the stream through that
<kdub> havent delved as deeply, but probably the same story with scene::SurfaceFactory
<greyback> mirout
<greyback> Could not connect to a display server: Failed to send message to server: Success
<bschaefer> thats ... a confusing message?
<greyback> good to know the error succeeded
<bschaefer> we succeeded in failing to send a message!
<alan_g> Failed to connect but succeeded anyway
<alan_g> (For some suitable value of "Success")
<bschaefer> haha
#ubuntu-mir 2016-04-05
<zzarr> duflu, thanks for your response about the Intel HD 3000
<duflu> zzarr: tis OK. That's what we're here for
<zzarr> I can hardly wait until I get the computer, it's an HP Probook 4330s with an upgraded CPU to a i7-2670QM and I will install a 480GB SSD + 8GB RAM :-D
<zzarr> does XMir work out of the box or do I have to configure it myself?
<duflu> zzarr: Xmir has been rewritten and is no longer designed as a full desktop replacement, but just a way to launch X apps in Mir. The Unity8 desktop is probably not ready for general usage but you can install it and switch between Unity7/8
<duflu> zzarr: Excellent timing for a new computer, with 16.04 coming
<zzarr> duflu, okey, it was the ability to run X-applications I wanted, but that should just work if I understood you correctly
<zzarr> duflu, yes, it is :-D
<zzarr> I will get it this week :-D
<duflu> zzarr: Also worth noting, Libertine/Puritine (the launcher we're developing to transparently run X apps) is under development and I hear under redesign too
<duflu> I don't know much about it. But am defacto maintainer of Xmir itself, which you can just keep running as an X server if you know how
<zzarr> duflu, okey, what is the preformance like with Xmir?
<duflu> zzarr: Quite reasonable, but not as good as native Unity7. On desktop it will default to high performance mode, but that is not stable. If in doubt use -sw to run it in stable software mode like we do on mobile
<zzarr> duflu, okey
<duflu> ... which will make it slower
<zzarr> duflu, it will.... I assumed that
<duflu> I'm working on performance enhancements that will benefit both Unity8 and Xmir right now. Although they're probably months away from release
<zzarr> duflu, 16.10?
<duflu> Yes
<zzarr> nice
<zzarr> duflu, could you help me later (when I got my new computer) to configure Xmir? (or is there a good tutorial?)
<duflu> zzarr: Yes, it's easy
<duflu> No official docs
<zzarr> duflu, thanks :-D
<zzarr> duflu, will Mir have a remote control possibility (like ssh -X ...)?
<duflu> zzarr: Nothing officially planned, but never say never
<zzarr> duflu, okey
<zzarr> duflu, how does Mir handle multiple GPU's? (Some laptops have that)
<RAOF> It doesn't, at the moment.
<zzarr> okey
<RAOF> It's on the near-term TODO list.
<zzarr> the one I'm buying have only the Intel card
<duflu> Fortunately RAOF is a sucker for punishment and working with that right now
<RAOF> There's nothing fundamentally difficult about making it work (all the hard parts have already been done; mostly in the kernel) it just requires providing the right interfaces and mushing them together.
<zzarr> RAOF, are you implementing it in such a way that one could plug'n'play a GPU? (like Thunderbolt 3 eGPU)
<RAOF> That should be possible. I'm not sure if the kernel will play nicely with GPU hot plug, though :)
<RAOF> For those playing at home, eglQueryDeviceStringEXT(devices[i], EGL_DRM_DEVICE_FILE_EXT) works better if you've actually filled in the devices array.
<duflu> I've been thinking external GPUs are going to become a hot topic. Possibly the simplest path to a VR-capable machine for many people (assuming they have Thunderbolt 3)
<zzarr> nice, I'm sure the kernel ether will play nicely or will in the future
<duflu> Because you could theoretically match Vive/Oculus requirements with a laptop that way
<RAOF> External GPU enclosures are surprisingly expensive.
<zzarr> duflu, that's true
<duflu> Expensive yes, but just a theoretical way to avoid large gaming rigs
<zzarr> RAOF, yes they are, but I think they will be less expensive as the demand increases
 * duflu doesn't see any reason why a cable and PCIe enclosure should stay expensive
<duflu> And power supply
<zzarr> I also think that there will be monitor/enclosure combos (all in one package)
<RAOF> That would be pretty cool, actually.
<duflu> Sadly requires prior investment in a very recent laptop. So nowhere near cheap
<duflu> Although I guess micro desktops will follow with USB 3.1
<zzarr> I thought of another thing one day, it would be awesome if Intel made a CPU with 2 M series cores (like the one in 12" Macbook) and a i5 or i7 quad core in one package in a 10" or 12" tablet
<duflu> I'm sure they have considered it and have Apple design reasons why it doesn't exist... yet
<RAOF> I don't think Intel fabs are set up for the low-power silicon process that would make that useful?
<zzarr> and you could dock it with a keyboard/mousepad part which had a bigger battery and a stronger GPU
<duflu> RAOF: The 12" Macbook is a reasonable proof of concept that it's catching up
<RAOF> AIUI ARM's BIG.little architectures make sense because they use a different process/silicon for the little CPUs optimised for low leakage power rather than low active power?
<zzarr> so when in tablet mode the M series core should be active and when in laptop mode the i5/i7
<zzarr> RAOF, yes, that's true
<RAOF> Why not just downclock/downvolt the i7 in tablet mode?
<zzarr> RAOF, that works too :-)
<duflu> That's a point. The larger cache of an i7 would still help
<zzarr> perhaps turning of 2 cores?
<RAOF> Race-to-idle is still a thing :)
<zzarr> what is that?
<RAOF> I think the current state of the art (for Intel, at least) is to run as fast as possible to process all the available work and then idle in an extremely low power state.
<RAOF> Hence race-to-idle.
<zzarr> ohh, I see
<RAOF> Hence the counterintuitive result that limiting the CPU clock rate usually doesn't save you power.
<RAOF> Because idle CPUs use much less power than even the lowest-power active state.
<zzarr> RAOF, a valid point
<zzarr> is it possible to suspend an application without suspending the hole system?
<RAOF> Yes; Ubuntu Touch does it all the time.
<zzarr> will the desktop do that too?
<RAOF> (SIGSTOP is the relevant piece of posix)
<RAOF> No, because it's got severe drawbacks (such as only your focused application being able to do anything at all) :)
<zzarr> RAOF, yea, you're right
<duflu> zzarr: You can do it any time:    'kill -STOP <pid>' and 'kill -CONT <pid>'
<duflu> Just be careful what you stop
<zzarr> RAOF, well the criteria for suspending/not suspending should be different for desktop
<zzarr> duflu, very
<zzarr> duflu, is it possible to hibernate an application too?
<RAOF> What's the difference between that and suspending it?
<duflu> zzarr: Not that I know of, but STOP will keep it frozen for the lifetime of the system (till you reboot)
<RAOF> (CRIU might be the google-sauce you're looking for)
<zzarr> suspending is stopping/hibernate is to save it to disk too
<RAOF> zzarr: https://criu.org/Main_Page
<duflu> SIGSTOP/ freezing all your processes since 1973
<zzarr> thanks for the link, interesting
<tjaalton> hi, anyone around to test mesa 11.2.0-rc4? I'd like to upload 11.2.0 to xenial today
<tjaalton> there shouldn't be any surprises, at least the mir-egl patch didn't need updates for this
<tjaalton> and if not, what would I need to do to test it myself?
<RAOF> tjaalton: Install it, fire up a unity8 desktop session?
<tjaalton> ah, too easy then :)
<tjaalton> might even have that installed somewhere..
<tjaalton> I see a bunch of segfaults due to banfdaemon, and a black screen
<tjaalton> oh and upstart taking most of cpu
<tjaalton> so banfdaemon and ibus-ui-gtk3 are segfaulting on unity8 startup here
<seb128> tjaalton, you mean bamf instead of banf? unsure why that would start under unity8, it's quite x11 centric I think and unity8 doesn't need a matching service that's built in u8/mir
<tjaalton> seb128: oh right, bamf
<tjaalton> I just installed unity8-desktop-session-mir and tried to start it
<tjaalton> but doesn't run
<seb128> not likely due to bamf or ibus
<tjaalton> so how to test it without hosing another laptop? does it run on qemu?
<tjaalton> lighdm looks all weird on this machine now
<tjaalton> better after reboot, but still can't select unity from it
<tjaalton> err, unity8
<tjaalton> huh, it got removed
<tjaalton> ok now I got something
<tjaalton> another password prompt?
<tjaalton> with a big circle
<tjaalton> ok it works, just kbd layout was wrong
<tjaalton> works as in the session runs, apps don't start
<tjaalton> how do I tell it should be this broken or due to something I did?
<tjaalton> there's the scopes window open, clicking browser or system settings opens a window which immediately closes
<duflu> tjaalton: Yeah the immediate closing is a known bug (ted owns it)
<duflu> At least one of them anyway
<duflu> It got mostly fixed in the past month or so tho
<duflu> ?
<tjaalton> ok, this is fresh xenial
<seb128> tjaalton, cgmanager needed to be active at some point, unsure if that's still true
<seb128> try to systemctl start it
<seb128> if it's not
<seb128> to see if that makes a difference
<tjaalton> wasn't running, doesn't help though
<seb128> :-/
<seb128> do you get anything in .cache/upstart/<job>.log
<duflu> Oh that's a cool test. A non-nested server has the same latency as a nested server if you just raise the buffer queue from 3 to 5
<tjaalton> seb128: which job?
<tjaalton> no log for cgmanager
<seb128> tjaalton, whatever you try to start
<seb128> ubuntu-system-settings for example
<seb128> webbrowser is known to not work atm I think
<tjaalton> nope
<seb128> rm .cache/upstart/*
<seb128> try to start settings
<seb128> see what gets written?
<seb128> also #ubuntu-unity is likely a better channel
<seb128> those issues are not mir ones
<seb128> you might get more people about the help in the unity team
<tjaalton> sure
<tjaalton> guess mesa is working fine so I'm fine :)
<tjaalton> er, happy
<seb128> :-)
<duflu> There are pixels. But they do not do as instructed.
<duflu> Pixels have been sufficiently herded though
<josharenson> I'm trying to get the greeter (running under mir) to launch a unity7 session (under X). It wasn't working before because of a lightdm bug, but I think I've fixed it, and now I get this exception in u-s-c's log http://pastebin.ubuntu.com/15637751/
<RAOF> josharenson: Hm. Looks like usc is giving up DRM master and then trying to change display configuration.
<josharenson> RAOF: Should it just stop when X is started?
<RAOF> If that's the plan, yes.
<RAOF> It should stop *before* X is started :)
<josharenson> RAOF: ok, so its likely a lightdm issue then I suppose (since lightdm is orchestrating all of this)
<RAOF> Possibly. USC also shouldn't try to change display configuration after being paused.
#ubuntu-mir 2016-04-07
<duflu> RAOF: That ShmBuffer branch has a FTBFS
<duflu> BTW
<duflu> FYI
<RAOF> Yeah, I'll get on to that.
<RAOF> I was rather hoping it was just CI being continually broken rather than having to work out how to reproduce it :)
<RAOF> If CI is now working, then yay!
<duflu> Yeah, I know I'm guilty of repeatedly trying to land things without noticing actual test/build failures are stopping it
<RAOF> If CI is consistently working now then I can try to fix it without spinning on spurious failures. (I wasn't able to reproduce the build failure locally, which was annoying)
<duflu> The good news is autolanding started working again yesterday within minutes of me deciding to land by hand.
<duflu> And then I stopped
<duflu> I don't think CI is consistently working though
<duflu> At least wasn't last night
<duflu> RAOF: This might help you (I've been thinking we might end up using it in Mir anyway): https://github.com/anholt/libepoxy
<duflu> https://launchpad.net/ubuntu/+source/libepoxy
<RAOF> duflu: Yeah, I might just use that.
<duflu> That would also allow us to swing between GL and GLES I think
<duflu> Which some older Intel GPUs seem to want
<RAOF> I don't think so? I think we use functionality only found in GLES?
<RAOF> It'd make it easier to swing, though.
<zzarr> hello!
<zzarr> I have my new computer now :-D (at home)
<zzarr> duflu, I tried Mir yesterday, but I got a problem, it's confused by the fact that my computer have 2 monitors (one internal on the laptop and one HDMI)
<duflu> zzarr: Which Mir server are you running?
<duflu> Our demo servers let you configure the multimonitor layout, but I don't think Unity8 has that feature yet(?)
<zzarr> duflu, I just installed unity8-desktop-session-mir
<duflu> zzarr: Yes, it's not ready for general use
<zzarr> duflu, lucky I'm not a general user then :)
<zzarr> duflu, I will test it again without the HDMI cable connected
<duflu> zzarr: Yes, that's more predictable. The missing feature is:  https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1401916
<ubot5`> Launchpad bug 1401916 in Ubuntu UX "[desktop] Configuration of screens positions and geometry" [Medium,Triaged]
<zzarr> duflu, I know that this question might be as simple to answer as when the first snow will come in the winter (here in Sweden, GÃ¤vle), but do you have any idea when it could be fixed?
<duflu> zzarr: Some things like multi-monitor, cursors, and window management are all more advanced in Mir itself (without Unity8). So if you want to get involved in Mir itself, remove Unity8 from the equation and build the lp:mir source. Or vice-versa if you want to improve Unity8 you can ask in #ubuntu-unity
<zzarr> duflu, thanks
<zzarr> duflu, what can I do with a mir-server without unity(8)?
<duflu> zzarr: You can hack the code, but it's not a desktop environment :)
<zzarr> :)
<zzarr> I ask this to get a better understanding for how it works, does an application connect to Mir in a similar way as a X-client to a X-server, but over a unix-socket instead of tcp/ip?
<duflu> zzarr: Yes it does
<zzarr> that would mean one could remote control a computer with the help of nfs/vpn in theory
<zzarr> duflu, is there a document describing the protocol used (I found one for X once, it "told" me bit by bit what was expected and how to respond)
<duflu> zzarr: No, the unix-socket only establishes the relationship to the server and then it's essentially shared memory (local machine only). However you can find the protocol information here: http://bazaar.launchpad.net/~mir-team/mir/development-branch/files/head:/src/protobuf/
<RAOF> Bear in mind that we reserve the right to break protocol at our merest whim.
<RAOF> libmirclient is the only supported mechanism for clients to interact with a Mir server. :)
<zzarr> thanks duflu
<zzarr> duflu, if I made a protocol for remote control (this might be a way to integrate Mir in to crouton/Chrome OS devices) would you be interested (to try it)?
<duflu> zzarr: Sorry, already overwhelmed
<zzarr> duflu, I understand
<zzarr> duflu, well I have to do it first
<zzarr> duflu, would a Mir client be a good start? (I meant should I write one as a tutorial)
<duflu> zzarr: Yes, the Mir source code has a few under examples/
<zzarr> duflu, nice, I'll download that then
<strahl> Hi, will be MIR ready for 3d games on Nvidia cards in 16.04 release?
<strahl> with official driver, or with nouveau
#ubuntu-mir 2016-04-08
<hallyn> hi - is there a way in unity8/mir to make capslock be control?
#ubuntu-mir 2016-04-09
<strahl> Hi, will be MIR ready for 3d games on Nvidia cards in 16.04 release? If not with proprietary driver, at least with nouveau.
<hallyn> so...  any way to make capslock into control in mir?
#ubuntu-mir 2017-04-03
<alan_g> alf: FYI MirAL just had its first "autolanding" - it worked. Thanks again for sorting that out.
<alf_> alan_g: yw, glad it worked without issues
#ubuntu-mir 2017-04-04
<Son_Goku> tvoss: I don't suppose you know if any progress was made on merging those libinput patches upstream?
<Son_Goku> libinput 1.7.0 was just released into Fedora 26 and Rawhide last week, so I'm really hoping some progress was made...
<tvoss> Son_Goku: I'll check
<greyback> anpok_: could you have a look at this: https://code.launchpad.net/~andreas-pokorny/qtmir/keep-mir-types-alive/+merge/321427/comments/843232
<anpok_> greyback: oh .. that will have the same problem
<greyback> anpok_: so qtmir explicitly has to keep input hub alive. I find that extremely strange. Does qtmir need to use this wrapper?
<greyback> alan_g: ^ you might be interested
 * alan_g looks
 * alan_g still does not understand
<alan_g> greyback: I'll look again when I have headspace
<greyback> alan_g: just keeping you in the loop, no action required
<alan_g> It still looks like solving a symptom, not solving the problem.
<greyback> I suspect the wrapper is confusing things
 * alan_g realizes this is the same area he is about to change for D&D
<alan_g> anpok_: IIUC it is only the "input hub" wrapper that QtMir needs to own? Not the other four components?
<alan_g> That still sounds wrong (as in "leaky abstraction"). But makes more sense.
<alan_g> greyback: anpok_ https://code.launchpad.net/~andreas-pokorny/qtmir/keep-mir-types-alive/+merge/321427/comments/843550
<anpok_> alan_g, greyback: ok
<alan_g> anpok_: I'm about to MP a fix in Mir
<anpok_> just in time..
<anpok_> I havent start that branch yet
<anpok_> *ed
<alan_g> There's no guarantee you'll like my solution
<alan_g> anpok_: https://code.launchpad.net/~alan-griffiths/mir/preserve-ExternalInputDeviceHub/+merge/321845
<anpok_> why not own it inside display_server.cpp?
<anpok_> hm config changer is transitively the same
<alan_g> Well, the server object doesn't own everything directly and ConfigChanger also owns what EIDH wraps.
<anpok_> ok
<Son_Goku> tvoss: any progress?
#ubuntu-mir 2017-04-05
<duflu> robert_ancell: Hey can you let me know which commit the latest Xmir release went up to? I was committing changes up to last night so imagine it's not fully up to date
<robert_ancell> duflu, I don't know off hand, look at the changelog to work it out?
<duflu> robert_ancell: I can probably figure it out from the source code then. Thanks
<robert_ancell> yeah, I'd be doing the same thing
<duflu> It's not like there's a huge number of bugs closed, but it's more than zero
<duflu> alf_: CI is unhappy today. Keeps aborting
<duflu> 03:42:44 Waiting for the completion of device-runtests-mir-testflinger
<duflu> 06:29:13 Build timed out (after 180 minutes). Marking the build as aborted.
<alf_> duflu: thanks, I'll look into it... probably some job has blocked the krillin device we are using
<alf_> duflu: yeah, so https://mir-jenkins.ubuntu.com/job/device-runtests-mir-testflinger/186/ is stuck and has blocked everything after that. Unfortunately, testflinger doesn't support timeouts or the ability to abort yet, so although we abort in jenkins there is no automatic way to unblock the actual testflinger device without manual intervention
<alf_> duflu: plars is working on this
<alf_> duflu: adding a per job timeout for testflinger jobs
<duflu> OK, thanks. I'm not bothered... finished Xmir fullscreen mode support now. My day is ahead of schedule
<duflu> Bonus: You can now bypass X apps
<alan_g> anpok: does this mean you know where the bug is? And how to fix? https://code.launchpad.net/~alan-griffiths/mir/preserve-ExternalInputDeviceHub/+merge/321845/comments/844127
<alan_g> (I don't follow the explanation.)
<anpok> alan_g: no not that was a suspicion.. as I looked at the checkout I realized that it does not happen during shutdown..
<anpok> I assumed that the hub gets destroyed while at the same time the input devices get removed..
<greyback> alan_g: this might interest you: https://code.launchpad.net/~gerboland/qtmir/refactor-opengl/+merge/322023
<alan_g> greyback: looking
#ubuntu-mir 2017-04-06
<AdamH> Hello all, I am trying to create a snap using the mir-kiosk-apps demo but can't get snapcraft to complete. I am following the instructions at https://developer.ubuntu.com/en/snappy/guides/mir-snaps/
<AdamH> Staging qtchooser-config
<AdamH> Staging qmldemo
<AdamH> Priming qt-examples
<AdamH> [Errno 2] No such file or directory: '/home/adamheavens/mir-kiosk-apps/stage/qt-demos/photoviewer/photoviewer'
<AdamH> but keep getting the above error
<AdamH> Any ideas?
<alan_g> AdamH: the guys that know this best are in the USA, so offline. I'm guessing that the contents of the snapcraft.yaml are out of step with the contents of qt-examples.
<AdamH> Thanks will take a look at snapcraft.yaml and see what I can figure out.
<alan_g> anpok_: FWIW I think I tracked down the ExternalInputDeviceHub race
<anpok_> ok?
<anpok_> havent looked again yet
<alan_g> anpok_: let's give CI a chance first
<alan_g> attente: the gtk release that just landed is nice work.
<alan_g> I can now (just about) run an Impress presentation on miral-desktop, which was my goal for the ACCU conference in a couple of weeks.
<attente> alan_g: great! a bit of a pity given yesterday's news though...
<alan_g> I know. I wonder if that news gets me a bigger or smaller audience.
<alan_g> Certainly means I need to rework a few things
 * Laney hugs #ubuntu-mir
<AdamH> Hello, does anybody have a simple hello work program that uses mir and Qt as a snap package? Trying to learn all the moving parts but can't get mir-kiosk-apps to create a snap using snapcraft
<alan_g> AlbertA: ^
<AlbertA> AdamH: what issues are you hitting?
<AdamH> AlbertA: I am following the instructions at https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ but get the following error when running snapcraft [Errno 2] No such file or directory: '/home/adamheavens/mir-kiosk-apps/stage/qt-demos/photoviewer/photoviewer'
<AlbertA> AdamH: which version of ubuntu are you using? I usually use an lxd container with xenail + the overlay ppa
<AlbertA> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay
<AdamH> I am using xenail. I will have a look at the overlay ppa, thanks.
<AdamH> AlbertA: Thank you sir, worked without issue once I installed the overlay ppa!
<AlbertA> AdamH: great!
<AdamH> ls
#ubuntu-mir 2017-04-07
<duflu> robert_ancell, I was in the middle of an Xmir adventure before the news and now have a bunch of fixes committed. Shall we release them?
<duflu> bregma__, ^ ?
<robert_ancell> duflu, release xmir?
<duflu> robert_ancell: Yes
<robert_ancell> duflu, into zesty? It's closed
<duflu> Oh, of course
<duflu> I always fail to check the schedule
<duflu> Pity. I think I did more Xmir work these past two days than the rest of the past year
<bregma__> it'll still be there to release into Z+1 if we get the chance
<duflu> No problem. Releasing the work is slightly less important than having a large task half done.
<duflu> or half undone
<alan_g> AlbertA: what time zone are you in today?
<AlbertA> the same one as yesterday :)
<alan_g> Trouble sleeping?
