#ubuntu-mir 2014-01-20
<anpok> whats the simplest way to get an armhf mir build from a branch and unity8 and all ABI dependent libraries built against that mir version
<mlankhorst> ppa
<racarr> Moooorning
<tvoss> racarr, good morning :)
<racarr> Are we standing up?
<mlankhorst> no idea ;P
<mlankhorst> got anything for me to sort out in mesa?
<mlankhorst> or any mesa bugs
<ogra_> should we invent some so you dont run out of practice ?
<mlankhorst> naw
<anpok> do we need orientation support in that form?
#ubuntu-mir 2014-01-21
<duflu> This is odd. Why is Xorg slower on Haswell than Sandybridge?!
<duflu> Mir has no such problems
<RAOF> duflu: What test?
<RAOF> duflu: Also, fast Sandybridge vs slow Haswell?
<duflu> RAOF: I swapped my drive out of an HD2000 system into an HD4400
<duflu> And it stutters quite a bit
<duflu> Oops... HD4600
<duflu> I'm suspicious of:  [     1.949] (**) intel(0): "Tear free" disabled
<duflu> But can't remember what it used to be
<mlankhorst> there didn't used to be a tear free option
<mlankhorst> and it was always disabled :p
<duflu> mlankhorst: Just guessing...
<duflu> But if I wanted a real answer I would debug Compiz
<duflu> trying to avoid that
<duflu> alan_g: Any hints as to how to force gmock to match 16 elements passed to a GLfloat* parameter? :)
<alan_g> duflu: write a bespoke matcher?
<duflu> alan_g: That's what I thought, but attempts so far don't even compile
<duflu> And the docs are too vague to explain why
<alan_g> racarr has written quite a few around the input tests
<duflu> On second thoughts, this test probably should not exist using mocks. It assumes too much about the internals of the class
<alan_g> Talking about assuming implementation details: Does anyone think SocketSessionTest.basic_msg is a readable or useful test?
 * alan_g wants to delete it
<duflu> alan_g: If you can't read it then that doesn't bode well. I though you knew that stuff better than most
<duflu> +t
 * duflu wanders off
<ricmm> kdub: asleep? ;)
<alan_g> alf_: can you take a look? I'm getting happier with it (but it may be just that I'm getting used to it): https://code.launchpad.net/~alan-griffiths/mir/spike-exposing-rpc-in-frontend/+merge/202351
<alf_> alan_g|lunch: sure
<kgunn> alf_: a matter of curiosity, we don't have triple buffering on at the client level do we ?
<alan_g> kgunn: we don't
<alf_> kgunn: alan_g: AFAIK, the code supports triple buffering for client surfaces. What is blocking it?
<kgunn> alf_: so i was just thinking, wrt side stage, where the code relies on snapshotting when "closing"/"revealing"
<kgunn> and that the pipeline is stalling
<kgunn> e.g. its gotta read from the buff
<kgunn> before it let's it continue rendering
<kgunn> & swapping buffs
<kgunn> whereas, triple buffering would at least help alleviate
<kgunn> this getting in at least one extra render while you're still reading
<kgunn> (all theory of course)
<kgunn> ricmm: ^
<alf_> kgunn: are we seeing an actual slowdown when the sidestage is revealed/closed?
<kgunn> alf_: yeah there's definitely some stall/jank at times
<kgunn> if you flash devel-proposed, it has sidestage...N10 of course
<alf_> kgunn: And I am assuming that snapshotting been identified as the culprit or is this a theory?
<kgunn> alf_: all theory
<ricmm> alf_: do you have a N10?
<alf_> ricmm: yes
<ricmm> can you give it a go with the latest image
<ricmm> you'll have the feel of whats happening
<alf_> ricmm: ok
<alan_g> alf_: sorted tabs (and placated valgrind over the SocketSessionTest.basic_msg_is_received_and_dispatched test)
<alf_> alan_g: ok
<dandrader> do you guys have trouble getting useful backtraces out of gdb on the device (arm)?
<kdub> dandrader, sometimes
<dandrader> kdub, any trick I can do to improve it?
<kdub> dandrader, unfortunately no, havent spent a lot of time looking
#ubuntu-mir 2014-01-22
<kdub> many code reviews today
<RAOF> much landing?
<kdub> RAOF, mockable-udev looks like its gotten enough +1's :D
<RAOF> *finally*  :)
<RAOF> kdub: So, https://code.launchpad.net/~kdub/mir/compositor-double-start-stop/+merge/201242 seems reasonable to land to me, but how do we mark this as âthis entire problem should be solved by removing this interfaceâ
<RAOF> kdub: Because I agree with the others that unity-mir has no business directly starting & stopping the compositor.
<duflu_> RAOF: I did ask for input from the team on that before doing it. No one replied :)
<RAOF> duflu: Um, ECONTEXT
<duflu> RAOF: When I put start/stop calls in unity-mir
<RAOF> Ah, right.
<duflu> Yeah, it might be nice to say: bool DisplayBuffer::asleep { return all outputs are asleep; } and the compositor can check that and not render to display buffers whose outputs are all off
<kdub> RAOF, yeah, we'll need a new interface accessible from DefaultServerConfiguration for them to use
<duflu> kdub: No need. It can be implicit and the compositor can sleep as required ^
<duflu> Gah. Why must Haswell graphics be slower than Sandy Bridge?! This is annoying. I don't even have a smooth desktop
<RAOF> duflu: That's really odd.
<RAOF> duflu: *my* Haswell is nice and fast. That said, it *does* have about twice the processing units as yours and a big shiny 128MB L4 cache on it.
<duflu> It's almost as if all that wonderful asynchronous triple buffering I came to know and love isn't there any more
<duflu> RAOF: To be fair, I'm complaining about a saucy system so perhaps the driver isn't quite there like it is for trusty
<duflu> And I can't easily boot trusty because this is one of those systems where Ubuntu images are unbootable (old bug)
<RAOF> Hm. Let's play with std::future...
<RAOF> Zoe tries, and fails, to stay awake all day...
<RAOF> Hey, is there any way to get QtCreator to do a parallel build?
<RAOF> duflu: I'm sure you'll be particularly overjoyed about mir::X::GlobalSocketListeningServerSpawner. :)
<duflu> RAOF: Unfortunately I can't shoot people from my desk
<duflu> Easily
<duflu> Sorry, bad day
 * duflu realizes he only has a Nerf gun
<duflu> RAOF: I suggest if you know the name is devious, then fix it instead of proposing it :)
<RAOF> Yeah, I'll do so before proposing it :P
<tvoss_> RAOF, for your qt creator question: did you try ninja as a build system?
<RAOF> tvoss_: Ninja doesn't support Mir, AFAIK (the 3rd_party stuff confuses it)
<RAOF> I have tried a couple of times :){
<tvoss_> RAOF, oh, I haven't tried ninja with mir, but might well be ...
<tvoss_> RAOF, it's still a bit shaky in case of more complex project layouts
<alan_g> alf_: thoughts on https://code.launchpad.net/~alan-griffiths/mir/spike-exposing-rpc-in-frontend/+merge/202351?
<alf_> alan_g: sorry, forgot to approve
<alf_> alan_g: anpok: What do you think about splitting mir_client_library.h into separate *.h files, which mir_client_library.h then includes (e.g. mir_client_library_connection.h, mir_client_library_surface.h)
<alan_g> alf_: not worried by the "magic numbers"?
<alan_g> alf_: no strong objection, but why? Are their clients that would only want part of the API?
<alf_> alan_g: I don't expect most clients to use the output capture API, but that's not my main reason. I want to do that to make the headers files more readable and partitioned. I feel mir_client_library.h is becoming too large.
<alan_g> alf_: I guess we are recapitulating the evolution of windows.h - looking forward to MIR_ASYNC_LEAN_AND_MEAN. ;)
<alf_> alan_g: We could make the decision to move to separate include files as the preferred way to use mir_toolkit and just keep mir_client_library.h for backwards compatibility
 * alan_g was JOKING - we should learn from history and do as you suggest.
<mlankhorst> ;o
<alf_> alan_g: @magic numbers, well it's reasonably obvious what is going on, but I wouldn't mind e.g. std::tie(header[0], header[1]) = bytes_of(body_size) if we want to hide the details
<alan_g> Is there a good reason to hide the details - I see no value in added abstraction
<alf_> alan_g: I have approved, so you have your answer :)
<alf_> alan_g: but having the abstraction I think would remove complaints about magic numbers (it becomes obvious what 0x100 is in the context of a bytes_of() function)
 * alan_g imagines "std::numeric_limits<unsigned char>::max() + 1"
<anpok> alf_: I think there are a lot of people that do not read header files at all, just read the doxygen and examples, and would not appreciate structured header files
<anpok> but that also means the whole rest would prefer it
<alf_> anpok: I am proposing it more for our (as mir developers) benefit, than for the users of the mir libraries. But it will also help with not creating an unwieldly, concentrated header file, if we move to different #include file per API object. That's the way I am developing MirOutputCapture at least: to use it you will need to include <mir_toolkit/mir_output_capture.h>, it will not be part of mir_client_library.h.
<alan_g> alf_: anpok mp in dire need of (yet) another opinion: https://code.launchpad.net/~dandrader/mir/switchingBundle_lp1270964/+merge/202446
<alf_> alan_g: looking
<dandrader> alan_g, btw, I'm trying out a test for it that won't lock on failure or check the internal state of SwitchingBundle
<alan_g> dandrader: excellent
<anpok> alan_g: what do you mean with your comment https://code.launchpad.net/~dandrader/mir/switchingBundle_lp1270964/+merge/202446/comments/472337
<anpok> ah ok
<anpok> nm
 * alan_g deletes reply
<anpok> did not comment there yet, because I have not read up on SwitchingBundle
<anpok> yeah, good opportunity to do so now
<dandrader> alan_g, if I understood it correctly, the sole purposes of that frameno parameter in compositor_acquire is to solve the use case of two (or "n") monitors displaying the very same buffer?
<alan_g> dandrader: that's similar to my understanding - except snapshotting might be another case
<dandrader> alan_g, hmm, but the snapshot feature or API there is orthogonal to that frameno parameter as far as I can tell
<alan_g> dandrader: you may be right (this stuff keeps changing while I sleep)
<dandrader> :)
<anpok> snapshot means buffer is just being rendered by a compositor thread?
<alf_> anpok: it means that we need to peek a buffer in order to take a snapshot of it, we don't want to "consume" it in the process
<alan_g> tvoss_: got a moment for a design consultation?
<tvoss_> alan_g, sure
<alan_g> I'm thinking about greyback's need to make server => client calls
<alan_g> http://pastebin.ubuntu.com/6797668/
<alan_g> But this sort of change breaks compatibility
<alan_g> s/i/a/
<tvoss_> alan_g, not sure why you need the wrapper
<alan_g> Otherwise we don't know what to deserialize
<alan_g> At the moment server only gets Invocations, client only gets Results
<alan_g> And that's already messy as Result is either a Result or some "events"
<alan_g> Allowing it to be an Invocation too...
<alf_> alan_g: Any idea why I could be getting mir/tests/mir_test_framework/in_process_server.cpp:77: Failure bind: Address already in use ?
<alf_> alan_g: it started happening after a crash in a test I am making that uses the InProcessServer, but not all InProcessServer tests fail like this
<alan_g> alf_: that's weird! how can a new socket already be bound?!
<alan_g> You mean new processes?
<alf_> alan_g: yes, e.g. running 'bin/mir_acceptance_tests --gtest_filter=DemoPrivateProtobuf.*' fails
<alan_g> Then socketpair() is allocating a socket already bound by a process that has already exited?
<alan_g> Or, something
<alan_g> Weird
<alan_g> I don't immediately have an idea. tvoss_ ^^ ?
 * alan_g knows sockets are weirder than he can imagine
