#ubuntu-mir 2013-03-18
<robert_ancell> RAOF, did you look at https://code.launchpad.net/~vanvugt/mir/super-simple-connect/+merge/153307?
<RAOF> I had not; looking.
<RAOF> Google Mock: Fuzzing g++ since 2012
<RAOF> Bah! The android build is broken?
<RAOF> kdub: I'm having problems with the android build. Here?
<alan_g> alf_: have you looked into the trunk failure to build for android?
<mmrazik> hello
<mmrazik> are you guys aware mir fails to build in PPA?
<mmrazik> https://launchpadlibrarian.net/134529318/buildlog_ubuntu-quantal-amd64.mir_0.0.2bzr507quantal0_FAILEDTOBUILD.txt.gz
<mmrazik> I don't quite see why it was ok in jenkins :-/
<mmrazik> it looks like r505 is the first one that started to fail
<alan_g> mmrazik: that's https://code.launchpad.net/~alan-griffiths/mir/fix-bug-1156543/+merge/153740
<mmrazik> great
<alan_g> mmrazik: it was OK as we build with input in CI and without for PPA
<mmrazik> I see
<mmrazik> should we just add a build without input as well?
<alan_g> There are too many options that we don't test - is on my TODO list (but low down)
<alan_g> mmrazik: Please feel free
<mmrazik> alan_g: ok
<alan_g> mmrazik: we break the android target even more often
<mmrazik> alan_g: yeah... android is on my list. I can add the crosscompile easily (like in 5 minutes). I'm having some troubles with running the tests on the phone
<mmrazik> I'll just add the compile
<mmrazik> better than nothing
<alan_g> mmrazik: even if it didn't run (oh you said that)
<mmrazik> alan_g: I was overly optimistic with those 5 mins :-/ It used to work last week but there is a new dependency (glog) and jenkins is unable to find it. Need to ping kdub later where am I supposed to get it
<alan_g> mmrazik: the glog dependency shouldn't have landed
<mmrazik> alan_g: its in kdub's ndk script
<mmrazik> alan_g: which is called from the cross-compile script
<alan_g> mmrazik: I see. (I fixed glog for raring+armhf - not sure where we are on quantal)
<mmrazik> alan_g: so maybe all we need to do is to remove the dep from lp:~kdub/mir/ndk-rewrite for now
<alan_g> mmrazik: I'd guess so. kdub will know what the current status is
<mmrazik> ack
<kdub> good morning
<racarr> Morning
<kdub> mmrazik, the line that has glog for me in my sources is "deb [arch=armhf] http://ports.ubuntu.com/ubuntu-ports/ raring main restricted universe multiverse"
<mmrazik> kdub: so its not supposed to build on quantal?
 * mmrazik tries with raring
<kdub> mmrazik, good point... i haven't sorted out where the quantal package is
<kdub> mmrazik, we should only build for quantal because thats the only environment we have to run on
<kdub> mmrazik, would it ease what you're doing if i roll back that change?
<mmrazik> kdub: I'm trying to add android build (using the cross-compile script) to the ci/autolanding process
<kdub> yay
<mmrazik> I don't really mind if it is running on raring or quantal
<mmrazik> kdub: if quantal makes more sense then we need to resolve the dependency somehow (possibly reverting it)
<mmrazik> kdub: the compilation started on raring
<mmrazik> so it seems to be fine there
<kdub> mmrazik, it should build on both... we just don't have a raring phablet image to test the result on
<mmrazik> kdub: I'm struggling with the phone anyway :-/ So let me add the raring build (without tests) for now
<alan_g> racarr: kdub could someone look at  https://code.launchpad.net/~alan-griffiths/mir/fix-bug-1156543/+merge/153740 ASAP
<kdub> mmrazik, sounds good, getting the raring build (minus tests) under ci is a good first step
<racarr> alan_g: approved
<alan_g> racarr: ta
<kdub> oh, standup today: working on unblocking the glog branch, hope to mp my branch for android display construction
<kdub> will get my nex7 working again too
<racarr> hrm "        the_frontend_shell() override
<racarr> " ?
<racarr> test_focus_management_api.cpp
<racarr> this doesn't work with my GCC
<alan_g> racarr: are you still using 4.6?
<racarr> 4.7.2
<alan_g> racarr: I don't believe you
<racarr> this is an old branch so maybe the build directory is so old its on 4.6
<racarr> I will try that
<racarr> I believe me though I have tried to add
<racarr> override in the past to
<racarr> testing server configuration overrides
<racarr> but my GCC never supported it
<alan_g> 4.7 does
<racarr> ok yep it was an old build directory is all :)
<racarr> alan_g: Fixed header installation in prepare-for-inprocess-egl (r508)
<alan_g> racarr: ack, just finishing off some renaming changes and will look
<racarr> alf_: ^
<racarr> You still have a dissaprove on prepare-for-inprocess-egl
<racarr> if you can take a look
<racarr> needs fixing*
<kdub> hello philipballew
<philipballew> hey kdub
<philipballew> be back, reboot time
<racarr> alan_g: Updated prepare-for-inprocess-egl-clients again to fix android build
<racarr> was just some unmerged test structure reorg
<racarr> havent tested myself yet though chroot is still updating
<kdub> alan_g, with the google log package, armhf/quantal seems to be broken https://launchpad.net/ubuntu/+source/google-glog
<kdub> alan_g, would you know who to ping about that?
<alan_g> racarr: Just offered up the refactoring we discussed Friday - https://code.launchpad.net/~alan-griffiths/mir/refactor-shell-cleaner-Surface-class/+merge/153851
<alan_g> kdub: looking...
<kdub> maybe seb128 ?
<racarr> alan_g: Looking
<alan_g> kdub: seb128
<seb128> kdub, can't you use the raring version?
<seb128> quantal is "stable", e.g not an active serie
<seb128> work is not happening on it
<seb128> we could SRU a fix if really needed though...
<kdub> seb128, the phablet builds are still quantal
<kdub> makes installing/compiling mir on quantal easier
<kdub> but i don't know how much effort an sru is though
<seb128> I don't think that deb has lot of depends, just wget and dpkg -i it on quantal if needed
<seb128> sru ... needs the fix to be uploaded, reviewed, validated, stay a week in staging for verification and then hit -updates
<seb128> it's not a ton of work but we try to not spent time on quantal at this point
<kdub> seb128, yes, it looks like the download/dpkg -i is the easier route to go
<racarr> err. looking for real now
<dank101> Hola
<UbuPhillup_> dank101: hallo
<racarr> alan_g: Ok got comically distracted but just now went through refactor-shell-cleaner-surface-class
<alan_g> racarr: amusing
<racarr> it looks good and clears up the tests...it took me a few reads though...I think the naming SurfaceSource/SurfaceBuilder
<racarr> is kind of unclear
<racarr> and I wasn't sure what to expect from the types
<alan_g> racarr: any help with the names gratefully received
<racarr> I wonder if SurfaceBuilder is 'SurfaceOwner'
<racarr> that is how It hink of it
<racarr> Really its like a SurfaceOwnerController but that's unhelpfully verbose
<racarr> it's also very much like a SurfaceManager ;)
<kgunn> racarr: surfaceCoordinator?
<racarr> I am not sure. Don't want to block on it I think but wanted to see if we could come up with an idea because while I think SurfaceBuilder provides a good description
<alan_g> racarr: I'm not sure that really helps (but open to persuasion). At least part of the problem is that surfaces::Surface and shell::Surface are confusing names
<racarr> of what the class does within shell:: it doesn't clarify the relationship between surfaces and shell and the ownership model (which is the primary purpose of this class)
<racarr> so I think between the controller, source, and builder there is a lot of ambiguity of responsibility
<racarr> kgunn: Maybe...that's sort of what the object is but not necessarily what it exposes to shell::
<racarr> alan_g: shell::Window
<alan_g> racarr: as alf keeps pointing out the design talks about surfaces
<racarr> a window is a surface with a certain ownership model, an input channel, window management metadata (state...) etc.
<racarr> hmm
<alan_g> Maybe we can edit the design?
<racarr> I think
<alan_g> I am
<racarr> the distinctin between surface and window is a useful one to make
<alan_g> racarr: Sure
<racarr> because...hmm...haven't made this concrete yet
<racarr> but I am imagining the shell might wnat to create surfaces for certain effects or components
<racarr> that are nothing like windows
<racarr> and should be a surfaces::Surface and in the surface stack
<racarr> but are not a shell::Window
<racarr> is it
<racarr> a SurfaceArbitrator?
<racarr> I think that's my last idea.
<alan_g> racarr: who do we ask why the design talks about *surfaces*? Is that just an assumption about implementation?
<racarr> Hmm. I dunno. I will try and find out
<racarr> katie: ^
<racarr> alan_g: My impression, is even as an assumption about implementation, it doesn't really assume much right?
<alan_g> racarr: Because if we can line up the terminology as "windows" it reduces the overloading.
<racarr> what is a surface ;) how is it different from a layer? how is it different from a window?
<katie> racarr, alan_g, i used surfaces because we wanted to move away from assuming things were windows
<racarr> I think surface is just a word we
<racarr> like
<racarr> katie: We own the definition of window though
<katie> i think that it helped us iearly on to move away from our old way of thinking
<katie> early
<alan_g> Hmm, so maybe surfaces::Surface is the one with a wrong name
<katie> racarr, i don't know what you mean
<racarr> katie: I mean, there is nothing we have to
<racarr> assume by calling things windows
<racarr> because we are defining that word by behavior
<racarr> katie: the context, btw is about windows being a kind of surface.
<racarr> alan_g: Hehe. I like
<alan_g> katie: We'd like to get clear terminology and at the moment we've two meanings for "surface" within mir
<racarr> layers::Layer, but I think that's
<racarr> just because I like the word layer
<alan_g> racarr: I don't think layer does it - too much baggage
<racarr> mm.
<alan_g> racarr: tile has a different sort of baggage
<racarr> scenegraph::?
<racarr> surfaces is like a scene graph, shell is the controller and compositor is the view
<racarr> but
<racarr> it's shell that cares about words like
<katie> alan_g, racarr , from my point of view surface implies something more generic than a window
<racarr> "Surface" or "Window" 'sufaces/scene gaph'
<katie> but I did not assume any particular implementation :)
<racarr> only cares about what appears on the screen
<racarr> <not convinced....brainstorm>
<racarr> katie: One of the thoughts is everything an application makes is a window whereas
<racarr> the shell may want to create more general surfaces
<alan_g> katie: agreed
<racarr> I could be
<racarr> I dunno
<racarr> I tend to think of surface as a more generic window too but
<racarr> I could be just as easily convinced that a surface was a subregion of a window or something else
<alan_g> racarr: we rename "surfaces" to "scenegraph" and "surfaces::Surface" to "surfaces::Page"?
<alan_g> racarr: we rename "surfaces" to "scenegraph" and "surfaces::Surface" to "scenegraph::Page"?
<racarr> which makes me think that the words really aren't that useful
<racarr> alan_g: Hmm...I dunno about page...why page?
<alan_g> racarr: don't like "surface", "layer", "tile", tried something else...
<racarr> :)
<racarr> scenegraph::Node is a little jarring at first when you think about
<racarr> the shell/surfaces interaction as it is written now
<racarr> but maybe it makes sense, a
<alan_g> I think Node is a bit too general
<racarr> shell::Surface is a scenegraph node with certain behavior
<racarr> mm
<racarr> because in particular it's
<racarr> a renderable target or something
<racarr> to that effect.
<alan_g> <cough/> as now written shell::Surface has a surfaces::Surface
<racarr> hmm
<racarr> I liked the idea of scenegraph...but now I am looking for a word for this "renderable target" concept, i.e. with swappable color buffers, etc
<racarr> and the only convention really (from dri, etc)
<alan_g> "image"
<racarr> is "Surface"
<racarr> i.e. this is the terminology in mesa etc
<racarr> alan_g: It seems strange for an Image to have a buffer swapper
<alan_g> ack
<racarr> I think I like the most shell::Window and surfaces::Surface
<racarr> I would be almost inclined to say scenegraph::Surface
<racarr> because the shell, can then insert in to the scene graph say
<racarr> a scenegraph::Image
<racarr> as an overlay or some such
<racarr> but
<racarr> it's kind of an imagined case for now
<racarr> a possible concrete example of
<alan_g> racarr: should we land the current version and continue to think about names? (Because I don't think the latter is zeroing in yet.)
<racarr> a non window surface, is a software cursor
<racarr> it could either just be drawn by the compositor (through ijecting PointerController)
<racarr> or it could actually be modelled in the scene graph as an element
<racarr> I think this simplifies the model for implementing compositor:: but
<racarr> it really depends, do we have a SurfaceStack or a SceneGraph?
<racarr> alan_g: Hmm I think so
<alan_g> I think we *should* have a scenegraph
<racarr> me too :)
<alan_g> (Relatively simple compared to those in gaming engines)
<alan_g> "scenegraph::Facet"?
<racarr> alan_g: For April fools I want to implement a mir compositor on the Unity3D game engine
<racarr> just to really mess with people...
<alan_g> racarr: you need to b e quick
<racarr> maybe next year
<racarr> Facet is kind of general
<racarr> it sounds more like something the compositor sees
<racarr> than the shell
<racarr> i.e. something you look at but not touch
<alan_g> racarr: the shell is mostly working with shell::Surface (which has a scenegraph::Facet)
 * alan_g isn't really convinced
<racarr> hmm. it's a good thought
<racarr> does shell::Surface modify the scenegraph::Facet or is it all through a controller?
<racarr> I think it doesn't capture the fact that it has
<racarr> advance_bufer and get_buffer_ipc_package though
<racarr> or perhaps once we redo the API it just has next_buffer
<racarr> scenegraph::Buffers
<racarr> scenegraph::AdvanceableBuffer
<alan_g> racarr: I'm approaching EOD - so have to leave it to you for now.
<alan_g> I think that tries to capture too mcu
<racarr> hehe ok
<racarr> thanks for chatting :)
<alan_g> *much
<racarr> mm...
<racarr> Hopefully it will come to me
<alan_g> racarr: it is good to talk. Maybe you can find someone else with the right idea in a different timezone.
<racarr> Have a good evening
<racarr> Mm
<alan_g> Have a good day
<racarr> kdub: Could your android bug you just filed be about the input stuff in frontend?
<kdub> racarr, just updated with details
<kdub> was just going to ping you to advise :) https://bugs.launchpad.net/mir/+bug/1156749
<ubot5> Launchpad bug 1156749 in Mir "example clients in rev508 do not connect" [Critical,In progress]
<racarr> kdub: The problem is DummyInputManager server/server/input returns
<racarr> null mi::InputChannel I guess
<racarr> but hmm that should be fine...
<racarr> kdub: I will look at it soon
<racarr> zoned in atm
<racarr> kdub: Unless it is blocking you :)
<kdub> racarr, it will start generating a lot of question marks, so its best to fix asap
<kdub> racarr, i mp-ed up a fix
<racarr> kdub: Ah...actually
<racarr> the code is in error...I guess a committ was lost
<racarr> it should be if
<racarr> surface->supports_input()
<racarr> response->add_fd(surface->client_input_fd())
<racarr> sorry to not look sooner...was unwinding a big "make this test compile list"
<racarr> also branch contains extra commented out lines
<kdub> racarr, ah ok... could you upload over? (i pushed to a team branch)
<racarr> kdub: https://code.launchpad.net/~mir-team/mir/fix-surface-creation-when-input-disabled/+merge/153912
<racarr> pushed changes and approved you should approve and change to approved
<racarr> (How many approvables could an approver prove if an approver could approv approvables?)
<racarr> We may never know
<kgunn> racarr: same as licks on a tootsie-pop
<kgunn> racarr: i just realized age gap on my comment http://www.youtube.com/watch?v=0UYvsk6_foc
<racarr> I remember these commercials :)
<kdub> racarr, i have a half written test for this condition, i'm going to finish that up and upload at the same time
<racarr> kdub: Great!
<kdub> racarr, pushed, but we'll wait for jenkins and another review
<kdub> since we both have committed to the branch
<racarr> since my dist upgrade yesterday
<racarr> most shared_ptr errors generated internal compiler errors
<racarr> rather than line numbers :(
<racarr> line numbers were a crutch anyway
<racarr> kdub: Test looks good
<racarr> kdub: Though the name made me expect to see a test that
<racarr> replicated the failure scenario
<racarr> err hmm
<racarr> nvm I had a backwards in my head
<robert_ancell> RAOF, "Also unlike XCB and Xlib, it's programmatically generated from the protocol definition". I guess XCB sort of solved that problem by rewriting the spec in a programatic way
<kdub> robert_ancell, quick review? https://code.launchpad.net/~mir-team/mir/fix-surface-creation-when-input-disabled/+merge/153912
<robert_ancell> kdub, looking
<kdub> thanks
<robert_ancell> kdub, yeah, looks good to me
<robert_ancell> kdub, you want me to set the master status?
<kdub> robert_ancell, won't hurt, should be fixed in short order though
<robert_ancell> tvoss, Was your issue in https://code.launchpad.net/~robert-ancell/mir/server-headers/+merge/153281 resolved?
<robert_ancell> racarr, also ^
<racarr> I hate it when tests pass and htey arent supposed to
<robert_ancell> racarr, do you need to review this https://code.launchpad.net/~afrantzis/mir/multi-threaded-compositor-synced-with-trunk/+merge/153661? It says your review is "pending"
<kgunn> robert_ancell: was just noticing the same ^
<racarr> robert_ancell: I approved the old version...am just abstaining now...trying not to get distracted :)
<racarr> I am happy for it to land I looked over the weekend briefly but didn't approve because it was brief
 * kdub is still reviewing multithreaded compositor branch
<racarr> brb lunch
<robert_ancell> kgunnAFK, can you change the drafter on https://blueprints.launchpad.net/ubuntu/+spec/client-1303-qt-mir-backend?
<robert_ancell> alf_, can you change the drafter on https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-glmark2 to mir-team?
<robert_ancell> kgunnAFK,  and also https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-galaxynexus
<kdub> i ticked multithreaded compositor to 'approved to land'
<racarr> Back
<racarr> send-clients-input is 16/19 todos finished XD
<racarr> maybe its done growing...
<RAOF> robert_ancell: Right. You write a machine-parsable version of the protocol for XCB, and then codegen from that.
<robert_ancell> kdub, nice
<kgunn> robert_ancell: ack will do
<kgunn> robert_ancell: hey...more clean up, can you make me (or you) the "assignee" to https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-converged
<robert_ancell> kgunn, I set the drafter to mir-team, does that work?
<kgunn> robert_ancell: no, bill filler wanting a name there...just put me
<kgunn> why i have no idea
<robert_ancell> kgunn, can you do it now I changed the drafter?
<kgunn> robert_ancell: real time/live race condition :)
<kgunn> had to refresh page
<robert_ancell> heh
#ubuntu-mir 2013-03-19
<robert_ancell> RAOF, did you flash your nexus 4? Any gotchas?
<RAOF> robert_ancell: Yeah, I've flashed my nexus 4. No gotchas that I can remember.e
<RAOF> Except that you can't keep the screen off but the device on, so it's less interesting as a build box than I hoped :)
<robert_ancell> RAOF, because it emits too much light?
<RAOF> robert_ancell: No, not really. It's aesthetically displeasing.
<RAOF> I could totally use it as a buildbox.
 * robert_ancell hears the worlds smallest violin
<ogra_> just turn the brightness to 0
<ogra_> there is a sysfs handle for it
<RAOF> Oh, nifty.
<ogra_> (its just linux ;) )
<ogra_> though i wouldnt recommend to build on an eMMC/SD card
<duflu> I wonder how that compares to using the Nexus 7 as a build box (which I found quite successful)
<ogra_> the SoC is definitely a lot more powerful
<duflu> Though if you can cross compile from a PC, that wins
<ogra_> but you dont have USB host mode ...
<ogra_> well, for packages that are designed for cross building, thats true
<RAOF> Sounds like a job for sshfs!
<duflu> Why do you need USB host mode when you have scp/rsync? :)
<ogra_> well, sshfs/rscny over wlan ...
<ogra_> could use plain nfs as well, i guess that would be faster ...
<duflu> Yeah wifi's not much worse than USB 2.0
<ogra_> but if these are the chouces i'd actually take the MMC
<ogra_> *choices
<ogra_> though stilll, a chromebook is $250 ... and comes with  USB 3.0
<duflu> Ugg. New keyboard. I'm very slow now. Please be patient.
<RAOF> Ah, *there* we go - /sys/class/backlight/lm3530/device/lm3630_backlight_on_off
<ogra_> if you want a serious device to do native arm builds thats the way to go
<RAOF> Is building on the MMC likely to kill the flash quickly?
<ogra_> nah, i doubt you will manage that in the time you own the phone
<ogra_> but its slow I/O
 * duflu wonders what's wrong with the existing Mir cross-compile script
<ogra_> if your build requires at least some disk I/O it will have quite some impact
<ogra_> duflu, in the end it will be packaged and have a bunch of dependencies ... and that means native builds
<ogra_> while you build raw upstream code and are sure you have a cross bits in place thats different
<ogra_> s/a/all/
<ogra_> cross building packages with a dependency chain is trickier :)
<TheMuso> RAOF: Do you not have a pandaboard at your disposal? Would that not be a suitable build board?
<duflu> TheMuso: Pandas are hopelessly slow. Nexus 7 blows it out of the water and supposedly Nexus 4 is similar
<duflu> ogra_: Thanks you made me realise I can finally buy Chromebooks in Australia. But $349 :P
<TheMuso> duflu: Rotery disk is better than flash for building no?
<TheMuso> At least there is that option with panda.
<TheMuso> But I guess you could use rotery with the Nexus7.
<TheMuso> duflu: And out re Chromebooks in Australia.
<TheMuso> s/out/ouch/
<duflu> TheMuso: It's true the bottleneck on Nexus 7 is slow flash. But I recall that the panda having only two cores (and slower) was a bigger issue compared to the 4-core Tegra3
<TheMuso> Fair enough.
<TheMuso> I guess we need better dev boards then. :p
<duflu> Well if ARM servers with far-too-many-cores are now real products then that would be a good build solution, surely... ?
<duflu> I think it was HP talking about such products in Copenhagen.
<duflu> www.hp.com/go/moonshot
<duflu> Of course, that's for Ubuntu builds. Not your desk ;)
<robert_ancell> RAOF, does installing the PPA mesa hose the phablet UI?
<RAOF> robert_ancell: I don't see why it would.
<RAOF> robert_ancell: Does it? :)
<robert_ancell> RAOF, we'll find out soon...
<duflu> Surely surface-flinger does not depend on Mesa library paths....
<duflu> Or anything "Mesa"
<RAOF> Also, the PPA mesa shouldn't break anything that depends on Mesa *anyway*
<duflu> True. My laptop still works with Ubuntu goodness
<duflu> What's the _eventual_ preference for stride? Should it always represent #bytes or will it become #pixels?
<duflu> (with respect to MirGraphicsRegion)
<alf_> duflu: bytes
<RAOF> Bytes is probably more useful, yeah.
<duflu> alf_: Ta. And good morning
 * alf_ notices that we now have an Android CI job (the buildng part of it, at least)
<tvoss> alan_g, ping
<alan_g> tvoss: ?
<alf_> alan_g: fyi, I am working on changing render-surfaces to use DisplayServer(Configuration)
<alan_g> alf_: Excellent!
<racarr> Mew
<racarr> Morning :)
<alf_> racarr: Hello
<alan_g> racarr: Hello
<racarr> alan_g: Hi
<racarr> alan_g: Btw wanted to ask you...seen any weird segfaults with
<racarr> droidinput::sp, droidinput::Vector and finally the android atomics?
<racarr> I thought I was going to make my big integration test for input branch pass last night and now segfaults in android atomics
<racarr> tried with and without android types
<alan_g> racarr: I haven't
<alan_g> Is this a hybris/android target?
<racarr> alan_g: No native x86
<alan_g> Not seen it. Want me to look? (Yet.)
<racarr> alan_g: I will try and make a reduced test case later. I haven't spent so much time on it yet
<racarr> I was just hoping it sounded familiar
<alan_g> Sorry to disappoint you
<racarr> deciding what to do with prepare-for-inprocess-egl-clients now
<racarr> :) no worries
<racarr> it is weird because the android doesn't really need
<racarr> a NativeDisplayContainer
<racarr> so it would be possible to write the
<racarr> mir_egl_native_display_is_valid using
<racarr> an ifdef (just mir_connection_is_valid) on android
<racarr> seperate versions of mir_egl_native_display_is_valid
<racarr> or an android implementation (which is rather trivial)
<racarr> but seems kind of like a verbose way to do nothing
<alf_> status: investigating a graphical glitch in the WIP code to change render-surfaces to use DisplayServer(Configuration)
<racarr> alf_: Any opinions on what to do with android for NativeDisplayContainer?
<racarr> I am inclined to just move the definition of mir_toolkit::mesa_native_display_is_valid
<racarr> to android/gbm
<alf_> racarr: let me refresh my memory
<racarr> alf_: :) Don't feel like you have to process it immediately
<alf_> racarr: it would be refreshing change from trying to debug a graphical glitch :)
<racarr> Aha...I know the feeling
<racarr> the basic issue is pretty simple, mir_egl_native_display_is_valid uses mcl::EGLNativeDisplayContainer::instance which is defined in the gbm bits
<racarr> along with the implementation of EGLNativeDisplayContainer
<racarr> trying to decide if android should also implement EGLNativeDisplayContainer (seems unnecessary)
<racarr> or one of these other approaches should be used
<hikiko> hi
<alf_> racarr: It would be a dummy implementation, so I don't see the harm in doing it this way. It would move the complication to the build system instead of the code.
<alf_> racarr: (almost dummy implementation)
<racarr> hmm
<racarr> Im not sure which way to do it though (using the build system) so now I am kind of leaning
<racarr> to just implementing the display container haha
<alf_> racarr: IIRC, The only symbol that the rest of the code needs mcl::EGLNativeDisplayContainer::instance(), so defining it in src/client/android/android_native_display_container.cpp should do the trick
<racarr> alf_: But it wants an instance of EGLNativeDisplayContainer returned
<racarr> so have to write a little android stub
<racarr> thats what I just did though :)
<alf_> racarr: right, and great :)
<alf_> racarr: perhaps Kevin will find the abstraction useful and use it more extensively in the android backend
<racarr> thats what I am thinking
<racarr> alan_g: prepare-for-inprocess-egl-clients is updated
<racarr> android build works :)
<alan_g> racarr: I'll look soon
<racarr> Going to change https://code.launchpad.net/~robertcarr/mir/happy-monday-dedupe-more-stubs/+merge/153713 to approved if no one objects soon :)
<alan_g> racarr: It will conflict with something I'm working on - but that's life
<racarr> What are you working on?
<racarr> hmm actually I need
<racarr> another approve, I think no review since I merged trunk
<racarr> I dunno if someone wawnts to review...
<racarr> changes at 190-211 came in during trunk merge
<alan_g> racarr: https://code.launchpad.net/~alan-griffiths/mir/refactor-frontend-Surface-cleanup/+merge/154138
<alan_g> racarr: looking at prepare-for-inprocess-egl-clients
<racarr> :) thanks
<racarr> frntend-Surface-cleanup looks fine so far (quick read)
<alan_g> racarr: that's what you MP would conflict with.
<johnjohn101> any ideas on what video system will be best supported by mir (short term)?
<alan_g> racarr: "+Cflags: -I@INCLUDEDIR@/mir" - can that be right?
<racarr> err. let me look
<racarr> alan_g: No its not
<racarr> its left over from when we had like
<racarr>  err.../usr/include/mir/mir_toolkit/api.h
<racarr> r512 :)
<racarr> hrm
<racarr> my test doesn't seem
<racarr> to fail or pass or crash or anything
<alan_g> racarr: we need to nail down this naming issue.
<racarr> it appears to exit unit tests normally
<racarr> alan_g: Which, sorry
<racarr> for headers?
<alan_g> racarr: and their directories and packages
<alan_g> racarr: there's a reason the first TDD step is to write a failing test.
<racarr> alan_g: It did fail until I implemented it
<racarr> and then it failed in more surprising ways (the atomic stuff, which is now fixed)
<racarr> but now it just runs, seems to go through the test
<racarr> and exit google mock normally
<alan_g> what was that (atomic stuff)?
<racarr> but there is nothing about passing or failure or exceptions or errors or
<racarr> anything
<racarr> just wasn't keeping a droidinput::sp when I needed to
<alan_g> Tried putting #error in the test body?
<racarr> ?
<alan_g> To prove you're compiling the test and haven't lost it in a merge
<racarr> oh well I just tried that but yes
<racarr> it is the test...
<racarr> I can remove expectations
<racarr> and get errors about unexpected calls etc
<alan_g> racarr: could you be leaking the mock objects?
<alan_g> Then their expectations are not validated
<racarr> mm thought about that so then I tried verifying them
<racarr> and also checking for leaks
<racarr> the thing is it doesn't even print OK/FAIL or whatever
<racarr> it just exits
<racarr> tried breaking in exit
<racarr> but its not informative
<alan_g> racarr: puts("GOT HERE")?
<racarr> it finishes the entire test
<racarr> body
<racarr> and invokes the tear down
<alan_g> racarr: that's too weird.
<alan_g> What's the branch, which test?
<racarr> alan_g: lp:~robertcarr/mir/send-inputs-to-client
<racarr> unit_tests/inut/android/test_android_input_manager.cpp
<racarr> set_input_focus
<alan_g> alf_: do we have a useful answer for johnjohn101 @"any ideas on what video system will be best supported by mir (short term)?"
<alan_g> racarr: I'll see what happens here
<racarr> alan_g: thanks
<racarr> the thing is if you comment out
<racarr> line 239
<racarr> the expectations fail
<racarr> but it pritns things and becomes useful again and properly faild
<alan_g> racarr: bzr denies that branch exists
<racarr> properly fails*.
<racarr> err..
<racarr> alan_g: Oh send-input-to-clients
<racarr> not send-inputs-to-client
<racarr> XD
<alan_g> Wandering "s" ;)
<alf_> johnjohn101: Do you mean what kind of GPU? Also, do you care about mobile devices or desktop?
<alan_g> racarr: missing file?  fatal error: mir_test_doubles/mock_input_focus_selector.h: No such file or directory
<racarr> whoops...sorry haven't done my pre push pass on this branch yet
<alan_g> racarr: no worries - but I need that file to test what you have
<racarr> alan_g: Pushed another rev
<alan_g> racarr: ack
<alf_> johnjohn101: in any case, on the desktop it's anything with a working DRM/KMS and GL (Mesa) driver (mostly tested with intel and radeon). For mobile is the nexus and galaxy nexus phones.
<alf_> alan_g: racarr: Is anyone looking into stabilizing the VM CI build? If not, I will try to take a look tomorrow.
<alan_g> alf_: what's the problem?
<alan_g> racarr: I see the problem
<racarr> Oh?
<racarr> *prepares for facepalm*
<alan_g> (But it does leak)
<racarr> oh really
<alan_g> racarr: I don't see the solution yet
<alan_g> ;)
<alf_> alan_g: racarr: BespokeDisplayServerTestFixture.focus_management is consistently failing in VM builds (both for CI and autolanding)
<racarr> alan_g: Oh hmm wait something related to the MockInputDispatcher leaks?
<racarr> alan_g: I have not looked yet no...didn't know it was
<alan_g> alf_: I didn't know => haven't looked into it. All yours.
<alf_> alan_g: racarr: ok
<alf_> all: Have a great rest of day
<alan_g> alf_: Have a great evening!
<racarr> See you alf_
<racarr> alan_g: Hmm wait even if I remove all the expectations I am still getting the same weird non-failure
<racarr> but it was definitely failing earlier...what have I done!
<alan_g> racarr: The process is exiting (with status 1)  after doing the TearDown() step. I have a vague recollection of seeing that with an attempt to access an already dead object during destruction.
<racarr> hmm
<racarr> status: Stuck and hungry so breaking to cook bacon and a bagel :)
<racarr> during the day I sometimes think of myself as an object for transforming bacon, bread, and tea and C++ in to
<racarr> different C++
<ogra_> poor jono
<ogra_> but at least he has a bagel as company
<jono> lol
<racarr> Took me a second!
<alan_g> racarr: I don't see what is happening. No C++ exception, no signal and _exit() is called with an uninformative stack. Going to play chess instead.
<ogra_> funnily you wrote that while on the ubuntu phone list the mail with "[Ubuntu-phone] No bacon?" rolled in
<ogra_> we're really community driven these days :)
<ogra_> bacon everywhere !
<racarr> alan_g|chess: Enjoy :) I will figure it out
<racarr> thanks
<min2> hello
<racarr> narrowed it down significantly...
<racarr> something weird with droidinput::sp and gmock going on
<racarr> surprising! ;)
<racarr> oh or maybe not...it seems to really just be the construction of the window handle from the application handle...
<racarr> maybe there is something I am missing about droidinput::RefBase
<racarr> hmm
<racarr> I fixed it but I don't understand how...and ran in tot he next problem! InputChannel constructor throws without real fds
<racarr> hmm ok later maybe a factory and mocking for droidinput::InputChannel
<racarr> for now the test can use a socketpair ;)
<bcbc2> I'm running mir on 13.04 with the ppa. When I add 'type=mir' to lightdm.conf and restart lightdm it runs in low graphics mode. If I then reboot I just get a black screen. I'm following the instructions here: http://unity.ubuntu.com/mir/using_mir_on_pc.html Any hints on how to debug?
<kgunn> bcbc2: did you "ensure you have the proper custom Mesa build installed"
<bcbc2> kgunn: it says "If you installed Mir using the packages from mir-team staging PPA ..., you should be good to go.
<kgunn> bcbc2: it sure does...and you should....hmmm
<bcbc2> kgunn: I tested it with those instructions for "Running MIR natively". I used mir_egltriangle and it worked okay. Does that qualify as 'some-mir-client' in those instructions?
<kgunn> bcbc2: yes
<kgunn> its what you think....just a little gl triangle app rendering to a mir surface
<bcbc2> kgunn: ok... good. So are there any log files I should be checking too troubleshoot the black screen? I've been rebooting into recovery mode and removing 'type=mir' before restarting to get around it.
<johnjohn101> is mir shipping with the next version of ubuntu ( 13.10 maybe).
<kgunn> bcbc2: sorry...i'm not the best at desktop x stuff...
<kgunn> bcbc2: i'll be honest...i've been on quatal....wonder if its cause your on raring?
<kgunn> bcbc2: no specific knowledge....just thinking aloud
<bcbc2> kgunn: ok - cool. It's not a big deal. I'll maybe play around with quantal or take a break. Thanks.
<kgunn> bcbc2: you prompted me to update a second hand machine i had to raring....maybe i'll try those instructions and see what gives
<kgunn> also....i'll mention it to some of the other fellows who have more experience on x/compiz/mesa
<kgunn> johnjohn101: shipping is kind of loaded
<kgunn> johnjohn101: in general there is a goal/vision of convergence of what we achieved with the ubuntu touch/phablet
<kgunn> if you read some of the spec
<johnjohn101> next year is ok. i'm ready for ubuntu to be at the next level
<kgunn> https://wiki.ubuntu.com/Mir
<kgunn> johnjohn101: sorry...digging out links i'm slow :)
<kgunn> one more
<kgunn> https://wiki.ubuntu.com/UnityNextSpec
<johnjohn101> tx kgunn
<kgunn> not sure when you got disconnected
<kgunn> but if you look at those 2 links
<johnjohn101> last message from you was "one more"
<kgunn> https://wiki.ubuntu.com/UnityNextSpec
<johnjohn101> sorry working and connecting to clients and it resets
<kgunn> np
<kgunn> so those 2 links outline what/why and point to the how which is really in all the blueprints
<kgunn> but you could think...focus is to get solid on "small screen" devices first
<johnjohn101> kind of crazy for ubuntu to switch to QT on a dime
<kgunn> then grow into "large screen" devices to achieve 1 code base to rule them all
<kgunn> johnjohn101: it may seem a little crazy...but i think Qt evolved to the point where you can get gl goodness & great ease of use/fast development (as a toolkit)
<racarr> [ RUN      ] AndroidInputManagerDispatcherInterceptSetup.server_input_fd_of_focused_surface_is_sent_unfiltered_key_events
<racarr> Device added: id=0, name='', sources=0x00000101
<racarr> [       OK ] AndroidInputManagerDispatcherInterceptSetup.server_input_fd_of_focused_surface_is_sent_unfiltered_key_events (4 ms)
<racarr> Yay
<kdub_> racarr, on device :) i saw our input library booting up the input devices
<kdub_>  *?
<racarr> kdub_: Probably!
<racarr> the way it is in trunk is if you have permissions on the input device it should probe the appropriate ones and events will flow from kernel->event hub->input reader->input dispatcher->input dispatcher policy->event filters (there are none in trunk)
<racarr> and then there will be no focused window so it will be dropped
<racarr> this last branch is to hook up focus and
<racarr> THEY GOOOOO
<RAOF> Who wants to review client-side-buffer-age! It'll be fun!
<racarr> RAOF: I will do it in just 10 minutes. it will be good to switch state back and forth before I do self review
<RAOF> Oh, god. Self review. BAH
<racarr> hehe
<racarr> RAOF: https://code.launchpad.net/~robertcarr/mir/send-input-to-clients/+merge/154221 exists and is close to its final state if you want something t look at :) will propose properly after self review round after reviewing client-side-buffer-age!
<racarr> But first, tea + food
#ubuntu-mir 2013-03-20
<jono> http://www.reddit.com/r/LinuxActionShow/comments/1alqka/regarding_matt_and_the_monkey_suit_its_on_like/
<jono> probably best to not let this guy down ^
<jono> :-)
<RAOF> Used by default in a non-Ubuntu distro is a ballsy call.
<robert_ancell> Has anyone compiled qmir before?
<robert_ancell> qmake ; make doesn't seem to do it for me
<smspillaz> RAOF: oh cool, you got buffer age working
<RAOF> smspillaz: Yeah. Next up: actually using it in XMir.
<RAOF> Actually, before that is probably âextend __DRIbuffer to allow me to pass prime fds to dri drivers, damnitâ
<smspillaz> RAOF: I wonder how you got it to work - the DRI drivers don't really make any guaruntees about what buffer you're going to get next
<smspillaz> its all very driver specific
<smspillaz> some drivers with copy-back-to-front on swap, others will swap, others triple buffer
<smspillaz> though I guess that all happens within the xserver bits
<RAOF> *Mir* knows exactly what buffer it's going to send to the client.
<smspillaz> yeah I figured as much
<RAOF> Right. Each buffer the client receives has a (client-)unique id; it's reasonably easy to implement age tracking on that ;)
<smspillaz> RAOF: how do you handle the discrepancies between the drivers though ?
<RAOF> Which discrepancies between drivers? We exclusively pageflip, and handle n-buffering ourselves.
<RAOF> We don't use any of the X bits; we're not using the DRI2 protocol.
<RAOF> Nothing ever gets a SwapBuffers request, except egl/platform_mir, which we own.
<smspillaz> RAOF: remind me - do the Xorg bits of dri2 have driver-specific things there ?
<smspillaz> I looked into doing this in X a while ago and remembered there was some driver-specific stuff that would have made it difficult, but it was a while ago
<RAOF> Yes - the X bit of SwapBuffers calls into the DDXes SwapBuffers function.
<smspillaz> ah okay that makes sense
<RAOF> I think for X you would indeed need to push this all the way down to the DDX, or _possibly_ hook into the bits generating intel swap events.
<smspillaz> RAOF: it was a total PITA
<RAOF> This is not an uncommon sentiment when working with X :)
<smspillaz> yeah it was this stuff here http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/tree/src/intel_dri.c#n838
<RAOF> I tried to factor a bunch of that stuff out into the X server at one point.
<RAOF> Because all 3 of the drivers were doing the _exact_ same thing, and they had exactly the same segfault bug.
<smspillaz> heh
<smspillaz> I think nouveau works a little differently
<smspillaz> intel has the optional triple-buffer thing
<smspillaz> nouveau didn't
<smspillaz> I remember that much
<RAOF> Yeah. At one point -ati and -nouveau had just copy&pasted the -intel code and run a sed over the names; it's diverged a bit from there :)
<smspillaz> felt like it
<smspillaz> Also I830
<smspillaz> heh
<smspillaz> Party like its 2002
<racarr> smspillaz: !
<smspillaz> racarr: hi'
<racarr> RAOF: Just left some comments on buffer age...
<smspillaz> no I'm not writing any code for you :p
<racarr> Hi :)
<racarr> thats what you say now
<smspillaz> seriously, I'm not
<smspillaz> :)
<racarr> I know :)
<smspillaz> also, you guys need to fix the privacy settings
<smspillaz> I can't see half the merge proposals
<racarr> wip
<smspillaz> racarr: no, as in I click on them and I get a page that says "go away"
<smspillaz> example: https://code.launchpad.net/~robertcarr/mir/prepare-for-inprocess-egl-clients/+merge/153889
<smspillaz> (you'll need to log out)
<RAOF> I _think_ it might be the merges or the branches that were set up prior to going public?
<RAOF> It's not clear how to make them public.
<smspillaz> RAOF: I think the lp settings are that projects are private or public, not branches
<smspillaz> so something is broken somewhere
<RAOF> Incorrect! lp:~raof/mir/client-side-buffer-age was a private branch.
<RAOF> And now that it's a public branch the merge proposal is also public.
<RAOF> Ok.
<smspillaz> RAOF: I don't see the MP
<smspillaz> its not public :)P
<RAOF> https://code.launchpad.net/~raof/mir/client-side-buffer-age/+merge/151869
<RAOF> ?
<smspillaz> RAOF: so I can see if if you give me the link
<smspillaz> but it doesn't turn up in +merges or +activereviews
<RAOF> That might take a little while to propagate?
<smspillaz> should be instant
<racarr> I think it will be fixed once we get all the mps through
<smspillaz> yeah
<RAOF> racarr: Thanks for the review.
<racarr> RAOF: Sorry its kind of scattered
<RAOF> That's ok.
<racarr> I am really tired...have been a little too full stream all around last 3-4 days :)
<racarr> I thought I would try and say something though
<racarr> and overall it makes sense :)
<RAOF> What do you think of pulling the age() related bits into ClientBuffer; the implementation shouldn't be different between AndroidClientBuffer and GBMClientBuffer.
<RAOF> I'm leary of mixing interface and implementation there.
<RAOF> Woo! Android build builds!
<tehcloud> does having an Android build mean Mir has been tainted with Java?
<TheMuso> tehcloud: No
<TheMuso> tehcloud: Java is only used for apps on android, I believe all the infrastructure stuff is C/++.
<TheMuso> C/C++ even.
<RAOF> And we're not even using that; we're using the android kernel and GLES drivers.
<TheMuso> I know that, just clarrifying that java is only used at the app/UI level.
<RAOF> Yeah, I presume you did, but tehcloud probably didn't :)
<tehcloud> yeah, I'm not exactly an expert in this subject matter
<smspillaz> TheMuso: brb, off invention "++"
<smspillaz> its C++ with the C bits removed
<smspillaz> oh wait that's Java, never mind
<smspillaz> *inventing
<TheMuso> lol
<smspillaz> They should have called Java "++"
<smspillaz> that would have ended up in so much hilarious confusion
<tehcloud> in an ideal world there would be no Java
<TheMuso> Java has its place, just like all languages.
<TheMuso> I don't use it myself.
<TheMuso> But can understand, accept and respect its usefulness.
<tehcloud> that's why you think that way ;)
<tehcloud> try using it at work
<smspillaz> Java would be useful if we didn't have AWT
<RAOF> Man, the ubuntu touch images don't even have rsync in them!
<racarr> RAOF: "tsyncninja" A touch based file synchronization utility based on the popular fruit slicing mini game
<RAOF> Hm. âmake style_checkâ isn't really very useful, is it âº
<RAOF>  ~/Canonical/Mir/mir/build â® make style_check 2>&1 | wc -l
<RAOF> 1031
<racarr> RAOF: I always grep for the files I modified
<racarr> and just fix those
<racarr> "always"->"on good days"
<racarr> RAOF: I kind of like pulling the age related bits in...(just catching backscroll)
<racarr> the mixing implementation and interface is a red flag though
<racarr> the other red flag is the
<racarr> implementation of the ageing semantics on the mock buffer with the expectations
<racarr> in one of the tests
<RAOF> Yeah, that's rather awkward.
<racarr> which says that really there is
<racarr> another object
<racarr> BufferAgeTracker (complete strawman name)
<racarr> and its an integration test
<racarr> but...eh
<racarr> I am not sure how strongly I feel about it
<duflu> racarr: Orange flag at most. If there's no real testing value gained by mocking systems code then I think it's often OK to mix implementation with interface
<racarr> Sure, orange flag :)
<racarr> Maybe Buffer has a member
<racarr> type BufferAge
<RAOF> ClientBuffer could well have a public uint32_t age, yes.
<duflu> On the other hand... being able to test code natively is preferable to mocking. And if you can do that, then you don't need to separate interface from implementation
<racarr> RAOF: No I mean a
<racarr> BufferAge age, and then the methods increment_age, mark_as_submitted, age()
<racarr> etc
<racarr> move to BufferAge definition
<racarr> and out of the platform code
<RAOF> Possibly. I *think* the Buffer might actually want to do something on mark_as_submitted(), though.
<racarr> duflu: Here the interface is seperated because it actually has multiple implementations
 * duflu stops generalizing about code he hasn't seen yet
<racarr> RAOF: does it have to do with the age
<racarr> duflu: Hehe. my number 1 hobby!
<RAOF> racarr: No, not to do with age.
<racarr> RAOF: Then I would imagine
<duflu> Generally speaking... we should use Go.
<racarr> buffer.submit() does that thing and
<racarr> also calls buffer_age.mark_as_submitted()
<RAOF> racarr: The *age* interface doesn't actually have multiple implementations, though.
<racarr> RAOF: In what tense? Right now it does i.e. increment_age is implemented in the test, the android buffer and the gbm buffer
<racarr> so the idea is to just move the implementation to a single shared BufferAge type
<RAOF> racarr: In the sense that it's ever sensible to have different behaviour there.
<racarr> mm
<racarr> so I mean it's a concrete type
<racarr> its just to avoid mixing implementation in to the ClientBuffer API
<racarr> I guess there is still some :)
<RAOF> Alternatively, ClientBuffer abstract, AgeableBuffer concrete, {GBM,Android}ClientBuffer inherits from both?
<racarr> RAOF: Mm
<racarr> RAOF: Anyway...I don't feel strongly enough about any of these to feel like
<racarr> blocking on it...but maybe if you think one is a particularly good idea or europe has a good idea :)
<RAOF> Hm, it seems that our coding style has a significant exception in the tests.
 * duflu would prefer to call it a coding /fashion/
<RAOF> Coding /ambiance/
<tvoss> uRAOping
<tvoss> RAOF, ping
<RAOF> Yo!
<RAOF> tvoss: What's up?
<tvoss> RAOF, good morning :) looking at your buffer age branch, did you run it with XMir, yet?
<RAOF> tvoss: No, haven't yet done the xmir bit.
<tvoss> RAOF, ah, was just curious. I remember you mentioning that the buffer age stuff might help
<RAOF> XMir is currently in a bit of flux, too; it's half way through being adjusted to lp:~raof/mir/use-dma-buf
<tvoss> RAOF, ah cool :)
 * tvoss is going to review racarr's branch now
<RAOF> It should help with XMir performance though, yeah.
 * RAOF has performance-parity third on his TODO list, under finish-buffer-age and use-dma-buf