<anpok> alf_: when would that happen?
<anpok> the snapshot - but not consume?
<alan_g> anpok: snapshots shouldn't "steal" frames from compositing
<alan_g> alf_: can you try updating in_process_server.cpp:77 to dump the boost diagnostics?
<alf_> alan_g: nothing interesting there, but strace is interesting http://paste.ubuntu.com/6797795/
<alf_> alan_g: it seems we try to open a socket file after all
<alan_g> alf_: where's that?
<alf_> alan_g: line 508
<alan_g> nm just found it
<alf_> alan_g: removing the leftover file fixes the problem, but of course this shouldn't be happening in the first place
<alan_g> alf_: ack. I'll look into it
<alan_g> want to file a bug?
<alf_> alan_g: sure
<alf_> alan_g|tea: https://bugs.launchpad.net/mir/+bug/1271604
<ubot5> Ubuntu bug 1271604 in Mir "Tests that use the InProcessServer bind the default socket file" [Undecided,New]
<kdub> hey anpok, could you take a 2nd look at: https://code.launchpad.net/~kdub/mir/hwc12-support/+merge/202015
<anpok> alf_: where can I find the code that takes the snapshots - or requests filling the glpixel buffer?
<alf_> anpok: you mean the code from the unity8 side?
<anpok> yes
<alf_> anpok: unity-mir/src/modules/Unity/Application/applicationscreenshotprovider.cpp
<anpok> oh there
<alan_g> alf_:  https://code.launchpad.net/~alan-griffiths/mir/fix-1271604/+merge/202722
<anpok> kdub: any idea why launchpad shows changes in mock_hwc_composer_device_1.h that already landed in devel?
<kdub> anpok, where are you seeing that?
<anpok> https://code.launchpad.net/~kdub/mir/hwc-layerlist-improvements/+merge/202738 line 118 +
<kdub> maybe the diff was generated before the other one landed
#ubuntu-mir 2014-01-23
<RAOF> Man, don't double-tap <tab> in gdb...
 * RAOF 's console scrolls through the 2MB or so of symbol names
<tvoss_> RAOF, verbosity for the win :)
<RAOF> Ahem.
<RAOF> Create the pipe *before* you fork()
<RAOF> And we win!
<RAOF> And with that, EOD!
<RAOF> Turns out that std::future is a quick way to large symbols.
<duflu> RAOF: Not enough bytes in your life?
<duflu> Later
<anpok> is anybody of you succesfully using sbuild to build mir?
<anpok> for armhf
<anpok> i just got weird cmake problems - i get cmake messages like successfully found pkg-config \n egl found and then on the next line pkg-config not found (found version 0.26) and glesv2 not found...
<anpok> http://paste.ubuntu.com/6802564/
<kgunn> anpok: are you following this https://lists.launchpad.net/ubuntu-phone/msg05556.html
<anpok> yes, but I also followed the configuration steps from here https://wiki.ubuntu.com/SimpleSbuild
<kgunn> anpok: i tried week before last and i was actually able to build...but then failed the build's unit test run
<kgunn> hmmm, kinda looks like the chroot might not have set up correctly?
<kgunn> only a guess
<alan_g> Hmm, I just tried cross-building and got "/usr/lib/gcc-cross/arm-linux-gnueabihf/4.8/../../../../arm-linux-gnueabihf/bin/ld: cannot find /lib/arm-linux-gnueabihf/libpthread.so.0 inside" whatever that means
<alan_g> ... but zapping the "partial-armhf-chroot" fixes it
<dandrader> is that a known problem? https://jenkins.qa.ubuntu.com/job/mir-clang-trusty-amd64-build/713/console
<dandrader> "tests/acceptance-tests/test_protobuf.cpp:104:35: error: inheriting constructors are not supported"
<alan_g> dandrader: I thought that was supported now
 * alan_g wonders which clang version this is