<RAOF> That's going to be _all manner of fun_
<tvoss> RAOF, \o/
<duflu> Hurray... mir just overflowed it's first page of bugs in Launchpad (75 per page) :/
<duflu> *its
<RAOF> A fair number of those are "fix committed", though.
<duflu> Yeah, first comment still holds. But I wonder when the "0.0.2" release should be tagged and we move on to more meaningful milestone numbers...
<duflu> Oh great. 0.0.2 is already marked as released, but also still active
<duflu> That needs fixing
<duflu> tvoss: What should our next milestone be? 0.0.3? 0.1.0?
<duflu> Assuming 0.0.3. We can change it later...
<RAOF> Are those milestones at all meaningful?
<duflu> RAOF: No. I just realized....
<duflu> RAOF: We need to fix up our branch-to-series relationships before milestones make sense
<duflu> I'll bug Robert about it when he's online tomorrow
<tvoss> duflu, yeah, talk to Robert or kgunn please
<duflu> tvoss: Writing detailed email...
<tvoss> duflu, thank you
<alan_g> Good morning. (It is snowing!)
<duflu> alan_g: Morning. Not sure whether to be jealous.
<alan_g> duflu: don't be - it'll just make everything wet and cold
<alan_g> duflu: we need to reach consensus about include (directory) names as Europe and Australia seem to think differently. Have you seen the thread on mir-devel?
<duflu> alan_g: Keep forgetting to subscribe to that. Too many other mediums of Mir discussion. Will do so now
<alan_g> duflu: A choice of mediums isn't bad.
<duflu> Well, only if one is more effective than another and it's not being used
<RAOF> alan_g: I'd be interested to hear your thoughts on the great "where to put buffer aging implementation"fest of '13 racarr & I had in backscroll, too.
 * alan_g wonders where to find it
<RAOF> alan_g: Ah, you don't have backscroll? Let me pastebin
<RAOF> alan_g: http://paste2.org/p/3228842
<alan_g> RAOF: Looking...
<duflu> alan_g: As part of "breaking the dependency on Android input", doesn't that mean that desktop builds should not enter any *android* directories?
<alan_g> RAOF: ...need to remind myself what the code looks like...
<duflu> "[alan-griffiths] Input refactoring (don't depend on Android): DONE"
<alan_g> duflu: It was porting the input stack to use std/boost instead of android equivalents.
<duflu> alan_g: But still desktop builds enter a couple of *android* dirs?
<alan_g> duflu: yes
<duflu> That's a bit confusing.
<duflu> Hmm
<alan_g> duflu: we've adopted more android code than just the input stack
<duflu> alan_g: Even the android input stack still seems to be required for desktop input. Is that right?
<alan_g> duflu: we've forked the android input stack for use on all platforms
<alan_g> duflu: and reduced its dependency on other android stuff to a bare minimum
<duflu> Ah, OK. So there will be no escaping the 3rd party code generating all those errors/warnings that clang dislikes
<alan_g> duflu: not without work
<duflu> Heh
 * RAOF heads bedwards
 * duflu heads kitchen-wards
<tvoss> katie, ping
<katie> tvoss pong
<tvoss> katie, hey, got anything to sync up?
<katie> tvoss, a couple of things, yes.. shall we jump on a hangout?
<tvoss> katie, sure, let me grab coffee :)
<alan_g> alf_: ping
<alf_> alan_g: pong
<alan_g> alf_: do you want to do any more on render-surfaces-use-display-server or shall I set it to approved?
<alf_> alan_g: I am ok for now, I prefer to do any additional enhancements in another MP
 * alf_ prepares himself mentally for a review of lp:~robertcarr/mir/send-input-to-clients
 * alan_g has just finished the mornings reviews. alf_, send-input-to-clients isn't the worst on the brain.
<alan_g> *morning's
<alf_> alan_g: I haven't checked in detail, I just saw the +1066 diff :)
<kdub_> hey all, status, still up north at the gpu conference, will be back to a normal day tomorrow
<alan_g> kdub: hope you're having fun!
<kdub_> alan_g, thanks! picking up on some useful info, a lot of emphasis on gpu compute though
<alan_g> kdub: that doesn't surprise me. I know a lot of folks that believe that is what GPUs are for.
<alan_g> (That's what comes of working with investment banks.)
<racarr> Morning
<alf_> status: changed render-surfaces to use DisplayServer, reviewing, investigating test failure in VM CI and VM autolanding.
<racarr> alan_g: for comments on send-input-to-clients
<racarr> are you thinking just
<racarr> msh::Surface implements mi::InputTarget or some such
<racarr> or something else...
<racarr> I thought about that but then it escaped my mind XD
<alan_g> racarr: that sounds sensible
<racarr> Ok :)
<alf_> alan_g: racarr: @send-input-to-clients, in the same spirit as Alan's comment, I think that FocusSelector belongs in shell::, not in input::
<alan_g> alf_: true
<racarr> alf_: Yeah sounds right
<racarr> alan_g: Lots of reinterpret_casts removed in r515 for prepare-for-inprocess-egl
<alan_g> racarr: excellent!
<racarr> alan_g: alf_: Do you guys need review on anything this morning before I sink in to
<racarr> send-input-to-clients
<alan_g> racarr: no - there were too many reviews for me to write any code
<racarr> *whistles innocently*
<tvoss> kdub, ping
<alf_> racarr: no pending MPs for me, thanks!
<racarr> Next feature branch for me btw is, clients-receive-input.
<racarr> which is going to look like. MirSurface, takes a MirEventDelegate containing bool handle_event(...,MirEvent,...)
<racarr> constructs an InputReceiverThread from it. InputReceiverThread uses epoll to wake when there is data on the FD and uses the InputReceiver to consume
<racarr> pending events and hand them out to the callback
<racarr> if anyone has any
<racarr> thoughts/alternatives/etc
<racarr> alan_g: I am struck trying to decide on the name of the
<racarr> interface msh::Surface exposes to the InputManager
<racarr> there also has to be one for msh::Session
<racarr> input::Surface is just more trouble XD
<alan_g> racarr: you had mi::InputTarget earlier. Changed your mind?
<racarr> oh
<racarr> alan_g: Well only because there are two
<racarr> and SessionTarget reads weird
<racarr> but really the session interface is not used as an input target (it doesn't have an FD) it's just for info
<racarr> so mi::ApplicationInfo
<racarr> mi::Target
<racarr> set_input_focus_to(ApplicationInfo, target)
<racarr> it feels redundant to write mi::InputTarget, etc.
<alan_g> Does "Application" belong there? Or is it a more general "Session"?
<racarr> alan_g: It's hard to say
<racarr> we create a
<alan_g> A little redundancy can help clarity
<racarr> droidinput::InputApplicationHandle
<racarr> from it
<alan_g> Yeah, but android input stack wasn't quite our use case
<racarr> mm
<racarr> I think its probably closer to a session
<alan_g> racarr: we can rename things in the input stack to bring it into line
<racarr> set_input_focus_to(mi::SessionTarget, mi::SurfaceTarget)?
<racarr> mm
<alan_g> racarr: but lets do that later
<racarr> yes aybe a good task for next week if we can land the basics of input this week
<racarr> then clean up, (espescially down in droidinput)
<racarr> next week once it is under end to end test
<racarr> and ITERATE!
<racarr> alan_g: Just realizing also...I guess msh::SingleVisibilityFocusMechanism needs to work in terms
<alan_g> racarr: yes, and we can lose MIR_INPUT_USE_ANDROID_TYPES after that too
<racarr> of msh::Session
<racarr> and not mf::Surface :)
<racarr> so it can see the SessionTarget type
<alan_g> racarr: ack
<racarr> ugh but there is no msh::Session anymore
<racarr> just application session
<racarr> which if you use that get back to the point where you cant mock session for the focus mechanism.
<alan_g> racarr: there is, it is in the src directory
<alan_g> racarr: sorry, you're right
<racarr> alan_g: session not surface I got it
<racarr> backwards too
<alan_g> racarr: we're missing more than one interface around this area
<racarr> mm
<racarr> trying to find a way to proceed for this branch without tearing apart shell again aha
<racarr> I dont like using the ApplicationSession interface for the FocusMechanism set_focus_arg because then it becomes cumbersome to mock
<racarr> (need constructor args, etc...its weird)
<racarr> but also don't like defining
<racarr> hmm
<racarr> at first I didn't like it...msh::ApplicationSession implements msh::Session implements mf::Session
<racarr> but maybe that's really how it is.
<racarr> default_surface for example
<racarr> is part of
<racarr> msh::Session
<racarr> but not mf::Session
<alan_g> racarr: yes, but that *ought* to be part of an interface, not just in an implementation
<racarr> alan_g: Yes msh::Session is the interface
<racarr> msh::ApplicationSession is the implementation
<racarr> default_surface is introduced at msh::Session
<alan_g> racarr: I'm sure you'll sort it all out while I take my wife out for a meal.
<alan_g> ;)
<racarr> alan_g: Have a good evening :)
<racarr> ill sort it out
<racarr> I have this suspiscion that (not for this branch)
<racarr> but maybe really mf::Surface and mf::Sessio don't exist
<racarr> and SessionStore::create_session and create_surface_for
<racarr> return
<racarr> SessionIPCPackage and SurfaceIPCPackage
<racarr> except then how do you advance the buffer ;)
<racarr> for now msh::Session I believe
<alan_g|life> racarr: they exist, but they're not quite correct yet
<racarr> This is a difficult refactoring
<racarr> because...
<racarr> hmm well if you introduce msh::Session inbetween mf::Session and ApplicationSession
<racarr> the SessionManager wants to deal with things in terms of msh::Session (to say pass to the focus mechanism)
<racarr> but has to take mf::Session as input and as output
<racarr> mer...
<racarr> feel stuck on a good solution. espescially one that doesn't double the diff size of this branch so breaking for lunch
<racarr> thai should be coming any minute now...
<racarr> if mf::SessionStore::open/close session used the same style as mf::Session open/close/get with ID.
<racarr> then the internals (session container, focus mechanism including bridge to input) can work in terms of msh::Session (inherits mf::Session) which can implement
<racarr> InputTarget...
<racarr> the problem is app_container->remove_session/create_session has to take the same type (or a mapping must be maintained) as session_store open/close
<racarr> nvm that is just weird. because the SessionMediator only accesses one instance of session
<racarr> per instance
<racarr> the only thing I can come up with, is
<racarr> eeeeerrrr...no nvm
<racarr> *facepalm*
<CodyS> hello???
<kgunn> robert_ancell: i swear i thot you changed this...i'm going bp crazy https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-phone
<kgunn> can you make it mir-team drafter ^
<kgunn> CodyS: hello
<robert_ancell> kdub, yeah, I'm sure I changed that too..
<CodyS> ok thanks...i wasn't sure if i was lagging too bad...
<kgunn> robert_ancell: arrgggg....cached webpage
<robert_ancell> no, I just updated it then
<kgunn> nevermind (sheepishly)
<kgunn> oh
<kgunn> robert_ancell: got another one https://blueprints.launchpad.net/ubuntu/+spec/client-1303-mir-inter-app-data-transfer
<robert_ancell> kgunn, done
<kdub_> racarr, for in-process-egl mp, i'm a bit hazy as to what eglNativeDisplayContainer is an interface to
<kdub_> also hooray for android build ci!
<robert_ancell> racarr, I'm reading alan_g|life's ML post about the use of mir_toolkit for server processes - when you use Qt in process does it need a special interface to compile against? i.e. an interface that is different to the server and the client interfaces
<racarr> robert_ancell: I dont thinks o but some of the interfaces are shared between the server and client
<racarr> I havent fully processed that ML discussion yet
#ubuntu-mir 2013-03-21
<RAOF> Dear clang: thank you for catching the spelling mistake in "mark_as_sumbitted" that g++ ICEs on.
<RAOF> Much love, Chris.
<RAOF> Less love because your build of the unit-tests segfaults, but that may well be our problem.
 * xnox is actively learning C++ and I'm using clang++ cause otherwise I'd be stuck learning gcc codebase instead.
<duflu> xnox: Clang is really useful in telling you what mistakes you've made, regardless of skill level. Keep in mind however that Mir is not yet functional when built with clang++. And it might not be for a long time.
<RAOF> Ok. What the hell?
<RAOF> This: http://paste.ubuntu.com/5633273/ patch makes MirClientSurfaceTest.client_buffer_created_on_next_buffer segfault.
<RAOF> But MirClientSurfaceTest doesn't *use* AgingBuffer, nor do any of its dependencies!
<duflu> RAOF: Side effects... Maybe try: valgrind bin/unit-tests
 * duflu tries to ignore the circus going on in Canberra
<RAOF> duflu: I did, but it wasn't very helpful; just an invalid read, which I knew about because reading 0x16
<RAOF> was what was causing the segfauult.
<RAOF> HAH!
<RAOF> That's a trick for the uninitiated - test_aging_buffer.cpp and test_client_mir_surface.cpp are both built into unit-tests, and have differing class definitions for mir::test::MockBuffer
<RAOF> I have no idea why that's not either (a) a compile time error, or (b) supposed to work.
<RAOF> This suggests that our tests are quite fragile - we've got a number of definitions of mir::test::MockBuffer lying around in various .cpp files which just happen to be identical.
<duflu> RAOF: The linker always chooses and keeps one copy of a symbol. It's only a problem if the multiple copies are different :)
<duflu> RAOF: Sorry, I mean it chooses and keeps one of each unit name. By default an object is a unit, but you can make single functions/methods separate units
<tvoss> RAOF, can this be connected to -Bsymbolic_functions?
<RAOF> tvoss: Maybe?
 * RAOF -> baby
<tvoss> RAOF, have fun :)
<duflu> tvoss: -Bsymbolic* flags are usually only needed in large plugin-based systems (like two of my previous projects). If you're not dynamically loading plugins then -Bsymbolic is usually a mistake that should have been solved with moving source code around. And/or better namespaces.
<tvoss> duflu, -Bsymbolic is one of the default flags set during package builds
<duflu> tvoss: Sure, it's safe to turn on. But in non-plugin systems you don't need it
<duflu> In plugin systems you need to to get around the problem of controlling which template instantiation the runtime linker binds to
<duflu> "need it to"
<tvoss> duflu, I do agree with you, no question about that. But the ubuntu packaging setup pulls it by default
<duflu> Hmm, it's only a few characters, and probably doesn't hurt anyone
<duflu> I'm sure there are use-cases for not having Bsymbolic but don't recall any
<duflu> Oh, yes I do. You want to avoid Bsymbolic when you have important data stored in static members of a class. To ensure everyone is looking at the same copy of the static member
<tvoss> duflu, yup, that was one of the use-cases that was breaking for us in one of the test-cases, but I cannot recall which one
<duflu> tvoss: You can avoid all these problems if you're careful to explicitly instantiate templates in a single location. And mark them as "extern" in your headers.
<duflu> Assuming it's a template
<tvoss> duflu, it wasn't a template, I think it came down to a static object taking care of the google protobuf initialization
<duflu> Ugh
<tvoss> duflu, the approach is perfectly fine, but the cpp was compiled into multiple so's
<tvoss> duflu, and normally the linker should have made it one symbol, but with -Bsymbolic, every so got its own instance
<duflu> tvoss: Technically Bsymbolic does not affect or reduce duplicate symbols in your binaries. It only defines the rule for which one to point to at runtime.
<duflu> If there are duplicate symbols, then that's something to fix in the source code/makefiles
<tvoss> duflu, I do disagree. Looking at the definition of static in C++, the expected behavior even if the _same_ cpp is compiled into multiple so's that all get loaded at runtime, the symbol should be unique
<duflu> tvoss: Sure, if you're smart about creating the ideal compiler (which does not exist). I'm just talking about how to handle real-world compilers
<tvoss> duflu, well, gcc without -Bsymbolic actually works :)
<tvoss> duflu, so close to ideal
<duflu> Ideal until you put in in a plugin system, load plugin A then B, and unload plugin A. You're left with B pointing to symbols in A that are no longer mapped in memory
<duflu> "put it in"
<tvoss> duflu, @plugin system: agreed, but I was referring to implicitly loaded so's
<duflu> Yup. Just covering all the bases. All options have a use-case somewhere
<tvoss> duflu, yup
 * tvoss wants to have GNUInstallDirs as offered by cmake 2.8.10 :)
<RAOF> Why not have it?
<RAOF> apt-cache policy cmake
<RAOF> cmake:
<RAOF>   Installed: 2.8.10.1-0ubuntu6
<RAOF> :)
<alf_> duflu: lp:1158120, have you started looking into it? I noticed this in vm ci builds, and I was planning to investigate.
<alf_> lp 1158120
<ubot5> Launchpad bug 1158120 in Mir "acceptance-tests.BespokeDisplayServerTestFixture is failing randomly (approx 10% of the time)" [High,New] https://launchpad.net/bugs/1158120
<duflu> alf_: No not working on it
<alf_> duflu: ok, I will take a look today then
<robert_ancell> alf_, I'm still not resolving QtPlatformSupport/private/qgenericunixfontdatabase_p.h, in fact I don't have any private/ dir under /usr/include/qt5/QtPlatformSupport/
<robert_ancell> qthybris is using similar stuff, but I seem to have all the build-depends
<alf_> robert_ancell: there are some qt -private packages
<robert_ancell> alf_, not in raring it seems, are they from a PPA?
<alf_> robert_ancell: no, I am not using the PPA anymore, switched to the archive
<alf_> robert_ancell: e.g. qtbase5-private-dev
<robert_ancell> alf_, aha! Cheers
<tvoss> robert_ancell, best to ask loicm :)
<robert_ancell> tvoss, did he write some of this?
<robert_ancell> bzr says no
<tvoss> robert_ancell, I think the project is called qtubuntu now, and yeah, he wrote almost all of it
 * alf_ managed to delete his vim config files... to the backup!
 * robert_ancell bzr branches
<robert_ancell> tvoss, oh, I've had my Loics confused. Thank makes more sense :)
<tvoss> robert_ancell, I do keep confusing them, too :) let's call them french1 and french2
<tvoss> robert_ancell, as, according to tedg, there are approximately only 5 people living in France & Germany, enumerating them should be easy
<robert_ancell> tvoss, I'm sure they would be supportive of the idea. We could get them all F1-F5 t-shirts for conferences too
<tvoss> robert_ancell, yeah ... but hell breaks loose if they start exchanging shirts :)
<robert_ancell> those crazy French!
 * tvoss is scared of people eating frogs :)
<alan_g> alf_: looking at https://code.launchpad.net/~raof/mir/client-side-buffer-age/+merge/151869 ...
<alan_g> I can't see why TEST(MirClientAgingBufferTest, buffer_age_starts_at_zero) passes, surely AgingBuffer default initializes buffer_age - which for a POD is an unspecified value. Am I missing something? Or should there should be a constructor that initializes buffer_age to 0.
<alf_> alan_g: looking...
<alf_> alan_g: I don't think TEST(MirClientAgingBufferTest, buffer_age_starts_at_zero) makes any sense at all, since we are testing the return value of a mock object. It passes because no expectation is set on age(), and googlemock just returns a default value (0).
<alf_> alan_g: hmm, wait, let me look more closely
<alan_g> alf_: that's a different problem - it isn't a mock of AgingBuffer
<alf_> alan_g: you are right, got carried away by the name
<alf_> alan_g: does make_shared value-initializes the created object?
<alan_g> alf_: investigating
<alan_g> alf_: seems so
<alan_g> If I change it to use new, the test fails
 * alan_g shudders
<alan_g> Anyone read this? http://pragprog.com/book/lotdd/modern-c-programming-with-test-driven-development
<tvoss> alan_g|lunch, nope, haven't read that one
<tvoss> alan_g|lunch, shall we share a copy, it's drm-free if I understand it correctly
<alan_g> tvoss: I still like paper. (And I'd like to hear opinions before spending time reading it.)
<smspillaz> alan_g: looks interesting
<alan_g> smspillaz: it could well be. (But so are more books than I have time to read.)
<smspillaz> alan_g: anything in particular in that book that makes it worth reading though
<smspillaz> it kinda feels a lot like most other books I've read ("inject all the dependnencies, write all the tests!"
<smspillaz> )
<alan_g> smspillaz: That's what I teach too - it really is as simple as deciding to do it.
<smspillaz> I guess the only stuff I'm interested at this point is "how to write effective tests that actually test all the cases"
<alan_g> You've read GOOS?
<smspillaz> a bit
<alan_g> It's the best book I know on the subject by some margin.
<alan_g> But then I drink beer with Nat & Steve.
<smspillaz> heh
<smspillaz> alan_g: heh, so the extracts from this book feel like "here is how to use google test ... the way you already use it"
<alan_g> smspillaz: it may be the way *you* use it. But there are a lot of wrong ways out there
<smspillaz> alan_g: of course, I'm sure there some bits I haven't considered in there
<Braggart> kdub: Just read your latest entry on Ubuntu Planet. One thing you did not discuss is the prospect of Wayland compositor using Android drivers.
<Braggart> Do ping me when you're around and reply, otherwise I myself would forget that I left this question.
<kdub> Braggart, can't talk about everything at once :)
<kdub> hello folks! status today, working on landing that android display branch, moving on to hwc work
<Braggart> Nothing wrong with that. Asking since you mentioned I can ask. :)
<Braggart> kdub...?
<kdub> if they can get it to work too, more power to them i guess :)
<kdub> also all, i'm back from san jose today, back to my normal day :)
<smspillaz> Braggart: my understanding is that pq got it working by hacking wayland to work on top of bionic, and then got it to the point where the compositor ran, but there was no graphics buffer sharing (as that was implemented through wl_drm which implemented wl_buffer)
<alf_> kdub: Hi! Question: I get some flickering when I use render-surfaces on nexus 4. Is this because the vsync work is not finished there yet?
<kdub> alf_, yep
<alf_> kdub: ok
<kdub> smspillaz, Braggart that's my understanding as well, just the framebuffer was accelerated
<kdub> alf_, that's what I plan on working on today actually :)
<alf_> kdub: great :)
<Braggart> Not possible to do a separate graphics buffer sharing bionic?
<Braggart> *sharing implementation for bionic?
<smspillaz> Braggart: bionic isn't really the problem, I think it was just more of a case of it being not implemented yet
<Braggart> So instead of the said hypothetical implementation, we get a new compositor.
<Braggart> Right that answers all my questions, thank you.
<Braggart> smspillaz: Thanks for all the hard work.
<smspillaz> *shrug*
<smspillaz> maybe I shouldn't talk to people, I seem to make them upset :(
<alan_g> smspillaz: I don't see anything in what you said. (Some people just want a pretext to be upset.)
<smspillaz> alan_g: heh, I've been in both positions before
<smspillaz> with young age comes immaturity at times I guess
<alan_g> The young have no patent on immaturity
<smspillaz> prior art ?
<smspillaz> I suppose the seemingly limitless immaturity demonstrated by the "elder" Simon Crean in Australia today pretty much proves that point
<smspillaz> (dunno if you saw, but there were a series of very dramatic events in australia today that pretty much put the nail in the coffin for current government come the september election)
<alf_> alan_g: kdub: MultiThreadedCompositor needs an interface through which to learn when something in the surface configuration changes (i.e. to register a callback with). A couple of names I have thought so far: CompositingState(Notification), RenderStateChangeNotification. Of course, we could also extend RenderView, with the rationale that it is the interface through which the compositor subsystem in general accesses the surface stack, but this w
<alf_> alan_g: kdub: Thoughts?
<alan_g> alf_: I think it is likely "CompositingContext" not "CompositingState"
<alan_g> alf_: but I think I prefer adding callbacks to RenderView.
<alan_g> Callbacks on a view seem to be a sensible mechanism
<kdub> yes, a callback seems sensible
<kdub> alf_, "when something in the surface configuration changes", whats an example of what you're thinking?
<kdub> an example of what changes, i mean
<alan_g> yes, that's a point, the compositor isn't caching state - it submits code to be applied to the view.
<alf_> alan_g: Conceptually a change callback fits in RenderView, and it's how I have it in my local code right now. On the other hand, RenderView is used by two different (but related) components for two different purposes, hence my concern.
<alan_g> Then it might be that RenderView should be two related dependency interfaces
<alf_> kdub: the idea is that the compositor will only composite when it needs to, which means when any surface changes state (position etc) or contents (a new buffer is pushed)
<alan_g> alf_: that makes a lot of sense
<alan_g> so it would be like notify_changes(area, callback)
<kdub> alf_: ah, okay... when i was thinking about that problem a while back, a callback made sense like that made sense to me too
<alf_> alan_g: in the first iteration it will just be notify_changes(callback), i.e., redraw everything when anything changes, but it surely makes sense to add the area later
<alan_g> alf_: the callback could be passed an affected area and the decision taken there
<alan_g> alf_: but I agree that's for later
<kdub> alf_, we should always have a 'redraw all' even if can only redraw certain areas
<kdub> drivers sometimes -_-
<alf_> alan_g: kdub: I was thinking about the area mostly in terms of which output is affected. At least for now, we don't support redrawing only part of an output; we recomposite the whole output every time.
<alan_g> alf_: sure
<alf_> alan_g: kdub: ok, for now I will keep the callback in RenderView. We can reconsider later.
<alf_> alan_g: kdub: callback => callback registration mechanism
<alf_> thanks
<alan_g> alf_: ack. But this discussion makes me wonder if RenderView should be RenderModel
 * alan_g ducks
<alf_> alan_g|coding: could be, let's see how the code feel in the MP, and I am happy to discuss further and amend
<ogra_> kdub, hmm, your blog post seems slightly wrong, or do you actually plan to teach the android GLES drivers to do actual openGL ?
<kdub> ogra_, gp. no :) all opengles
<ogra_> ..."when you run mir inside of an Ubuntu Touch phone/tablet, you use the android platform to get full OpenGL acceleration"
 * alf_ is unhappy about ICEs he has been getting lately
<racarr> Morning :)
<kdub> morning racarr
<racarr> sorry to be a little late :)
<racarr> I seem to have acquired always moving at ten million miles an hour syndrome these last few weeks
<racarr> Did anyone have a chance to look at the...
<racarr> "something" issue in send-input-to-clients requiring the dynamic cast
<racarr> this GCC crashing on all nontrivial template errors
<racarr> is starting to become a timesink -.-
<tvoss> kdub, could you fix your blog post regarding opengl vs. gles?
<kdub> tvoss, yes, ogra_ had a good pt
<tvoss> kdub, thx :)
<ogra_> :)
<kdub> done
<tvoss> kdub, thx again
<racarr> I had a dream last night
<racarr> where we had a code review tool where while reviewing the code you could suggest minor fixes inline
<kdub> gerrit does that
<racarr> and the person could accept or reject them easily
<racarr> it was a nice dream
<racarr> kdub: Is it useful? It sounds like it would be really useful if done right...
<kdub> i liked gerrit a lot, but its aimed towards git
<racarr> mm
<racarr> alan_g|coding: Updated send-input-to-clients and prepare-for-inprocess-egl but no hurry
<racarr> Does anyone have any thing they would like me to work on /review/help with
<racarr> or should I jump in to receive-input-in-client
<alan_g> racarr: could you check https://code.launchpad.net/~vanvugt/mir/surface-types/+merge/154261 please?
<alan_g> racarr: will look at send-input-to-clients and prepare-for-inprocess-egl now
<racarr> alan_g: Great thanks
<racarr> will look now
<racarr> alan_g: Would be interested to know what you think about the need for the dynamic cast in send-input-to-clients (SessionManager::set_focus_to)
<racarr> it's quite difficult to find a refactoring that works ...
<alan_g> racarr: the first thing I see on lp is "Text conflict in include/server/mir/shell/application_session.h"
<alan_g> racarr: I guess you need either a dynamic cast or a lookup mechanism (hashmap?)
<racarr> alan_g: It seems so right...without some sort of heavier
<racarr> refactoring
<racarr> alan_g: One sort of possibility
<racarr> is that actually
<racarr> eh well.
<racarr> if it worked in terms of IDs like Surface
<racarr> then you could keep track of the bits as msh::Surface inside the session manager, and return mf::Session from mf::SessionStore and msh::Session from msh::SessionManager
<racarr> and it works because of covariant return types
<racarr> (as opposed to the "covariant arguments" that you would need now)
<racarr> but it seems strange to store IDs like that because the only client of open/close session
<racarr> is the session mediator which only uses one session per instance
<racarr> so its kind of just an obfuscation
<racarr> from that perspective
<alan_g> Hmm smart pointers are not covariant
<alan_g> anyway, I'm not bothered about the cast
<alan_g> Even if it does suggest a bit of tension in the deswign
<racarr> Yeah it's always correct and clearly so by suggestion
<racarr> but it feels like it is
<racarr> a bug in our type system
<racarr> haha
<racarr> s/suggestion/inspection
<racarr> "Correct by suggestion" hmm
<racarr> reviewed surface-types
<racarr> if prepare-for-inprocess-egl is ready to land we should wait to switch to approved
<racarr> until I can sync up with RAOF later and land the
<racarr> mesa changes concurrently
<racarr> merging trunk in to send-clients-input now
<racarr> lol...
<racarr> the deletion of trailing whitespace in application_session.h
<alan_g> racarr: both branches need conflicts sorting out
<racarr> conflicted with my addition of a metho
<racarr> alan_g: Just pushed fixed conflicts on send-input-to-clients
<alan_g> racarr: just "went home"
<racarr> and prepare-for-inprocess-egl-clients :)
<racarr> alan_g|life: Sounds good :) have a good evening
<racarr> brb in 15
<racarr> Anyone have time to give a final round of review
<racarr> to prepare-for-inprocess-egl?
<racarr> Well no rush
<tvoss> alf_, you still around?
<RAOF> racarr: What do you need from mesa?
<RAOF> racarr: If the android input stack wasn't a steaming pile of won't-build-with-clang you could use that :). Yeah, g++ ICEing on any gmock error is getting really old.
<kdub> thomi, are you able to add a 'deb' line to the sources.list of the mir CI pbuilder on jenkins?
<racarr> RAOF: I didn't have the ICE problem until
<racarr> a recent dist-upgrade...
<racarr> it's super frustrating
<racarr> like I just wrote a whole new acceptance test file and tried to compile it
<racarr> ICE! XD
<racarr> RAOF: From mesa! prepare-for-inprocess-egl-clients is basically ready to land
<racarr> so we need to land the mesa changes concurrently
<racarr> the stuff for the NativeDisplay with
<racarr> callbacks
#ubuntu-mir 2013-03-22
<RAOF> racarr: Just to be clear - you'd like https://code.launchpad.net/~rocket-scientists/mir/mesa-egl-platform-mir-native-display to land, yes?
<RAOF> racarr: Ok, so where do I get mir_client_library_mesa_egl.h from?
<duflu> RAOF: It used to be proposed here but has since vanished or been renamed... https://code.launchpad.net/~robertcarr/mir/prepare-for-inprocess-egl-clients/+merge/153889
<RAOF> Ah, seems it got renamed to native_display.h
<RAOF> Not a big fan of that header name.
<thomi> kdub: hey, still around?
<RAOF> racarr: Ok, so my hacks to make https://code.launchpad.net/~rocket-scientists/mir/mesa-egl-platform-mir-native-display buildable against lp:~robertcarr/mir/prepare-for-inprocess-egl-clients don't result in a working mesa.
<bcbc2> Running mir ppa on Raring. When I add type=mir to lightdm.conf I get a terminal login. This is the lightdm.log: http://paste.ubuntu.com/5636106/ Any ideas? PS the mir_egltriangle runs correctly in the separate test
<RAOF> bcbc2: XMir currently isn't in the PPA, so those steps won't work.
<bcbc2> RAOF: ah ok. So I need to compile from source?
<RAOF> bcbc2: XMir & the associated drivers will land after I've landed https://code.launchpad.net/~raof/mir/use-dma-buf/+merge/153267 and the associated changes.
<RAOF> bcbc2: Yeah, you can build from source if you want; the necessary code is on github - https://github.com/RAOF/xserver and the associated driver from xf86-video-{ati,intel,nouveau}
<RAOF> (Note, I don't think nouveau's currently working)
<RAOF> bcbc2: It's pretty boring, too (as long as it works) - everything looks exactly like it currently does, with the exception that colour management doesn't work :)
<bcbc2> RAOF: ok thanks. I'll probably wait a bit then. yeah it's boring IF it works ;)
<duflu> mmrazik: Would it be possible to make Jenkins CI build Mir against clang?
<duflu> Test cases don't work yet, and it requires a custom cmake command, but the static analysis is very useful
<RAOF> Does input build yet?
<mmrazik> duflu: sure. what is the cmake command?
<duflu> RAOF: No. And not for the foreseeable future. There are "errors" in code we have to keep :P
<RAOF> Boo.
<duflu> mmrazik: https://code.launchpad.net/~vanvugt/mir/clang/+merge/153984
<duflu> RAOF: But there's a chance the offending code can be worked around by moving pieces. Have not looked in detail
<mmrazik> duflu: does the build fail with those commands? I see input is disabled but what about the tests?
<duflu> mmrazik: Yeah tests fail. We expect that into the near future at least. Just testing it builds with clang is enough
<mmrazik> duflu: oh.. they fail during execution, not during compile?
<duflu> mmrazik: Yeah execution fails. It all builds (without input)
<mmrazik> ok
<tvoss> duflu, RAOF is the clang build step optional for CI then?
<duflu> tvoss: It's non-existent right now. But I think it should be compulsory due to the high value of its static analysis
<duflu> And we pass the clang test now. So nothing to be fixed
<tvoss> duflu, for the static analysis: I do agree, but: we need gcc, too, especially to be able to execute the tests, right?
<duflu> tvoss: Of course. gcc still builds and runs tests
<tvoss> duflu, okay, then I'm fine
<duflu> Hah. No I'm not suggesting drop tests from CI :)
<tvoss> duflu, just tried to clarify on the backlog :)
<duflu> Man, even when I was reviewing hundreds of bugs per day, I never tried keeping up with IRC backlogs...
<tvoss> duflu, I sometimes do :)
<RAOF> For high-value channels, sometimes.
<duflu> RAOF: They exist?
<RAOF> Heh.
 * duflu -> coffee