<anpok> clang-3.2
<alan_g> dandrader: not a known problem, but that C++ support is fairly recent in clang. 3.4 definitely supports it.
<dandrader> alan_g, that failed in https://code.launchpad.net/~dandrader/mir/SwitchingBundlePrint/+merge/202447. so the code is already there. maybe CI changed its clang version?
<alan_g> dandrader: maybe. Or maybe the node is out of date. I guess #ubuntu-ci-eng can tell us
<dandrader> alan_g, should I ask them or will you do it?
<alan_g> I can
<dandrader> alan_g, ok, thanks!
<alan_g> mterry: do you know which branches were involved in robert_ansell's failed attempt to get USC working without a filesystem endpoint? I'm suspecting the problem was lp:1271655 but can't find his code.
<mterry> alan_g, hmm, let me dig.  I remember they all had similar names
<alan_g> mterry: thanks
<mterry> <mterry> alan_g, hmm, let me dig.  I remember they all had similar names
<mterry> <mterry> alan_g, at least lp:~robert-ancell/lightdm/private-mir-connection and lp:~robert-ancell/unity-system-compositor/private-mir-connection
<mterry> <mterry> alan_g, I think only those two...
<mterry> <mterry> alan_g, at the time I also had to grab mir/devel, but that's in trusty now
<mterry> alan_g|tea, ^ sorry, had irc issue
<alan_g> mterry: thanks
<anpok> kgunn: yes .. just redoing the chroot resolved it..
<alf_> alan_g: I pushed the branch with the problematic tests at lp:~afrantzis/mir/mir-output-capture-basic-client-api
<alan_g> alf_: I'll take a look - which test is the problem?
<alf_> alan_g: bin/mir_acceptance_tests --gtest_filter=MirOutputCaptureTest.* hangs in MirOutputCaptureTest.gets_valid_egl_native_window
<alf_> alan_g: but MirOutputCaptureTest.gets_valid_egl_native_window by itself runs
<alan_g> alf_: ack. Building
<alf_> alan_g: the last two tests MirOutputCaptureTest.create_and_release_contact_server and MirOutputCaptureTest.gets_valid_egl_native_window are similar
<alf_> alan_g: you can get the same effect if you run either twice (with --gtest_repeat)
<alf_> alan_g: Removing "delete capture;" from src/client/mir_output_capture_api.cpp alleviates the problem (but causes a leak, of course)
<alan_g> alf_: I can reproduce the hang (in first incantation above)
<alf_> alan_g: The apparrent cause of the hang is the display server not stopping when told to do so, i.e., it seems that the main loop just ignores(?) our stop() call. Pressing ctrl-c unblocks it somehow
<alf_> s/apparrent/apparent/
<alan_g> alf_: OK - just looking at where the threads are at
<alan_g> Hmm. exiting the debugger seems to unblock too
<alf_> alan_g: it's really weird... it's even more weird that removing the "delete capture" as mentioned above "fixes" the problem... I can't see the connection (unless it is a timing issue?)
<alan_g> alf_: weird just means there's a fact we're missing
<kgunn> alan_g: wanna have a chat now about the potential release process changes
<alan_g> dandrader_: fginther & cjwatson figured out what happened.
<dandrader> alan_g, great!
<kdub> alan_g, with ~vanvugt/mir/fix-1271853, would you be okay with me top-approving?
<alan_g> kdub: yes, you have the right.
<kdub> alan_g, :D was just checking if that needs-info was a blocker
<alan_g> kdub: it would be nice to know
<xnox> Saviq: i've mixed a bug in cmake, and mir & unity8 cross-building works once again out of the box.
<xnox> s/mixed/fixed/
<ogra_> dont mix the fixes :)
<mterry> kdub, I'm running mir/devel on my mako with USC.  USC is crashing with "error binding buffer to texture".  Any clues?
<kdub> mterry, new to me
<mterry> kdub, it happens because eglCreateImageKHR returns EGL_NO_IMAGE_KHR in mga::Buffer::bind_to_texture()
<mterry> kdub, this doesn't happen with trusty mir
<kdub> mterry, let me try something
<anpok> xnox: i thought it work again but now I got that message: make[1]: Leaving directory `/Â«PKGBUILDDIRÂ»/obj-arm-linux-gnueabihf'
<anpok>    dh_install -O--parallel -O--fail-missing
<anpok> dh_install: usr/lib/arm-linux-gnueabihf/libmirserver.so.13 exists in debian/tmp but is not installed to anywhere
<anpok> dh_install: missing files, aborting
<anpok> make: *** [binary] Error 255
<anpok> dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2
<xnox> anpok: with mir or unity8?
<xnox> anpok: i've compiled mir_0.1.3+14.04.20140108-0ubuntu1_armhf.build as in the archive
<xnox> anpok: http://paste.ubuntu.com/6804190/
<xnox> anpok: sounds like a packaging change is needed of whichever revision shows that bug above.
<anpok> ah
<anpok> building a mir branch
<anpok> i think i have mixture of abi verison 13 and 14
<kdub> mterry, i see...
<kdub> <CreateImage:1363>: Unsupported buffer format: 3.
<kdub> this is probably a regression of some sort
<kdub> i havent been tinkering in this area lately, not sure what it could be at the moment
<mterry> Yar.  Is this from that alpha patch?
<kdub> it might be, lets try backing it out and seeing if that helps
<kdub> mterry, i can try in about...
<kdub> 30 min
<mterry> kdub, I'll give it a go
<kdub> mterry, at any rate, i think that robotfuel has some scripts for firing up a server and checking a client against it
<kdub> we should improve those to fire a server, nested server, and client
<mterry> robotfuel, ^ pretty please  :)
 * robotfuel looks at backlog
<mterry> robotfuel, especially since we're about to enable nested mode
<mterry> by default
<kdub> because I don't think we have a full test for nested
<kdub> in the CI process
<robotfuel> what are you trying to run?
<robotfuel> mterry: what are you trying to run?
<kdub> ./mir_demo_server -f /tmp/socket1 & ./mir_demo_server --host-socket /tmp/socket1 -f /tmp/socket2 & ./mir_demo_client_egltriangle -m /tmp/socket2
<mterry> robotfuel, so the problem I hit is using nested mode.  I'm trying to run unity-system-compositor (USC) and it crashes with "error binding buffer to texture".  But kdub was just saying that we don't have good test coverage for nested mode in general (which allows such regressions to slip in)
<mterry> robotfuel, so apparently you have a nice script for testing that may benefit from adding a nested server
<kdub> robotfuel, i'm just suggesting once we get the problem we're seeing fixed, we should improve the CI to protect the nested server from regressions
<robotfuel> mterry: yes we could easily add a test for that. let me give you a link to the current one.
<kdub> which me or another mir team member could help with :)
<kdub> robotfuel, thanks
<robotfuel> mterry: there is this https://bazaar.launchpad.net/~chris.gagnon/+junk/mir-medium-test-runner-for-jenkins/view/head:/mir-mediumtest-runner.sh and this  https://bazaar.launchpad.net/~chris.gagnon/+junk/mir-demo-runner/view/head:/bin/mir-demo-tester
<robotfuel> mir-demo-tester is in a all the way finish because I thought shell bindings for subunit were going to land, but they haven't yet. https://code.launchpad.net/~thomir/subunit/trunk-add-cmd-line-script
<robotfuel> s/is in/isn't
<mterry> robotfuel, I'm less interested in running the script myself than just making sure a nested server gets added to it to avoid regressions in the future.  Something like kdub's line above:
<mterry> ./mir_demo_server -f /tmp/socket1 & ./mir_demo_server --host-socket /tmp/socket1 -f /tmp/socket2 & ./mir_demo_client_egltriangle -m /tmp/socket2
<robotfuel> mterry: does that automatically stop the server when it's finished?
<mterry> I doubt it
<kdub> mterry, filed a bug https://bugs.launchpad.net/mir/+bug/1272041
<ubot5> Ubuntu bug 1272041 in Mir "mir nested server failure: what(): error binding buffer to texture" [Critical,New]
<mterry> kdub, awesome.  I'm compiling a version of mir just before the alpha bits landed for testing.  But compiling takes a while
<kdub> mterry, okay :) (also, you know of cross-compile-chroot for mir?)
<mterry> kdub, I've cross compiled with pbuilder before, but it's not much faster
<kdub> not much use for packages, but if you're working in a mir-only world for some problems, its a real time saver
<kdub> well, thats an emulated cross compile, the script does a native cross compile
<kdub> eg, a toolchain that runs on x86 that produces armhf libs
<mterry> hmm.  I'm so wedded to the packaging workflow, but that sounds tempting
<kdub> mterry, yeah, i just thought I'd throw it out there
<kdub> mterry, lp:mir/devel rev 1328 is the culprit
<mterry> kdub, aha
<mterry> kdub, yup, that's the alpha patch I was going to test
<mterry> anpok, ^
<mterry> bug 1272041
<ubot5> bug 1272041 in Mir "mir nested server failure: what(): error binding buffer to texture" [Critical,New] https://launchpad.net/bugs/1272041
<anpok> re
<anpok> xnox: yes thanks for parsing the error message
<anpok> mterry: that happened on n10?
<mterry> anpok, mako (n4)
 * mterry goes to gym for a bit
<mterry> anpok, any luck?  Any testing I can help with?
<rsalveti> kdub: so it seems mir is working mostly fine with flo (nexus 7 - 2013), I have just one critical issue atm
<rsalveti> kdub: after mir/powerd turns the screen off, nothing can turn the screen on again
<rsalveti> so the rendering keeps working, but screen is constantly off
<rsalveti> had to disable powerd to have unity8/mir working with it
<rsalveti> and this also happens when running mir_demo_server_basic
<rsalveti> it works fine first time you run it, but it seems it turns the screen off automatically when you stop it
<rsalveti> so next time you run the screen will be completely off, as it fails to turn on the screen again
<rsalveti> kdub: I'm just uploading the image I got here, will have the link ready in a few
<kdub> rsalveti, cool, its encouraging mir works
<kdub> rsalveti, taking a late lunch, be back shortly
<rsalveti> kdub: ok
<anpok> mterry: kdub already has a solution which i can only verify to work on none n4 devices - lp:~andreas-pokorny/mir/fix-1272041
<mterry> anpok, ooh, will test
<rsalveti> kdub: flash http://people.canonical.com/~rsalveti/aosp/flo/, then http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20140123.1/trusty-preinstalled-touch-armhf.zip via recovery
<rsalveti> kdub: the android container takes ~1 min to load, still investigating why, and current mir will be broken because of hwcomposer 1.2, so if you want a working unity8 just use my ppa: https://launchpad.net/~rsalveti/+archive/ppa
<rsalveti> and make sure to disable powerd as well
<kdub>  rsalveti thanks
#ubuntu-mir 2014-01-24
<RAOF> Ha!
<RAOF> When introspecting the set of fds a process has open, be aware that you might actually open an extra fd in the process of introspection... :)
<rsalveti> kdub: were you able to give it a try?
<kdub> rsalveti, not yet, distracted by https://bugs.launchpad.net/mir/+bug/1272041
<ubot5> Ubuntu bug 1272041 in Mir "mir nested server failure: what(): error binding buffer to texture" [Critical,Confirmed]
<rsalveti> got it
<rsalveti> interesting
<kdub> never a dull day on the mir team
<RAOF> Hm. google mock can't handle returning move-only things.
<duflu_> It's so over-featured, I get it can... somehow
<duflu_> I *bet*
<RAOF> Not according to the google mock lists.
<duflu_> Then I blame C++ for giving us such things
<duflu> Stroustrup will be personally responsible for the downfall of humanity, I suspect
<RAOF> https://code.google.com/p/googletest/issues/detail?id=395 for those playing at home.
<RAOF> Also annoying: QtCreator is super-confused by >> in templates.
<duflu> RAOF: That's a common problem with (older?) compilers too. If you have nested templates you need a space: "> >"
<RAOF> duflu: I >> in templates is a C++11 feature IIRC.
<duflu> RAOF: Not sure what you mean. But  do remember when I started learning and using the STL that ">>" was a syntax error/ambiguity. You have to put a space in the middle.
<RAOF> duflu: http://en.wikipedia.org/wiki/C%2B%2B11#Right_angle_bracket - >> as not-always-right-shift operator is a C++11 language feature.
<duflu> That explains why it mysteriously started working when I joined Mir
<RAOF> So if you weren't building with --std=C++11... ;)
<duflu> Still, for the cost of one character you can write backward-compatible code. Sounds like a good deal
<RAOF> Hm. Don't change things out from under cmake *too* much or it might fail to notice that you're changing some code, not compile it, and your tests will inexplicably fail, even though you've added code that should make them pass.
<anpok_> RAOF: if I am not mistaken the make generator of cmake does not notice if you change a self defined variable that changes add_definitions or changes CMAKE_CXX_FLAGS without also changing a different variable like CMAKE_BUILD_TYPE .. at least I had some bad experience that made me do all define like settings in header files created through configure_file
<duflu> anpok_: I think he is past EOD/EOW
<duflu> Till Tuesday :)
<anpok_> oh it is friday again
<alf_> duflu: anpok_: alan_g: Any preference for MirOutputCapture vs MirOutputRecording vs ... ?
<duflu> alf_: Mir*Recording is my preference. Unsure about mentioning "Output" though
<duflu> It sounds better. "Recording" is clearly an ongoing process whereas "Capture" sounds like an instantaneous screen grab or something
<duflu> Woo, my Friday afternoon experiments have solved cloned output stutters
<alan_g> +1
<alf_> duflu: MirScreenRecording? We need to mention something at least since plain MirRecording is too vague (input? output? something else?)
<duflu> And more generally boosted potential composting performance
<alf_> duflu: \o/ sounds good :)
<duflu> alf_: Yes I thought the same about MirRecording
<duflu> maybe
<duflu> Not sure
<alf_> duflu: I like Output since the recording is targeting a specific MirDisplayOutput, so perhaps even MirDisplayOutputRecording if we don't mind being more verbose
<alf_> duflu: but I think MirOutputRecording is clear enough
<duflu> alf_: Is it per output or DisplayBuffer? If the latter that's not even a client-visible concept
<alan_g> ScreenCapture?
<alf_> duflu: it is per output
<anpok_> as a non native speeker both capture and recording do indicate an ongoing process
<anpok_> but recording also indicates that each frame is stored
<anpok_> while capture sounds like .. you get the current frame everytime you look at it..
<anpok_> *speaker..
<alf_> anpok_: which is actually what is going on...
<alan_g> Looking at the mir-devel list we've talked about "screenshotting" and "screencasting"
<duflu> alf_: ScreenCast?
<anpok_> i like screen cast
<duflu> Since there's no requirement for actual "recording"
<duflu> Oh. It's one word... MirScreencast with lower c
<alan_g> Good enough
<duflu> http://en.wikipedia.org/wiki/Screencast
<duflu> It's on Wikipedia so it must be true
<duflu> :)
<alf_> A *screencast* is a digital recording of computer screen output, also known as a video *screen capture*
<duflu> alf_: I have too many memories of bugs where we ask for a screen capture, meaning screenshot
<duflu> So Capture is ambigous
<alf_> alan_g: anpok_: duflu: it's Screencast 1...
<alf_> 2...
<alf_> 3...
<alf_> Sold!
<duflu> Yay for finding new nouns not yet used in the codebase
<alf_> duflu: alan_g: anpok_: And guess what the relevant interface on the server side will be called ;)
<duflu> Clarence?
<alf_> MirDisplayScreenOutputClarence
<alf_> ..ProviderManager
<alan_g> ...er
<duflu> Hmm, do we really have the words "DisplayScreenOutput" side by side?
<alf_> duflu: I hope not! :)
<anpok_> MirDOScreencaster
<anpok_> no dont take it serious
<duflu> VideoDisplayScreenOutputViewportBufferImplementation
<alf_> anpok_: as you can see we are way past seriousness at the moment :)
<alan_g> anpok_: we all know "Avoid class names that end in er"
<duflu> I shouldn't joke. Compiz had function names twice as long
<anpok_> alan_g: hm like Verbalizer?
<alan_g> anpok_: http://www.benhallbenhall.com/2013/01/naming-objects-er-object-names/
<alan_g> There was an image floating around that showed a room with "OO" names like "InternalToExternalAccessProvider" (door) - can't find it.
<duflu> Heh. I'm sure I've been ranting about ER for years :)
<duflu> "er" not "ER"
<alf_> alan_g: anpok_: duflu: Of course, sometimes, especially for narrow interfaces, a name ending in -er is actually a good choice
 * duflu -> dinner, long weekend
<alf_> dinn-er another name we should avoid! :P
<anpok_> alf_: but thats to some degree because of c++ - those narrow interfaces are probably just a single function (op()) and in a different language would just be a function
<anpok_> there the verb does not have to become a noun
<dandrader> have you guys successfully used apitrace on a Nexus 10 (or any other device)?
<anpok_> not tried yet
<dandrader> any other trick for tracing gl calls?
<anpok_> it does not work?
<dandrader> anpok_, apitrace? no.
<anpok_> just tried with manual preloading
<anpok_> oh
<anpok_> it did create something reasonable,
<anpok_> but when replaying on the desktop it complains that we never call glViewport
<anpok_> maybe I should use a better exmaple than mir_demo_standalon_render_surfaces
<dandrader> hmm, when I tried with qmlscene it complaining about some missing API function
<dandrader> complained
 * dandrader tries with some mir example
<anpok_> we could add that to apitrace then
<anpok_> i mean any other trick would involve doing the same, and making it work :)
<dandrader> yeah, works with mir_demo_client_triangle but with qmlscene it bails out with "error: unavailable function eglBindAPI"
<anpok_> strange egltrace.so has it
<dandrader> anpok_, exactly
<dandrader> anpok_, do you also get the same with qmlscene?
<dandrader> maybe it's because of the order or way that qmlscene loads its dependencies (through a qt platform plugin, etc)
<anpok_> qmlscene does not start
<anpok_> ah ok
<anpok_> now I get the same behaviour
<anpok_> i tried to find out when egl was added to apitrace
<alf_> Debugging boost::asio is not fun...
<ricmm> kdub: ping / when back
<ricmm> guys one question
<ricmm> how do we do handover of a buffer from server to client over ipc
<ricmm> fd mappings of the server gralloc'd space?
<anpok> dandrader: hm
<anpok> dandrader: qmlscene only links libGLESv2.so and not libEGL.so
<dandrader> anpok, what about the QPA library that it eventually loads?
<anpok> so whith LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/apitrace/wrappers/egltrace.so:/usr/lib/arm-linux-gnueabihf/libhybris-egl/libEGL.so.1.0.0
<anpok> it should work
<anpok> then egltrace can use eglGetProcAddress to get the real functions
<dandrader> anpok, namely /usr/lib/arm-linux-gnueabihf/qt5/plugins/platforms/libqubuntumirclient.so
<dandrader> that one does link against libEGL
<anpok> ok
<anpok> i just tried qmlscene with an empty scene
<anpok> and when libEGL is preloaded it did not aport on eglBindAPI
<anpok> *abort
<anpok> oh I have to go..
<anpok> bbl
<dandrader> anpok, ok, thanks for the help!
<dandrader> anpok, damn, it doens't abort on start but the sole contents of the trace are "0 eglBindAPI(api = EGL_OPENGL_ES_API) // incomplete"  :/
<dandrader> I think I will have to inject the apitrace wrapper via LD_LIBRARY_PATH....
<dandrader> anpok, ok, this seems to have done the trick: LD_PRELOAD=/usr/lib/arm-linux-gnueabihf/apitrace/wrappers/egltrace.so:/usr/lib/arm-linux-gnueabihf/libhybris-egl/libEGL.so.1:/usr/lib/arm-linux-gnueabihf/libhybris-egl/libGLESv2.so.2
<anpok> ah ok
<kdub> ricmm, pong
<ricmm> kdub: ahoy
<ricmm> kdub: can you jump in a hangout?
<kdub> sure
<ricmm> k
<ricmm> ill call you
<ricmm> canon acc
<kdub> ricmm, https://android.googlesource.com/platform/system/core/+/master/include/cutils/native_handle.h
<ricmm> kdub: http://pastebin.ubuntu.com/6809300/
<ricmm> E/IMGSRV  ( 5712): :0: gralloc_register_buffer: Cannot register a buffer twice (ID=36)
<ricmm> kdub: did you drop?
<kdub> i'm still here, hangout stopped
<ricmm> kdub: http://pastebin.ubuntu.com/6809354/
<ricmm> handle.version=12, handle->numFds=1, handle->numInts=13, handle->data[0]=29
<ricmm> <mir::client::ClientBuffer>
<ricmm> kdub: http://pastebin.ubuntu.com/6809480/
<ricmm> kdub: http://pastebin.ubuntu.com/6809656/
<ricmm> http://pastebin.ubuntu.com/6809667/
<ricmm> kdub: http://pastebin.ubuntu.com/6809689/
<BullSherd> Wow, Google is making really strange things http://goo.gl/YEkaMA
<BullSherd> funny haha xD
<dandrader> kdub, ping
<kdub> hello dandrader
<dandrader> kdub, hi!
<dandrader> kdub, is there any code at all in mir
<dandrader> that clears the contents of a client buffer?
<kdub> via GL?
<dandrader> kdub, in any way
<kdub> glClearColor(0.0, 0.0, 0.0, 0.0); glClear(GL_COLOR_BUFFER_BIT);
<kdub> will clear to black
<kdub> if you change the floats (r,g,b,a) itll change it to different colors
<dandrader> kdub, I mean if mir *does* do it
<dandrader> kdub, not how to do it
<kdub> ah :) we do have a 'buffer initializer' class... let me ch eck if its used
<dandrader> kdub, 'cause I'm debugging the prototype qml mir compositor. and, for a qml client, every now and then one of this frames is shown completely white
<dandrader> so I'm wondering if this bogus white frame could possibly be caused by mir server
<dandrader> or if it must be the client messing things up
<dandrader> afaIct, in the client application there's no call that would clear the frame white (used apitrace to check)
<dandrader> it has something to do with the interactions between threads
<anpok> GLRenderer does it in begin i think
<dandrader> if the scene graph rendering is done in qt's main (GUI) thread, the bogus white frames never show I
<dandrader> show up
<anpok> but it uses the default setting
<anpok> which hopefully is not changed?
<dandrader> but if I enable the scene graph rendering to be done on its own, separate, thread, then the bogus white frames pop up every now and then
<kdub> dandrader, there isnt a 'quick way', but our 'examples/render_surfaces.cpp' programs a buffer color initializer
<kdub> when the buffer is created
<kdub> currently, the default server does not fill to a color on allocation
<kdub> anpok, GLRenderer will clear the display composition, i think we're looking for a way to clear the client's buffer only
<anpok> ok
<dandrader> if I understood things correctly, mir creates a ring buffer of buffers for a given client once, and after that the contents of those buffers are modified only by the client
<kdub> dandrader, right
<kdub> dandrader, the buffers can be destroyed and created again (like on resize), but we won't post a resized buffer until after its been filled by the client
<dandrader> kdub, ok. but in this case the size of the client doesn't change
<dandrader> well, will continue debugging it on Monday
<dandrader> have a nice weekend
#ubuntu-mir 2014-01-25
<RAOF> Woot!
<RAOF> Turns out that if you wait using a condition variable for a boolean to become true it's important to set that boolean to true before signalling the condition variable. Who knew?
<mlankhorst> who didn't:p
#ubuntu-mir 2015-01-19
<mlankhorst> can I enumerate all input devices in mir and get notifications about devices being added and removed?
<alan_g> mlankhorst: I don't know (I think it is a work in progress). anpok_ ^?
<anpok_> mlankhorst: not yet
<anpok_> but on the list
<mlankhorst> oke
<attente_> AlbertA: hi, do you know roughly when the demo server will have support for menu surfaces?
<alan_g> attente_: It's a USA holiday for AlbertA
<attente_> oh, thanks alan_g
<anpok> hm did we ever use umock dev in ci on mako?
<anpok> ah ok umockdev-run is not what we want
<seb128> hey there
<seb128> does mir allow to change keyboard layouts through some api/command?
<anpok> right now only us keyboard is loaded
<anpok> and there is no option to change that
<seb128> anpok, thanks
 * seb128 is going to file a wishlist about that then ;-)
<racarr> Morning!
<alan_g> racarr: don't you have a holiday?
<racarr> alan_g: omg thats true
<attente_> is there a way to bring a surface to front?
#ubuntu-mir 2015-01-20
<alan_g> duflu: has one of us misread lp:1412492? AFAICS it is about real keyboard layout, not OSK. (I.e. switching ASERTY, QWERTY etc.)
<duflu> alan_g: I will update and ask for clarification
<seb128> alan_g, duflu, it is about real keyboard layout
<seb128> e.g having keys on my laptop azerty keyboard do what they are supposed to do
<seb128> atm when I press the "z" I get a "w", e.g the layout is qwerty
<seb128> I commented on the bug
<tsdgeos_> racarr: your patch for qtubuntu doesn't compile
 * tsdgeos_ realizes racarr is probably sleeping
<anpok_> alf_: we were causing that error with wrapper.c .. it overwrites LD_LIBRARY_PATH
<alf_> anpok_: ack
<anpok_> so with the mp it gets more robust
<anpok_> because of the absolute path... but we should also change wrapper.c
<anpok_> or come up with a better solution
 * alan_g votes for a bet
<alan_g> ter solution
 * alan_g must learn to hit one key at a time
<anpok_> hm how about not having a wrapper at all.. but search in ../lib/server-{modules,platforms}/ and in the configured MIR_SERVER_PALTFORM_PATH?
<kdub> i'd much rather search and test than have a wrapper
<greyback> alf_: hey, continuing from Friday - finding a gl config with pbuffer support - here is all the configs I'm getting with eglGetConfigs: http://pastebin.ubuntu.com/9794951/
<greyback> all the EGL_SURFACE_TYPE are set to EGL_WINDOW_BIT (4)
<greyback> tried adding eglGetErrors everywhere, but all imply success
<greyback> so think maybe I should use something other than pbuffer. FBO probably
<greyback> just for context, I'm working on multimonitor support for Qt. On monitor removal, Qt wants to create a temporary offscreen surface so that it can clean up the gl resources associated with the removed monitor
<alf_> greyback: I am not sure that makes much sense to me, but Qt knows best :)
<greyback> well I won't be changing Qt,  I just want to make it happy
<alf_> greyback: +1 for FBO
<greyback> ack
<racarr> Morning
<racarr> tsdgeos: IT is still depending on unlanded changesI will mark WIP
<tsdgeos> racarr: i see, tx!
<greyback> alf_: FBO works nicely, thanks
<attente_> hi, i saw that https://code.launchpad.net/~albaguirre/mir/add-menu-api/+merge/244632 was merged, thanks for that. is there any plan for adding support to the demo shell for it? also, is there any plan for just having a generic subsurface api?
<anpok_> we decided to avoid a generic api when it comes to handling surface types
<anpok_> or rather the team decided that the shell should be able to consistencly decide and implement the surface behavior.. instead of letting the client pick a combination of available semantics
<attente_> anpok_: ok, thanks
<anpok_> o_O s/c/t
<anpok_> so it means if something is missing or not the way clients or shells prefer it we need complaints
<racarr> there will be many kinds of child surfaces :)
<racarr> there will not be "sub surfaces"
<anpok_> all kids are different
<racarr> at any point in the near future I guess
<attente_> sorry, right, that's what i meant
<racarr> maybe one day, specialized for video decoding orsome such
<attente_> is anyone working on adding those menu surface semantics to the mir demo server?
<attente_> i was trying to look through the codebase but couldn't figure things out
<racarr> attente_: I guess AlbertA is going to add something to one of the example servers but its caught up in some
<racarr> big refactorings aha
<AlbertA> attente_: oh right...i will attempt to add it to the demo server later in the week....
<AlbertA> attente_: the big refactoring is regarding window management and roles....so after that we can have a place where to put those semantics in mir by default (but over-ridable)
<attente_> AlbertA: ah, cool. thanks!
#ubuntu-mir 2015-01-21
<racarr> only 68 more files to remove mir event access from
<racarr> will be here for meeting but going to break for a while
<DalekSec> Hello!  Sorry to come with so little detail, but is there a known issue with xmir, nouveau, tty switching, or such that would cause a screen lockup?  What I did, booted into the xmir session, looked at a couple things, ran a few commands, switched to a tty and ran a couple more, switched back to TTY7 and after a little typing nothing seemed to take anymore, keyboard or mouse.  I was also unable to
<DalekSec> switch TTYs.
<DalekSec> Congrats otherwise, was more responsive than before! :)
<duflu> DalekSec: Not surprising such bugs might still exist, but I'm not aware of anyone else still experiencing that kind of thing. Not sure
<DalekSec> Oh sorry, Mir 0.10.0, forgot to say. >_<
<DalekSec> duflu: OK, thanks.  It was a live session anyway, so no harm.
<duflu> DalekSec: Yeah I could tell if it's "more responsive" :)
<DalekSec> Ahaha. :D
<duflu> DalekSec: BTW Mir 0.11 will be noticeably better for XMir
<DalekSec> duflu: Oh?  And is that going to be released into vivid soon?
<duflu> DalekSec: Probably more like a month away. It will take that long to reach critical mass
<DalekSec> Ah, alright.  Thanks.  I suppose I should check the tabloids to see what might be coming. :P
<duflu> DalekSec: Maybe, but this channel is more accurate :)
<duflu> because the Mir team is actually here
<DalekSec> Oh indeed, I don't follow it too closely though, too many things to keep track of.
<duflu> Ha. I keep starting the wrong version of our demo servers by accident. But you notice the difference immediately as 0.10 is noticeably more laggy than 0.11
<duflu> racarr: You could make a permanently opaque structure for clients like:
<duflu> struct MirEvent
<duflu> {
<duflu>     long long serial_num;   // A unique ID for this event. Only Mir can use it.
<duflu> };
<duflu> And let the server decide how long is right to remember each one internally
<duflu> if not "char opaque[1024];" ;)
<DalekSec> (Oh woah, 1212753 was fixed?!  Also, I don't suppose that'll fix the software renderer?)
<duflu> I mean let the client library decide how long to keep the internal representation of each
<duflu> DalekSec: Kinda. That error should now be impossible but none of mir-team has hardware to reproduce and verify it
<DalekSec> So I suppose if I get a chance, I should check it.  OK, coolio.  I'll stop bugging now. :)
<duflu> Ugg, I top approve things and then am surprised when they land
<duflu> Clever
<anpok> hm is there any reason why RAOF used mir/{client,server}-platform as install paths for platforms but just {client,server}-modules inside the build?
<greyback> alf_: hey, I've multimonitor working with Qt. Did you ever observe, with mesa, that one display's swap buffers would cause swap buffers of the other display to block?
<anpok> wow, one thread per monitor?
<greyback> yeah
<anpok> and a single qml scene?
<greyback> yeah
<alf_> greyback: \o/, I haven't noticed this. Could it be locking at the qml/qt level?
<anpok> hm then one event loop .. hmm are renderers allowed to draw one scene multiple times?
<alf_> greyback: Also is this using MultiThreadedCompositor now or just Qt as before?
<greyback> anpok: one per "frame" the QML scene is synchronized with the scenegraph. The scenegraph can then be passed over multiple times if need be
<anpok> oh
<anpok> i mean .. cool
<greyback> alf_: just Qt. It's another project to combine mir and qt's renderers
<alf_> greyback: ok
<greyback> anpok: note it's not a single scene as you'd define it. We've 1 QML scene, but it is split into 2 subtrees, one subtree for each monitor
<greyback> anpok: so I can't easily have something 1/2 way on each monitor
<greyback> alf_: so yeah it could be many things, I just heard rumour mesa might be an issue
<anpok> hm something like that might happen with qxl
<alf_> greyback: I haven't noticed something like this locally, but I haven't tried MM recently. Does the blocking have a visible effect?
<greyback> alf_: with relatively complex scenes yes. I see one monitor's eglSwapBuffer block for 7-10ms every frame
<greyback> I'm sure you would have noticed that however. So probably something I'm doing wrong
<greyback> but yay for almost working , and not crashing
<alf_> greyback: Is that the low-level eglSwapBuffer call in mesa::DisplayBuffer ?
<greyback> alf_: not quite, it's the DisplayBuffer::gl_swap_buffers and flip calls
<alf_> greyback: If this includes flip then a delay is normal, since need to synchronize with vsync to do the flip.
 * greyback goes to disable on non-primary monitor...
<alf_> greyback: having said that, you should also be seeing such a "delay" even with one monitor. If you are seeing very different delay behavior with multiple screens we should look into it. Of course, with multiple screens we are stressing the GPU more...
<greyback> alf_: I only see such a delay with one monitor. I want to see how a stock mir server behaves
<duflu> greyback_: Multi-monitor could theoretically suffer from indefinite freezes on secondary monitors (part of bug 1395581)
<ubot5> bug 1395581 in Mir "Double-buffered surfaces may lag or freeze if event driven and not constantly redrawing" [High,In progress] https://launchpad.net/bugs/1395581
<duflu> ... in theory
<duflu> Although your render time should be <1ms on desktop
<greyback_> duflu: ok, will keep that in mind. I've an animation on both screens, so both should be constantly redrawing
<greyback_> how do I make proving shell change to side-by-side config?
<duflu> greyback_: --help ;)
<greyback_> you mean I have to read, ugh
<duflu> greyback_: Also you'll get significantly higher performance releasing all your renderables before the flip()
<duflu> If not already
<greyback_> duflu: not so easy for qtmir to do that just yet, but yeah I understand why
<duflu> greyback_: Sounds a lot like buffers_ready_for_compositor() is underestimated for the second monitor... which is bug 1395581
<ubot5> bug 1395581 in Mir "Double-buffered surfaces may lag or freeze if event driven and not constantly redrawing" [High,In progress] https://launchpad.net/bugs/1395581
<greyback_> duflu: I'm not even rendering client surfaces yet. This is compositor only
<duflu> greyback_: Not nested I take it
<greyback_> well mir-proving-shell works nicely
<greyback_> duflu: correct
<duflu> greyback_: OK, good luck. It's getting late here
<greyback_> so qtmir has a problem somewhere
<greyback_> duflu: absolutely, go away :)
<duflu> Kay
<alan_g> greyback_: would you also check "mir_demo_shell --display-config sidebyside  --window-manager tiling"? (There are some - probably irrelevant - compositing tweaks in proving shell)
<greyback_> alan_g: ok
<greyback_> alan_g: ah I don't have the latest mir for that
<greyback_> mir_proving_server --display-config sidebyside  --window-manager tiling
<greyback_> [1421840251.676989] (II) SharedLibrary: Loading libmirplatform5driver.so
<greyback_> Unknown command line options: --window-manager tiling
<alan_g> greyback_: nevermind then
<greyback_> next time
<alan_g> Like I said the tweaks are probably irrelevant. Just peace of mind to eliminate them
<greyback_> just figured out it's a qt problem, so I wouldn't worry :)
<alan_g> :)
<anpok> for various definitions of 'I'?
<greyback_> :D
<alan_g> anpok: it's a common abbreviation for "if I were you then I wouldn't worry"/"I wouldn't worry if I were you"
<anpok> ... lost in translation
<tsdgeos> guys, do you use zeitgeist for something?
#ubuntu-mir 2015-01-22
<anpok_> alan_g: hm if we copy the wrapper instead of linking it the gdb symptoms would be gone
<alan_g> anpok_: I don't understand
<alan_g> alf_: small update, still happy? https://code.launchpad.net/~alan-griffiths/mir/improved-Rectangles/+merge/247161
<anpok_> hm we talked about the wrapper causing troubles.. i.e. with gdb.. hmm on monday?
<alf_> alan_g: looks good
<alan_g> anpok_: surely the wrapper needs to be linked to execute
<anpok_> i mean that gdb does not cope with mir_what_ever beging a symbolic link to ./wrapper
<anpok_> when you try to restart for example..
 * alan_g understands now
<alan_g> anpok_: alf_ either of you want to review this (otherwise I'll TA) https://code.launchpad.net/~albaguirre/mir/dialogs_and_tooltips/+merge/246655
<alf_> alan_g: feel free to TA
<alan_g> done
<alf_> kdub: Hi! I was looking into mir_native_buffer.h and noticed we have a special case there for Android. Can we remove that special case by making Android serialize its data into a BufferPackage ?
<alf_> kdub: (background: I am working on making the Mir core more platform agnostic)
<kdub> alf_, which is the android-specific part?
<alf_> kdub: #ifdef ANDROID typedef struct ANativeWindowBuffer MirNativeBuffer;
<kdub> alf_, ah, yes, well I dunno
<kdub> I mean, I guess we can convert ANativeWindowBuffer to a MirBufferPackage, but its tricky, mostly because ANativeWindowBuffer has a refcounting system
<kdub> alf_, remembering a bit more... for android, we're given a native window interface, for mesa, we had to define one ourselves
<kdub> like, the only place I see that struct needed is in the client API is in common/mir_toolkit/mesa/native_display.h
<alf_> kdub: which struct are you referring to?
<kdub> MirBufferPackage
<alf_> kdub: (btw, a branch that's up for review move mesa/native_display.h out of common/)
 * kdub will look
<kdub> okay, that branch seems a good idea
<kdub> (lp:~afrantzis/mir/remove-mesa-specific-code-from-mircommon)
<kdub> and it makes sense to me that MirBufferPackage ends up in mir-client-platform-mesa-dev
<alf_> kdub: I see MirBufferPackage used throughout the client code (MirSurface, ClientBufferDepository etc)
<kdub> alf_, right, it was mostly for convenience
<kdub> because, MirBufferPackage is the analogue to ANativeWindowBuffer
<kdub> so, I see a distinction in that MirBufferPackage is something we have to define for the mesa eglNativeWindow
<kdub> and its also what we happen to be using internally from convenience
<alf_> kdub: Wasn't the point that MirBufferPackage would be a platform-independent container of buffer information interchange between server and client?
<alf_> kdub: the platform independent parts being the data[] and fd[] arrays
<alf_> kdub: which only the client/server platforms would know how to read
<kdub> alf_, I suppose, but I've always thought of MirBufferPackage as more of the mesa-analogue to ANativeWindowBuffer
 * kdub rethinks from the perspective that MirBufferPackage is the platform-agnostic type, and mesa eglnative types just happen to use it 
<kdub> I guess though that means that the mir_native_buffer.h header should be shipped in that new mesa package, but be used internally in the server code
<kdub> and... coming back to the original question :) I think serializing it for the purposes of the client code is okay for now
<kdub> with the caveat that, mir_surface_get_current_buffer() is a public mesa-specific function I guess
<alf_> kdub: I wonder if this could be changed to be a "platform operation" instead.
<kdub> yeah, that would be good
<kdub> and then getting the buffer for the mesa egl would just be a platform operation
#ubuntu-mir 2015-01-23
<anpok> duflu: hm since you just posted to s-p-p, are you looking at the failing GLibMainLoopTest?
<duflu> anpok: Nope. But it's everywhere. Maybe look at both bugs I think I logged some related steps to reproduce something like it in the older bug
<anpok> oh ok
<duflu> anpok: What is spp?
<duflu> Oh, a branch name
<duflu> Yeah it's affecting all the branches
<tvoss> #join ubuntu-ci-eng
<alan_g> duflu: we've a new CI blocker? Any progress?
<duflu> alan_g: anpok/alf are looking
 * alan_g likes that it is SEP
<alf_> duflu: alan_g: Yes, I am investigating, I am adding comments to the bug as I come across interesting observations to keep you in the loop
<duflu> alf_: Australia's long weekend starts in 10 minutes. You don't need to update me :)
<alan_g> duflu: have a great weekend ! See you next week.
<alf_> duflu: Have fun!
<anpok> alan_g: SEP?
<alan_g> Someone Else's Problem - it's Hitchiker
<alan_g> Mmm "16 bytes below stack pointer" sounds like normal RVO to me
<alf_> alan_g: anpok: I managed to recreate on krillin
<alan_g> My hero!
<anpok> hm yes there are stack related arm changes in the diff
<anpok> ah no thats something else
<alf_> anpok: alan_g: https://code.launchpad.net/~afrantzis/mir/fix-1413748/+merge/247403
<alf_> anpok: alan_g: Let's see what CI says
<attente_> hi, was the mir_connection_create_spec_for_menu_surface api removed?
#ubuntu-mir 2015-01-24
<mardy> hi! Would Mir run on a GMA 3150, specifically on a Lenovo Ideapad s10-3t?
<anpok_> mardy: yes
<mardy> anpok_: thanks! I definitely need to try it out, then!
#ubuntu-mir 2015-01-25
<c74d3> Is Mir typically used with X and an X shim? Can it be used without those?
<c74d3> (I know pretty much nothing about Mir, other than that it's an alternative to X and Wayland, and is apparently the only one of the three to offer release signatures or secure downloads.)
<anpok> c74d3: there is Xmir
<c74d3> Is Xmir required? I'd like to avoid X entirely.
<anpok> Xmir is only needed to run X applications inside
<anpok> gtk and qt have mir ports
<anpok> so not for those
<anpok> and sdl and glfw .. and many other libraires
<anpok> as shell there is currently only unity8 in a useable state for tablet and phone form factors
<c74d3> Oh, I didn't realize that those libraries could work directly with Mir. That sounds better than I expected.
<anpok> a pc desktop with unity8 is currently being worked on
<anpok> since mir is meant to provide window management bits, writing shells will be simple
<anpok> it is not feature complete for what a desktop needs
<anpok> but we are just adressing that, and with that we also add default implementations to the mir server library .. so writing your own shell will only require a few lines of code
<anpok> http://youtu.be/MXHulRlq10s thats already old
<c74d3> Thanks. What is a "shell" in this context? Is it like a window manager?
<anpok> window manager and more
<anpok> or depends on how those terms are defined ..
<c74d3> I have used Unity (before Mir existed), but I know little about it and wouldn't know what was Unity and what was GTK/X/etc.
<c74d3> I use X with i3 currently, so i3 is what I think of as a "window manager".
<anpok> ah tiling ..
<anpok> alan_g recently started a tiling window manager on mir
<c74d3> I would recognize floating window managers too, though I don't use i3's floating mode.
#ubuntu-mir 2016-01-25
<alan_g> anpok: you got back OK?
<anpok> alan_g: got back kind of late on sunday.. there was another problem in frankfurt..
<alan_g> :(
<anpok> and luggage is still not here
<alan_g> That's disappointing
<flux__> when will 0.19 land?
<flux__> oh there's also 0.18.2
<alan_g> flux__: hopefully this week
<flux__> yay :D
#ubuntu-mir 2016-01-27
<zzarr> hello!
<zzarr> is it possible to use chromebook/freon drivers the same way as android in ubuntu?
<ogra_> zzarr, no need to, the binaries in chromeOS use glibc, you should be able to use them directly
<zzarr> ogra_, so it's just user-land drivers required?
<zzarr> I have a arm based chromebook
<ogra_> well, probably kernel too, but neither of them would need a container like the android drivers on the phone do
<zzarr> okey
<ogra_> i have the first samsung arm crhomebook ... havent used it in gaes, but i was able to use the chromeOS hangouts and flash plugins from it under ubuntu .... so drivers should work the same
<ogra_> s/gaes/ages/
<ogra_> *me glares at his fingers
<zzarr> okey, I have a rk3288 based asus chromebook flip
<anpok_> ogra_: so they are somewhat drm/kms-like?
<zzarr> anpok_, I have read that they are
<ogra_> anpok_, no clue .... but they will surely run if you have the right kernel
<ogra_> and provide GLES if you have the necessary libs installed
<zzarr> ogra_, how did you install ubuntu on your arm chromebook?
<ogra_> does libhybris emulate/provide a kms like layer ?
<anpok_> ogra_: no, but there is hybris egl that offers the right entry points
<ogra_> zzarr, that was years ago ... someone provided some howto that i followed, back then you could switch the bootloader to developer mode and freely pick between a parallel installed ubuntu or  chromeos then
<ogra_> and the native ones would differ ?
<zzarr> ogra_, I have my chromebook in developer mode and I can boot from a sd card
<ogra_> right, i think thats what i did
<ogra_> then copy over the right libs and run ldconfig to have the linker find them ...
<zzarr> so, what kernel should I use in order for ubuntu to work?
<ogra_> the chromebook source ... and then a config merged from a default ubuntu one and the hardware specific options from the native chromebook config
<zzarr> ogra_, it sounds easy, but should I get the ubuntu touch tar ball or ubuntu-core?
<zzarr> ogra_, what I really want is to use mir/unity8 on my book
<ogra_> does that matter as long as apt works ? :)
<zzarr> ogra_, you're right
<ogra_> note that getting this merged kernel config right can be very time consuming
<ogra_> (takes a lot of trial and error and rebuilds)
<zzarr> ogra_, is there a guide?
<ogra_> not really, no
<ogra_> there are some scripts in the normal ubuntu kernel packages that do config checks for essential options an ubuntu kernel should have
<ogra_> i'd start from there
<zzarr> okey, thanks
<zzarr> ogra_, will I be able to run mir? (if I'm successful?)
<ogra_> zzarr, thats beyond my knowledge level ... the drivers should surely be capable to, but you might need kms support as anpok_ mentioned above .... and i'm not sure if they provide that or not (though chromeos might)
<ogra_> *might use it
<zzarr> so in other words if I get kms support I will be able too, other whys not
<anpok_> zzarr: we use kms to setup the outputs ... dmabuf fds to transport buffers between client and server.. if you use the mesa platform. So you need support for those specific parts..
<ogra_> i'd guess chromeOS uses that too though
<ogra_> (but just guessing here)
<zzarr> anpok_, I say okey, but it's a bit outside my knowledge
<zzarr> there is a arch linux version for my chromebook, could I use the kernel they provide?
<alan_g> zzarr: if you're not using the mesa from the ubuntu archive you'll also need to pick up some patches for Mir support. (I don't know the details.)
<zzarr> okey alan_g|lunch I'll try with the ubuntu one first
<alf> Saviq: bregma: https://code.launchpad.net/~afrantzis/jenkins-launchpad-plugin/triggered-builds/+merge/284117
<bregma> alf, nice, dunno if I'll get a chance to test it though...
<alf> bregma: np, I added a script in the description to run locally (if you have jenkins-launcphad-plugin config files set up)
<alf> bregma: actually, just give me a build url for libertine and I will paste the output and you can tell me if it is sane
<bregma> alf, you could try https://jenkins.canonical.com/libertine/view/Libertine%20CI/job/libertine-ci-update-mp/lastBuild/ --  that's the job that updates the MP for CI
<zzarr> ogra_, I have obtained the kernel configs from my chromebook, what command do I use in order to make the kernel ubuntu-ish
<zzarr> ?
<zzarr> I have also (git) cloned the chromebook kernel
<Saviq> hey folks, can you please comment on bug #1538659, i.e. what's the applicable dependency chain in this case?
<ubot5> bug 1538659 in unity8 (Ubuntu) "unity8-desktop-session-mir is missing mir-platform-* and mir-client-* dependencies" [Undecided,New] https://launchpad.net/bugs/1538659
#ubuntu-mir 2016-01-28
<duflu> Wow. Good anti-aliasing = almost readable text at 3px high
<zzarr> duflu, what? 3px awesome
<duflu> zzarr: Just admiring Google docs previews. And trying to read the docs in tiny print
<zzarr> duflu, nice, what device?
<duflu> zzarr: Desktop
<zzarr> duflu, mir?
<duflu> zzarr: No just Chrome...
<zzarr> duflu, okey
<duflu> But I shall try to make Mir as good in future
<zzarr> duflu, you're a programmer @ Canonical?
<duflu> zzarr: Yes :)
<zzarr> duflu, awesome
<zzarr> duflu, I have obtained the kernel config from my ASUS Chromebook Flip (ARM, RK3288)
<duflu> zzarr: Want to try to use Mir?
<zzarr> I know I some how need to extract the hardware parts in order to merge with the Ubuntu kernel and use Mir
<zzarr> duflu, you're right on the money
<zzarr> duflu, I can't think of a better OS for the computer then Ubuntu since it have a touch screen and can flip in to a tablet
<zzarr> I can boot it from a SD card
<duflu> zzarr: If the kernel supports DRI for your graphics chip then you can stick with the ChromeOS kernel (which helps a lot and often is more likely to work for some ARM devices than stock Ubuntu)
<duflu> zzarr: What's in /dev/dri?  or /sys/class/drm?
<zzarr> duflu, I'll have a look
<duflu> I am a ChromeOS fan too. Although Google has a habit of using very old kernels in ChromeOS and Android
<zzarr> in /dev/dri card0 card1 controlD64 renderD128 renderD129
<zzarr> duflu, yes, I know
<zzarr> duflu, other whys the Chromebook is awesome
<duflu> Yeah ChromeOS is pretty. But once you run Ubuntu on a Chromebook it's profoundly faster (for Intel anyway). Which means Google's got a lot of improving to do
<duflu> I recall they are building a new display system to solve that (and replace X11 that it still uses I hear)
<zzarr> in /sys/class/drm I find card0 card1 card1-eDP-1 card1-HDMI-A-1 controlD64 renderD128 renderD129 version
<duflu> Although there might be other reasons why their windowing system is slow
<zzarr> my Chromebook uses a windowing system called freon
<duflu> zzarr: OK, good news: Your ChromeOS kernel has a chance of just working with Mir (Ubuntu in a chroot installed via https://github.com/dnschneid/crouton). It's definitely worth a try. You sure that's ARM and not Intel?
<zzarr> duflu, I have a crouton chroot installed
<duflu> zzarr: You'll need to have it set up for fullscreen Ubuntu (not Ubuntu in the browser)
<zzarr> duflu, it's an ARM I'm sure about that
<duflu> Wow that Chromebook Flip looks like a great device
<zzarr> duflu, it is :-D
 * duflu adds it to the wishlist
<zzarr> quad core, 4GB RAM :-)
<duflu> zzarr: OK then. The next hurdle you might find (I remember hitting this now) is that Chromebooks often lack VT support in their kernels. Which is not a big deal but just Mir can't deal with that yet -- https://bugs.launchpad.net/mir/+bug/1169020
<ubot5> Launchpad bug 1169020 in Mir "[regression] Mir gives up too easily - std::exception::what: Failed to find the current VT" [Medium,Triaged]
<duflu> So that will stop you unless you have the Mir code I suspect
<zzarr> I have the kernel config for the chromebook, can I add a console to it that way?
<duflu> Not sure. Not very likely how nailed down ChromeOS is. You can only change what Google lets you change
<zzarr> but if I have the source code (which I have) and the config, can't I just configure and build a new kernel?
<zzarr> I thought I might be able to build a kernel with this tutorial https://github.com/dnschneid/crouton/wiki/Build-chrome-os-kernel-and-kernel-modules
<duflu> zzarr: If you're in a chroot then you need a kernel that doesn't break ChromeOS. So I would recommend keeping the existing one and we should fix Mir to suit
<zzarr> duflu, yea, but I thougt I should build a new kernel and run a stand alone environment from a SD card
<duflu> zzarr: Sounds like the Ubuntu kernel lacks support for the chipset then?
<duflu> Usually does for newish ARM devices
<zzarr> yes, but I can configure a Chromebook kernel and build it
<zzarr> so I install a custom Chromebook kernel on the SD card along with Ubuntu
<zzarr> that way I should get the best of both worlds
<duflu> True
<duflu> zzarr: I would personally recommend sticking with the chroot though. Fixing Mir theoretically is easier than building your own OS with custom kernel :)
<zzarr> duflu, I have that as a second way out then :-)
<zzarr> it's more fun to try it from scratch
<duflu> It's good you think that
<duflu> Because someone has to be adventurous and try
<zzarr> I have built linux kernels before (for UltraSparc)
<zzarr> duflu, exactly, that's the way we move forward
<zzarr> duflu, I'm a programmer too you see, so I know about the fact that some things are hard to do
<zzarr> duflu, what line or lines define the console in the kernel config?
<duflu> zzarr: Sorry, don't know
<zzarr> okey, I'll stfg it
<duflu> zzarr: Thanks for reminding me about the VT bug though. If I remember and get time I'll try to fix it before the bug reaches 1 year old
<zzarr> duflu, no problem :-)
<duflu> Actually the bug was from 2013, but I only associated it with chromebooks mid last year
<zzarr> duflu, okey
<duflu> If Xorg in an Ubuntu chroot can start, Mir has no excuse for failing to start...
<duflu> We just have unnecessary error checking. And some errors are not really errors.
<zzarr> duflu, that explains it
<zzarr> duflu, but I don't get any 3D/OpelGLES support in the chroot (since ChromeOS uses freon)
<zzarr> duflu, I though of making a freon to mir wrapper (I don't know if it's a good idea or not a time a go)
<zzarr> duflu, I guess it would be a huge project even though both mir and freon is based of some parts of wayland
<zzarr> not knowing if they are the same parts or not
<duflu> zzarr: I'm not sure about Freon, but Mir and Wayland are entirely unrelated other than both (only just recently) use the same input library libinput.
<duflu> I thought Freon was also completely separate
<zzarr> duflu, okey, so mir has nothing to do with wayland.... I see, I think that freon has thought
<duflu> zzarr: You remind me now that Mir (when using the mesa-kms driver) also requires a device-specific driver in the Ubuntu chroot under /usr/lib/x86_64-linux-gnu/dri/. As Ubuntu doesn't have that for your ARM chip, it will be software-rendered even when working properly
<duflu> Which is not good. It won't run well at all
<zzarr> duflu, that's not nice
<duflu> zzarr: I know. It's because we use the Mesa implementation of OpenGL, which is portable but requires a DRI module specific to Mesa and the chipset to be accelerated
<duflu> So hardware-accelerated Mir is limited to those covered by /usr/lib/x86_64-linux-gnu/dri/*
<duflu> Minus *sw* :)
<zzarr> duflu, so I will not be able to get an accelerated mir without that driver what ever kernel config I manage to create?
<duflu> zzarr: I suspect that's right
<zzarr> duflu, could I use an android-lxc for mir?
<duflu> Unless you can find a custom libGLESv2 that works for your chipset
<duflu> zzarr: For ARM hardware you might find usable drivers from Android, yes. But that's a maybe.
<duflu> But Mir (via libhybris) only knows how to do that within an Android filesystem.... I think?
<zzarr> duflu, I know for a fact that there are Android devices based off of RK3288
<zzarr> duflu, I suspect that you're right
<duflu> I should clarify that using any custom libGLESv2 (e.g. future Nvidia support!) also requires a custom Mir driver to be written to bootstrap it for mode setting and buffer management
<duflu> Hmm actually that's not quite right. We might be able to mix and match. But no matter because such a /usable/ libGLESv2 for RK3288 may not exist.
<duflu> Or likely we're missing other glue
<zzarr> duflu, okey, is it possible somehow to compile a libGLESv2 for RK3288 myself?
<zzarr> duflu, or do I need deep knowledge about how the RK3288 chip (Mali764) is built?
<duflu> zzarr: You might need source code, but actually the ABI for libGLESv2 is well known. So you might be able to find and just copy a binary too. Although that assumes it's no linking to something awkward (like Android's bionic)
<zzarr> duflu, okey
<faenil> hello people
<core_t> hi
<faenil> After 1 day of debugging we found out the vivid+overlayppa LAPTOP setup I have here didn't boot to unity8
<faenil> because it was missing
<faenil> EGL_PLATFORM=mir
<faenil> but it seems that env var should not even be needed
<faenil> I'm here to report the issue and ask for advice :)
<core_t> doesn't sound like a mir problem, try with unity people #ubuntu-unity
<core_t> j/k :P
<faenil> LOL
<faenil> I was about to throw a digital fist over :D
<core_t> :D
<alan_g> faenil: I've never used EGL_PLATFORM=mir - I wonder what detects it.
<faenil> alan_g: you mean who needs it?
<alan_g> ack
<faenil> without that, libEGL turns to libX11-xcb, and calls GetXcbConnection -> segfault
<alan_g> alf: any ideas? ^^
<alan_g> faenil: is $DISPLAY set? Unsetting that might discourage attempting an X connection
<faenil> alan_g: we tried with DISPLAY= cmd
<faenil> no diff
 * alan_g suspected as much
<alan_g> faenil: I imagine you must have more than a vanilla vivid+overlay setup to get unity8 desktop. What else did you install?
<faenil> just unity8-desktop-session-mir
<faenil> then discovered that didn't pull in mir platform and client packages
<faenil> so I installed 2-3 packages
<faenil> mesa-kms, mesa-x, evdev4...
<faenil> and that's it
<alan_g> mir-graphics-drivers-desktop?
<alan_g> That *ought* to pull in all the needed stuff in one go
 * alan_g grabs v+o laptop
<faenil> alan_g: yep, already reported a bug where that was suggested
<faenil> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1538659
<ubot5> Launchpad bug 1538659 in unity8 (Ubuntu) "unity8-desktop-session-mir is missing mir-platform-* and mir-client-* dependencies" [Undecided,New]
<faenil> oh, it was you :P
<alan_g> :^)
<faenil> so, yeah, I don't know what else could be missing
<alan_g> Just updating & installing - I'll see what happens here and if I can diagnose
<faenil> my laptop is running overlayppa as well, and I can boot unity8 without hacks
<faenil> so I'm more inclined to think we're missing a pkg
<alan_g> Sorry, what's the difference between "my laptop is running overlayppa" and "vivid+overlayppa LAPTOP setup"?
<alan_g> I've probably other packages installed, but with apt-get install unity8-desktop-session-mir  mir-graphics-drivers-desktop I can start a guest session with unity8. (But all I get is a black screen with a cursor)
<faenil> alan_g: the buggy one is not my laptop
<faenil> it's a laptop I setup from scratch :)
<alan_g> Ah, that's because USC is running, but nothing is connected to it.
<faenil> alan_g: yes that's the issue, unity8 dies
<faenil> good, you can reproduce it ;)
<alan_g> \o/
<faenil> that's the issue :)
<faenil> if you add EGL_PLATFORM=mir somewhere so that unity8 picks it up
<faenil> it will boot to unity8 :)
<alf> alan_g: I wonder if changes to the way we export symbols have made it impossible for mesa to detect that mir is running
 * alan_g wonders where USC publishes the endpoint. There's no /tmp/mir_socket
<alf> alan_g: Perhaps USC doesn't publish an endpoint, the connection fd is just passed to sessions?
 * alf has only faint memories of such facts, but can't be sure
<alan_g> My memory is that robert_a couldn't make that work at first, and so publishing the endpoint got "embedded"
<anpok> thought it was moved to /run/mir_socket .. or something like that
<alan_g> You're thinking of $XDG_RUNTIME_DIR/mir_socket - but root tends not to have $XDG_RUNTIME_DIR set
<kdub> isnt it /var/run/mir_socket?
<anpok> http://bazaar.launchpad.net/~lightdm-team/lightdm/trunk/view/head:/src/unity-system-compositor.c#L467
<anpok> use the source lukes
<alan_g> it's /run/lightdm-mir-0
<anpok> on desktop?
<alan_g> OK, I can crash a mir client. I'll dig into it after lunch
<faenil> alan_g|lunch: yeah it crashes on GetXcbConnection
<faenil> (most likely, or at least that was what we found out yesterday)
<faenil> libEGL -> libX11-xcb -> GetXcbConnection -> segfault
<alf> Saviq: Hi! I am trying to setup sbuild for Mir, duplicating what you have done for unity8. For the prepare-1-sbuild job how do I get the key files to pass as parameters? Can I just do 'sbuild-update --keygen' locally and upload, or do I need to do something different?
<Saviq> alf, yeah, that's what I did
<Saviq> should have documented that
<alf> Saviq: btw, you have done a great job with all the prepare and build scripts. I am have I can just copy them with small changes and they work :)
<alf> Saviq: s/I am have/I am happy/
<Saviq> alf, changes!? :P
<Saviq> alf, would be interested to know what you needed :)
<alf> Saviq: not additions, just skipping some parts because I don't yet have some plugins currently installed (e.g. conditional build step, set build name)
<Saviq> alf, ah those
<Saviq> alf, I'm not totally sure about the conditional build steps, the plan was to skip heavy steps if they've been done on a machine already
<Saviq> so you can just run the prepare job and let it figure stuff out
<Saviq> seems to be working fine
<alan_g> faenil: can you confirm whether apt-get remove mir-client-platform-mesa2 fixes the problem for you? (It works for me)
 * alan_g thinks that there's a packaging "incantation" missing somewhere
<faenil> alan_g: I hope it's not that, because that's what I did for my own laptop as well a week ago, but I think I checked that and mesa pkg was not installed in the setup I made from scratch
<faenil> let's see...
<faenil> alan_g: and I agree about the pkg incantation, that's my opinion as well
<faenil> alan_g: crap, it's installed...
<faenil> I spent two days debugging an issue I fixed on my own laptop by myself a week ago.
 * faenil headdesks
<faenil> greyback: ^
<faenil> (ok, it was 2 weeks ago)
<greyback> faenil: you're joking?!
<faenil> greyback: I wish I were
<greyback> aiii
<greyback> still,  that identifies a mir packaging/so lib issue
<faenil> yeah, let's see if I reported a bug first time got my own laptop booting
 * faenil reads backlog from good old times
<faenil> [13.01.16][17:59]<      faenil> | anpok: I've got mesa.so.2 and mesa.so.3
<faenil> [13.01.16][18:01]<       anpok> | try to get rid of mesa.so.2
<faenil> greyback: ^ he saved me last time :D
<faenil> [13.01.16][17:58]<       anpok> | crash in XGetXcbConnection sound like mesa loads an older mir client driver and tries to verify the EGL Display it got from the mir server
<faenil> boom, that was the winning hint
<faenil> dednick: ^ if you're interested :)
<dednick> heh
<dednick> proable need a Replaces: mesa2 in the package control for mesa3
<faenil> alan_g: http://bazaar.launchpad.net/~unity8-desktop-session-team/unity8-desktop-session/trunk/view/head:/debian/control#L18
<dednick> i have about 10 different versions of mir on my laptop. sound probably sort that out!
<faenil> so, desktop session is depending mir-graphics-drivers-desktop already
<alan_g> dednick: I think "Breaks" is probably right, but I disavow all knowledge of those rules
<dednick> yeah. i have no idea which one it is :)
<alan_g> faenil: did you raise a bug? I can poke RAOF about adding the right incantation. (I trust his advice on these.)
<faenil> alan_g: ok, the problem with session-mir is that overlay PPA has a version from March 2015
<faenil> which didn't pull in drivers
<alan_g> That needs an update then.
<faenil> sil2100: ^
<faenil> now, who pulled in mesa2 and mesa3 at the same time is another mistery that needs solving
<faenil> s/who/what
<sil2100> faenil: hmmm, could you guys get a bug filled for that?
<faenil> sil2100: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1538659
<ubot5> Launchpad bug 1538659 in unity8 (Ubuntu) "unity8-desktop-session-mir is missing mir-platform-* and mir-client-* dependencies" [Undecided,New]
<faenil> I will rename the title now
<sil2100> faenil: thanks, let me look at it shortly
<faenil> sil2100: the PPA doesn't have that pkg, so it's coming from vivid archive
<faenil> sil2100: title updated
<faenil> alan_g: I'm not sure what I should report a bug about
<faenil> that somehow I end up with mesa2 and mesa3 together after installing vivid and session-mir? :D
<alan_g> Well, that would be fine except that recent libmirclients die if mesa2 is installed.
<alan_g> There ought to be some way to tell dpkg to sort that out.
<alan_g> But if you've not logged a bug already I can create on
<alan_g> *one
<kdub> what's that trick for using bzr and meld? is it just "bzr diff -r lp:mir --using meld" ?
<faenil> alan_g: yeah I just don't know who pulls both mesa2 and mesa3 in
<faenil> (haven't filed a bug yet)
<alan_g> faenil: mesa2 is probably from a seed. mir-graphics-drivers-desktop?
<alan_g> Or maybe its mesa?
<faenil> alan_g: don't know
<faenil> alan_g: https://bugs.launchpad.net/mir/+bug/1539184
<ubot5> Launchpad bug 1539184 in Mir "Unity8 on Vivid doesn't boot, due to mesa2 and mesa3 client platforms being installed at the same time" [Undecided,New]
<faenil> I left it vague
<faenil> at least we won't forget about it now ;)
<alan_g> faenil: thanks, I'll update
<faenil> cheers
#ubuntu-mir 2016-01-29
<duflu> Hmm, that new libinput released 45min ago in xenial looks interesting. I wonder what it fixed
<camako> RAOF
<RAOF> Yo!
<camako> around?
<camako> oh cool.. Hey I'm trying to publish mir 0.19
<camako> it needs a core dev ack for packaging changes
<RAOF> Throw me the link!
<camako> RAOF, could you lend me a hand?
<camako> RAOF, this is the silo : https://requests.ci-train.ubuntu.com/#/ticket/901
<camako> not sure where the link is
<RAOF> Bah.
<RAOF> Hm. I think you actually need an archive admin, because we've introduced new packages (and they'll need to be promoted to main)
<camako> RAOF, umm this link has "ack packagin changes" option... https://ci-train.ubuntu.com/job/ubuntu-landing-010-2-publish/build
<RAOF> Oh, wow! Where did you find that!
<camako> :-)
<RAOF> We shouldn't be retrospectively changing changelog entries, but the changes are purely formatting, so aren't terrible.
<camako> I don't know if whoever is clicking needs to have admin/core-dev priviliges though
<RAOF> Well, I've got those privileges.
<RAOF> (But shouldn't use the AA privileges âº)
<RAOF> Well, I've acked the packaging changes.
<camako> RAOF, where did you do that?
<RAOF> I pressed that button :)
<camako> lol makes sense
<camako> RAOF, did you press 'build' too? Make sure you're logged in first.
<RAOF> I did press build.
<RAOF> And then I pressed build again, and it did something else.
<RAOF> BONZA!
<camako> ah ok I see it
<camako> yeap uploading
<camako> ... aaand success! thanks RAOF
<RAOF> Win!
<zzarr> hello duflu :-D
<core_t> !seen 0.19
<ubot5> I have no seen command
<core_t> :'(
<zzarr> core_t, what should that command have done?
<core_t> zzarr, release mir 0.19
<core_t> :D
<core_t> hm... Version 0.19.0+16.04.20160128-0ubuntu1 uploaded 20 hours ago
<zzarr> core_t, I wounder what version of mir I use
<zzarr> (on my MX4)
<core_t> 0.18.1
<core_t> probably
<core_t> if you are on stable
<duflu> zzarr: Release in progress, not an official update yet. But it has reached proposed: https://launchpad.net/ubuntu/+source/mir
<duflu> core_t ^
<core_t> thanks duflu :D
<duflu> Oh dear. That changelog for 0.19.0 is messy and incomplete. Sorry.
<zzarr> core_t, I am on stable
<zzarr> duflu, do you have time to take a peak at this link? http://malideveloper.arm.com/resources/drivers/arm-mali-midgard-gpu-user-space-drivers/
<duflu> zzarr: Interesting but I'll have to skip it till next week
<zzarr> duflu, I'm still thinking about if it is/how it could be possible to get Mir on my Chromebook
<zzarr> duflu, okey, no problem, I'm very grateful that you have taken the time you have and that you help me :-D
<zzarr> duflu, I think I forgot to tell yesterday, but I do like Mir :-D
<duflu> zzarr: Good. We aim to make it likeable.
<duflu> Although have some steps to go still.
<zzarr> duflu, yes :-)
<zzarr> duflu, it's a bit sad that my MX4 can't handle MHL.... but there's nothing to do about it I guess
<Saviq> guys, qtmir and qtmir-gles doesn't seem to build in proposed http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#mir
<zzarr> is there a guesstimation when Aethercast will be installable/useful?
<anpok_> hm soon-ish
<zzarr> like OTA-10?
<zzarr> or will it be an app I install?
<anpok_> i assume it will be part of the image.. but not sure which OTA.. the frequency of the OTA seemed to have increased these weeks,,
<zzarr> anpok_, yes you're right
<anpok_> zzarr: you can watch the launchpad bzr repository and look for aethercast test silos .. not sure if there is one currently set up
<zzarr> okey, anpok_, thanks
<greyback_> hey, I just apt-get updated to mir0.19, and see that I still have old version of mir-client-platform-mesa and  mir-platform-input-evdev
<anpok_> hm how did you update
<greyback_> apt-get update
<greyback_> distupgrade
<anpok_> so you did not install the kms7 evdev4 driver packages?
<anpok_> do you have mir-graphics-drivers-desktop/android installed?
<greyback_> I'm missing mir-graphics-drivers-desktop
<anpok_> ok,
<anpok_> then it has no package to upgrade that depends on the new packages..
<greyback_> yeah, that pulls the newer drivers in
<greyback_> I wasn't aware of that package existing
<greyback_> cool, thanks
<anpok_> maybe we should have a recommends for those?
<alan_g> anpok_: AIUI that would end up pulling the mesa stack onto the phone in some scenarios
<anpok_> hm.. then this will our "did you try turning it off and on again"
<anpok_> +be
<alan_g> We ought to be able to do better, but debian packaging incantations are not my thing#
<greyback_> most likely, best solution when the time comes is for ubuntu-desktop to depend on mir-graphics-drivers-desktop
<greyback_> assuming we will distinguish touch and destop in future...
 * alan_g thinks "desktop" is a bad name - it really means mesa-kms && mesa-X11, if we ever have another "desktop" stack, or a non-desktop "mesa" (dragonboard anyone?) it gets confusing
<anpok_> yes.. as soon as we get proper egl backend loading in mesa pulling both drivers might not be such a big issue
<alan_g> I'm sure we discussed that around March '15 - it is almost a year later
<anpok_> yip
<zzarr> I long for Aethercast :-)
<alf> Saviq: Hi! Is ccache working for you in unity8 jenkins?
<alf> Saviq: In Mir (using your scripts) it gets called when building, but it seems to have no positive effect. Could it be that it doesn't recognize the files because of different file paths?
<camako> Saviq, @qtmir build failure, we build this so many times before publishing. Why is it failing now? was there another landing?
 * camako checks
<Saviq> camako, britney behaviour change, qtmir's autopkgtest is wrong in that scenario as it's trying to build old qtmir against new mir :/
<camako> Saviq, ok so I talk to ci guys?
<Saviq> camako, #ubuntu-devel rather, infinity's been helping, but it looks like we might need to force it through unless they've a way to re-run with qtmir source from proposed
<Saviq> /source/d
<camako> Saviq, ok thanks for chasing
<Saviq> camako, I'm going into flight mode, so you might want to follow up on #ubuntu-devel
<camako> Saviq, thanks
<kdub> i've somewhat convinced myself that
<kdub> we need a MirBufferContext for the new semantics
<kdub> instead of mincing the MirBufferStream to do the new and old jobs
<kdub> internally, its a mess to mince it thusly :)
<kdub> a manually controlled api isnt really a stream
<MoPac> Hello -- On login to a Unity8-desktop-session-mir session (liveUSB of latest/updated 16.04), I'm getting a segfault in libmirclient.so.9 (system crash, session never loads, have to restart lightdm). I wanted to raise it here before I reported it as a bug in case it's not really meant to work on a liveUSB like that...
<MoPac> The dmesg line is "system-crash-no[17587]: segfault at 0 ip 00007f7ed7cc500f sp 00007ffc17d965b0 error 4 in libmirclient.so.9[7f7ed7c72000+8c000]"
<alan_g> MoPac: does this help? https://bugs.launchpad.net/mir/+bug/1526658/comments/17
<ubot5> Launchpad bug 1526658 in mir (Ubuntu) "Mir clients (including Unity8 itself) crash in XGetXCBConnection() if multiple versions of mir-client-platform-mesa are installed." [High,Triaged]
<MoPac> alan_g: "unable to locate" either of those packages
<MoPac> But I did have a mesa3 and mesa4 -- removing those and retrying
<alan_g> MoPac: Try removing all but the latest. You'll need the latest of them
<MoPac> I'm trying with just -dev ... I'll then try with just 4
#ubuntu-mir 2017-01-23
<tsdgeos> i'm not sure if "junior job" is actually asking for an open position
<tsdgeos> i'd say it's probably more of a task easy for a newbie to do
<tsdgeos> at least that's the term we use in KDE for those tasks
<alan_g> Oh. Like s/job/task/
#ubuntu-mir 2017-01-24
<duflu> Saviq: I'm off in a minute. But could you do me a favor and look at promoting the 'performance' tag, and any others that are well-used?
<duflu> Similarly demoting unused ones
<duflu> In Unity8, not Mir
<duflu> Please, thanks bye
<kuchtam> Hi all,
<kuchtam> How can I make first commit to Mir ?
<kuchtam> What I do till now:
<kuchtam> bzr branch lp:mir
<kuchtam> Fix with small mistake in doc.
<kuchtam> and now bzr commit ?
<anpok_> kuchtam: then push to a new branch  lp:~your-user-name/mir/some-descriptive-name
<anpok_> kuchtam: then go to that branch on launchpad and propose for merging..
<kuchtam> Ok Thank you I will try.
<bregma> kuchtam, there is an unpublished (work in progress) doc on how changes get merged to lp:mir: http://people.canonical.com/~stephenwebb/mir-docs/contributing/continuous-integration.html
<bregma> just to give you an idea
<bschaefer> bzr push lp:~your-user-name/mir/some-descriptive-name
<kuchtam> Thank you
<bschaefer> bregma, did you make those fancy flow charts?
<bregma> bschaefer, I did
<bregma> plantuml
<bschaefer> those sure are fancy
<bschaefer> o nice
<bregma> click on "View page source" to see the raw source
<bregma> I'm-a trying to make gooder Mir docs, using SPinx just like the Linux kernel does
<bregma> first Mir, then Libertine
<bregma> then, I dunno, doc *all* the things
<bregma> http://people.canonical.com/~stephenwebb/mir-docs/contributing/documentation/intro.html#building-the-documentation
<bschaefer> haha, they do read betting then a large read me though
<bregma> I have found, over the decades, that good documentation is one of the biggest weaknesses of free software
<bregma> "read the code" they said
<bregma> feh
<bschaefer> but the code does what it says!
 * bschaefer would have to agree in my small amount of years
<RAOF> In much the same way as quantum physics is all you need to understand to understand the American political system.
<bschaefer> hahaha
 * bschaefer sadfaces
<RAOF> (It's true! It's just unhelpful)
<bregma> trump may or may not have won, we will not know until someone opens the box
 * bschaefer goes no where near that box
<bregma> yeah, be careful, whatever is inside may scratch you viciously
<bregma> unless its dead
<bschaefer> haha
 * bschaefer loves with documentation links from comments are dead
#ubuntu-mir 2017-01-25
<duflu> That's unusual. A Jenkins task appeared on a community-contributed branch. But only after the branch got approved. Is that new?
<duflu> It's a pleasant surprise
<kdub> camako, with https://code.launchpad.net/~kdub/mir/no-bufferusage-in-rs/+merge/314699, might be good to clarify some plans/comments
<kdub> I guess the point that's come up is the mirclient and platform-plugins point and the abis involved
<kdub> with loading those plugins
<kdub> like, the plugins are c++ abi, and they have access to the interfaces that make up the opaque mir types presented in the client api/abi
<camako> kdub, ok I'll take a look today
<kdub> camako, thanks, no rush of course
#ubuntu-mir 2017-01-26
<alan_g> greyback: It's an API break, but I think I can avoid breaking ABI: https://code.launchpad.net/~alan-griffiths/miral/rename-place_new_surface-to-place_new_window/+merge/315665
<greyback> alan_g: I need to ask, does the window manager policy have influence over subsurfaces/individual buffer streams?
<greyback> or is that not in the current scope of the api?
<greyback> I just want to be clear on what a "window" definitely is
<alan_g> no (at least not yet)
<alan_g> bufferstreams are not windows (they are closer to the original intent of "surface" before feature creep
<greyback> alan_g: understood
<alan_g> FWIW that's an area where redesign is happening as a result of the vulkan POC
<greyback> oh really? Good to know
<alan_g> whether it will affect window management...
<anpok> greyback: should not have influence..