<RAOF> Channels like #debian-x and #debian-cli are quite low traffic, so they have a signal/noise that makes backscroll sometimes a worthwhile investment.
<tvoss> tvoss -> coffee
<RAOF> Let's see if this mesa lets me use lp:~raof/mir/use-dma-buf
<Cheery> has anything new happened recently?
<duflu> Cheery: New code is landing in Mir every day. But I don't think any of the recent changes are interesting to users (yet)
<Cheery> anything new about nvidia drivers?
<Cheery> apparently.. no
<tvoss> Cheery, I think the easiest way to stay up to date is to subscribe to the mir mailing list (see https://wiki.ubuntu.com/Mir)
<alf_> tvoss: pong
<RAOF> Cheery: I wouldn't hold my breath for news on the nvidia front; my guess is that it'll be a while before we('re allowed to âº) have anything interesting to reveal.
<alan_g> alf_: tvoss: Another day without progress on "Include directory structure, and installation packages" :(
<duflu> Awesome. I now realise the past few hours work needs to be partially redesigned from scratch. And 13 minutes to weekend.
<alan_g> duflu: I hear your pain
<duflu> Oh dear. Over-stimulation and too many ideas for a Friday evening. Better go open some wine and make dinner.
<smspillaz> mmm wine
<alan_g> alf_: got time for a review? https://code.launchpad.net/~robertcarr/mir/send-input-to-clients/+merge/154221
<alf_> alan_g: I thought I had already reviewed that, but it turned out I forgot to actually press the button :)
<alan_g> LOL
<alan_g> Good job I reminded you
<alf_> alan_g: The poor review... it was patiently waiting for me in a forgotten browser tab :)
<alf_> alan_g: you saved it from it's pain
<alf_> alan_g: s/it's/its/
<alan_g> alf_: I'm going to fix lp:~robertcarr/mir/prepare-for-inprocess-egl-clients in a trivially different branch so we might get it landed too
<alf_> alan_g: ok
<alan_g> alf_: https://code.launchpad.net/~alan-griffiths/mir/prepare-for-inprocess-egl-clients/+merge/154909
<alan_g> alf_: does this look like the bug you were fixing? Or is it a new problem?
<alan_g> https://jenkins.qa.ubuntu.com/job/mir-quantal-amd64-ci/173/console
<alf_> alan_g: It's in the same code, but I don't think it's related. It seems similar to the one we are getting in VM builds (some client/server process synchronization issue).
<alan_g> alf_: thanks, for looking
<alf_> alan_g: aha, I have managed to recreate it locally at last! I had to sufficiently overload/slow down my computer to recreate it...
<alf_> alan_g: well, at least I have recreate some problem, hopefully the same as the one we are seeing
<alan_g> alf_: Does that mean I can leave it to you?
<alan_g> At least for now
<alf_> alan_g: sure, I will try to take a look today
<alf_> alan_g: is this problem happening consistently or sporadically for normal (non-VM) CI (i.e. is it blocking our CI)?
<alan_g> alf_: I've only seen this instance
<alan_g> I'll set it approved again and see what happens
<alf_> alan_g: ok, if it proves to be a blocker, I will take a look now
<alan_g> alf_: Looks like it is an intermittent problem. The worst ones to prove are fix. :(
<alan_g> *fixed
<alan_g> mmrazik: do you know what caused this? https://jenkins.qa.ubuntu.com/job/mir-android-raring-i386-build/95/console
<mmrazik> alan_g: looking...
<alan_g> alf_: are you happy with this? https://code.launchpad.net/~kdub/mir/android-display-factory/+merge/153907
<alf_> alan_g: checking
<mmrazik> alan_g: I think it was a network error. Let me retry
<mmrazik> bzr error messages are not particularly helpful :-/
<alan_g> mmrazik: I'd be happy to switch to git
<mmrazik> alan_g: seems to be reproducable. I have a call now but will check afterwards
<alan_g> mmrazik: thanks
<mmrazik> alan_g: oh.. its because the branch is private
<alan_g> mmrazik: oops
<alan_g> mmrazik: Do I need to create a new branch?
<alf_> alan_g: reviewed ("needs fixing")
<alan_g> alf_: ta
<mmrazik> alan_g: I made it public
<mmrazik> let me re-run the job
<alan_g> mmrazik: thanks
<alf_> alan_g: @CI error, I don't see anything suspicious, it's probably just the server being late. We should increase the wait time to a sufficiently large value, e.g., 10 seconds, and see if it helps. The VM builds are consistently failing, so, if this works, we will get an indication that we are solving the right problem.
<alan_g> alf_: ok
<kdub> good morning
<kdub> hey mmrazik, for the android ci builds, could we add the phablet-team's armhf ppa (with libhybris packages) to the jenkins pbuilder setup?
<kdub> it will help with this failure https://code.launchpad.net/~mir-team/mir/consolidate-crossbuild-scripts/+merge/154762
<mmrazik> kdub: sure. ppa:phablet-team/ppa ?
<kdub> yep, thats the one
<mmrazik> kdub: done + I queued a rebuild
<kdub> thanks mmrazik
<mmrazik> btw. there is a clang build enabled in addition
<alan_g> are we supporting clang?
<mmrazik> alan_g: is the question "do we care about clang errors" or "can we compile lp:mir with clang"?
<mmrazik> the later is true
<mmrazik> duflu asked me to have clang job in jenkins earlier today
<mmrazik> this is what the jenkins job is doing: cmake .. -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DMIR_DISABLE_INPUT=ON
<alan_g> mmrazik: the question is "does spending time on clang help deliver what we promised"
<mmrazik> right
<mmrazik> alan_g: can't answer
<mmrazik> shall I drop an e-mail to mir-devel ?
<mmrazik> I thought you guys care given you approved the MP
<alan_g> AFAIK clang isn't a supported platform (just a nice to have).
<kdub> alan_g, +1
<kdub> alf_, re-review of android-display-factory? :)
<alf_> kdub: on it
<mmrazik> kdub, alan_g: so you are -1 on clang blocking the ci/autolanding
<mmrazik> what if I keep it for ci and remove for autolanding? I.e. you will be able to merge code even if clang fails
<alan_g> mmrazik: yep
<kdub> mmrazik, yes, at least until we figure get our gcc arm compiles to a nice point
<mmrazik> so should I remove clang completely?
<alan_g> mmrazik: g++ arm is a supported platform
<mmrazik> shall I translate g++ arm as building natively on arm (like we do in ppa)?
<alan_g> mmrazik: clang shouldn't distract you or us from what we are trying to deliver
 * mmrazik is removing the clang job
<mmrazik> kdub: your branch compiles on android again
<kdub> i just saw, thanks mmrazik
<alan_g> kgunn: hangout to find a way forward on the include directories question: https://plus.google.com/hangouts/_/fa5325fabc3ebf8c432cbc427c9f78b02e2a6806b8?authuser=0&hl=en-GB (alf_ kdub racarr - you're welcome to join in)
<kgunn> thanks alan_g !!
<kgunn> alf_: racarr kdub ^ if you want to join
<alf_> kgunn: thanks, coming
<racarr> morning
<alan_g> racarr: ^^
<racarr> still going on?
<alan_g> ack
<racarr> ok just a sec
<alf_> kgunn: http://www.timeanddate.com/worldclock/meeting.html
<racarr> merged trunk on send-input-to-clients :)
<alan_g> racarr: looking
<racarr> alan_g: Have you seen anything in andoid with
<racarr> Compat.h and redefinition of lseek64 and _FILE_OFFSET_BITS < 64?
<racarr> It happens when trying to include the fake_event_hub in my new acceptance test
<racarr> am guessing it only works in other places because of some header included previously
<racarr> or some such
<alan_g> racarr: it isn't something I remember (but why would I try)
<alan_g> I usually stuff #error in the offending header to get an include backtrace
<racarr> No idea, just not sure if you had seen it come up in the process of refactoring :)
<racarr> mm
<racarr> its like AndroidConfig.h isnt being included
<racarr> ah
<racarr> I did not know about the uses_android_input macro
<racarr> in CMake
<alan_g> alf_: re earlier discussion about separating run_mir () for reuse - it is done in https://code.launchpad.net/~mir-team/mir/misc-code-cleanup/+merge/155018
<alan_g> racarr: "Fixed the comments" - did you push the changes?
<racarr> apparently now!
<racarr> not
<racarr> it looks like I did now :)
<racarr> alan_g: ^
<alan_g> racarr: I didn't want to set "Approved" and then have you remember. ;)
<racarr> thanks :)
<_NerdyMe_> hey guys is there a chance for a question about a possible use case about MIR which (if technically possible) would save compositing overhead...
<_NerdyMe_> the idea is (as it is server allocation) for the case of a cell phone: apps normally run maximised. so they use the whole screen except the top panel. the compositor has a buffer which includes the "whole" screen and when the client asks for the buffer in a state that it has the focus then you pass a reference to a subset of that very same compositor buffer. so that way you never have to copy anything around etc.... and when you bring in the launche
<_NerdyMe_> r it will render directly over that very same buffer... is that possible?
<kgunn> _NerdyMe_: yes
<kgunn> _NerdyMe_: this is what is known as "bypass composition" in the mobile industry
<kgunn> _NerdyMe_: it should be "for free", this kind of logic....along with some other goodies
<kgunn> _NerdyMe_: is supported by hw vendors in hwc hal
<kgunn> _NerdyMe_: and on gpu fallback path....its fairly simple logic
<kgunn> _NerdyMe_: all in all....yes....its something we know we'll do
<kgunn> _NerdyMe_: support
<_NerdyMe_> kgunn: thank you. the thing is I have no clue how that buffering stuff actually works, just had my thought on it. that makes feel good, like even I could make my own display server hahaha let's call it ISS. great, thx for the info. wish you all good luck!
<kgunn> _NerdyMe_: ISS...good one
<kgunn> racarr: hey, where do i look for test output (like aggregate run rate/pass rate stuff) ?
<kgunn> racarr: as well, tested code coverage data
<racarr> kgunn: I am trying to find where it went since jenkins moved around
<kgunn> racarr: thanks for the help
<racarr> Anyone around?
<racarr> Trying to figure out how to test the input receiver polling logic...
<sturmflut> I tried to write my own Mir client but the include files in the current PPA packages seem to be borked. I #include <mir/client/mir_toolkit/mir_client_library.h> but it tries to #include "mir_toolkit/c_types.h" and there is no mir_toolkit/c_types.h in the default path
<racarr> sturmflut: I guess there is something wrong with the pkgconfig...will make a note. for now -I/usr/include/mir (you should have mir_toolkit/c_types.h in there) should do it
<racarr> though...um...if c_types.h landed that means a branch landed that wasn't supposed to land yet
<racarr> and mesa will be out of sync and not working ;)
<racarr> kdub: Ping?
<kdub> pong
<kdub> racarr^^
<racarr> kdub: Prepare-for-inprocess-egl landed accidentally
<racarr> so I guess things will be broken
<racarr> because i havent pushed the mesa changes
<racarr> trying to figure out what to do...
<kdub> racarr, broken how?
<kdub> racarr, android seems ok
<racarr> kdub: Will be broken on mesa...well
<racarr> I guess you can just pass the MirConnection as the EGLNativeDisplayType
<racarr> and nit will work
<racarr> but mir_connection_get_egl_native_display
<racarr> will return the
<racarr> new struct that mesa cant handle yet
<racarr> I guess mir_connection_is_valid (called by old mesa)
<racarr> will then return 0 and it will just fail
<kdub> well, if there's a quick fix, let's mp it.... if not backing out the change seems like the way to go
<RAOF> racarr: And I couldn't get your mesa changes to work :)
<sturmflut> Anyone working in a Mir backend for SDL? Being able to run games on Mir would be awesome
<tehcloud> sturmflut, have you run ANYTHING on Mir yet?
<sturmflut> tehcloud: The demo clients from the repository, yes
<tehcloud> I suspect the Mir devs are focussing on getting it on par at least with Wayland, before committing resources to SDL
<tehcloud> and I think the SDL devs are not working on it either, since they are trying to release 2.0
<racarr> sturmflut: Afaik no one has touched SDL yet :)
<racarr> RAOF: Oh you are here.
<racarr> Hmm. I am kind of engrossed in input but should fix this.
<racarr> so if you have time to review something in 30 minutes or so I could make an updated patch
<RAOF> racarr: Because, during my morning walk with ZoÃ«, I realised why my mesa changes to support use-dma-buf only half worked :)
<racarr> where did mesa repo move since everything went public?
<RAOF> github
<racarr> RAOF: Aha. The mesa mind virus
<RAOF> racarr: Enjoy.
<RAOF> racarr: https://github.com/RAOF/mesa
<racarr> RAOF: Ok between checking out and building a fresh copy and all will take a while
<racarr> but will get back to you soon
<RAOF> racarr: Question re: mir_connection_is_valid and your native_display patch - couldn't you just pass a MirConnection in to mesa and have mesa pull the native display out of that? Then you could keep using mir_connection_is_valid.
<RAOF> There are two hard problems in computing: cache invalidation, naming things, and off-by-one errors.
<RAOF> Mesa was a cache invalidation problem :)
<racarr> RAOF: http://paste.ubuntu.com/5638637/ should work
<racarr> but there is a little cleanup to be done perhaps
<racarr> RAOF: Can't pass a MirConnection as the
<racarr> display type because there is no
<racarr> MirConnection ont he server side
#ubuntu-mir 2013-03-23
<RAOF> Hm. Sending a new fd for each buffer isn't super-awesome :)
<racarr> not the most awesome no
#ubuntu-mir 2013-03-24
<RAOF> Hm. Where did mir_toolkit/c_types.h go?
<racarr> kdub: Don't suppose you happen to be idling around IRC on sunday?
<racarr> trying to figure out something with the StubServerTool in test_client_mir_surface...
#ubuntu-mir 2014-03-17
<RAOF> Today, on âWell, that's weirdâ: Surprise Wallaby!
<duflu_> RAOF: ?
<alan_g> alf__: anpok anyone fancy a quick USC MP? https://code.launchpad.net/~alan-griffiths/unity-system-compositor/tidy-config-options/+merge/210381
<alf__> alan_g: sure
<kgunn> davmor2: on that bug 1290416
<ubot5> bug 1290416 in unity-mir "Mako locks up roughly once a day since R226" [Critical,Confirmed] https://launchpad.net/bugs/1290416
<kgunn> you can still repro with the same steps you listed there in the report i assume ?
<kgunn> just checkin'
<kgunn> altho...this now seems to be a hang in unity-mir
<kgunn> dandrader: are you free enough today to dive into this bug ^
<kgunn> dandrader: it was originally thot to be the null-snapshots for apps problem we found in the mwc images
<kgunn> but that fix has landed in archive/image...and davmor2 says he can still get a crash/hang but just less frequent
<kgunn> bregma: can you or a designate use the silo packages to test unity8 preview and make sure that bug is actually fixed ?
<kgunn> or did you test dev branch already ?
<bregma> kgunn, is the silo ready to test?
<kgunn> ...building
<kgunn> just planning ahead :)
<bregma> OK, ping me again when it;s ready to test and I'll verify -- it's a quick test
<bregma> either you can log in, or you reboot
<kgunn> coolio
<davmor2> kgunn: It's happened to me twice over the weekend, and I think popey got hit by it this morning too. (but that may of been something else)
<davmor2> kgunn: it's slowed down in appearance though.
<dandrader> kgunn, I'm working on the "unity8 as mir compositor" front, but I can switch to this bug if it's more important
<kgunn> davmor2: can you verify that it's creating a crash file ? or how do we know this is still unity-mir ?
<kgunn> davmor2: and ...i guess this is going to take hours at a time to test ? :-/
<kgunn> dandrader: you might be able to continue working....while you test ^ :)
<popey> davmor2: no, i dont believe I have seen that
<davmor2> kgunn: yeap it takes hours, no there is no crash file, I think that I got all the info I could for the guys and added it to that bug when it was in the locked state
<davmor2> popey: that's fine then
<kgunn> davmor2: sorry to be a pest....just want to chat through it... as to help dandrader or whoever gets the bug
<kgunn> davmor2: so...no real repro steps, just play with the phone and let it sit ?
<kgunn> does it happen when interacting with the phone ? or the phone is just resting ?
<kgunn> e.g. is the phone always in "screen off/blanked" state ?
<davmor2> kgunn: it  happens most for me from what I've noticed interacting in the dash so, closing apps, swiping between screens
<davmor2> kgunn: I don't remmeber it locking while resting
<kgunn> davmor2: ok...that's good to know, can you run "top" on it while locked up ?
<davmor2> kgunn: I did and gave feed back nothing was 100%+
<kgunn> davmor2: ok...no worries, that could just mean deadlock somewhere...
<davmor2> kgunn: I don't know if that was added to the bug but I can certainly see if I can find the pastes
<kgunn> davmor2: cool...
<davmor2> kgunn: which is what I think daniel has diagnosed it as iirc from the bug right?
<kgunn> davmor2: yep
<kgunn> davmor2: i was just poking you for info that might not be in the bug... :)
<davmor2> kgunn: meh I can't find the pastes in the irc logs :(  I'll have another dig in a bit.
<kgunn> davmor2: no worries...
<davmor2> kgunn: from the photo attached to the bug you can see where it locked up I was swiping out the launcher :)
<kgunn> davmor2: thanks...and basically that image just sits there, and no touch inputs are responded to right ? (e.g. classic hang)
<davmor2> kgunn: 2 things happen the screen blank kicks in or it displays that image and nothing else, so when you hit the power button it is straight back to that screen rather than the welcome screen (hope that made sense)
<kgunn> davmor2: yes...makes sense...and that's interesting too
<kgunn> definitely a user space deadlock...kernel is ok
<kgunn> davmor2: ok...i'm a liar, one last question :)...any chance you've seen this _without_ activing the OSK ?
<davmor2> kgunn: every thing works via adb so I could run top, I could trigger the backtraces that the guys asked for I just couldn't get the graphics to do anything :)
<kgunn> mmm...i was thinking input lockup for a moment, but you're right, more likely render side
<davmor2> kgunn: pass I'd of been using it on and off throughout the whole day so the OSK would of been open at some point but it hasn't crashed while the osk has been open if that helps
<kgunn> davmor2: if you do find those top traces....let us know...i'd be curious about mem stats too
<davmor2> kgunn: yeap give me about an hour to finish off some other stuff and I'll have a proper dig
<kgunn> davmor2: no problem...we've got plenty to chase in the meantime :)
<alan_g> kgunn: this seems to do it: https://code.launchpad.net/~alan-griffiths/unity-system-compositor/prepare-for-Mir-0.1.7/+merge/211334
<kgunn> alan_g: thanks...i had the exact change almost...but i missed the removal of stand-alone bit
<alan_g> kgunn: yeah. I stole yours
<davmor2> kgunn: meh I can't find them and I think I know why I think it was banded around in the landing hangout not on irc so I'm kinda stuffed when it locks up again I'll get you some copies of top
<kgunn> davmor2: thanks for looking
<kgunn> yeah...just dump it in the bug
<kgunn> bregma: hey on the cursor topic...racar says...
<kgunn> racarr> finished step 1 of 3 steps for client cursor API
<kgunn>  but still desktop preview can be unblocked by just enabling the cursor in USC with a command line option or something
<kgunn> bregma: so will enabling hw cursor via u-s-c do it for you ?
<racarr_> Looks like Canonical has approved a number of travel REQâs to the upcoming sprints in Austin, Las Vegas, Malta and London. As a result I have been sent multiple travel requests all within hours of each other.
<racarr_> las vegas oO?
<bregma> kgunn, I don't see an appropriate command-line switch listed in unity-system-compositor --help ...  the 'or something' might need a little fleshing out
<racarr_> No there is nothing yet I meant
<racarr_> we can add one
<bregma> racarr_, we'd also need to patch lightdm, and prepare for complaints about having the cursor with no mouse:  maybe it's still better to wait for proper support altogether
<ogra_> kgunn, can we land this in the not to far future ? https://code.launchpad.net/~unity-team/unity-system-compositor/new-gl-screen/+merge/210466
<racarr_> bregma: Wait what? why patch lightdm
<racarr_> and what do we mean the cursor
<racarr_> with no mouse
<bregma> racarr_, lightdm is what spawns unity-system-compositor, any command-line option needs to be added there, and a cursor with no mouse happens when you unplug your mouse (or don't have a mouse at all) and there's a cursor
<bregma> eg. the Asus transformer
<bregma> or my Yoga2 when it's folded into tablet mode
<racarr_> ah
<racarr_> second bit isnt entirely trivial to fix
<racarr_> patching lightdm doesnt seem that bad...isnt the command line in some conf file anyway
<ogra_> we support asus transformer with any image out there ?
<racarr_> ogra_: u8 desktop preview
<ogra_> racarr_, we still dont have any arm images for tegra devices anymore
<ogra_> (tegra was happily dropped all over the place)
<racarr_> oh I thought there were x86 ones
<racarr_> lol I have no clue
<racarr_> anyway I dont have a strong opinion on whether we should do the cursor command line thing
<racarr_> but a proper fix is unlikely to land before next monday and it keeps on coming up
<ogra_> heh, well, there probably are ... i stopped looking at transformers a while ago :)
<racarr_> bregma: kgunn: So is the conclusion we are happy if the more detailed cursor fix makes it to mir/devel by monday
<racarr_> and we can avoid doing this thing in USC/lightdm
<racarr_> or
<bregma> racarr_, yes, that should be OK
<racarr_> the opposite
<racarr_> ok
<kgunn> racarr_: if we could get something nice by monday...we'd all be good to go...just note...march 23 is final beta for trusty
<kgunn> final freeze is apr 10th
<racarr_> yeah it seems kind of
<racarr_> that was kind of my point espescially with
<racarr_> sasy mir/devel by monday
<racarr_> worst case is a whole extra week
<racarr_> I dunno though. We can reevaluate wednesday
<racarr_> not counting the time to get stuff to archive etc.
<kgunn> racarr_: we can cherry pick also...which would be a quicker landing
<kgunn> (for mir)
<racarr_> mm
<racarr_> ok well lets reevaluate wednesday or so the
<racarr_> workaround can be
<kgunn> yep
<kgunn> sounds good
<racarr_> done all in one day
<racarr_> so no hurry
<racarr_> Lunch!
<kgunn> bregma: yo!...we got some packages
<kgunn> https://launchpad.net/~ci-train-ppa-service/+archive/landing-019/+packages
<racarr_> annn back
<kgunn> thomi: so is there an "autopilot for dummies" around?...like, if someone just knows they want to add
<kgunn> say a specific test, but doesn't want to learn all the fmwk'y stuff...
<thomi> heh
<thomi> well
<kgunn> template i'm thinking
<thomi> you'd typically talk to your QA representative
<thomi> who will write the first few tests for you, and show you how it's done / train your team
<kgunn> but.....?
<thomi> no 'but', I'm just too tired to structure English sentences properly yet - haven't had my first coffee yet
<thomi> Who have you guys been working with from the QA dept?
<kgunn> ah
<thomi> kgunn: If you're not already working with someone, I can find someone to help you out
<bregma> kgunn, can't test mir 0.1.7 with unity8 because libunity-mir1 has not been rebuilt against it
<kgunn> bregma: hmmm, i'm just updating my phone....libunity-mir1 should be in those packages...
<kgunn> does that make sense ?
<kgunn> it should work
<bregma> maybe the publish hadn't made it out to my local mirror, I'll update again
<bregma> ... yep, looks like that was the problem
<bregma> kgunn, unity8 no longer crashes on startup on the desktop with 0.1.7 from the silo ... something else is totally messed up and nothing renders, but at least it's not crashing
<kgunn> bregma: i don't know whether to be happy or cry
<bregma> kgunn, it may not be a problem in Mir, there are lots of places where things can go wrong between the renderer and the desktop shell
<bregma> one of the errors: QOpenGLShader::link: "error: linking with uncompiled shadererror: linking with uncompiled shader"
<bregma> that's not a Mir problem
<kgunn> ah...phew
<racarr_> bregma: Err, not sure what the context is but this may be an old issue surfacing up again
<racarr_> where qtubuntu forces a GLES context but Qt packages on the desktop are statically compiled
<racarr_> against desktop GL
<racarr_> so sometimes QML emits shaders that
<racarr_> dont compile
<racarr_> we got randomly lucky initially in that the shell worked fine, because it just happened to emit shaders
<racarr_> in the common subset
<racarr_> but some of the qml examples always had this problem
<racarr_> anyway unless anyone ever fixed that its very likely a qt update or random
<racarr_> shell QML change
<racarr_> could have created issues
<bregma> racarr_, I'm familiar with the problem (I'm the one who fixed it in qtubuntu) but it may well be the same problem elsewhere in the stack
<bregma> problem is it's hard to tell who is compiling the shaders
<bregma> ...unless Qt5.2 was built to use GLES only,.....
<racarr_> haha thats what
<racarr_> I was just going to say
<racarr_> re: who is compiling the shaders
<racarr_> you mean where they are coming from?
<racarr_> LIBGL_DEBUG=1 MESA_DEBUG=1
<racarr_> will show the GL errors as they occur (link, etc)
<racarr_> and GLSL_DEBUG=dump will dump shaders but im nots ure that will give you the errors right away
<racarr_> may help
<bregma> I don;t have a problem seeing the errors:  keywords like 'highp' is throwing off the compiler (it's GLES only, Qt build for GL would strip that keyword out of shader code before compiling, which leads me to believe it's a Qt5.2 problem)
<racarr_> sounds like the original problem is back right the
<racarr_> oh no I misread sorry
<racarr_> so, the context is desktop GL (no highp)
<racarr_> but Qt is now compiled to emit GLES
<racarr_> its really shocking to me that that is a
<racarr_>  ./configure option
<racarr_> and not like
<racarr_> a runtime option
<racarr_> or anything else
<racarr_> but anyway
<racarr_> sounds like...fix qt (probably not lol) and or change qtubuntu back to use
<racarr_> GLES
<kgunn> wondered if qt5.2 was going to throw a wrench somewhere
<racarr_> ...ugh already feels like a long day
<racarr_> unfortunately a little to early for that
<rsalveti> racarr_: unfortunately that's a build time decision, and we're also having issues with that for the x86 emulator, as we need gles by default
<rsalveti> I know we have people upstream working to dynamically select the right backend, but would probably be something for qt 5.4
<racarr_> rsalveti: Mm thats what I was saying shocking that it is a ./configure option
<racarr_> ok so it is GLES now though so qtubuntu ust needs to use GLES as well
<racarr_>  / request a GLES context
<racarr_> and everyone can be happy
<racarr_> bregma: ^
<rsalveti> it's not gles by default though
<rsalveti> desktop uses qt built with gl
<rsalveti> I think qtubuntu-desktop is also using gl
<bregma> it looks to me like the patch Add-workaround-for-GL-on-Android-emulator.patch applied to Qt5.2 just Does the Wrong Thing regarding shaders on the desktop -- it forced GLES shaders on the desktop _unless_ it's running on an Android emulator, if I'm readong the code correctly
<rsalveti> that patch was dropped for qt 5.2
<rsalveti> and I'm adding it again, that's just for emulator
<rsalveti> we had it in 5.0 for months
<bregma> I just pulled ubuntu:qtbase-opensource-src, it does not appear to be dropped
<rsalveti> it only affects the shader if render string is Android Emulator
<rsalveti> upstream is only using that for the android backedn
<rsalveti> at least that was the case when I backported the patch
<rsalveti> checking that again
<racarr_> oh sorry misunderstood what rsalveti said
<racarr_> thought you meant switched to GLES by deault
<racarr_> not need
<racarr_> auto optimism completion ;)
<bregma> "if (d->shaderType == Fragment && !ctx_d->workaround_missingPrecisionQualifiers)" is the key line, and workaround_missingPrecisionQualifiers is false on the desktop, meaning with the patch, the GLES-specifci keywords will not be removed from the shader code
<bregma> which is exactly what I;m seeing
<bregma> workaround_missingPrecisionQualifiers is only set to true if glGetString(GL_RENDERER) == "Android Emulator", which is not generally true on the regular desktop
<rsalveti> bregma: right, but that is the expected behavior
<rsalveti> the problem here is why are we getting a GLES specific keyword?
<bregma> oh, so you expect Qt5.2 to not support the desktop?
<rsalveti> that workaround is needed by the emulator because it uses a GLES->GL translator driver
<rsalveti> that's why the need to remove the GLES specific keyword
<rsalveti> a workaround in Qt would be to always force the workaround with true in case the host renderer is GL
<bregma> that would do it
<rsalveti> but that will just be indeed a workaround as the main problem is that it shouldn't even be getting the GLES specific shader at all
<bregma> the only GLES-specific thing about these shaders is the highp/midp/lowp keyword, at least up until recently
<rsalveti> yup
<rsalveti> bregma: do you know who is sending the GLES specific shader?
<bregma> when I was hunting down the qtubuntu problem, they were all default Qt shaders
<rsalveti> hm, that would be unexpected, as qt was built with GL by default on x86
<rsalveti> bregma: we didn't have this issue before, right?
<bregma> there's only one set of shaders, only difference is the precision keyword that gets undef'd
<bregma> until I upgraded my desktop to QT5.2, Unity8 was running (with a patched Mir)
<bregma> now I don't need the Mir patch
<rsalveti> right, shouldn't be related with mir
<rsalveti> then, if you want to have this patch applied more generically, we'd need to find a generic way to find if the host is using GL
<bregma> I think you'll find that if Qt doesn't want to render things nicely on the desktop, there will be a lot of dissatisfied Kubuntu users
<rsalveti> that's for sure, but if that is indeed broken (qt by default sending GLES specific shaders), we have a major issue
<rsalveti> I'm still not sure if this is indeed not caused by our stack
#ubuntu-mir 2014-03-18
<duflu> RAOF: Are the new valgrind failures related to your stuff that landed? https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-amd64-ci/820/console
<RAOF> duflu: Indirectly, yes; leaks in the clients are now fatal, too.
<duflu> RAOF: Hmm, but existing bugs should have blocked it from passing CI before it landed
<RAOF> duflu: But these are obviously nondeterministic failures, because my CI run passed.
<duflu> Whee
<RAOF> I love a nondeterministic leak in the morning!
<duflu> Woo code review backlog halved yet again
<duflu> Interesting. I had to start almost 50 Mir clients blended over each other before any of them slowed down. That's probably pretty good.
<duflu> Arguably 100 (dual screen clone mode)
<duflu> alan_g, alf__:  Am I the only one subscribed to USC bugs?
<duflu> Or am I just the only one particularly interested in them? :)
<alf__> duflu: I am not getting any notifications, let me change that
<alan_g> duflu: you're interested in USC bugs?!
<duflu> alan_g: I mean willing to triage
<duflu> alf__: Particularly Ubuntu project bugs for package "unity-system-compositor" ;)
<duflu> alf__: I found myself looking at how the cursor logic works, and wonder; do we ever intend to support multiple cursors?
<duflu> MirMotionEvent would appear to not care how many there are
<alf__> duflu: I haven't heard of such a requirement. Is there a use case for multiple cursors?
<duflu> alf__: Just wondering, if I had to modify it whether only one would still be acceptable
<alan_g> duflu: I don't think we have any cursor "use cases" but racarr is working on that. I've seen mentions of touch devices having multiple cursors (up to ten) - but I don't know if that is the same thing (because we've not decided what a cursor is)
<duflu> OK, doesn't seem like a big issue
<RAOF> alan_g: Actually, Apple touchpads do up to 15 touches, for some reason :)
 * alan_g counts fingers, toes, nose and wonders...
<RAOF> duflu: Those cursors in MirMotionEvent correspond to touches; unless you think we don't need to support >1 touch, you'll need to keep them all :)
<duflu> RAOF: The issue then is you have to assume pointer[0] is the cursor
<RAOF> No you don't.
<RAOF> Sorry; phone. Let me expound:
<RAOF> You don't assume pointer[0] is the cursor; you only move the cursor in response to MirMotionEvents that come from relative input devices; mice, trackpads, etc.
<RAOF> And then, generally, only when there's a single entry in pointer[] (because otherwise you're on a touchpad doing something like a two-finger scroll, which shouldn't move the cursor)
<duflu> RAOF: Maybe it's just that I never cared to find out the kind of device a motion event comes from, trying to be widely compatible...
<RAOF> Yeah, but for cursors you need to care. Because cursors only make sense for relative input devices.
<alan_g> is anyone looking at the CI failures? Seems to be bug 1293944
<ubot5> bug 1293944 in Mir "Mir deb packages with versioned names cannot be installed simultaneously any more" [Medium,Triaged] https://launchpad.net/bugs/1293944
<alan_g> alf__: is anyone looking at the CI failures? Seems to be bug 1293944
<ubot5> bug 1293944 in Mir "Mir deb packages with versioned names cannot be installed simultaneously any more" [Medium,Triaged] https://launchpad.net/bugs/1293944
<alf__> alan_g: I am not (not yet at least)
<alf__> alan_g: What changed and we are now having this problem? I don't remember having that issue in the past.
<alan_g> alf__: I don't know - I've not looked into it either. (It might well "go away" as the CI system images get updated)
<alf__> alan_g: it could also be a CI script issue... Why is libmirserver16 even installed at that point? The packages built by CI have libmirserver17 in them.
<alan_g> Could it be a transitive dependency? e.g. mesa?
<alf__> alan_g: It could, but unfortunately the logs are not verbose enough to see what's being installed
<alan_g> alf__: OK I'll go ask on #ubuntu-ci-eng
<alan_g> It seems odd that we install *any* to build Mir.
<alan_g> **any* Mir library
<alan_g> alf__: cjohnston thinks he may have found the CI problem - testing now. (Hopefully we'll see a result before EOD)
<cjohnston> alf__: AIUI, with the system-images.u.c changes, that broke our flashing jobs, which prevented devices from being cleaned before the next job ran
<alf__> alan_g: cjohnston: thanks!
<robotfuel> alan_g: fyi ci is failing because a json file moved on a server and phablet-flash isn't resetting the devices like it should be. the phablet-flash jobs are being updated now.
<robotfuel> kgunn: ^
<kgunn> thanks for the heads up
<kgunn> wondered why our mp's were so "red" this morning
<kgunn> thot jenkins was a hater
<mterry> alan_g, I just retested all my split stuff with Mir 0.1.7 and I'm seeing similar (not sure if same yet) symptoms to before your fix to the early buffers in nested mode landed.  Were there other changes that might have affected that?
<alan_g> mterry: otp - 30min
<mterry> np
<davmor2> kgunn: I'm not loving mir today
<kgunn> got it
<alan_g> mterry: sorry - meeting covered a lot more that I expected
<mterry> alan_g, no worries, I got sidetracked myself
<mterry> alan_g, so!  I remember testing your branch earlier in relative isolation on top of 0.1.6
<mterry> alan_g, and what I saw was seamless transitions between my "spinner" app and the greeter.  This was presumably because the greeter didn't create a surface until it had one ready to paint
<alan_g> mterry: I'm not aware of there being anything that reverts the changes, but there are some issues seen elsewhere. Mo
<mterry> alan_g, today I tested on top of 0.1.7 and I'm seeing a "black gap" between spinner and greeter
<mterry> alan_g, not sure if you're familiar with what I mean by spinner
<alan_g> mterry: I'm not
<alan_g> But these are similar effects to what you describe: <kgunn> bugs -> https://bugs.launchpad.net/mir/+bug/1294051 https://bugs.launchpad.net/mir/+bug/1294053 https://bugs.launchpad.net/mir/+bug/1294048
<ubot5> Ubuntu bug 1294051 in Mir "Apps are much slower to open" [Critical,New]
<ubot5> Ubuntu bug 1294053 in Mir "Settings app opens to a blank screen unless given enough time to render or the app is touched" [High,Confirmed]
<ubot5> Ubuntu bug 1294048 in Mir "Touch has a rotate issue" [Medium,Confirmed]
<mterry> alan_g, the spinner is just a small client that USC uses when a Mir session is supposed to be focused but isn't ready yet (like on boot, or on lock if the greeter is slow to appear)
<alan_g> I guessed as much
<mterry> alan_g, and USC switches to the session once it has a surface
<alan_g> And the "black gap" was the sort of artifact you saw when the nested session posted buffers prematurely?
<alan_g> AlbertA: not sure if you've found anything, but this ^^ sounds like it might be another symptom of the same problem.
<mterry> alan_g, yeah
<AlbertA> alan_g: yeah I found the issue
 * mterry perks up
<alan_g> \o/
<alan_g> What is it?
<AlbertA> alan_g:
<AlbertA> alan_g: oops, it's renderable.buffers_ready_for_compositor() > 1;
<AlbertA> it should be > 0
<AlbertA> in rendering operator
<alan_g> It shouldn't
<AlbertA> it always misses the last frame
<AlbertA> because it's asked
<AlbertA> after compositing
<AlbertA> not before
<alan_g> But the one it just composited is still "ready"
<AlbertA> alan_g: nope
<alan_g> and shouldn't be counted
<AlbertA> alan_g: that
<alan_g> AlbertA: but the renderable doesn't know which compositor rendered the buffer: there's always one "ready".
<AlbertA> alan_g: ummm
 * mterry can easily test to see if it at least solves my problem (as a data point)
<AlbertA> alan_g: why would there always be one ready
<AlbertA> in any case it does solve the 3 bugs
<alan_g> At the expense of always scheduling another compositing pass.
<AlbertA> alan_g: because there were buffers ready though
<AlbertA> alan_g: from my log the client posted one
<AlbertA> alan_g: and it was not composited
<AlbertA> alan_g: at the end
<AlbertA> alan_g: i.e you see a client_release, but no following compositing step
<alan_g> AlbertA: OK that is wrong, but I don't think the fix is right (or at least complete)
<AlbertA> alan_g: sounds like a race between asking the number of ready buffers
<AlbertA> alan_g: and when compositors release the acquired buffer?
<AlbertA> alan_g: from what I gather from your comments
<alan_g> The fact that a buffer has been composited doesn't make it unavailable for compositing
<alan_g> Because another compositor can use it for the same frameno on a different screen
<AlbertA> alan_g: right...but then we need a notion of
<AlbertA> alan_g: of buffers not posted by any compositor
<AlbertA> alan_g: call I suppose
<AlbertA> alan_g: ahh which I guess nCompositors fills that role
<alan_g> But compositor B still needs to render the buffer even though compositor A has already done so.
<AlbertA> alan_g: yeah I got that
<AlbertA> alan_g: just trying to see how we can check the number of pending buffers for a specific compositor
<AlbertA> alan_g: since right now rendering operator does not have any knowledge of what compositor is being called from
<alan_g> I figured it was the number ready for compositing less the one we just composited.
<AlbertA> well in the case of one compositor
<AlbertA> only
<AlbertA> nready does go down
<alan_g> But you're right - that one can have been "eaten" by the client
<AlbertA> but for multi compositor it does not for the reasons you mention
 * alan_g didn't do enough testing on single monitor setup. /o\
<alan_g> So if we move "uncomposited_buffers |= renderable.buffers_ready_for_compositor() > 1;" to the top of the function?
<alan_g> We'll get the count we actually want regardless of the number of compositors?
<AlbertA> alan_g: I think so, but still racy isn't it between compositors?
<alan_g> AlbertA: I think they should see the same value - because the count changes later.
<alan_g> But this isn't my favourite code to reason about
<kdub> yeah, not mine either
<kdub> seems a good time to diffuse some of it though
<AlbertA> alan_g: yeah the nReady logic is hard to follow
<alan_g> AlbertA: are you set up to test shifting the assignment?
<AlbertA> alan_g: I'm about to test it
<AlbertA> alan_g: I mean on android, I don't have a multimonitor setup at the moment
<alan_g> AlbertA: I do - and am about to build it
<mterry> AlbertA, I did test your > 0 change for giggles and it didn't fix the issue I was seeing.  Should I try moving assignment or do you think that means that my problem is not the same?
<AlbertA> mterry: probably not the same then
<AlbertA> alan_g: yeah moving the assignment works well here
<alan_g> AlbertA: I don't see any obvious side-effects on multi-monitor
<mterry> alan_g, AlbertA: assuming that wasn't my bug then, I'll take any wild guesses before I start deep-diving to find difference
<AlbertA> mterry: yeah this is more about not compositing the last posted buffer from a client
<AlbertA> mterry: sounds like you still have a blank buffer kinda issue no?
<mterry> AlbertA, alan_g: currently USC is just using the existence of a surface to start showing it.  Should I be calling something like "ready_to_composite()" on the surface/session to confirm it's ready to be shown?
<alan_g> mterry: there's a buffer available when swap_buffers after called with a non-nullptr parameter
<alan_g> mterry: there's a buffer available after swap_buffers called with a non-nullptr parameter
<alan_g> The surface exists as soon as the client creates it
<mterry> alan_g, guh, OK.  I have to go back to intercepting swap_buffers.  When I tested with your branch before, I didn't need to bother with that, so I assumed things had changed.  No biggie.  I can test with that
<mterry> alan_g, thanks
<anpok> hm is there something wrong with nested in devel?
<alan_g> anpok: other than ^^?
<anpok> :)
<anpok> if i start demo shell as root, chmod 666, then conenct another demo shell as user, vt switch does not hang.. everything seems fine
<anpok> as soon as I start e.g. finger paint connecting to the nested shell vt freezes
<alan_g> anpok: are the server processes still running?
<anpok> sleeping all of them.
<alan_g> anpok: what about simpler clients? mir_demo_client_basic for example?
<anpok> not yet tried .. first tried on my branch then on devel ..
<anpok> if it fails you see me reconnect..
<anpok> since restarting x did not help either
<alan_g> anpok: the other thing to try is sshing in and "sudo chvt"
<alan_g> AlbertA: it also fixes lp:1290306
<AlbertA> alan_g: really? nice
<AlbertA> alan_g: so screencasting should be fixed by this too then...let me try
<AlbertA> alan_g: is the sync logic supposed to track the fastest compositor or the slowest?
<AlbertA> alan_g: I suppose the fastest making the other drop frames when necessary?
<AlbertA> the issue with screencasting is if the screencast compositor renders faster than the display compositor
<AlbertA> the display compositor starts dropping frames
<AlbertA> I suppose to catch up
<AlbertA> so the clients think they are rendering faster
<alan_g> AlbertA: I'm not 100% certain. duflu chose the algorithm
<AlbertA> but for the special case of screencasting it whould be the other way around
<alan_g> Anyway, I'm past EOD - so if there's nothing urgent?
<AlbertA> alan_g: no, just rambling
<dansuf> Hi, I'm porting touch to my phone, I've got this error when running lightdm: http://pastebin.com/KMaQKNEL
<dansuf> and in unity-system-compositor-log I've got this error:
<dansuf>  terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
<dansuf>    what():  error during hwc set()
<kdub> dansuf come back!
<anpok> adreno200
<mterry> If I wanted to call "set_focus_to(session1); set_focus_to(session2)" in USC, how do I guard that so that the user doesn't see a peak of session1?  Compositor::stop/start?  Scene::lock/unlock?
<kgunn> racarr_: ^ ?
<kgunn> i would have guessed, never start the compositor
<kgunn> ....
<kgunn> kdub: or AlbertA might know as well... ^^
<kdub> where did he go...
<AlbertA> yeah I would say don't start the compositor until after session2 focus
<kdub> why would the compositor affect the input focus?
<AlbertA> I believe he's trying to hide the surface more than anything
<mterry> AlbertA, kdub: I want the graphics system to not make any immediate changes when I do set_focus_to(session1), but wait until I'm done setting focus to(session2)
<mterry> or at least, not render the changes
#ubuntu-mir 2014-03-19
<kdub> ah, because right now the focus is tied to the z-order?
<AlbertA> right
<kdub> let me poke around...
 * mterry wasn't able to find something appropriate
<kdub> mir::DefaultServerConfiguration::the_shell_focus_setter maybe
<kdub> but that might be something to fix in msh::DefaultFocusMechanism too
<kdub> racarr_ ^^?
<mterry> kdub, well.  I mean, sure.  I'm using focus to get at z-order (it's actually convenient that they're tied together now). But my goal is not to futz with the focus subsystem, but to avoid the flash of session1 when I'm trying to adjust z-order of sessions
<AlbertA> does the focus change force show on the session?
<AlbertA> meaning have you tried session1->hide()
<AlbertA> just from poking at the source it doesn't look like it "unhides" it
<mterry> oh hm, maybe...  let me try clever hiding/showing
<mterry> AlbertA, unhides?
<AlbertA> shows
<mterry> AlbertA, ah the focus you mean
<AlbertA> heh
<AlbertA> right
<mterry> AlbertA, let me play with hiding, good idea
<AlbertA> the focus change in DefaultFocusMechanism doesn't look like it messes with the show/hide state
<racarr_> woah things happened
<racarr_> *reads*
<racarr_> I see.
<racarr_> oh
<racarr_> mterry left
<racarr_> I think the answer is to overrride the focus setter...I dont understand
<racarr_> exactly why
<racarr_> you would focus 1 session then another but not want the 1st session to show up
<racarr_> if it ust needs keyboard focus or something like that there is the mir::shell::InputTargeter
<racarr_> Iunno.
<racarr_> oh I see using focus to adjust the z order
<racarr_> I think the answer is to use surface->raise ;)
<RAOF> Heh.
<RAOF> racarr_: Yo!
<RAOF> You in the mood for some cursory stuff?
<RAOF> I Have Opinions!
<duflu> AlbertA: Can you remember to set the Milestone and other details on bugs when you're working on them? Otherwise I have to play catch up and fix them every day :)
<AlbertA> duflu: sure
<duflu> AlbertA: Thanks. Don't be afraid to do project management stuff in Launchpad. It's really just a matter of whoever-notices-what-needs-fixing-first
<duflu> RAOF: Any tips on my comment to https://bugs.launchpad.net/ubuntu/+source/unity-system-compositor/+bug/1294507
<duflu> ?
<ubot5> Ubuntu bug 1294507 in unity-system-compositor (Ubuntu) "unity-system-compositor crashed with SIGABRT" [Undecided,Invalid]
<anpok_> resize events hmm
<anpok_> they never seem to happen for the surface of a nested server
<anpok_> duflu: can you give me a hint - when finger paint runs in nested, and the nested surface gets resized.. the finger paint surface is aligned bottom left..
<anpok_> another thing I saw is that the gl_renderer in the nested server still assumes the same view port size
<duflu> anpok_: Not sure. I suggest checking that you haven't accidentally dragged/moved the whole nested server surface inside demo-shell
<anpok_> to circumveit that I injected a resize event to the client side surface when a different sized buffer arrives..
<anpok_> checked that
<anpok_> i do exactly that
<anpok_> only move the nested server
<duflu> anpok_: Still don't know :(
<anpok_> I am verifing that co-ordinate transforms are now correct
<anpok_> thats just a side issue now..
<anpok_> I mean.. co-ordinates are correct, but mismatch with visaual placements..
<anpok_> k
<anpok_> will dig further..
<duflu> anpok_: Obviously, test with development-branch and see if it has the same bug :)
<anpok_> it has
<anpok_> and other things
<anpok_> now that I made the gl_renderer get the right view port rectangle the top left alignment is correct..
<duflu> anpok_: That doesn't sound right. How is the viewport rectangle wrong?
<anpok_> but the displayed finger paint surface seems to have increased in scale by the fraction the nested surface got resized..
<duflu> anpok_: Sounds like you resized the nested server
<anpok_> Yeah thats what I do
<anpok_> (not supported?)
<duflu> Never considered really
<duflu> I guess coordinates could be wrong
<anpok_> I resize the nested server surface to lik 50x50 .. and gl_renderer::set_view_port gets no call.. still assumes 0,0 1600x2560
<anpok_> or rtahter 2560x1600 or something..
<duflu> anpok_: I was playing with set_viewport yesterday. It doesn't (yet) get called after construction. Sounds like we need to call it more/
<duflu> ?
<duflu> For the nesting case
<anpok_> It gets called at construction.. but a resize of the nested server does not cause another renderer reconstruction
<duflu> anpok_: If you can please isolate any fix for that bug from your other work
<anpok_> hence it stays at initial size
<duflu> Yeah, sounds like a nesting-specific bug
<anpok_> but I can pass the information from the resized surface through the nested output down to the renderer object
<anpok_> that change enough for a MP?
<duflu> anpok_: As small as possible is always best. If you can separate things then do
<anpok_> k .. will check for scaling later
<duflu> anpok_: And a bug report to describe the problem :)
<anpok_> hehe
<anpok_> thats the hardest part
<anpok_> can you have a brief look at my branch .. hmm
<anpok_> wait
<anpok_> http://bazaar.launchpad.net/~andreas-pokorny/mir/add-geometry-transformation/view/head:/include/shared/mir/geometry/transformation.h
<anpok_> It is lacking a better name..
<anpok_> In a later MP I want to use that to do the co-ordinate transformations
<anpok_> it allows us to avoid any calculations and still supports rotations scaling and so on..
<anpok_> and makes it simple to make run time changes to them..
<anpok_> brb
<anpok_> I am no longer sure about the name..
<anpok_> as I was about to add something like rectangle hit testing as a free standing function or method..
<duflu> anpok_: Transformations are arbitrary so we should stop mentioning "rotate" or "scale" completely. Instead the code that needs those (render_surfaces) should just surface->set_transformation(some_matrix)
<duflu> It might be a good idea to replace set_rotation in our existing classes with set_transformation(). Now we can
<duflu> anpok_: I was going to do it, but it would be awesome if you could generalize set_rotation() to set_transformation() and move the responsibility for creating the rotation matrix into render_surfaces
<duflu> Woo... multi-monitor frame sync without framenos, on the way
<anpok_> duflu: I wanted to do that with the help of transformation ..
<anpok_> which I meant to become a generalization of surface positioning and transformation.. + the inverse ..
<anpok_> doing the inverse on a matrix does take some more time and it does add some floating point error..
<duflu> anpok_: Oh, I see now. The generic name confused me. It's more than just a transformation. Regardless, we need to remove all mentions of rotation and scaling from the existing surface classes. They should only know a single  "transformation" matrix
<duflu> anpok_: We should also *never* need to invert. Matrices should be arranged such that you only try to invert orthonormal matrices (whose inverses are just transpose)
<anpok_> yes, thats what I have been doing internally
<anpok_> the intersting part will be to which surface interface the change should happen
<duflu> anpok_: I'm running out of time before I have a family dinner to run to. But is the meaning of Transformation to join transformation() and size+position into one? If so then I get it but "Transformation" is a bad name
<anpok_> sure
<anpok_> I try to change my bio rythm
<anpok_> go!
<duflu> anpok_: I still suspect the whole exercise is a bad idea. You would have to integrate the whole display transformation into the input logic to get it right. Not just surface transformations. The display transformation will change at the Renderer level during some effects (in future)
<anpok_> hm as you already said .. those changes are temporal
<anpok_> thus .. if the effect is going to be persistent.. the input system needs to know about it..
<duflu> anpok_: Yeah good memory. We could just block all input during such transformations because "we can't calculate it"
<duflu> Compiz solves the problem by only supporting relative movement. It never needs or uses absolute coordinates
<anpok_> i suspect shells would only use reasonable transformations in a persistent manner.. and thats the use case here..
<anpok_> I dont think that solve anything.. since a relative movement on a transformed surface still needs to be transformed..
<duflu> It would be a lot less work. But also couldn't support touch
<anpok_> i took care to not impose unnecessary calculations when dispatching input
<anpok_> but measurements on n4 showed that the worst case isnt that bad either
<duflu> anpok_: I suspect your super "Transformation" might not need to be a class. Maybe just a new function - surface::transformation_with_size_and_position()
<duflu> And then I ran out of time
<mlankhorst> RAOF: ping?
<RAOF> mlankhorst: Pong?
<mlankhorst> RAOF: oh less relevant now that I did the work myself, did you update mir for 10.2 snapshot-ish?
<RAOF> mlankhorst: No, not since 10.1.
<RAOF> That area of the code shouldn't churn much, though?
<mlankhorst> yeah I did some work in ubuntu+1, I'll push it soon :P
<mlankhorst> it moved some crap to a vtable
<RAOF> Oh.
<RAOF> We should really get around to sticking the whole EGL platform stuff into loadable modules.
<mlankhorst> or upstream it already
<RAOF> Well, both, ideally.
<mlankhorst> stuffed it in ppa:canonical-x/x-staging
<anpok_> alan_g: the issue from yesterday https://bugs.launchpad.net/mir/+bug/1294610
<ubot5> Ubuntu bug 1294610 in Mir "client attaching to nested server seems to freeze the VT" [Undecided,New]
<alan_g> anpok_: I remember you asking about it
<anpok_> no news.. so far.. I could not dig further. It is no issue on android
<anpok_> I first have to improve my second terminal for debugging - that means replacing a hard disk..
<alan_g> Yeah, I usually ssh in from another box for this stuff. (And VT is only relevant to mesa)
<anpok_> alan_g: not sure if you noticed from the scroll back I try to resolve a window placement issue with nested clients being resized.
<anpok_> hm it might be a reasonable rare use case but we have it in the demos
<alan_g> anpok_: I didn't. So that's with a client of a server_shell that's a client of a server_basic?
<anpok_> two server shells and fingerpaint
<anpok_> with a minimal change I made the nested shell become aware of a resolution change
<alan_g> But the hose server_shell will process the resize
<anpok_> yes
<alan_g> *hist
<anpok_> means nested surface gets smaller..
<alan_g> **host
<alan_g> ack
<anpok_> but nested server still renders like full screen
<anpok_> and also has view port set up like that ..
<alan_g> I understand
<anpok_> due to the way gl writes to the buffer it gets bottom left aligned and hence touched pixels do not match drawn pixels
<anpok_> or rather touch co-ordinates that get proper transformed..
<anpok_> maybe I just provide my change as a MP and we discuss that there
<anpok_> i mean .. I think I need to do more .. like announce that the display output changed ..
<alan_g> that makes sense - but is this the most urgent thing to fix?
<anpok_> alan_g: what is urgent?
<alan_g> anpok_: The stuff needed for 14.04 touch
<greyback> alf__: hey, I'm running in multimonitor (MM) setup (just 2, not mirrored). But when I bring up mir_demo_server_shell, I get mirrored output. Is there a demo to test Mir's MM abilities?
<greyback> alf__: never mind, found the CLI switch
<alf__> greyback: mir_demo_server_shell --display-config sidebyside and you can try mir_demo_client_display_config to change config on the fly (see help for handled key events)
<alf__> greyback: ok
<greyback> alf__: thanks :)
<kgunn> greyback: mterry alan_g|lunch ... so i'm following up on a request to think about making mir/unity-mir/usc one source tree, for the obvious reason it makes build/release life simple...but i think it's a bad idea (e.g. hard to quick release a unity-mir fix for instance)...thots ?
<greyback> alf__: sorry, am idiot, but where do I see the mir_demo_client_display_config help? The --help switch (or -h) is ignored
<mterry> kgunn, yeah, both unity-mir and usc often have feature/bug fix releases unrelated to mir
<kgunn> ..and the real answer is live with the release pain in order to drive us to a stable server i/f
<kgunn> imho
<alf__> greyback: it works for me :/
<greyback> alf__: ah, I'm running it with sudo (since mir server root), and the --help switch seemed to be ignored
<alf__> greyback: hmm...
<greyback> kgunn: I'm against it. While yeah I do see the benefit for distro releases, I fear it'll give the appearance that Mir is Qt only. For nonQt users, do we add configure time switch to disable Qt (and thus unity-mir) at build time then? What if I want to make a unity-mir clone in GTK, where does my code best go?
<kgunn> ah nice point
<greyback> kgunn: also, long term ambition is to get large chunks of unity-mir into Qt. The Qt guys were interested in supporting Mir, like it supports Wayland
<greyback> so shoving that code directly into Mir just complicates that transition path
<kgunn> ack
<greyback> kgunn: I was of the impression that the whole silo infrastructure was designed explicitly for this very problem anyway
<kgunn> greyback: it is, altho only 1/2 way there...what's missing is a "dedicated silo" for us which is in the plans (e.g. what they call "airline" vs "train")
<greyback> kgunn: I see. Then the airline sounds like the right way to go IMO
<alan_g> +1
<kgunn> they've also taken one step closer...you can get around the "silo-ck" allowing you to build at will (but not land) when another person is trying to build/land in the same project
<kgunn> cause the silock is really where the pain (time delay) has been
 * alan_g wonders where we can find hosting to set up our own build system
<greyback> alf__: I guess changing display resolution/refresh rate with xrandr doesn't impact the resolution Mir chooses
<alf__> greyback: the display configuration is per VT so they act independently
<greyback> alf__: aha
<alf__> greyback: (assuming you mean mir in a VT and normal X in another, not talking about XMir)
<greyback> alf__: correct assumption. Essentially I'm trying to set up my env so I can see the impact of the MultiThreadedCompositor, i.e. when the outputs have different resolutions. I guess I should see frame drops on the slower display
<greyback> alf__: but xrandr depends on X. Know any way I can configure a display without X?
<ogra_> fbset ?
<alf__> greyback: Why do you want to configure a display manually? In any case, mir should be able to set the display configuration you want (perhaps need to hack the example code to do so).
<greyback> alf__: both my displays run at about 60Hz, but my monitor can run at 75Hz with a lower resolution, so want to select that resolution for MIr.
<greyback> I'll see what I can hack in
<alf__> greyback: ok, that's possible, but it's not provided by default by mir_demo_client_display_config.
<greyback> ok
<alf__> greyback: you need to set MirDisplayOutput::mode to the value you want (index of one of the modes available in ::modes[])
<greyback> alf__: that's useful, thank you
<alf__> greyback: sorry, that's MirDisplayOutput::current_mode
<kdub> anyone else want to weigh in on https://code.launchpad.net/~kdub/mir/platform-specific-options/+merge/210500 ?
 * alan_g has said enough
<kdub> alan_g, yeah, thanks for the reviews :)
<alan_g> kdub: try alf__
<anpok_> hm alan_g said that it only works if we ignore unknown options in mir server, is that still true?
<anpok_> I thought this change now just exposes the underlying boost program options to combine them with the platform graphics options?
<kdub> we have to parse the options twice, once to get the right platform library name
<kdub> and the first parse just scans for the platform library name, so it ignores any other specified options
 * alan_g said that it only works *because* we ignore unknown command-line options
<anpok_> ah because during the first scan we have those only supported by the platform.. and the then on second scan with the options from platform graphics we get could fail on unknown ones..
<anpok_> do we care that about frequency of ABI breaks when we expose boost program options to the server<->platfrom graphics interface?
<kdub> server/platform abi moves in lockstep
<alf__> kdub: looking
<kdub> thanks!
<racarr_> mterry: Btw I saw your question yesterday after you left...you should be able to use surface->raise to set the Z orders
<racarr_> so then you can use hide
<racarr_> (which using focus to set z order will undo for you)
<mterry> racarr_, well, I want to do it on a session level, but I suppose I could do it to each surface in session, and try to keep existing order internal of the session
<mterry> racarr_, is that right, that focus calls show?
<racarr_> mterry: Yes focus calls show
<mterry> racarr_, ok, that would explain some flicker
<racarr_> Is it possible for you to ust place them in depth appropriately as they are created
<racarr_> you can set depth in PlacementStrategy
<racarr_> bregma: So cursor fix is going to be a little longer probably so going to do the quick and dirty solution
<racarr_> need to understnad a few details of the configuration for desktop preview
<racarr_> what else is running under USC? I mean.
<racarr_> IS greeter under USC? What about xmir?
<racarr_> greeter isnt under USC presumably but does that happen if they install xmir?
<racarr_> is that supported
<racarr_> etc
<racarr_> kgunn: ^
<kgunn> robert_ancell: ^ you know ?...in the context of unity8 desktop preview
<robert_ancell> racarr_, kgunn, greeter is not running under u-s-c. LightDM launches a u-s-c for each Unity8 desktop session and it only runs the shell inside that
<racarr_> hi robert_ancell!
<racarr_> ok perfect
<robert_ancell> racarr_, hey :)
<robert_ancell> I don't know of the support status of xmir - we still have all the code in LightDM but you'd have to install the packages to enable it
<racarr_> err hey wait
<racarr_> if we launch a usc for each Unity8 desktop session
<racarr_> and only run the shell
<racarr_> why are we launching
<racarr_> USC
<robert_ancell> racarr_, because we need u-s-c as root and the shell as non-root
<racarr_> oh of course lol
<racarr_> Ok :D
<robert_ancell> it's basically u-s-c "pretending to be an X server"
<racarr_> (dealing with enabling cursor in desktop preview for context)
<robert_ancell> yep
<racarr_> Where does the bit that tells lightdm how to launch USC for the desktop preview
<racarr_> look?
<racarr_> will need to add a command line option there
<racarr_> s/look/live/
<robert_ancell> racarr_, the usc command line?  Or the bit that tells lightdm that a session should run in Mir?
<racarr_> robert_ancell: the usc command line
<racarr_> I mean the situation is ust we disabled the hardware cursor in USC for xmir so
<racarr_> need to add a --enable-cursor to USC and
<racarr_> have lightdm pass it
<racarr_> for desktop preview
<robert_ancell> racarr_, ah, ok. You need to edit src/unity-system-compositor.[ch] and add that as a property
<robert_ancell> and set that property in src/seat-xlocal.c in create_unity_system_compositor()
<robert_ancell> and then update in tests/src/unity-system-compositor.c to report that flag and then tests/scripts/*.conf to check for it
<racarr_> err is this for desktop preview only though? dont want to pass --enable-cursor to XMir
<robert_ancell> racarr_, is this the long term solution? Or should the shell be triggering / rendering the cursor?
<racarr_> robert_ancell: Perhaps in the long term just the shell renders the cursor
<robert_ancell> racarr_, we use src/seat-unity.c for "proper" Mir sessions
<racarr_> perhaps as early as next week
<robert_ancell> src/seat-xlocal.c is the traditional VT switched sessions
<racarr_> xmir just disables it via cursor client API
<robert_ancell> xlocal is a legacy name, we should really name it to seat-vt.c now
<racarr_> but things are getting close on desktop release so just trying to take care of it...didnt realize it would involve
<racarr_> so many changes to lightdm though...I was expecting some like
<racarr_> u8-desktop-session.conf or something and I would just add an argument there
<robert_ancell> racarr_, you can do that too
<robert_ancell> by setting unity-compositor-command in the config
<robert_ancell> it might interact with xmir seats though because that config is shared between the two
<robert_ancell> racarr_, I can do the lightdm change if you want, it wont take long
<robert_ancell> racarr_, but if you have this cursor client API, why not just enable it through that?
<racarr_> robert_ancell: Ok if you dont mind that would be great :D Ill do the USC changes now...option will be --enable-hardware-cursor=on/off (default: off)
<racarr_> robert_ancell: Oh because its not going to be finished until the next day or perhaps the day after that then
<robert_ancell> ok
<racarr_> its gotten kind of large so will take a while to review
<racarr_> then there is the whole landing cycle...
<racarr_> and it could easily be 2 weeks before anything could use it I guess
<racarr_> so starting to get concerned about desktop freeze
<racarr_> robert_ancell: I guess just --enable-hardware-cursor to enable it
<racarr_> omit to disable it is better
<racarr_> no on/off aha
<robert_ancell> yeah, I was worried about breaking older versions
<robert_ancell> will do
<racarr_> robert_ancell: nvm I forgot how boost::option works it has to be --enable-hardwarecursor=on/1/true/whatever (I guess pass true)
<robert_ancell> racarr_, lp:~robert-ancell/lightdm/usc-hardware-cursor
<racarr_> but alse will still be the default so can still omit it
<robert_ancell> oh, so I have to send --enable-hardware-cursor=true?
<racarr_> yes...sorry
<racarr_> https://code.launchpad.net/~robertcarr/unity-system-compositor/add-cursor-option
<racarr_> bregma: kgunn: ^ these two branches should do it I guess
<racarr_> maybe this is an appropriate situation for distro patching?
<bregma> I can't test anything until I figure out why Qt5.2 doesn't work on the desktop
<racarr_> Ah of course
<racarr_> any progress on that end?
<bregma> racarr_, nope, except I get it on all my machines :( and when running apps over ssh but not when I run apps from unity7, so I suspect it may have to do with Mir after all
<kgunn> racarr_: robert_ancell ...thanks for sorting that out (and so freakin' quick :)
<kgunn> robert_ancell: btw, how the heck are you ?
<robert_ancell> kgunn, doing well, yourself?
<robert_ancell> nice location for the next sprint :) Will be good to catch up with all
<racarr_> yes thanks for help robert_ancell  :)
<racarr_> I know right? When kgunn said it might be something exciting
<racarr_> I kind of assumed that was a oke and we were going to Boston
<racarr_> :p
<kgunn> robert_ancell: good, if we could just get the spring weather to stick in texas...it keeps freezing every few days
<kgunn> i know...its cool enough i'm gonna have my wife join for some time after the sprint
<robert_ancell> I have a feeling a lot of the company will be taking holidays around this sprint
<racarr_> RAOF: Ping?
<racarr_>  or perhaps pong technically
<racarr_> brb in 10.
<racarr_> back
<RAOF> racarr_: Pong!
<RAOF> racarr_: You're thinking cursors?
<racarr_> RAOF: Yes. and wondering wwhat you were thinking
<RAOF> Cool.
<racarr_> as to the small bits that were on launchpad...uh
<racarr_> it was a mild hallucination that doing it per connection was going to be easier and also a useful step towards per surface so I ust imagined doing that first
<RAOF> Hah!
<racarr_> but have now decided it was silly and am on to mir_surface_set_cursor
<racarr_> and um...
<RAOF> It probably _would_ be easier to do per-connection :)
<racarr_> well but you have to write code that ends up not being useful
<racarr_> so its pretty pointless
<RAOF> Yeah.
<RAOF> It's not a step towards per-surface cursors, which is what you need.
<racarr_> Also re:create_hardware_cursor
<racarr_> and unique/shared here it actually is shared
<racarr_> with the GBM::Display which manipulates it in case of pause/stop, etc.
<racarr_> which is mostly why it hasnt been moved to some more appropriate place of allocation yet
<RAOF> Urgh.
<racarr_> err pause/resume
<racarr_> to restore the position iirc
<RAOF> Yeah, because it's all wrong! :)
<racarr_> lol
<racarr_> what are your thoughts :D
<RAOF> So, what I think should be the final state is: The cursor is a renderable in the scene, and the compositor is responsible for getting it on the screen.
<RAOF> Under GBM the compositor will check if the topmost renderable in the scene is (a) the existing hardware cursor or (b) usable as a HW cursor, and do the API twiddling necessary.
<racarr_> ok
<RAOF> Under Android the HWC machinery will translate into basically a HW cursor anyway
<racarr_> Yes
<RAOF> So I think all the Cursor API wants to be is basically a pointer at a specific renderable.
<racarr_> hmm well I mean
<RAOF> If we want a server cursor API at all, I guess?
<racarr_> it seems like it still needs to be promoted to the server configuration and
<racarr_> from the perspective of mg::Cursor
<racarr_> RAOF: Well we are baking window management in to mir
<racarr_> so the surface cursor selection has to work by default
<racarr_> and input should be hooked up to the cursor, etc
<RAOF> Oh, yeah.
<RAOF> That was just rambling as to what extent we need a Mir-private Cursor API.
<RAOF> Or whether the various bits could just prod the relevant Renderable.
<RAOF> It's probably cleaner to have an actual interface to prod, though.
<racarr_> hmm
<racarr_> yes it is for tests
<racarr_> at least
<RAOF> Right.
<racarr_> its nice for example in the tests im doing to ust mock the_cursor on the server side
<racarr_> and expect that set_image is called various ways as
<racarr_> I generate motion events
<racarr_> etc
<RAOF> Yeah.
<racarr_> so, it should also be a renderable though
<racarr_> and rather than this whole weird bit where
<racarr_> the GBMDisplay holds on to it and
<racarr_> such
<racarr_> the default shell becomes responsible for putting it in the scene I guess?
<RAOF> Right.
<RAOF> I think so, yes.
<RAOF> Unless we want to bake in âthe cursor is always on top of everythingâ.
<RAOF> Which I'm ambivalent about.
<racarr_> mm I mean maybe its the deault shell, deault server configuration
<racarr_> somewhere there is a line that is like hey take the_cursor and put it on the_top_of_everything
<racarr_> lol Mir::DefaultServerConfiguration::the_top_of_everything
<racarr_> that seems like a good interface
<RAOF> :)
<RAOF> I think having it default to on top but overridable in the same way we let everything be overridable is correct.
<racarr_> ok  I think that makes sense. I think I can do that when I implement a software cursor
<racarr_> I want to finish this client API/theme loader stuff first
<racarr_> its gotten kind of large diffish lol
<RAOF> Yeah, theme loader stuff is a reasonable first step.
<RAOF> That way we can actually load different cursors :)
<racarr_> Im hoping to finish the client API bits and the cursor changer response to input thingamawidget tomorroww so thatw
<racarr_> we can at least enable/disable cursor and use that for xmir/desktop preview
<racarr_> then will finish the theme loader branch by friday
<RAOF> Yeah, would be nice.
#ubuntu-mir 2014-03-20
<alf__> greyback: Good morning!
<greyback> alf__: hey
<alf__> greyback: I am looking at the QtSG source code and I have some questions.
<greyback> alf__: shoot
<alf__> greyback: I see that each rendering thread (in qsgthreadedrenderloop.cpp) creates its own gl context, possibly shared with another context. How does this interact with the context provided by the DisplayBuffers?
<alf__> greyback: i.e. at some point there is "gl = new QOpenGLContext();", how do we manage to tell Qt to use our context instead? Or do we do something different?
<greyback> alf__: where do you see it actually creating the context? It should be asking the QPA (platform abstraction plugin) to create the gl context for it
<alf__> greyback: ah, so  QOpenGLContext() ends up calling our QPA to do the actual context creation?
<greyback> alf__: right, I implemented QPlatformOpenGLContext, which should on construction creates & wraps a gl context, exporting swapBuffers & makeCurrent and other methods
<greyback> what I actually do I just wrap the DisplayBuffer object from mir, knowing that the DB created the gl context, and connecting the makeCurrent and swapBuffers methods
<alf__> greyback: hmm, how will that work with multiple display buffers? How could we know which DisplayBuffer to use when we get a call to create a context?
<greyback> alf__: Each QWindow can have its own gl context. I wrap each DisplayBuffer with QOpenGlContext, and can ensure that each QOpenGlContext is used by a different QWindow. Then I'm hoping that Qt will just do the right thing
<greyback> since it has a render thread per QWindow
<greyback> that is what I need to check
<alf__> greyback: Since QOpenGLContext(); is called without any arguments, how can we know which QWindow this context is targeted for and hence which display buffer to use?
<alf__> greyback: unless there is some strict ordering that we need to follow so that QWindows match with the correct QPA gl contexts, but this seems very fragile...
<greyback> alf__: I agree it's not ideal, this is abusing Qt's window-based architecture a bit. But see that QSGRenderThread calls gl->makeCurrent(window), there is specifies which QWindow, and thus which DisplayBuffer to use
<greyback> alf__: QSGRenderThread::run I mean
<alf__> greyback: ok, so the QOpenGLContext we provide has access to all the DisplayBuffers and can decide which one at makeCurrent() time? Yeah, that could work.
<greyback> alf__: right
<alf__> greyback: Do you have that code somewhere? I want to take a look to find the best point to integrate the request for context properties (depth, stencil etc).
<greyback> alf__: lp:~unity-team/+junk/qpa-mirserver/  and the code you want is in src/platforms/mirserver
<alf__> greyback: great, thanks!
<greyback> alf__: if you want to build to test, you need the unity-api branch mentioned in https://docs.google.com/a/canonical.com/document/d/1IiHBDIW_e0qnGt-po1D2z5HJKrNhBwh6pdILeEN2sgA/edit?usp=sharing
<alf__> greyback: do you know if this works on the desktop?
<greyback> alf__: it did with Qt5.0, I've not tested with 5.2. Gimme 10 mins & I'll check
 * greyback has a secondary computer at hand now, won't be cursing Mir locking his VT so much any more :)
<alf__> greyback: btw, one thing I forgot to mention yesterday, is that between a Compositor::stop() and the next Compositor::start() the DisplayBuffers may have been invalidated, so we need to take this into account when stoping/restarting the Qt renderers.
<greyback> alf__: makes sense. I've not considered that at all yet
<alf__> greyback: (i.e. you can't assume any DisplayBuffer references will be valid, because of display reconfiguration changes)
<alf__> greyback: ok
<greyback> alf__: what I was hoping to test was, when Compositor::stop() called, I send a "hidden" event to all QWindows, which will block the next rendering pass. However am worried that's already too late
<greyback> alf__: how does that work in Mir? Could a DisplayBuffer be invalidated /while/ the renderer is working?
<alf__> greyback: No, when we get a display config changed event, we first stop() the compositor and then proceed with dealing with reconfiguration.
<kgunn> alf__: greyback ...i read your discussion about about matching the DB & QWindow gl context...one wonder on my part wrt multimonitor...how would that work if you wanted your QWindow to span 2 moniters? would scene just help track & toggle that QWindows glcontext mapping ?
<greyback> kgunn: not possible with Qt, it relies on 1 GL context per window
<alf__> kgunn: it's one qwindow per output, like we have one DisplayBuffer per output
<alf__> kgunn: greyback: but multiple qwindows can render parts of the same scenegraph, right? Or would we have separate SGs?
<greyback> alf__: I think both options are available to us
<kgunn> ah so there'd be a way around
<greyback> yeah, visually I think it possible to have a spanned desktop with the 2 windows
<kgunn> and greyback do i understand it right that QWindow is effectively a Qt app window surface ( not == screen)
<greyback> is something I need to prototype
<greyback> kgunn: right, usually QWindow is just that, a window. However I'm tricking it that a window corresponds to a Mir DisplayBuffer
<alf__> greyback: @extended desktop, it should be fine (and perhaps transparent), since we deal in virtual coordinates. We only need to say that this windows displays the scenegraph viewport x,y@w,h
<alf__> greyback: (hopefully qt can do that :))
<greyback> alf__: honestly I'm not sure it does. If there's 1 scenegraph tree for a root window, you can tag a subtree to be the SG for a child window, but then that subtree ignored by the root window's renderer
<kgunn> ack the QWindow foolery to DB
<greyback> alf__: spreading 1 scene over 2+ windows is not really an application use-case
<greyback> alf__: I need to see if working around it is easy, else can change the scenegraph renderer (which will be done anyway for HWC support)
<greyback> hmm, just had flashback to the unity2d days, when were were essentially doing this very thing
<alf__> greyback: hmm, some SG elements may need to be used multiple times (e.g. a surface between monitors). It would be ideal to have a single SG and just render with different clip borders for different outputs.
<greyback> alf__: yep
<greyback> most definitely
<alf__> greyback: I spy QSGClipNode which seems relevant
<greyback> alf__: that clips its subtree
<greyback> why need to clip the border?
<greyback> if you render outside the viewport of the current gl context, that doesn't appear on another display, does it?
<alf__> greyback: no
<alf__> greyback: gl does primitive clipping, but it would be even better to not process irrelevant nodes (= unnecessary GL vertices) at all, so that's clipping at the SG level. But I guess we can worry about this later.
<greyback> alf__: it's something I need to check up on, but I suspect Qt's renderer doesn't do any such checking
<greyback> which means for 1 SG with N multiple monitors, lots of gl calls are doing stuff off screen N-1 times
<anpok> I thought qt has a copy step that transfers the qml model into a scene graph to be consumed by the renderer thread for each(?) frame.
<greyback> anpok: it does
<anpok> I mean in that case there would be one qml scene, and two renderer scenes..
<anpok> or n renderer scenes..
<anpok> I wanted to say that we might be able to limit the scene at that copy step
<greyback> possible
<alf__> anpok: greyback: copying the qml model to scene graph for each frame sounds expensive :/ Is there some caching (or other optimization) going on?
<greyback> but that copy step is very much 1 qml scene -> 1 scenegraph afaik
<greyback> alf__: yes, it doesn't copy each time, it updates only the dirty nodes for each frame
<anpok> ah so I understood you correctly you were discussing qml scene -> scenegraph -> n renderers on the same screengraph but with clip nodes
<greyback> anpok: right, that's one option
<anpok> alf__: the issues they tried to solve was the js model taking too much time to settle and having too large variance in the settle time to have steady frame rate..
<anpok> I think they thought about providing some concept of "global properties" that could change more frequently than the js model to do those animations that shall be updated every frame
<greyback> anpok: alf__ Qt apps have a rendering thread, and a GUI thread. The QML engine (including the JS engine) live in the GUI thread. QML animations with *Animation{} are controlled by the GUI thread, as QML wants to know the progress of that animation. This isn't ideal as the GUI thread might block the rendering thread during animations. But Qt5.2 introduced *Animator{} which runs animations on the render thread
<greyback> with the sacrifice that QML doesn't know the progress of that animation
<greyback> so it's a fire and forget kind of animation
<greyback> we're not using it anywhere yet, and will be interesting to see what improvement it makes, if any.
<greyback> another place where GUI thread can block the rendering thread is if there's intensive javascript running, and that's generally bad coding
<anpok> hm but it would only block updates there... not really block
<kgunn> greyback: so for anything with input sync i'd think you'd want "Animation" GUI...and where you don't care about input, that'd be "Animator"
<kgunn> ?
<greyback> kgunn: right
<greyback> anpok: if updates block, then the SG tree is not considered dirty, so the renderer does not do a pass for that frame
<kgunn> SG not considered dirty for that app...right?...could be others not blocked
<greyback> yes, just that app
<mterry> Can I get a Mir expert's eyes on https://code.launchpad.net/~mterry/unity-system-compositor/switch-after-buffers/+merge/211776 ?  I think I do some sketchy stuff
<alf__> greyback: looking at miropenglcontext.cpp ... are we sure we don't need the EGL display an config? The m_format variable is set using these.
<greyback> alf__: yeah, you're right, it's needed. And that's not possible to get from the current context with egl* methods?
<alf__> greyback: it's possible if there is a current egl context, but I don't think there is at that point in the constructor.
<greyback> alf__: fair point
<alf__> greyback: However, we could get an EGL context from the mg::Display and make that current temporarily to get all the info.
<alf__> greyback: mg::Display::create_gl_context()
<greyback> alf__: I'm in your hands here, whatever you think best.
<greyback> I don't see why that wouldn't work anyway
<alf__> greyback: yeah, let's start with that and see how it goes
<alf__> :)
<greyback> alf__: ok
<kdub> alan_g, I'm considering making a std::list of renderables from the scene to unblock some of the DefaultDisplayCompositor/hwc stuff
<kdub> and I'm debating whether to add a method to mc::Scene, or to use the filters/operators to generate the list and leave mc::Scene alone
<kdub> I sort of prefer the 2nd approach, but was wondering what you thought before embarking on that
<alan_g> kdub: My preference is to pass the selection criteria to scene and for it to pass the collection to a supplied object.
<alan_g> And rework the "lock the world" stuff into that.
<kdub> so pass a collection of filters in, and then have the scene generate a the list based on that... so the second approach more or less
<alan_g> "second approach" from "vision" doc. Yes
<kdub> and also, I plan on it being a snapshot of the scene, eg, having a mg::Renderable(ms::BasicSurface const&) constructor
<alan_g> after talking to gerry I think it will work better than "option 1"
<alan_g> Slicing the BasicSurface? Why?
<alan_g> I was thinking along the lines of std::copy_if(surfaces.begin(), surfaces.end(), selector, back_insert_iterator(renderables))
<kdub> looking through code, that could work too
<kdub> I guess my main point here is that it would be a snapshot by copying rather than a reference into the surfaces like it is now
<alan_g> Basically we need to lock the "scene" during the copy, but the renderables(surfaces) can be accessed concurrently
<alan_g> Can't we just copy the shared_ptrs?
<kdub> I guess I just like locking, copying, and not worrying about the changes to the scene that happen between the copy and the render
<kdub> although, it might be simpler to just give the reference, even if that means some surfaces have that extra sliver of time to update their information whereas other surfaces would be accessed sooner and would have to wait til the next frame
<alan_g> Yes, I'm just questioning how deep the copy has to be.
<kdub> well, I guess I'll see in when I go to do the work... the first pass though will at least minimize how long the vector that holds all the surfaces is locked
<Saviq> hey guys, is there an ABI break between trunk and devel atm?
<alan_g> the buffer swapper can be shared. What else do you use?
<alan_g> Saviq: I have to check. ..
<Saviq> alan_g, not if it takes more than a minute or two, we'll know soon enough
<alan_g> Saviq: I don't see anything that's a definite "yes"
<Saviq> alan_g, ok, good enough
<Saviq> kgunn, â
<mterry> kgunn, also https://code.launchpad.net/~mterry/unity-system-compositor/switch-after-buffers/+merge/211776 will likely need a careful Mir eye.  I think I do some sketchy stuff in it.  If you know someone that has spare cycles
<kgunn> mterry: ack...i see its a nice small code change :)
<mterry> kgunn, of course :)
<kdub> I've seen two failures on TestClientInput in CI lately (with branches far away from input), has anyone else seen this?
<kdub> looks like a racy leak maybe
<alan_g> kdub: I've not noticed it - but that doesn't mean it doesn't happen
<kdub> there's a bug tracking it now if anyone else sees the same thing
<kdub> https://bugs.launchpad.net/mir/+bug/1295231
<ubot5> Ubuntu bug 1295231 in Mir "TestClientInput memory leak in CI" [Medium,New]
<alan_g> Tried reproducing locally? (Sometimes needs use_debflags, valgrind and patience)
<kgunn> mterry: definitely a few breaks on that branch...sorry, getting hit from multiple sides, got really distracted...as i said, i'll gen up the mp's add them to that silo/reconfig and we'll build...
<Saviq> hey folks, can't cross-build Mir in a trusty chroot: bug #1295364
<ubot5> bug 1295364 in Mir "Mir fails to cross-build a deb package" [Undecided,New] https://launchpad.net/bugs/1295364
<kdub> Saviq, confirmed that bug, I've seen that too
<Saviq> kdub, thanks
#ubuntu-mir 2014-03-21
 * RAOF would like gmock to hurry up and make NiceMock the default.
<duflu_> RAOF: That would be troublesome for finding things you missed
 * duflu_ -> lunch
<RAOF> duflu_: You can always explicitly make them naggy mocks if you want.
<RAOF> duflu_: Another question is: what sort of things you missed?
<duflu> RAOF: Naggy can be useful, yes :)
<Saviq> hey guys, do these test failures from devel mean anything to you https://launchpadlibrarian.net/170204996/buildlog_ubuntu-trusty-armhf.mir_0.1.8%2B14.04.20140321-0ubuntu1_FAILEDTOBUILD.txt.gz ?
<alan_g> Saviq: it is only a guess - but is that an attempt to run the tests on a machine with no graphics hardware?
<Saviq> alan_g, definitely, it's a launchpad builder
<Saviq> alan_g, if those tests require graphics, they shouldn't be included in make check
<Saviq> alan_g, OTOH it completed for i386 and amd64
<Saviq> alan_g, it's basically a PPA build of lp:mir/devel
<alan_g> alf__: ^^ you were looking into which tests ran where recently?
<Saviq> alan_g, alf__ ugh, so we lost that log right now, since the build was rekicked
<Saviq> let's see if it's consistent, then, will report back in some 37 minutes
<alan_g> Saviq: ack
<alan_g> alf__: FWLW there was a lot of "C++ exception with description "Could not open hardware module" thrown in the test body."
<alf__> alan_g: hmm, that sounds like android hw, but didn't kgunn disable them for package building? Let me see..
<alf__> alan_g: them = integration and acceptance tests
<alan_g> alf__: "them" is what failed
<alan_g> I thought so too
<alf__> alan_g: ah, they were disabled only in trunk not devel
<alan_g> Saviq: ^
<alf__> alan_g: don't we sync back from trunk to devel after release?
<Saviq> oh, explanations, /me likes :)
<alf__> alan_g: well, it's clear we didn't in this case, but aren't we supposed to do so?
<alan_g> alf__: we do. But this time there were some "trivial conflicts" maybe it got lost
<alf__> alan_g: Saviq: ok, let me sync again
<Saviq> alf__, looks like "nothing to do"
<Saviq> alf__, but indeed that change is not there
<alf__> Saviq: ok, I will propose an MP with the fix
<Saviq> alf__, great, thanks
<Saviq> alf__, please let me know when you get the MP, I'd like to put it in a silo
<alf__> Saviq: ok
<duflu> Whee, circular make_shared dependencies eat all the memories
<alan_g> duflu: stick to a DAG
<duflu> alan_g: I know but I didn't see the cycle coming
<alan_g> I guessed that ;)
<alan_g> I presume no-one else is looking into https://bugs.launchpad.net/mir/+bug/1295231?
<ubot5> Ubuntu bug 1295231 in Mir "TestClientInput memory leak in CI" [Medium,Confirmed]
<alf__> RAOF: do we require libumockdev >= 0.6? Trunk says no, devel says yes, but the change in devel predates last sync of devel => trunk
<duflu> alf__: I think that just landed for 0.1.8. It's documented in the upcoming changelog ;)
<duflu> Oh, that part's not documented
<alf__> duflu: you are right, it's post 0.1.7
<alf__> Saviq: https://code.launchpad.net/~afrantzis/mir/no-display-hw-tests-on-armhf-package-builds/+merge/212122
<Saviq> alf__, thanks!
 * alan_g looks at TestClientInput and feels a strong urge to delete and rewrite
<alan_g> alf__: happy for me to top-approve https://code.launchpad.net/~alan-griffiths/mir/once-Surface-interface-to-rule-them-all/+merge/212012?
<alf__> alan_g: hmm, I thought I had review that (or something similarly named :))
<alf__> alan_g: looking
<alf__> alan_g: @//resolve ambiguous member function names, what's ambiguous about them?
<alan_g> They exist in multiple base classes
<alan_g> (Which makes code calling them ambiguous)
<alf__> alan_g: but they are pure virtual in all of them, so shouldn't this just work?
<alan_g> I know what you mean, but no
 * alan_g tries to come up with code where it matters which name is resolved...
<alan_g> auto eg1 = &Surface::name; // eg1 is Base1::*()
<alan_g> auto eg2 = &Surface::name; // eg2 is Base2::*()
<alan_g> eg1 & eg2 have different types
<alan_g> Even though they call the same member function
<alan_g> There's no rule in the standard to disambiguate Base1::name and Base2::name
<anpok_> hm a using of either Base1::name or Base2::name?
<alan_g> that would work too
<alf__> alan_g: I don't get what the first two line you pasted show
<alan_g> The two alternative resolutions of Surface::name
<alan_g> It isn't real code - as both lines are ambiguous
<alf__> alan_g: ok, got it, thanks
<anpok_> mterry: hi
<anpok_> I was reviewing and now testing the u-s-c branch..
<anpok_> one question came up .. in which cases should the spinner show up?
<mterry> anpok_, hi
<mterry> anpok_, well, where you testing with other split branches or just the usc branch?
<anpok_> oh - only usc - and I only see it on startup .. i need a unity8 branch too?
<mterry> anpok_, so the branch is OK in isolation.  But you won't see all the scenarios unless you also install some other branches...  Let me give you links, and I can explain when you'll see others
<mterry> anpok_, https://code.launchpad.net/~mterry/unity8/split/+merge/210664 and https://code.launchpad.net/~mterry/ubuntu-touch-session/split/+merge/211549
<mterry> anpok_, the times you'll see it are 3-fold:
<mterry> anpok_, boot, waiting for greeter to come up; boot, after greeter comes up but if the session behind the greeter is slow to appear and you swipe greeter away very fast, you'll see spinner until user session finishes appearing; and when you lock device, if you turn it back on very quickly before greeter has had a chance to finish appearing, you'll see it
<mterry> anpok_, that second instance Design actually wants me to get rid of -- I'll make a small adjustment to that branch so that the greeter doesn't appear until the user session is also ready
<mterry> racarr_, hello!
<mterry> racarr_, we've got a testing PPA for the split greeter stuff going (which includes your remove-ensure-display-powered merge)
<mterry> racarr_, but I'm still seeing the screen turn on after locking
<mterry> racarr_, I was wondering if you had time to re-investigate that.  Might be easier now that there is a PPA with all the code for easier testing
<mterry> racarr_, https://launchpad.net/~ci-train-ppa-service/+archive/landing-004
<racarr_> mterry: Ok I will investigate
 * mterry buys a beer for racarr_, keeps it cold in fridge for ya
<mterry> tsk..  this beer will go bad before I see you next
 * mterry opens beer
<dansuf> Hi, I am porting ubuntu touch to my phone and I've got graphics-related issues. Here's a log generated by logcat when running lightdm: http://pastebin.com/ag6iSVkW . Also, in dmesg I've got "mdp4_overlay_play: pmem Error" and in unity-system-compositor.log: "terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
<dansuf>   what():  error during hwc set()
<dansuf> "
<dansuf> Any ideas what could be the cause of these errors?
<racarr_> mterry: Cheers lol
<racarr_> dansuf: Hmm I mean abstractly it looks like some of the hardware compositor usage through the android HAL...isnt working
<racarr_> the different devices have different quirks. kdub or AlbertA would know more.
<kdub> dansuf, yeah, something is going wrong with hwc and the drivers
<racarr_> We used to have a fallback mode...presumably still do, that might work for you
<racarr_> dansuf: in mir/src/platorm/graphics/android/output_buider.cpp I think you could force_backup_display(true) in the constructor
<dansuf> so it may be something connected to device files
<dansuf> racarr_, I will have to build mir?
<kdub> fallback is discontinued in most up to date qcom drivers
<kdub> which device?
<racarr_> Oh. :( maybe we dont have a fallback
<dansuf> aa far as i know its legacy version if this does change anything
<dansuf> i mean legacy qcom
<dansuf> i don't have big knowledge about all this stuff
<dansuf> it's sony ericson live with walkman, codename coconut
<AlbertA> it does look like dev permissions from the log
<AlbertA> or maybe your kernel driver does not instantiate those devices
<dansuf_> i applied udev permissions from android files
<kdub> yeah, maybe run as root and see if that helps
<dansuf_> i run it in root shell
<kdub> also, those drivers have a hwc.mdpcomp.enable (or similar), maybe try turning that off
<dansuf_> kdub, I set that to false in build.prop, it still fails but the logcat is slightly extended http://pastebin.com/Au3Paj1x
<kdub> i'd still guess there's some permissions or chroot mix up somewhere
<kdub> do the hybris test programs work?
<dansuf_> kdub, I didn't run them
<dansuf_> Where can I find them?
<kdub> /usr/bin/test_glesv2 from libhybris-test
<dansuf_> kdub, wow, it works
<dansuf_> I mean, the tests
<kdub> dansuf, good sign
<dansuf_> Although, egl seems to crash
<dansuf_> I'll try maybe to build mir with fallback
<dansuf_> So, I tried to build mir for ubuntu touch and It just throws error with no reason "[  7%] Built target android-input
<dansuf_> make: *** [all] Error 2
<dansuf_> "
<bregma> racarr_, just so you know, I pushed your u-s-c and the lightdm tweaks to https://launchpad.net/~unity8-desktop-session-team/+archive/custom and installed them, I now have a working mouse and trackpad in the Unity8 desktop session
<bregma> just. like. that.
<bregma> I look forward to those hittong the archive soon for winder consumption
<bregma> *wider
#ubuntu-mir 2014-03-23
<netlar> join #ubuntu
#ubuntu-mir 2015-03-17
<mterry> Hello!  Is http://unity.ubuntu.com/mir/setup_kvm_for_mir.html current?  I'm running a kvm with SPICE and QXL drivers and I don't have /dev/dri/
<mterry> Is there more setup to do, in order to run Mir inside kvm?
<kdub> mterry, as far as I know, it is current, alf_ would know  for sure though
<mterry> kdub, do you know if the kernel junk is obsolete though?  It mentions that 3.18 might be enough.  I'm testing with a 15.04 kernel
<mterry> Which is 3.19 these days
<kdub> mterry, i'm not sure
 * mterry looks hopefully at alf_
<mterry> What about running snappy on a real device?  I see the recommendation for a beaglebone.  But like, can I load it on my krillin?
<mterry> whoops, wrong channel
<anpok_> mterry: yes 3.19 is enough
<anpok_> mterry: do you see qxl in kernel messages?
<anpok_> havent upgraded my kvm vm for some time
<mterry> anpok_, let me check
<mterry> anpok_, "dmesg | grep -i qxl" gives nothing
<mterry> anpok_, but virt-manager suggests I am using it.  :-/
#ubuntu-mir 2015-03-18
<alan_g> alf_: wouldn't you rather switch USC to C++14 than keep writing "std::chrono::milliseconds"? ;)
<alf_> alan_g: yes, it's the plan, but I didn't want to introduce changes to too many aspects of USC. Although I guess that's just a simple switch, so I could enable this now if you would like.
<alan_g> I'm not insisting. Just wondering.
<alf_> alan_g: thanks for the review, @safe name, do you mean the "com.TestService" or the variable names?
<alan_g> the service name
<dandrader> What's the expected date for Mir 0.13 release?
<alf_> dandrader: No expected date at the moment. We are discussing whether we should release 0.13 or a 0.12.1 bugfix release. Do you need a feature that is going to be in 0.13?
<alf_> dandrader: (The discussion about 0.13 vs 0.12.1 is because of the freeze)
<dandrader> alf_, yes. this: https://bugs.launchpad.net/mir/+bug/1430315
<ubot5> Ubuntu bug 1430315 in mir (Ubuntu) "DisplayConfigurationOutput.physical_size_mm is undefined/zero" [Medium,Triaged]
<dandrader> alf_, sounds trivial enough for backporting to a bug-fix release?
<alf_> dandrader: possibly, I don't know if it depends on some new internal android backend feature
<alf_> kdub: ^^ could we conceivably backport the fix to 0.12 if needed?
<kdub> it could just be a new release of the android platform plugin
<kdub> but it could also ride along with a 12.1 release easily enough too
<dandrader> kdub, should there be a trello card, a bug tag or something else for this backporting to happen, so we don't forget about it?
<kdub> camako, what would be the best way to remember for the next release? ^^
<alan_g> AlbertA: you're saying NewCallback can't take a lambda? (At least one that doesn't decay to a function pointer.)
<AlbertA> alan_g: can it?  but even if it can it has the issue where it won't be deleted if the callback throws
<alan_g> Exception safety is not why  you wrote it.
<AlbertA> alan_g: sure but it doesn't matter at this point. They are not exception safe
<alan_g> ack
<AlbertA> In any case, when I looked at their definition they just seemed to take function pointers. I didn't see how I would wedge a lambda but maybe you can.
<alan_g> AlbertA: no, you can't unless the lambda decays. Let's write our own test framework...
<AlbertA> alan_g: right it can't decay since it captures
<AlbertA> alan_g: do you mean RPC framework ? :)
 * alan_g was confused
#ubuntu-mir 2015-03-19
<funkring> Good Morning!  I have some question about remote access and mir, could anyone help me?
<funkring> How remote desktop access via rdp, vnc,.. work with MIR?
<duflu> Wow. EGL is so weakly typed you can mistake EGLSurface for EGLDisplay
<duflu> And everything compiles, runs, just behaves not as expected
<mterry> If I just want to add some std::cerr prints to Mir for debugging purposes, is that going to print correctly (like, does Mir filter streams at all by default?)
#ubuntu-mir 2016-03-21
<k1l> !mir
<ubot5> Mir is the next-generation display server currently under development by Canonical and Ubuntu. It's slated for inclusion in Ubuntu 14.04. For more information on it, see https://wiki.ubuntu.com/Mir/Spec . For code, see https://launchpad.net/mir
<ogra_> heh
<k1l> is there an idea to update this bot factoid to be used in #ubuntu and other core channels?
<ogra_> well, the "slated for inclusion" shoudl definitely be re-worded
<ogra_> (and it should mention that it is used as default on the phones)
<k1l> yeah, if you have an idea give it a go :)  but we only have limited space on the irc protocol, so the whole mir history wont fit ;p
<ogra_> well, thats more a kgunn team job i think
 * alan_g wonder where the bot gets its "facts"
<k1l> most are manually set.
 * alan_g wonder where
<k1l> by the irc team
<k1l> the mir factoid is from 2008 and was last updated 2013
<ogra_> geez ... 6 years
 * alan_g wonders
<k1l> *3
<ogra_> k1l, 3 ?
<k1l> it was changed/updated 2013.  so 3 years :)
<ogra_> created 6 years ago
<ogra_> :)
<k1l> 2008 is 8years ago :)
<ogra_> god ... i should stop working :P
<ogra_> indeed 8
<alan_g> Missed retirement?
<ogra_> lol, kind of
<k1l> ogra_: is still living in the good old 2014 days :)
<alan_g> Age does that to memory
<alan_g> ;)
<alan_g> So, if we come up with a better fact how do we change it?
<k1l> propose it in #ubuntu-irc
<kgunn> ogra_: indeed...been on my todo list, cause alan_g|EOD alreay pointed it out like 3 weeks ago
<alan_g|EOD> kdub: I didn't point out the bot factiod (I dodn't know about it then). But it is part of the same public info problem
 * kdub thinks that msg was for kgunn ?
<kgunn> i'm sure kdub  :)
#ubuntu-mir 2016-03-22
<duflu> anpok: Does libinput have any special support for smooth two finger scrolling or is it just button 4/5 emulation?
<anpok> duflu: yes it has two finger scrolling support
<duflu> anpok: Does it have /good/ scrolling support (not emulating a wheel) ? :)
<anpok> duflu: it offers two information.. the emulated number of ticks.. and a finer grained (and hopefully properly scaled) movement vector
<duflu> anpok: So something like a normalized float vector relative to the touchpad dimensions?
<anpok> remember.. when we introduced libinput I default to the second ccase
<anpok> but that turned out to be problematic with downstreams..
<anpok> so we need to expose that via a real axis in mir client
<duflu> Heh. Compatibility or good software. Choose one
<anpok> then we could use it gtk and qt..
<duflu> anpok: My feeling is that the nice implementations of the world roughly map the touchpad height to scrolling the height of the screen. So if we could move in that direction with more precision I think it would be nice
<anpok> oh..
<duflu> You could abstract that using a float (or fixed point) motion vector
<anpok> duflu: libinput does have device specific scaling of the measured scroll gestures
<duflu> Hmm, methinks we need a nice demo client to play with it
#ubuntu-mir 2016-03-23
<alan_g> alf_: if a test core dumps is the core preserved somewhere we can get at it?
<alf_> alan_g: Which run is this for?
<alan_g> alf_: the most recent is https://mir-jenkins.ubuntu.com/job/device-runtests-mir/device_type=krillin/240/consoleFull
<alf_> alan_g: we are pulling the crash files from the device, but we are not archiving them. We would need to change the device-runtests-mir job to archive 'results/**' or similar
<alf_> alan_g: (archiving is a 'post-build' action)
<alan_g> alf_: not urgent but might be a useful addition to the backlog.
<alf_> alan_g: let me add quickly and you can retrigger a device-runtests-mir job
<alan_g> I've found two intermittent failure modes in the smoke tests to investigate. That's the more common one, but I'll try to reproduce locally.
<alf_> alan_g: I have added a post build action to archive results (including the crash files) our test runner scripts pull from the phone. Let me know if it gets the files you need..
<alan_g> Where will I find them?
<alf_> alan_g: you will need to trigger a new device-runtests-mir run, the results will be archived as artifacts accesible through the build page (https://mir-jenkins.ubuntu.com/job/device-runtests-mir/NNN/device_type=krillin/)
<alf_> accessible
<alan_g> thanks. (I guess it is good that the smoke tests are detecting smoke.)
#ubuntu-mir 2017-03-20
<anpok> alan_g: one final question on the dnd MP - so a client identifies a drop event by makeing a != nulptr test on the dnd handle of a pointer button up event?
<anpok> nm - there is a test for just that
<alan_g> anpok: yes
<alan_g> kdub: is mcl::ErrorChain obsolete - I don't see it being used.
<kdub> eh, guess we have check that mir_presentation_chain_get_error_msg is working
<kdub> could have been overlooked when MirRenderSurface error handling was introduced I suppose
<alan_g> Thanks. (I can delete it without screwing up WIP.)
<dandrader> anpok, around?
<anpok> yes
<dandrader> anpok, http://pastebin.ubuntu.com/24214922/
<dandrader> anpok, can this input validator alter keyboard modifiers?
<dandrader> anpok, eg: add a Ctrl keyboard modifier to a event that originally had none?
<anpok> well it did not..
<anpok> we changed that bit in lp:mir
<anpok> iirc it would only copy the input event modifiers..
<greyback> alan_g: hey, qtmir ftbfs against miral 1.3.1: miral/set_command_line_hander.h: No such file or directory
<alan_g> greyback: Sorry, a spelling correction: miral/set_command_line_handler.h
<greyback> alan_g: yep I know. Just thought you should know, in case you'd consider it an api break
<alan_g> greyback: thanks. But as the ABI is unbroken (which I care about more), I'm not too worried.
<greyback> ok
<dandrader> anpok, I don't get it. can the input validator in the currently released mir add keyboard modifiers to the kdb input event passed to Surface::consume()?
<anpok> dandrader: in 0.26 it only affected touch events
<anpok> and usually I hope it never did anything at all
<dandrader> anpok, I'm puzzled. I'm investigating a bug and currently it seems like qtmir is sending a keyboard event in surface->consume() without modifiers but it's arriving with a modifer on the client side (qtubuntu)
<anpok> hm
<dandrader> anpok, would that be possible?
<anpok> with unity8 every client gets a keymap ..
<anpok> that enables client side keystate tracking
<dandrader> anpok, hmm, so you mean mir client lib could be adding that?
<anpok> so if the client has seen a ctrl key down..
<anpok> and never seen a ctrl key up..  xkb common will assume that it is stil down
<greyback> alan_g: you missed fixing the typo in set_window_managment_policy.h
<alan_g> greyback: are you sure?
<alan_g> Rats! you're right
<anpok> dandrader: that key state is reset on focus change .. and if you need to filter out events... we could try to add a machinery to trigger the input device state events which would sync clients and the server again
<dandrader> anpok, I don't need to filter out events. I need to fix a bug where a client is creating and focusing a new child surface in response to a ctrl+O. once that child surface closes, the top-level surface is stuck with a ctrl modifier until ctrl is pressed+released again
<anpok> this is odd
<anpok> is there no focus change involved?
<anpok> oh hold on the new child is focused and gets focused again?
<dandrader> anpok, there are many bugs involved in that use case. in miral (just fixed), in qtmir and unity8.
<dandrader> anpok, and now I'm thinking there must be some issue in mir as well. miral just released its fix. will try with that
<dandrader> anpok, the new child surface does get focused
<dandrader> anpok, once that child window is closed and focuse is assigned back to the top-level surface. it gets a sticky ctrl modifier
<dandrader> anpok, even though, afaict, qtmir is sending key events without any modifiers.
<dandrader> anpok, will proceed my investigations further and if I can't pinpoint another bug elsewhere will add mir to the bug report
<anpok> ok..
<anpok> dandrader: MIR_CLIENT_INPUT_RECEIVER_REPORT=log would be helpful
#ubuntu-mir 2017-03-21
<duflu> RAOF: Packaging Mesa doesn't work if we don't build it :)   https://code.launchpad.net/~raof/mir/fix-android-only-build/+merge/320448
<RAOF> Right, was just looking at that.
<duflu> RAOF: I would lean toward deprecating V+O as a platform for CI instead
<RAOF> It would be the work of a moment to turn off V+O.
<RAOF> Other option would be to upload a newer mesa to the overlay.
<duflu> RAOF: Instead my one-line workaround (almost landable) would enable arm* on zesty
<duflu> Bonus points for abolishing overlay from CI
<RAOF> We don't have a device hooked up to do the android tests?
<duflu> RAOF: Oh
<duflu> Crap
<RAOF> Probably still useful to build on xenial+overlay, as that's the ~Ubuntu Core target.
<duflu> Well V+O for arm* builds fine if your build host is xenial
<duflu> Because that was the last protobuf 2.x platform
<duflu> Or we could fix the cross compile script/methodology to solve that
<RAOF> â¦until we land hybrid support, which requires a newer mesa than vivid+overlay :)
<duflu> Yay
<duflu> Indeed supporting vivid will become more difficult over time
<RAOF> On the plus side, we don't appear to actually be testing on a device at the moment anyway :)
<duflu> "they"?
<duflu> "we"?
<duflu> I'm blocked by a krillin failure. That's a pretty real device
<RAOF> There does not appear to be a CI target that deploys to a device and runs the tests anymore?
<RAOF> Ah, no, it's just not a top-level target.
<RAOF> OK. Turned building mesa-kms and mesa-x11 on for V
<RAOF> V+O again.
<RAOF> I can build mesa-kms for V+O; it just won't work. :)
<RAOF> 04:42:38 java.lang.OutOfMemoryError: PermGen space
<RAOF> Aaaaaaargh.
<alan_g> greyback: since you pointed out the corresponding typo... https://code.launchpad.net/~alan-griffiths/qtmir/future-proof/+merge/320466
<greyback> alan_g: ack, thanks for that
<greyback> alan_g: will we be seeing a 1.3.2?
<alan_g> I hope there are no bugs that will justify it. ;)
<alan_g> But there will be DnD & other features eventually.
#ubuntu-mir 2017-03-22
<dandrader> anpok, mir input event timestamps: does mir generates them from scratch or do they come from a lower layer?
<bschaefer> dandrader, in platforms/evdev/libinput_devices.cpp
<bschaefer> (say for keyboard: libinput_event_keyboard_get_time_usec)
<bschaefer> soo it seems like it comes from libinput based on the event being translated
<dandrader> bschaefer, ok, thanks. and yeah, I'm interested in kbd timestamps more specifically
<bschaefer> should be this function: mir::EventUPtr mie::LibInputDevice::convert_event(libinput_event_keyboard* keyboard)
<bschaefer> which sound propagate through all the nested bits into qtmir
<dandrader> bschaefer, so to synthesize a mir event I guess I will have to add elapsed time to some known event timestamp
<bschaefer> hmm yeah, umm let me check what evdev does
<bschaefer> as we use timestamps to check which event was last (for surface raise... and something else now)
<bschaefer> looks like it uses a timerfd_create(CLOCK_MONOTONIC, TFD_CLOEXEC | TFD_NONBLOCK);
<bschaefer> (though not sure how much help that is when its past mir :)
#ubuntu-mir 2017-03-23
<duflu> alan_g, how do I stop fatal exceptions from reporting themselves and get a stack trace?
<duflu> Oh, maybe I don't need to. Can guess what's crashing
<alan_g> IIRC mir::fatal_error = mir::fatal_error_abort
<duflu> alan_g: I mean on the command line :)
<duflu> It's an exception, not a fatal error. But Mir is trying to do its own error report (!)
<alan_g> I thought abort was the default
<alan_g> mapreri: re bug 1675138 - the 0.26.2 release is in silo 2600 awaiting QA. I know camako has spent time getting it this far - do we need to set him back? Or can the packaging changes be made directly?
<ubot5> bug 1675138 in mir (Ubuntu) "Please transition to Boost 1.62" [High,Triaged] https://launchpad.net/bugs/1675138
<mapreri> alan_g: what do you mean by "directly"?
<mapreri> (I didn't even remember I was on this channel!)
<alan_g> Without resetting the process in bileto
<mapreri> if you are fine with people uploading the package directly to the archive we can work it out, i.e. I upload a -2 as soon at 0.26.2-1 is uploaded, but then your next upload done through whatever CI should contain it.
<alan_g> mapreri: that would work for me
<mapreri> I have no idea how bileto (or whatever kind of CI/landing system) you are using work
<mapreri> oh, great
<mapreri> so, what would be the timing for 0.26.2 to land? :)
<alan_g> mapreri: out of my hands, first QA need to approve and then someone needs to push to archive. But I'd guess the next day or two.
<mapreri> that works just fine
<mapreri> I'll arrange the -2 upload, will you please merge it in 0.26.3 in the meantime?
<alan_g> AFAIK 0.26.3 doesn't exist (and likely won't). But I'll take care of it in that contingency.
<mapreri> ack
<greyback> anpok: hey, we're experiencing bug 1675357 where unity8 is getting continual key repeat events after you VT switch away. You were looking into key repeat bugs just like this, probably related?
<ubot5> bug 1675357 in Canonical System Image "Mir sending key repeat events continually to nested shell after VT switch (causes Unity8 lockup for a while)" [High,Triaged] https://launchpad.net/bugs/1675357
<anpok> greyback: yes ... mir fixes for that are in flight..
<anpok> greyback: but there is already a fix in qtmir that should evade that problem: https://code.launchpad.net/~andreas-pokorny/qtmir/store-and-recover-cookie-and-input-device-id/+merge/318528
<anpok> greyback: oh hold on.. thats a separate issue
<camako> tjaalton, which branch of pkg-xorg/lib/vulkan.git do I use?
<camako> debian-unstable?
<camako> I don't see an 'ubuntu' branch
<tjaalton> camako: because it's synced
<camako> I need to make updates to make Mir useable in the loader
<tjaalton> will you send them upstream?
<camako> tjaalton, yes, but not right away
<tjaalton> then just fork d-u
<camako> tjaalton, so we don't distro-patch this, do we?
<tjaalton> you will :)
<camako> :-)
<camako> thanks
#ubuntu-mir 2017-03-26
<flohack> Hi there
<flohack> Im failing when running AndroidMirDiagnostics.client_can_draw_with_cpu
<flohack> I get /build/mir-coQbl3/mir-0.24.1+15.04.20160928/src/platforms/android/utils/test_android_hardware_sanity.cpp:130: Failure
<flohack> Will the EGL modelist help? => http://pastebin.com/HTqPVVi7
