#ubuntu-mir 2013-06-03
<RAOF> Argh. My right ear is blocked.
<RAOF> This is surprisingly distracting.
<alan_g> alf_: FYI http://isocpp.org/blog/2013/05/gcc-4.8.1-released-c11-feature-complete
<alf_> alan_g: nice!
<hikiko> http://i.imgur.com/fjdJOzr.jpg <- display
<hikiko> sorry sdl display*
<kdub_> cool hikiko
<hikiko> :)
<alan_g> hikiko: nice. I want one. ;)
<hikiko> :D
<hikiko> I'll start the gbm integration tomorrow :)
<hikiko> now my day is over :) have a nice evening!!
<racarr> Morning
<kdub_> alan_g, with the suggestion for the swapper-swapper branch... were you renaming 'end_responsibility' to 'release_buffers_to' ?
<alan_g> kdub_: that was the suggestion. But the problem I saw was the mismatch between code and comments.
<kdub_> yeah... i think it can have a better interface though while we're looking at it though too :)
<alf_> status: Wrapping up basic lttng support, investigating communications timings/overhead
<kdub_> status, trying to wrap up SwapperSwitcher, got lost in the weeds of reworking our situation with ms/msh::Surface a bit
<kdub_> might need to discuss how we keep synchronized state about the surface stack more widely :)
<alan_g> status: trying to reverse engineer why egl (probably) does something strange with composition bypass attempt.
<kdub_> :/
<kdub_> maybe i can write a 'storm in a teacup' to see if i can find any problems with that use mode
<kdub_> i'm going to open up a can of worms here but.... all of our state concerning surfaces is migrating into the ms::Surface class
<kdub_> which might be fine :) but I just want to make sure its an active decision about the surface stack state
<kdub_> just to open it up to a larger base of thinkers :)
<racarr> kdub_: I think that's correct.
<racarr> well
<racarr> I dunno, I'm not sure, I've grown convinced that all the state we have now
<kdub_> to be more specific, we have the z-order in ms::SurfaceStack, but the position/alpha/etc are in ms::Surface
<racarr> is central to surfaces (except perhap, attributes/types, still unconvinced there)
<kdub_> and then we have 'shell state' in msh::Surface
<racarr> but have the thought that some state
<racarr> i.e. say...
<racarr> previous size
<racarr> never belongs on ms::Surface
<kdub_> racarr, yeah, i'd agree about that :)
<kdub_> racarr, is the different state in msh/ms supposed to be like 'ms::Surface' state is state the compositor cares about, but 'msh::Surface' state is stuff we have to track, but the compositor doesn't really care about?
<racarr> kdub_: Whoops sorry I only answered you in my head XD
<racarr> kdub_: Yeah I think, ms::Surface should be
<racarr> the minimal set of information the
<racarr> compositor and input stack have to know about
<racarr> and msh::Surface (well now, I'm still not quite convinced this is correct)
<racarr> holds extra state that we use to determine that
<racarr> kdub_: It's all spelled out very clearly in RoughArchitecture.png
<racarr> :p
<kdub_> haha
<racarr> kdub_: I think part of the problem as it stands is
<racarr> msh::Surface is a resource managing class as well
<racarr> as this like
<racarr> state proxy
<racarr> so its unclear
<racarr> Not only that it's a resource managing class
<racarr> that manages
<racarr> a resource managing class
<racarr> XD
<racarr> I think Alan thinks that perhaps the msh::Surface state
<kdub_> uh oh ;-)
<racarr> should be assosciation rather than attribute
<racarr> but I don't fully understand the implications in my head
<racarr> sounds nice :p
<racarr> well, perhaps its trying to get closer to the idea that the shell surface management acts as a policy proxy to the surface stack for the frontend
<racarr> a in RoughArchitecture.png :p
<racarr> but I don't know what the object structure would look like
<kdub_> racarr, i think that we have to rethink our 'views' (MVC connotation) a bit
<racarr> ?
<kdub_> confusing, sorry :)
<racarr> no I sort of get the idea im just not sure how we should rethink them
<kdub_> not rethink
<kdub_> refine
<kdub_> i am beginning to see 3 objects we have to provide info to
<kdub_> the compositor, input, and the shell
<racarr> the shell is slightly different too because it's two way right
<racarr> controller-view or something XD
<kdub_> right
<kdub_> i guess we're just globbing the information through ms::Surface
<kgunn> racarr & kdub...just sharing, ogra delivered "container flip"
<kgunn> http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/current/
<kgunn> ogra curious, so phablet-dev-boot -c would pull down container flip as part of the code base right ?
<ogra> follow https://wiki.ubuntu.com/Touch/Install#Manual_Installation (might need a hard reset after the first flash, it tries to boot into the non existing second part)
<ogra> nope
<racarr> Nifty :D
<kgunn> kdub_ & racarr caveat....no Nexus7...but i think that only hurts me
<ogra> these images will only get integrated with the phablet tools once we have them safely working
<racarr> kgunn: I want to use my nexus 7 :p
<kgunn> :)
<ogra> they boot, but apps start with white screen (platform-api most likely) and we need to fgure out the device access avcross the rootfses
<ogra> we found a ton if bugs today that were partially already fixed, tomorrows image should look a bit better
<kgunn> cool....maybe we'll let it breath a bit before biting into it
<ogra> they are ready to get an impression :) not for daily usage though ... but at least you dont need to chroot into ubuntu :)
<kdub_> oh i almost forgot about the container flip :)
<kdub_> i'll give it a go, very cool
<robert_ancell> RAOF, you are opposed to having a debconf question in the lightdm packaging?
<racarr> window_handles.erase(it);                                                                           window_handle = it->second;
<racarr> pure genius
<racarr> ;)
<robert_ancell> iteration fun
<olli> robert_ancell, RAOF, kgunn, bregma - once more, that was a good meeting, my comfort zone just got increased by large
<olli> now we just need to make it happen ;)
<robert_ancell> olli, details... :)
<olli> .oO(details...)
<olli> exactly
 * kdub_ has heard the devil's in the details
<racarr> sigh. I have an acceptance test in client-focus-notifications that hangs indefinitely
<racarr> in valgrind
<racarr> unless I turn on logging
<racarr> in which case it completes almost immediately
<racarr> *grin*
<racarr> Wrapping up the day soon. Made good progress on platform API, not as much moving around as I thought. Finished mirclient (except for some last bits of hybris wiring), started on mirserver, should start review tomorrow
<racarr> something going on in client-focus-notifications that I don't understand and am not going to today :p
<racarr> fix-input-registrar-locking should be ready to land
<kdub_> racarr, what last bits of hybris wiring?
<racarr> kdub_: Err, just setting up the platform API bits so we can load  parts from hybris (i.e. sensors) and parts not from hybris (i.e. mir) and build all the appropriate versions
<racarr> with the minimal amount of code duplication
<racarr> XD
<racarr> mostly missing bits in cmake but, there is this question of like...
<racarr> is there platform_api.so that can intelligently load , mirserver, mirclient, or for now hybris
<racarr> or is there platform_api_mirserver/mirclient.so and qtubuntu has the intelligent loading
<racarr> or is there platform_api_server/client and qtubuntu server/client (even if Qtubuntu is the same codebase)
<racarr> so ricmm wanted to sync up with loic on that
<racarr> and in the mean time I am doing the mirclient/mirserver implementations
#ubuntu-mir 2013-06-04
<RAOF> robert_ancell: Not really opposed, but I think it should be low priority (and so not shown by default on install). If someone adds the PPA, they probably want the system compository.
<thomi> hmm, so in the last three days something changed in mir, and now I once again get file handle leaks, which prevent the mir-stress tests from running.
<thomi> robert_ancell: got a second?
<robert_ancell> thomi, sure
<thomi> robert_ancell: I think that, even in it's uncompleted state, mir-stress is useful enough to be run on merge proposals. To achieve this, I need to get it merged into trunk. Do you see any issues with me merging it into lp:mir and continuing to work on it from there? (i.e.- after it's run on all MPs?)
<robert_ancell> thomi, as long as it works fine it should be good to start merging
<thomi> well, As of today, it would fail MPs, but that's because mir leaks FDs again
<thomi> which seems to be a recurring problem
<thomi> so it might cause you some grief, but in a good way :)
<thomi> robert_ancell: the other thing is that from next Monday (the 10th), I'm on holiday for 2 weeks, so perhps it's better to wait until I get back.. or maybe we pick a strategy so even if it causes problems it won't be too disruptive
 * thomi shrugs
<robert_ancell> thomi, worth proposing now, so it can get reviewed early
<thomi> ok
<robert_ancell> thomi, is lp:lightdm-trunk-packaging supposed to contain all the lightdm project files? I need to add a new build-dep, not sure what the correct way to update this branch is
<robert_ancell> I mean lp:~lightdm-team/lightdm/trunk-packaging
<thomi> that sounds like the "old" way distro used to do packaging.
<thomi> I'll investigate, one sec
<thomi> robert_ancell: yeah, in time we should probably regenerate that, but I believe you should be abel to update the build-dep in that branch fine
<thomi> just ignore all the other files :)
<robert_ancell> thomi, ok, cheers
<robert_ancell> I just push directly right? i.e. no MP
<thomi> robert_ancell: yep
<robert_ancell> thomi, and I don't need to update debian/changelog?
<thomi> robert_ancell: ideally we'd have inline packaging, but I understand why that's not an option here
<thomi> robert_ancell: nope, shouldn't need to
<robert_ancell> yeah, I've been trying to think of a better method, but ultimately there will be some Ubuntu specific things that would have to diverge
<thomi> yeah
<thomi> you could perhaps still make upstream release tarballs without the debian/ directory?
<robert_ancell> I could (and would)
<robert_ancell> RAOF, do you know of any other method to communicate the Mir socket to clients other than via a MIR_SOCKET env variable?
<robert_ancell> I guess in theory we could give the socket the shell and it could pass it on via some clever method but it seems it would make things overly difficult
<RAOF> I'm still partial to âthe shell opens a mir connection before spawning the client, and when it is spawned fd 3 is ready to connect to Mirâ
<RAOF> Failing that, it's an environment variable, or possibly just $RUN/user/mir/socket
<robert_ancell> RAOF, is there a potential case of having more than one Mir server to connect to?
<RAOF> I can't think of any reason why a user would want more than one Mir session active at one time.
<robert_ancell> RAOF, the problem with option 1, is you can't run an app from a terminal ever (unless we make some clever opt-in API to the shell)
<robert_ancell> I'm working on LightDM support for Mir sessions, but given they only exist in theory it's kind of hard to write test cases for :)
<RAOF> Eh, we write âmir-runâ which is a trivial wrapper around a shell DBus API to get an app spawned.
<robert_ancell> Also, I guess even in case 1 you would have to pass an env variable to the app to give it the fd number
<RAOF> No?
<robert_ancell> I'm assuming at the moment that whatever the solution there will be an env variable set - and I can base tests off that variable (and make the daemon set it)
<robert_ancell> hard code 3=mir socket?
<robert_ancell> you can't introspect fds in any way can you?
<RAOF> fd 3 would always be the mir socket, in the same way that fd 0-2 are always stdout, sterr, stdin.
<robert_ancell> unless we screw something up and another fd gets inserver
<robert_ancell> inserted
<RAOF> Correct.
<RAOF> But then that'd be a problem with sending the fd number as an environment variable anyway.
<robert_ancell> I couldn't think of a problem..
<RAOF> Well, it's the same sort of problem as âwhat if we leave another fd open as fd 3â, right?
<RAOF> âWhat happens if we screw up and the fd number we set in the environment doesn't match the actual fd?â
<RAOF> You know, we could also get this over dbus.
<RAOF> But that's probably overthinking it.
<robert_ancell> RAOF, ok, a specific case would be if an app was launching another app and had to pass on the fd - the next fd available might not be 3
<RAOF> robert_ancell: It could fork(), close(3), then open the mir connection, which should then be fd 3?
<robert_ancell> RAOF, 3 might be something else that it does need to pass on, e.g. some pipe for something
<robert_ancell> I guess you could dup and close, but it seems nicer to just be explicit
<RAOF> Yeah, I guess.
<RAOF> I suspect that we'll probably end up with $XDG_RUNTIME_DIR/mir/socket, or whatever $MIR_SOCKET points to if that's set.
<robert_ancell> yeah, that
<robert_ancell> 's what I'm hoping
<robert_ancell> RAOF, is that still what Wayland is doing afayk?
<RAOF> I think so, yes.
<RAOF> The well-known-fd option is cool, but probably overkill ;)
<robert_ancell> RAOF, pff, I don't even trust stderr to be 2, I use STDERR_FILENO
<alan_g> alf_: looking at client-rpc-report-lttng - and wondering (without thinking too deeply) that it would be nice to avoid having different client & server shared libs for lttng support. Would that require reworking the TRACEPOINT_* magic?
<alf_> alan_g: thinking...
<alf_> alan_g: I think this is doable. We would need to create a single SO containing the tracepoint provider sources (*_tp.*) from both client and server. This means that server produces mirserverlttng.a, the client produces mirclientlttng.a, and at some point (in shared?) we create a libmirlttng.so from these two.
<alf_> alan_g: However, it does create some complications in terms of packaging, and also it couples the client and the server object-file-wise.
<alan_g> alf_: thanks for thinking it through - I don't think that would be worth doing.
<alan_g> I was more thinking of removing the direct dependencies on lttng - not the program specific stuff generated
 * alan_g will be offline for a few minutes while he moves to the garden "office"
<racarr> Morning
<alan_g> Afternoon
<kgunn> alf_: ping
<alf_> kgunn: pong
<racarr> "Finished" new platform API mirserver. Coffee break!
<racarr> lol...
<racarr> tried not drinking caffeine for a while this morning to see what would happen
<racarr> now halfway through coffee...*twitch*
<racarr> I think
<racarr> I don't know when exactly.
<racarr> But we should adopt
<racarr> ubuntu::Event as MirEvent
<racarr> The current codepath on the client is kind of embarasing:
<racarr> read droidinput::InputMessage off the wire. Copy to droidinput::InputEvent, copy to MirEvent, send to platorm API, copy to Ubuntu event (99% identical with mir event...but not memcpy identical XD), send to toolkit, copy to QEvent
<racarr> Elegance: ^
<racarr> kdub_: An interesting point about the C->C++ layer in the client library and the lack of testing
<racarr> the same problems
<racarr> prevent platorm-api-mirclient from having good unit tests
<racarr> because you can't meaningfully mock the machinery of the client library, so you would have to mock the whole server, or just run a server or whatever.
<kdub_> right, its like oblique testing
<kdub_> and there are some oblique data paths that have popped up
<racarr> Ignoring for  second the idea of getting rid of mirclient
<racarr> it could be made more testable.
<racarr> i.e.
<racarr> we introduce a "ClientConfiguration" which lets you mock the machinery (i.e. MirConnection) etc.
<racarr> and there is private API like
<racarr> mir_connect_with_configuration
<racarr> (mir_connect calls this with default_configuration)
<racarr> though I don't even know what I want to test here and if that helps me ;)
<kdub_> i thought we had one of those
<kdub_> src/client/default_connection_configuration.cpp
<racarr> kdub_: I don't have that file ;)
<racarr> are you sure you didn't write it today
<racarr> uint32_t ua_ui_display_query_horizontal_res
<racarr> I wonder if someone will hate us for that in a decade
<racarr> "Unity crashes when I enable by second 2147483648
<racarr> pixel monitor"
<racarr> ...feels pretty unlikely
<kdub_> racarr, its a newer file... http://bazaar.launchpad.net/~mir-team/mir/trunk/view/head:/src/client/default_connection_configuration.h
<kdub_> maybe a merge will bring it in
<racarr> lol, it requires over 256 exabytes per second of bandwidth to drive a monitor that overflows 32 bit resolution
<racarr> with 32 bit color depth
<racarr> that
<racarr> cant be true
<racarr> anyway enough of that
<racarr> kdub_: Ohhh
<racarr> beautiul
<racarr> it came in alfs stuff
<racarr> I guess
<kgunn> racarr: kdub_ does the android input stack support pretty much any evdev device ?
<kdub_> my understanding is yes, but i'll for racarr to confirm
<kgunn> kdub_: mind joining #ubuntu-unity
<kdub_> oh sure.. .should add that one to my autojoin channels too!
<racarr> kgunn: Merr. Sorry. Comcast strikes again.
<racarr> Yes pretty much any evdev device seems to be the case
<racarr> there are all sorts of weird defines for like ...the right pedal axis, or the left rudder lol.
<racarr> *stretches* platform API server/client 2.0 are "finished" save for a sensors enabled hybris build, that's just one last bit of wiring for tomorrow though
<racarr> I think I just wrote roughly 100 3-4 line functions *cringe*
#ubuntu-mir 2013-06-05
<thomi> robert_ancell: who's been dealing with the packaging in lp:mir?
<robert_ancell> thomi, a mix of people, but I can help out with that
<thomi> robert_ancell: I'm trying to add the mir_stress binary to a new mir-stress package, but for some reason it's not adding the binary to the package
<thomi> I wonder if you have a second to look?
<robert_ancell> thomi, sure
<thomi> lp:~thomir/mir/add-mir-stress
<robert_ancell> thomi, hmm, it looks ok to me
<thomi> you mean, you think it should work, or it actually does work for you?
<duflu> Greetings...
<duflu> Hey why doesn't Gnome clock in raring know _any_ NZ timezone/locations? :)
<robert_ancell> thomi, I haven't compiled it but will try now
<robert_ancell> duflu, works for me..
<thomi> duflu: me too, in saucy too :-/
<robert_ancell> duflu, time to upgrade to saucy anyway :)
<duflu> It also reckons _every_ town in West Aust is called Perth :)
<robert_ancell> there's other towns in WA?
<thomi> duflu: well, that's accurate, isn't it?
<thomi> zing!
 * thomi high-fives robert_ancell
<robert_ancell> ka-pow!
<robert_ancell> we is so witty
<thomi> heh
<duflu> Don't mention the S word yet. I only just got my server to raring
<robert_ancell> duflu, phone is switching, so we are switching
<duflu> Fair enough. But not my stable server :)
<duflu> I'll put saucy on a couple of others
<thomi> TBH, the biggest issues I had with development releases in the past was the email client. Thankfully that particular problem has been solved for me now :)
<thomi> I've been running saucy for ages now, no serious issues yet
<robert_ancell> thomi, debuild failed: /home/bob/bzr/mir/add-mir-stress/src/server/options/program_option.cpp:98:13: error: âcerrâ is not a member of âstdâ
<robert_ancell>              std::cerr << "ERROR in " << filename << ": " << error.what() << std::endl;
<robert_ancell> continuing after adding <iostream>
 * duflu reconfigures modem
<robert_ancell> thomi, hmm, now it fails because examples/demo_client_accelerated.cpp gives:
<robert_ancell> /home/bob/bzr/mir/add-mir-stress/examples/demo_client_accelerated.cpp: In function âint main(int, char**)â:
<robert_ancell> /home/bob/bzr/mir/add-mir-stress/examples/demo_client_accelerated.cpp:82:26: error: variable ârcâ set but not used [-Werror=unused-but-set-variable]
<robert_ancell>      int major, minor, n, rc ;
<robert_ancell> this is because it's being compiled with -DNDEBUG and the asserts don't do anything
<thomi> robert_ancell: huh? I don't get that at all
<robert_ancell> thomi, this is just a bzr branch and a debuild
<thomi> robert_ancell: hmmm, I use 'bzr bd'
<thomi> robert_ancell: can you try that? AFAIK that's the way the distro team are recommending people build PS upstream projects
<robert_ancell> thomi, ok
<robert_ancell> thomi, same issue as before
<robert_ancell> (i.e std::cerr, is compiling with -DNDEBUG)
<thomi> that's odd, it builds fine for me
<thomi> I mean, it fails to sign the packages, but that's expected
<robert_ancell> hikiko, RAOF, meeting
<robert_ancell> thomi, ^
<hikiko> coming
<robert_ancell> kdub_, ^
<robert_ancell> hikiko, ping
<alan_g> alf_: do you want to review fix-input-registrar-locking before I top-approve?
<alan_g> hi duflu - welcome back
<duflu> alan_g: Thanks.
<duflu> I was about to log off ;)
<alan_g> OK bye. Catch you tomorrow. ;)
<hikiko> hi, question: what's the gbm_cursor?
<alan_g> hikiko: it's the hardware cursor
<alan_g> question: what do the ints in native_handle represent?
<hikiko> alan_g, we set a bo as drm cursor and we fill it using gbm?
<alan_g> hikiko: sounds about right
<hikiko> I mean cursor == a gbm bo rendered using drm (overlayed by gpu etc)?
<alan_g> yes
<hikiko> ok :)
<hikiko> thank you alan_g !
<alf_> alan_g: which native_handle is that?
<alan_g> android cutils
<alf_> alan_g: I think the information there supposed to be somewhat opaque and driver dependent
<alan_g> alf_: I knew that. ;)
<alan_g> The thing is when I try passing out a framebuffer there's a difference that affects the client behaviour.
<alf_> alan_g: ok, so I guess the answer is "Who knows" (Kevin will probably have mor info)  :)
<alan_g> alf_: yep
<alf_> alan_g: what happens?
<alan_g> alf_: a "normal" buffer gets posted back to the server, a frame buffer doesn't
<alan_g> the second int (index 1) seems to be key
<alan_g> "normal" buffers have 8, frame buffers 3
<alan_g> If I overwrite this with 8 the client attempts to post the buffer but then things (predictably) go wrong
<alan_g> So I'm wondering what this int is about...
<alf_> status: Started working on providing facilities for session/surface snapshots, in particular, implementing a BufferSwapper::compositor_peek() method
<racarr_> Morning
<alan_g> Afternoon
<racarr> greyback: Hangout? I dont have so much realy today (platform-API continues)
<racarr> making progress now though
<racarr_> Going to work on client-focus-notifications for a while to change pace from platorm-api
<racarr_> ghashashasfa over and over this test hangs when logging is disabled
<racarr_> over and over (100 iterations) it starts passing as soon as I enable logging
<alf_> racarr_: which test is that?
<racarr_> alf_: My new test in client-focus-notifications
<racarr_> Finally got a failing run out of valgrind + logs...narrowed it down to the client or the
<racarr_> test itself
<racarr_> fascinating, the event makes it all the way to MirSurace::handle_event but sometimes
<racarr_> handle_event_callback is NULL
<racarr_> but that should all be set up beore things even create and how can it race
<racarr_> and
<racarr_>         mir_wait_for(mir_connection_create_surface(connection, &request_params, create_surface_callback, this));
<racarr_>         mir_surface_set_event_handler(surface, &event_delegate);
<racarr_> there it is
<racarr_> ...*kick self*
<racarr_> lol
<racarr_> I thought for sure it was the socket code
<racarr_> not handling this sending an event before the surface is fully created well
<racarr_> and went through all the message serialization and parsing :(
<racarr_> does anyone remember
<racarr_> why event_delegate was removed from the constructor?
<racarr_> It's possible to fix now by setting the event_delegate rom the surface_created callback
<racarr_> as completion of that blocks reading of more messages
<racarr_> Lunch for racarr
 * kdub_ has waded into the mesa weeds
<kdub_> its strange that we put our egl native display type in the egl native surface type definition...
<racarr> namespace ubuntu { namespace application { namespace mir {
<racarr> feels pretty good :)
<racarr> kdub_: ?
<racarr> refresh my memory -.-
<kdub_> racarr, isn't it more fun to just do ubuntu_application_api_mir_client_api_query_for_targetable_surfaces_that_are_not_focused? ;-)
<racarr> kdub_: How do you know my password
<racarr> kdub_: Do you happen to know anything about building platform-API? I want to build phone packages in pbuilder but it says it needs hybris-dev which is a virtual package
<racarr> and uh...I don't really know what that means :p
<kdub_> racarr, you probably have to add the ppa with hybris in it to the pbuilder setup
<racarr> oh I didn't know it was still only in a ppa :)
<racarr> lol now aptitude
<racarr> segfaults
<racarr> what
<olli> robert_ancell, quick q
<olli> robert_ancell, in a full converged world where we have support for legacy X apps...
<olli> where I have a touch-only device (e.g. tablet) and a legacy X app, that is not touch enabled
<olli> where would we need to inject touch support for that app?
<olli> I would assume still in X & the resp. toolkit
<robert_ancell> olli, yeah, in the toolkit afaik
<robert_ancell> they would work as well as running Ubuntu on the nexus 7 at the moment I suspect
<olli> i.e. mir would take input and pass it on down to x
<olli> basically 1:1
<olli> none of the OIF translations would happen at the Mir level
<olli> is that close?
<robert_ancell> I think that's correct
<robert_ancell> I'm not sure if it's been completely designed yet, might be worth asking tvoss if he had any thoughts on it
<racarr> olli: That sounds correct to me.
<olli> OIF does a lot of math to conclude which touch action might have been triggered, might be interesting to see if mir couldn't just pass the result onto X
<olli> rather than the series of events
<thomi> robert_ancell: I wonder if you have time for a MP? src/mir-stress.cpp src/client.cpp src/threading.cpp src/results.cpp
<thomi> otherwise I'll wait till the Aussies get online
<robert_ancell> thomi, can have a look
<thomi> thanks
<robert_ancell> thomi, did you fix the packaging problem?
<thomi> robert_ancell: yep :)
<thomi> robert_ancell: turns out I was being dumb
<thomi> and had forgotten to install the binary
<racarr> olli: Maybe. Someone would have to do a close look at how they map up
<racarr> certainly step one is sending the "raw" events through
<olli> racarr, ack
<olli> will bug tvoss next week
<olli> not sure who approved his vacation
<racarr> Let's just hope he doesn't relax
<racarr> ;)
<olli> maybe I should call him
<olli> "hey, I just had this great idea about somthing I have no clue of"
<olli> his wife will kill me
<racarr> "How is your vacation?" "Good, yester..." Yeah, great so about X11..."
<ogra> you should wait 2-3h
<ogra> its way to early to call him :P
<olli> racarr, when you write "Yeah" I can't help but think of Office Space
<olli> yeah...., so
<racarr> haha
<olli> yeah, so... that jenkins template you wrote the other day....
 * thomi hides at the mention of the "j" word
<olli> thomi, did you not get my memo?
<thomi> ...
<olli> http://www.youtube.com/watch?v=Fy3rjQGc6lA
<racarr> whee, can build platform api-2 with hybris graphics/sensors, mir server/hybris sensors, mirclient/hybris sensors, and mirserver/mirclient desktop
<racarr> the story of how one shared library became 5
#ubuntu-mir 2013-06-06
<duflu> RAOF: Surprisingly, and ignoring the tearing, I could actually *feel* the desktop was more responsive with the PPA intel driver. I suspect that would mostly be due to double vs triple buffering...
<RAOF> Plausibly.
<duflu> I always thought it was imperceptible before now
<RAOF> We're ridiculously sensitive to latency, sometimes.
<thomi> robert_ancell: did you get anywhere with that MP? I fixed the failing CI :-/
<robert_ancell> thomi, what's the link?
<robert_ancell> thomi, 'add-mir-stress'?
<robert_ancell> thomi, did the client API not get fixed for leaking descriptors yet?
<thomi> robert_ancell: https://code.launchpad.net/~thomir/mir/add-mir-stress/+merge/167661
<thomi> robert_ancell: it was fixed, but then it broke again
<thomi> robert_ancell: so I want to get this as part of a CI run, to apply some pressure to not have it break again in the future
<robert_ancell> yep
<thomi> sorry for the delay - I did a dist upgrade and now saucy unity crashes every time I click anywhere in firefox :-/)
<robert_ancell> unity in saucy also went super-unstable when switching to saucy
<thomi> robert_ancell: thanks for the review. I like your package name better, so I'll chaneg it & then hit the button
<robert_ancell> thomi, with one last merge I think the lightdm tests (i.e. make check) should finally run on a server - what do we do to enable them in Jenkins?
<thomi> robert_ancell: just make them run as part of the package build
<thomi> something about roverriding dh_auto_test ?
<thomi> override_dh_auto_test:
<thomi> in debian/rules
<thomi> to run your tests
<thomi> and done!
<robert_ancell> thomi, oh duh. Cheers!
<alf_> RAOF: hi
<robert_ancell> pete-woods, hey, did the LightDM test changes make sense? Do you want to have a call?
<pete-woods> robert_ancell: I really appreciate you putting the effort in to help me here!
<pete-woods> I was expecting you to be in bed around now, though!
<pete-woods> I was going to stay up late tonight
<robert_ancell> pete-woods, I stay up late on Thursdays otherwise I never have overlap with you guys over that side
<robert_ancell> pete-woods, I'd be interested if there will be possible at some point to remove the mock service code in test-runner.c and replace it with dbusmock. At the time dbusmock didn't exist but I really needed it then
<pete-woods> robert_ancell: could you give me a short while to read the changes - I've not looked at them yet
<robert_ancell> np
<pete-woods> yeah, dbusmock is awesome
<robert_ancell> I'll be here another 15 mins
<pete-woods> okay
<pete-woods> speed code read!
<pete-woods> okay, cool, that looks like a nice start
<robert_ancell> pete-woods, yeah, I hope that shows enough to plug in the other tests
<pete-woods> robert_ancell: if we want to change the users, what do you think we should do there?
<pete-woods> re-write the whole passwd file, etc
<pete-woods> ?
<pete-woods> should the code there be extracted into a new method that blats the passwd file and corresponding extended user info file?
<robert_ancell> pete-woods, I'm not sure the case your talking about - you mean having users A B C then replacing them all with D E F?
<pete-woods> so say a user's name changes, or language, or anything like that
<pete-woods> robert_ancell: ^
<robert_ancell> pete-woods, I'd say add a method to test-runner.c to that can modify user information and yeah, replace the passwd file if necessary and update the accounts service API
<pete-woods> robert_ancell, okay cool, I'll have a look at doing that
<pete-woods> as long as you're happy with that sort of change
<pete-woods> I'm really nervous about disrupting as critical a project as LightDM
<pete-woods> I don't want 3 million angry geeks ranting at me!
<robert_ancell> :) That's what the tests are for!
<pete-woods> but it's the tests I'm screwing with!
<robert_ancell> yeah, you can do fairly radical things with the test-runner because it's only the tests that trigger that that will be affected
<robert_ancell> I'll push that MP - I was just keeping it open so you'd notice it
<pete-woods> okay fair enough, if you're happy with me messing with that, I'll re-do the changes
<pete-woods> *tests
<robert_ancell> sorry about that - it's always a pain to have to redo
<pete-woods> robert_ancell: there is one thing your runner doesn't catch that I'd like it to
<pete-woods> so the way I structure my dbus tests I make sure you create, destroy, create the service under test multiple times in a single process
<pete-woods> that way DBus gets upset at you if you don't clean up after youself
<robert_ancell> i.e. restart accounts service?
<pete-woods> as in repeat the lifecycle of liblightdm's UsersList object
<pete-woods> when it is destroyed it doesn't let go of it's reference to the display proxy
<pete-woods> liblightdm-gobject/user.c
<pete-woods> g_clear_object(&priv->display_manager_proxy);
<pete-woods> inside the finalize method
<robert_ancell> pete-woods, oh, that would be done inside the greeter - i.e. new/unref it a whole lot of times
<robert_ancell> or create/destroy the greeter object?
<pete-woods> the actual user list object
<pete-woods> that's what I was adding the tests for
<robert_ancell> do you think they'll work well if you make a method in the greeter that does that?
<pete-woods> what I'm getting at is that I think that the way the tests are run, it'd be nice if they lived inside a single process
<pete-woods> as that exacerbates resource problems
<robert_ancell> Yeah, that's the down-side of the current method
<pete-woods> but, I think it could be changed without affecting your test scripts
<pete-woods> it'd just be the test framework that would change
<robert_ancell> The thing is, that liblightdm shouldn't work at all really unless it is set up inside the LightDM environment - so the fact you can use the UserList is a bit of a fluke
<robert_ancell> In general it requires the connection to the daemon which is harder to mock
<pete-woods> totally fair
<pete-woods> I just think that you could do all the set-up and destruction without spawning lots of separate instances
<pete-woods> it's always amazing how many things you catch when you force all the tests to run in the same env
<pete-woods> you see how leaky things are (especially with resources)
<pete-woods> either way, we can at least fix the bug, even if we don't have a regression test
<robert_ancell> pete-woods, do you mean lightdm_greeter_new multiple times for example?
<robert_ancell> (from the same process)
<duflu> ping alan_g
<pete-woods> robert_ancell, that would probably do it
<alan_g> duflu: morning
<duflu> alan_g: Evening
<duflu> alan_g: What kind of "using directive" did you mean here: https://code.launchpad.net/~vanvugt/mir/move/+merge/162487/comments/358815
<duflu> ?
<pete-woods> robert_ancell: I guess what I mean is do something like call test-runner with a list of all the test scripts, then it would run each of them in the same process
<pete-woods> including all the setup and tear down
<robert_ancell> pete-woods, oh, I understand
<robert_ancell> pete-woods, yeah, the best you can get is to make a test that does 100 iterations etc
 * alan_g looks
<robert_ancell> the downside is it's very hard to link up valgrind etc and analyse the greeter that was run
<pete-woods> robert_ancell: if you ran each of them under a g_test instance you could even get a nice report about which of them failed
<robert_ancell> and you get coverage analysis
<alan_g> duflu: "using DefaultServerConfiguration::set_session_manager;"
<pete-woods> true!
<robert_ancell> pete-woods,  I'm open to improved tests, I'm just worried about two similar but different test frameworks to support
<pete-woods> robert_ancell: I totally understand, I'm saying we could improve the existing tests here
<robert_ancell> I think if we could get dbusmock into the existing tests or share some code it would probably work. But it would be quite some work
<robert_ancell> pete-woods, please do! :)
<pete-woods> yes!
<pete-woods> I don't really have time to go crazy, though
<pete-woods> damn full-time job ;)
<robert_ancell> pete-woods, you don't need to sleep right?
<pete-woods> robert_ancell: I think some people at canonical don't seem to sleep
<robert_ancell> that's been my assumption
<duflu> alan_g: Maybe I'm rusty, but I don't see what that solves. It's WindowManager::set_session_manager that is introduced
<alan_g> duflu: then I probably meant something I didn't say...
<duflu> alan_g: OK forget about it for now. I'll ask for clarification later when I repropose
<alan_g> duflu: https://code.launchpad.net/~vanvugt/mir/move/+merge/162487/comments/358816
<duflu> alan_g: Yeah that change at "195" doesn't exist any more. Someone else already committed the same thing on trunk :)
 * alan_g forgets about it (for now)
<hikiko> question: how do you: start the mir server, run a mir client and stop it from a tty? (atm i kill it with ssh :P)
<hikiko> +is it possible to run mir on a vm?
<alan_g|lunch> hikiko: http://unity.ubuntu.com/mir/using_mir_on_pc.html
<hikiko> i tried this alan_g|lunch  but I couldn't switch to other terminals or start the client
<hikiko> and I had to kill it through ssh
<hikiko> hmm sorry I wasn't root but still when I run the mir demo client I get seg fault
<alan_g> hikiko: are you running trunk?
<alan_g> and is it the client or server that segfaults?
<hikiko> alan_g, it was the client, now it's ok, I had a 2nd server running in the background that's why
<hikiko> sorry
<alan_g> hikiko: so you're OK now?
<hikiko> yes
<alan_g> cool
<hikiko> everything working fine
<alan_g> alf__: hikiko - I'm currently blocked on CB, is there anything I can lend a hand with?
<alf__> alan_g: is there something we can do to unblock you?
<alan_g> alf__: kdub_ is having a look. So probably best not to disrupt what you're doing.
<hikiko> alan_g, sorry I just saw it
<hikiko> what is the cb?
<alf__> hikiko: composition bypass
<hikiko> sorry if I sound too naive but what is the composition bypass?
<alf__> hikiko: it's when a client renders directly to the framebuffer instead of a normal surface
<alf__> hikiko: usual scenario for this is when a game goes fullscreen
<hikiko> so you have to make active the framebuffer (set colorbuffer etc) and then bind?
<hikiko> hmmm
<hikiko> well I don't know well the mir codebase but you mean when for example you go to the system compositor, you create a texture with width/height the virtual screen height and you redirect all your rendering to the texture and then you fill the compositors bo with that texture and you render?
<hikiko> (i should put some commas on that :p) i hope yuo make sense
<hikiko> i mean is that a framebuffer? a full screen texture?
<hikiko> or you refer to something else?
<hikiko> eg the linux fb0 device or sth else
<alf__> hikiko: framebuffer= the block of graphics memory that gets display on the screen by the graphics card
<hikiko> ok so you don't refer to the FBO in GLES
<alan_g> hikiko: on android I'm trying to pass out the framebuffer to the client. (But when the client calls eglSwapBuffer the buffer isn't returned to the server.)
<alf__> hikiko: what we want is for clients to be able to render directly to screen, instead of on a surface which we then render/composite onto the screen
<hikiko> so you need to have a shared framebuffer
<hikiko> and the client to have the full control there
<hikiko> isn't it?
<hikiko> I mean the client to have the ability to render directly to the fb
<alan_g> yes
<hikiko> and you provide a callback to the client for rendering for example?
<hikiko> like those in the client library?
<alan_g> The client renders to the frambuffer, calls next_buffer and the server swaps the FB to the display. (In theory)
<hikiko> alan_g, is it possible that your framebuffer is empty because you already sent it to the gpu with some make current in the wrong place ? (I guess no but I just say the most obvious mistake I can think of)
<alan_g> hikiko: when the client calls eglSwapBuffers I expect a call to next_buffer - but that doesn't happen. kdub_ is most familiar with the android blobs and is looking into it...
<hikiko> next buffer is a mir client isn't it
<alan_g> yes
<hikiko> method*
<hikiko> then how eglSwapBuffers will call a mir method?
<alan_g> hikiko: I guess my problem is more interesting than yours?
<hikiko> lol
<hikiko> ok I don't comfuse you anymore
<alan_g> hikiko: I don't mind, but I don't want to divert you from more useful work.
<alan_g> egl is supplied with a bunch of function pointers. One of which leads to next_buffer
<alan_g> and if a normal buffer is used next_buffer gets called after rendering.
<hikiko> I didn't know that egl has callbacks, interesting to know
<kdub_> hello, status, starting to dive into comp bypass, shepherding branches and cleanups too
<alan_g> status: deciding what to do while kdub_ dives into CB
 * alan_g has discovered that saucy is unstable on his netbook
<kdub_> alan_g, no exciting news so far, going to tinker with some small test programs for a while to explore what's happening
<alf_> status: experimenting with various approaches for providing surface snapshots, leaning towards having a separate thread in mir for this purpose
<alan_g> kdub_: at least I don't feel I missed something obvious. ;)
<alf_> status2: (also for snapshots) working on providing BufferSwapper::compositor_peek()
<kdub_> alf_, hmm. if the only 'lastposted' buffer is given out to the compositor, how would that work?
<kdub_> we could retain the reference to the 'lastposted' buffer in the swappers, and then allow 2 threads to compositor_acquire that buffer
<alf_> kdub_: yes, we need to keep information about which buffer the compositor has acquired
<kdub_> i've thought recently that compositor_{acquire,release} and client_{acquire, release} would be better if they were consumer_{} and producer_{}
<alf_> kdub_: but we need a separate peek() method that doesn't dequeue the buffer. We don't want snapshots to cause the compositor to drop frames.
<alf_> kdub_: I like the idea
<kdub_> alf_, i'm saying like, if we have a snapshotter and a compositor who both get the same buffer, we would have to wait for them to both release before triggering buffer advancement in the swapper
<kdub_> it would be cool even if the separate thread was a SnapshottingCompositionStrategy : public CompositingStrategy, then we could use the gpu to copy the buffer into thumbnail-size resolution and use the gpu's capability to scale the image
<alf_> kdub_: sure, but we shouldn't allow the snapshotter to make the compositor miss a buffer. If we just have normal acquire/release, then imagine: snapshotter acquires buffer, is done, releases buffer back to client, compositor acquires the next buffer => frame lost
<kdub_> ah, so the essence of the new function is that compositor_acquire would be required to advance the buffer
<kdub_> but peek_buffer would not trigger an advance on the return of the buffer it 'peeked at'
<alf_> kdub_: right, and of course if a buffer is being peeked at it will not return to the client until it is released by the peeker (is there such a word?)
<alf_> kdub_: and the change to producer/consumer make even more sense now that we have another type of consumer (the snapshotter)
<kdub_> alf_, right, the generic plan sounds good then :)
<alan_g> kdub_: alf_ do we actually need to hand out the buffer to the snapshotter? Wouldn't ExecuteAroundMethod be a better idiom?
<alf_> alan_g: do you mean something like BufferSwapper::with_compositor_buffer_do(std::function<void(Buffer&)> const&) ?
<alan_g> alf_: exactly
<alan_g> if could also do that on the compositor side, then - at least in theory - both the compositor and the snapshotter could access the buffer concurrently.
<kdub_> i guess either way, the buffer would be delayed the same potential amount of time
<alan_g> *if we
<alf_> alan_g: At first glance that could work, and I like the idea. Need to think through the locking/delay implications.
<kdub_> with peek_buffer() it could be concurrent too though
<kdub_> although i like the idea too
<alan_g> kdub_: I was thinking the the swapper lost the buffer between the calls?
<kdub_> right, either way (execute-around or a new method) we'll have to change it so we never loose the reference in the swapper for the compositor buffer
<kdub_> lose
<alf_> kdub_: So, yeah, perhaps we wouldn't need to lock the entire operation and get the best of both worlds. In particular, perhaps do what would be needed to "peek" the buffer, but don't give it out, process it through the callback.
<alf_> but I need to think through the details...
<kdub_> sure, i think both would work, and both would have worst case delay of (compositing-time + snapshotting time)
<kdub_> but best case delay of max(compositing-time, snapshotting-time)
<alan_g> agreed
<racarr> Morning
<alf_> kdub_: alan_g: best case delay from the compositor's perspective is 0 (if snapshotting begins and ends while the compositor doesn't need the buffer), worst case is snapshotting time
<alan_g> Afternoon
<kdub_> racarr, you have the mesa 'configure' command handy? my compile can't find a symbol for '_glapi_tls_Dispatch'
<alf_> kdub_: do you mean delay as in how much time the buffer is in use?
<kdub_> right, how long it is in use as a 'consumer' buffer
<racarr> kdub_: Uhhhh so I have seen that beore and got it from something weird but the configure command is
<racarr> ./configure --disable-gallium-egl --enable-gles1 --enable-gles --with-egl-p\
<racarr> latforms=x11,drm,mir,wayland --enable-gbm --enable-shared-glapi --with-gallium-\
<racarr> drivers=r300,r600
<alf_> kdub_: right, so I guess that's delay from the client's perspective
<alan_g> alf_: snapshotting shouldn't need to delay compositing (they should both treat the buffer as immutable)
<alf_> alan_g: kdub_: yes you are absolutely right, probably time to end my day :)
<kdub_> racarr, thanks
<kdub> with swapper-swapper, i can't decide if having an empty swapper and filling it later with buffers (such as adopt_buffer(mc::Buffer)) is 2 step initialization or not :)
<alan_g> Is it a precondition of using it that it is filled?
<kdub> in swapper-swapper's current state, i decided that it was, hence, i bundle the factory function and send it down via function interface
<alf_> kdub: alan_g: right now compositor_acquire() assumes that it always has a buffer
<kdub> right, so i guess it is
<kdub> maybe the solution is to have the SwapperMaster have the SwapperFactory, and it can alloc the new swapper
<alf_> all: Have a great rest of day. Talk to you tomorrow!
<kdub> instead of having BufferBundle kick a lambda down to indicate a change
<racarr> alf_: Bye
<kdub> you too alf_
<alan_g> Bye alf_
 * alan_g sees a fight coming: ~robertcarr/mir/display-sizes-are-unsigned vs ~vanvugt/mir/move
<racarr> what
<racarr> oh
<racarr> I see
<racarr> haha
<alan_g> Goodbye all - have a good one!
<racarr> See you!
<racarr> New platform-api branch is done except for some packaging bits that Gerry is going to help me with at ~robertcarr/platform-api/mir2
<racarr> moving on to qtubuntu now which should just be small things. Hopefully have things unity8 running on platform-api-v2/mir tomorrow
<kdub> racarr, very cool
<kdub> racarr, if you have time, could you look over swapper-swapper? many eyes make for better thread code :)
<racarr> kdub: Ok I will try. I know I said I would a few days ago then i got distracted by the stress test thread code XD
<racarr> I think I can do it after lunch though, before moving on to qtubuntu
<racarr> also by the end of lunch hopefully they will be done turning the concrete on the road in to
<racarr> powdered concrete
<racarr> and I might be able to focus long enough to do a review XD
<kdub> racarr, thanks :) threading code reviews are funnier than the straightforward ones
<kdub> because the reviews process ends with ' well, can't find anything wrong', instead of 'looks good to me' ;)
<racarr> kdub: But what about the mathematical proof of the display server
<racarr> Lunch! back soon
<kdub> i've worked out this fun way of bouncing c++ compile errors between clang and gcc to get the quickest reading on the problem for every situation
<racarr> Annnd back
<racarr> kdub: ?
<racarr> or do you just mean you go back and forth betwween them
<racarr> because that's what I do XD
<kdub> we just need a 3rd or 4th compiler toolchain, then we'd be really quick at diagnosing google mock explosions ;)
<racarr> kdub: Ok going to review swapper swapper now
<racarr> kdub: I think alan's last comment about bundling up was about
<racarr> the signature appearing so frequently it should be a composite type (vector reference bufers, size_t)
<racarr> I'm not sure, I was just thinking it's hard or me to understand size_t& original_size in end_responsibility
<racarr> but I am not very far yet :)
<kdub> the difference there is that during a switch, the number of buffers the dying swapper is responsible for can be different than the number of buffers the dying swapper is curerntly in possession of
<racarr> Mm
<racarr> ok I think I understand what is supposed to happen/the overall control flow now
<racarr> kdub: I also don't understand why BufferSwapperMaster extends BufferSwapper
<racarr> but that's ok for now I gues
<kdub> the SwapperSwitcher has to redirect returning buffers from the swapper that was destroyed to the new swapper
<kdub> really, I expect BufferSwapperMaster and BufferBundle to merge
<racarr> mm, so SwapperSwitcher implement BufferSwapperMaster and BufferSwapper
<racarr> but they are two interfaces?
<kdub> no, i think of it as a BufferSwapperMaster is a BufferSwapper that can also change between algorithms
<racarr> Mm
<racarr> kdub: Ok I think the locking makes sense. The one thing I am hung up on now
<racarr> is why the exception for control flow in SwapperSwitcher.
<racarr> Can't it be anticipated that
<racarr> swapper->client_acuire will throw forced_completion
<racarr> by updating some member variable in change_swapper
<kdub> no, because the client could have entered its wait long before the command to change the swapper comes in
<racarr> Mm right...
<racarr> kdub: Hmm, so
<racarr> is it so/is it a problem
<racarr> that, say 2 clients are waiting, and the swapper changes
<racarr> they are no longer guaranteed to get buffers in the order
<racarr> they requested them
<kdub> hmm, thinking
<racarr> right, because they are woken up at the same time after blocking when they handle the forced completion exception, then it's a race to call client acquire the second time
<kdub> well, as it is now, the client only has one buffer at a time
<racarr> der!
<kdub> and it would be a race in BufferSwapperMulti as well, so I don't think its a problem
<racarr> Sorry, silly questions, it's just not very well loaded in my head
<racarr> mm
<kdub> racarr, np, they're good questions to think about
<racarr> kdub: Is SwatcherSwitcher::end_responsibility a real TODO?
<racarr> what should it do...
<racarr> Swapper* XD
<racarr> SwatcherSwitcher might be a nice color management object though
<kdub> racarr, it is, technically, it should return the bu ffers to whoever owned it... i'd expect that as I do another pass on the interface (and the BufferBundle interface) that function would go away
<racarr> Mm makes sense.
<racarr> tests make sense :) cool test for RWLock
<racarr> kdub: I am a little suspiscious of
<racarr> test_swapping_swappers
<racarr> .cpp
<racarr> because you can comment out the implementation of change_swapper and it still passes ;)
<racarr> but I can understand how it's useful as a stress integration test...
<racarr> um
<racarr> I don't know it might be nice if there were a different filename like stress_test_swapping_swappers so people like me don't look for how it tests swapping swappers
<racarr> but that's not a huge problem either and the test names clear it up really
<racarr> kdub: Ok! LGTM
<racarr> I didn't really go through for whitespace/style because I guess Alan/Alexandros did
<kdub> racarr, well, if you comment out change_swapper, it is just tests that the swappers in normal conditions work ok. the change_swapper() is the essential part
<racarr> but am pretty convinced on the logic
<kdub> racarr, thanks!
<racarr> kdub: Right, but I mean the test file name implies
<racarr> that it tests, the swapper changing functionality works
<racarr> whereas in fact even if it doesn't, the test can still work.
<kdub> the subtle ways that test failed when I first wrote it were things like, it would hang, or the buffer's references would be lost
<kdub> so its one of those 'don't hang, don't lose the buffers' sort of tests :)
<kdub> thanks again though!
<racarr> no worries! It was interesting
<bregma> racarr, I understand you can point me at android input drivers for the desktop?
<racarr> bregma: Maybe!
<racarr> Can you clarify what you are looking for / expecting, because there aren't userspace drivers for specific input devices like in X11
<bregma> racarr, I'm looking for what needs to happen to get Unity8 on the desktop, I understood there was an android-based layer on top of evdev available?
<racarr> bregma: Yes.
<racarr> I think nothing special needs to happen (beyond everything else) we have it going on the desktop, it delivers events to Qt, etc.
<racarr> til: If you want to include symbols in your shared library from a static library and don't reference them internally you need to use -Wl,--whole-archive before your library, but then you also need to use -Wl,--no-whole-archive after your library
<racarr> because G++ appends its own libraries to the end of your list
<racarr> Whee, qtubuntu builds again
<racarr> bregma: Sorry I was pretty distracted XD um
<racarr> so yeah it's a layer on top of evdev that was originally android code
<racarr> though we've pulled out all the android dependencies, etc...
<racarr> and replaced some bits, for example we use xkbcommon for keymapping, etc.
<racarr> So it should be well suited for the desktop and we are matching it up with Qt, etc.
<racarr> one thing that is perhaps, a bit of an open question (at least not entirely closed to me, maybe someone knows the answer)
<racarr> is where/how we will do things that happen in X11 drivers for the desktop, that are of interest
<racarr> i.e. things like two finger scroll on synaptics
<racarr> etc
<kdub> haha, happened across some old mir prototyping code that had a todo in the gl renderer 'todo: replace with nux'
<racarr> kdub: The normal spelling is 'QML'
<racarr> XD. Nux is still in RoughArchitecture.png too
<kdub> haha, yeah
<kdub> once i cross compiled nux for android, using the android ndk
<kdub> that was a painful week :)
<racarr> Mm I bet
<racarr> just tested and ironed out a few errors and now ran some QML apps on top of platform-api-v2/mir
<racarr> now I just need to fix key mapping again (mostly deleting the correct code now that we do xkbcommon)
<racarr> andddddddddd
<racarr> then something I suppose ;)
#ubuntu-mir 2013-06-07
<bregma> racarr, what's the input library called and where can I find it?
<racarr> bregma: It lives in the mir tree.
<racarr> bregma: 3rd_party/android-input
<racarr> by itself it doesn't do a whole lot so we have the classes in mir::input (i.e. src/input, src/input/android)
<racarr> to tie it together
<thomi> RAOF: got a second?
<racarr> Getting a second nexus 4 in the mail tomorrow so I will finally have a full time Ubuntu phone :D
<racarr> also it will be white
<racarr> I'm sorry I just come back in the evening and distract the southern hemisphere
<racarr> working on getting platform-api branch proposable so ricmm can review it in his morning
<thomi> racarr: you're doing things on the platform api project?
<duflu> racarr: platform-api stuff probably relates to my cry-for-help email..? :)
<thomi> when I get back from holiday I'm going to try and get you guys to take on the python bindings for said project... at the moment every time you guys change the API the entire testing stack on the phone breaks :-/
<duflu> racarr: Cool, white, easy to distinuish
<duflu> +g
<duflu> thomi: We've been very aware of the need to stabilize it for a long time. Sorry to say I changed the client API again last night. But such changes are becoming rarer
<thomi> hey, that's OK... it just sucks that the python bindings are in a totally separate project. It makes them rather too invisible
<thomi> I'd like to have them in the same project, building at the same time as trunk
<racarr> thomi: duflu: Yes. There is a new version of the API, so I did new mir backends
<racarr> in the process of removing TODOs and testing the various qtubuntu configurations (mirserver/mirclient desktop/phone)
<racarr> Hopefully it should land with qtubuntu changes tomorrow or monday unless something horrible happens
<racarr> and things will just work tm*
<racarr> duflu: So the short answer on the email is if the old instructions don't work (you could still try building ~robertcarr/platform-api/mirserver and ~robertcarr/qtubuntu/mirserver then unity/phablet/integrate-mir)
<racarr> probably just wait until monday
<racarr> I guess there is no reason why that wouldn't work
<duflu> racarr: So long as you're not *aware* of anything those branches are missing...
<racarr> duflu: They should work, at least on desktop
<racarr> platform API, you need to build with
<racarr> -DPLATFORM_API_IMPLEMENTATION=mirserver
<racarr> qtubuntu, the whole source tree doesn't build (just the qpa plugin) so you go to src/platforms/
<racarr> then qmake -o Makefile
<racarr> make
<racarr> my system seems to have problems with finding the platform api so at this point becaue qmake isn't looking in arch specific directories so I have symlinks XD
<racarr> um but then that builds
<racarr> there was a fix that landed a few weeks ago in mesa that this will require so make sure your mesa is recent
<racarr> then to build unity you can
<racarr> I think it's
<racarr> ./build -s
<duflu> racarr: Recent as in PPA?
<racarr> then just go to a VT and ./run -m
<racarr> yeah PPA is perfect
<duflu> racarr: Copy, paste. I'll let you know how I went on Monday
<racarr> Cool :)
<racarr> im really hoping by the end of monday to have things in a state where it's as simple as add repository, run unity/build unity
<racarr> and then guess what it's time for!!
<racarr> FEATURES!
<RAOF> thomi: Yo.
<thomi> RAOF: hey - I sent an email to the mir-devel list, which is what I was gonna ask you about anyway. tl;dr version: mir client library leaks FDs again
<RAOF> Woot!
<thomi> yeah... not so much
<RAOF> So you'd like me to un Bork Bork Bork! the client library? :)
<thomi> RAOF: Yes pleese-a feex zee cleeent epee
<thomi> can't really do swedish chef in text...
<thomi> bork bork!
<duflu> Hmm, sometimes I thing Swedish Chef would make more sense than GCC, or Mir errors
<thomi> I'm sure we could patch clang
<thomi> warnings would print "bork", and errors would print "bork bork!"
<thomi> segfaults...
<duflu> GCC had drawn a fish on the screen... ?
<duflu> *has
<RAOF> Free the fish!
<racarr> oh yay trying to run unity on new platform-api leaves my system unresponsive
<racarr> do I A. Try and extract a stack trace failing and rebooting 10 times before suceeding
<racarr> or B. Speculate at possible causes failing and rebooting 10 times before suceeding
<racarr> ok the segfault was kind of funny, qtubuntu is now using a static keycode list, we can remove this because we use xkbcommon and its actually unused on phablet because the OSK goes through a different code path
<racarr> but I hadnt removed it yet in the new qtubuntu because I figured it was harmless
<racarr> but we send some pretty big keycodes apparently and it can overflow this array
<racarr> unity still doesn't show up but hard to tell if its these QML errors or something broken
<racarr> qt seems to be working but Shell.qml is broken
<racarr> in the branch I have
<racarr> going to get a clean build while I watch the daily show!
<racarr> Whee it runs
<racarr> apparently I only have 59 minutes of talk time left on my imac though
<racarr> XD
<alan_g> alf_: could you check https://code.launchpad.net/~robertcarr/mir/dev-package-depends-on-boost/+merge/167807
<alf_> alan_g: looking
 * duflu --> weekend
<kdub> good morning everyone
<alan_g> good afternoon kdub
<alf_> kdub: hi!
<alf_> kdub: alan_g: How about a hangout about swapper-swapper (and later with Robert about client-focus-notifications) to discuss how to proceed/speed things up?
<kdub> alf_, sure
<alan_g> alf_: give me 5 minutes to review the current state of swapper-swapper
<kdub> i have an update to take your simplification for the RWLockWriterBias class
<kdub> i'll push after the meeting though
<alf_> kdub: alan_g: hm, I can't find how to create a hangout :/
<alan_g> alf_: that's the new improved interface. ;)
<alan_g> keep clicking
<alan_g> kdub: i don't think it compiles anyway. ;)
<alan_g> "voud" indeed
<alf_> alan_g: kdub: https://plus.google.com/hangouts/_/ad562109a71a07604737b3453b414f1b29de4454?hl=en , let's give it a try
<racarr> Morning
<racarr> greyback: ricmm: Can we delay catchup 10 minutes? I am just finishing breakfast
<racarr> oh we cancelled it today?
<alf_> racarr: there?
<kdub> racarr, want to talking about client-focus-notifications on the hangout? :)
<racarr> Yes! sorry
<alf_> all: Have a great weekend
<racarr> You too alf
<racarr> *excited for the mailman to come*
<racarr> second nexus 4
<kdub> just in time for the nex7 to start working :P
<racarr> really!
<racarr> well that's ok nexus 4 is more useul anyway
<racarr> I noticed last night how much time I spent looking for windows and how disorienting this was
<racarr> since I switched to two monitors
<racarr> hotcorner for scale windows -> really nice
<racarr> Something I just noticed about filenames
<racarr> session_manager_test.cpp is significantly more useful than
<racarr> test_session_manager.cpp
 * alan_g expects renames by next week
<racarr> I named the mirplatform API impl files like, session_mir.cpp, application_options_mir.cpp etc, because I was copying the naming convention in there, but then I was tempted to rename the files to like, mir_session_options.cpp
<racarr> and realized that was actually really annoying
<racarr> because you have can't tab complete
<alan_g> Bye all. Have a good weekend!
<racarr> Bye!
<racarr> You too
<olli> do you guys know how far RAOF got with packaging xmir?
<olli> improving the packages that is
<racarr> Not I, sorry.
<racarr> Whee flashing new nexus 4
<racarr> the white ones look funny
<racarr> adb can not be run as root even after
<racarr> fastboot unlock?
<racarr> oh -b
#ubuntu-mir 2013-06-08
<j`ey> anyone tried mir in virtualbox?
<j`ey> looking on here: http://unity.ubuntu.com/mir/using_mir_on_pc.html "lsmod | grep drm" doesnt show drm
<j`ey> it's using vesa/pixman
<j`ey> well, I enable 3d acceleration in vbox, and got the drm module
<j`ey> but getting "problem opening DRM device", operation not permitted
<j`ey> ok, trying to build mir from source, it says to run this command:
<j`ey> mk-build-deps --install --tool "apt-get -y" --build-dep debian/control
<j`ey> but I get:
<j`ey> k-build-deps: Unable to find package name in `apt-cache showsrc debian/control
<j`ey> I executed it in the wrong dir
#ubuntu-mir 2014-06-02
<kdub_> camako, AlbertA, would either of you mind a '--disable-overlays' option in mir? would ease the landing path and would be a useful debug/performance toggle
<camako> kdub, sounds good... also useful during bringup on new device with overlay is problematic
<racarr__>  stomach is so happy about the return to normal lunch
<racarr__> spinach argula  yellow rice carrots peas corn lentils yello rice red and garbanzo beans dolma a falafel with humus and a blueberry/orange/bannana/strawberry fruit smoothie
<racarr__> :D
<racarr__> oh and raisins
<anpok> AlbertA: hm what do you mean is missing wrt to alpha support because of the split greeter?
<AlbertA> anpok: even for nested, we make the background opaque
<anpok> on devel?
<AlbertA> anpok: yes and soon 0.2.0
<AlbertA> anpok: so it may affect split greeter
<anpok> aye!
<anpok> hm that branch i made some time ago still merges with devel ..
<anpok> ah, nm it still needs additional work
<greyback> anpok: I guess input-sender will land around 0.2.1 then
<racarr__> coffee is so much less exciting now
<racarr__> that its not only available in a small windo
<greyback> yeah living in Europe is such a buzz for that very reason
<racarr__> greyback: Lol.
<racarr__> (Just ran to the coffee shop of course)
#ubuntu-mir 2014-06-03
<kdub_> fixing 1299977 is oddly cathartic
<kdub_> also, how much code should we share between our examples and our production code? I say ideally 'nothing' and the examples should only be based on the public headers
<racarr__> Morning!
<alan_g> racarr__: Afternoon here
<alan_g> racarr__: got time to make a couple of trivial fixes to https://code.launchpad.net/~mir-team/mir/cursor-spike-lightning-round-fix-input-area-contains/+merge/220111 - so we can land it?
<alan_g> anpok_: racarr__ here's a real easy one to review: https://code.launchpad.net/~alan-griffiths/mir/fix-1325602/+merge/221846
<racarr__> alan_g: Thanks! as soon as I finish breakfast I will
<alan_g> dednick: What do you think of:
<alan_g> s/trusted_participant_starting/participant_added/g
<alan_g> s/trusted_participant_stopping/participant_removed/g
<dednick> alan_g: i have no problem with that.
 * alan_g makes it so
<kdub_> we're in this funny position where we have an api/abi between the production code and examples/
<kdub_> my particular problem is that both the demo compositor and the default compositor need a renderer and some occlusion detection
<alan_g> What's funny about production code having an api/abi and example code using it?
<kdub_> well, i'd be okay if the api/abi was only the stuff in include/ of course
<kdub_> but in our examples, we're recommending modifying the production code to suit the purposes of the examples
<alan_g> That's odd
<kdub_> particularly mc::filter_occlusions_from and mc::GLRenderer
 * alan_g suspects the answer lies in bzr blame
<kdub_> well, the answer lies in how we're sharing GLRenderer
<kdub_> like, its useful because its the default, but do we want to share the code that is useful to the mir defaults in the hope that shell writers can make use of it too?
<kdub_> I say we don't, if you override a default, you have to write a full alternative
<alan_g> kdub_: I'm not familiar enough with the current state to know how reasonable it is. (Can one just wrap the default and change things that way?)
<kdub_> well, one could wrap the default, but we allow overridding various internally-called functions in GLRenderer
<alan_g> kdub_: I mean through the public api
<kdub_> right, like take the_gl_renderer() and wrap the default GLRenderer with shadow/frame painting
<alan_g> My feeling is that we don't have enough use-cases (yet) to drive a correct design, and that we've got [premature] generalization in the wrong places.
<kdub_> right, and I think the right place to move to overridding is the DisplayBufferCompositor (which just has a bool composite() function)
<kdub_> instead of Renderer which is funny interface with begin(), render(), end(), set_rotation(), etc
<kdub_> I just want to figure out if I should try to share mc::filter_occlusions_from with the demo shell, or just write a demo shell occlusion algorithm that doesn't use production code
<alan_g> I'm not voting on the "correct" answer. I just know the code is hard to adapt every time we try supporting something new. It needs good test cases and a refactor.
<racarr__> Im voting for decorations and shadows in the scene :p
<alan_g> kdub_: I don't think it hurts to share that algorithm.
<kdub_> it doesn't hurt to share, but hurts a bit to expand it to think about fancier decorations :)
<alan_g> kdub_: you were happy with the previous version (but CI wasn't). Could you check: https://code.launchpad.net/~alan-griffiths/mir/rework-test_client_library.cpp-mk2/+merge/221854 - thanks
<kdub_> okay
<racarr__> alan_g: Oh updated lightning-round btw
<alan_g> racarr__: top approved an hour ago btw
<racarr__> alan_g: Aha, thanks :)
<alan_g> anpok_: OK to land https://code.launchpad.net/~alan-griffiths/mir/fix-1325602/+merge/221846?
<anpok_> alan_g|EOD: yes
<racarr__> </lunch>
<racarr__> mwahaha I replaced my keybaord
<racarr__> with my laptop
<racarr__> and set up synergy for mouse sharing
<racarr__> its quite nice
<racarr__>  (+ keybooooooard)
<racarr__> ...though apparently with some key repeat glitches
<racarr__> digging in to the emulator bug now...its a little weird... (https://bugs.launchpad.net/ubuntu/+source/android/+bug/1319582)
<ubot5> Ubuntu bug 1319582 in Mir "emulator: 'Failed to start RenderThread' after opening/closing applications" [High,Triaged]
<racarr__> I dont know where the fix is but it cant be in mir/qtubuntu, etc, because how are they supposed to clean up
<racarr__> a clients eglWindowSurface (which in the emulator model has driver/host ssssssssssssssside reeeeeesources)
<racarr__> ...wow this keyrepeat ttttthing is great
<racarr__> I mean its like you allocate an eglContext and then crash and nothing leaks, presumably the kernel side component of the driver cleans up any hardware resources
<racarr__> so this is an emulator driver bug that android has worked around somehow (or we are misusing the emulator)
<racarr__> Who ever thought "apt-get source android" would be a thing
<racarr__> failed to fetch...hash sum mismatch?!?!
<racarr__> typedef SomeSortOfSmartPtr<type> TypePtr is an ugly pattern :p
<racarr__> I think I tracked down the emulator bug...and have a strong guess thats what lead to it.
<AlbertA> anaybody else with canonical irc connection issues?
<racarr__> nah. launchpad connection issues though
<kgunn> hey there...for anyone wanting to lend a hand in testing
<kgunn> we're trying to promote our mir 0.2.0
#ubuntu-mir 2014-06-04
<kgunn> we have some packages...if you wanna test on an n4, n7, n10...just flash the latest image from --channel=devel-proposed
<kgunn> then make the image writable (adb shell, then #touch /userdata/.writable_image)
<kgunn> don't forget to connect to wifi (phablet-network)
<kgunn> then adb shell...logon as phablet user, # sudo -u phablet -i
<kgunn> then sudo apt-add-respository ppa:ci-train-ppa-service/landing-008
<kgunn> then sudo apt-get update, then sudo apt-get install
<kgunn> libmirclient7 libmirclientplatform-android libmirplatform libmirplatformgraphics-android libmirprotobuf0
<kgunn> libmirserver20 mir-utils libplatform-api1-hybris libplatform-hardware-api1-hybris libubuntu-application-api-mirclient1 libubuntu-application-api-mirserver1
<kgunn> libubuntu-application-api1 libubuntu-platform-hardware-api1 qthybris qtubuntu-android libunity-mir1 unity-system-compositor
<kgunn> ...reboot the device
<kgunn> do some exploratory testing, note...go back to fresh image if you think you found an issue to double check
<kgunn> also, you can test on desktop as well...almost the same process, except for picking mesa instead of android for the lib install
<kgunn> if you wanna test, but not sure what to do on the devices...just follow https://wiki.ubuntu.com/Process/Merges/TestPlans/Mir
<kgunn> thanks!
<kgunn> any oddities...ping me or camako or any of the other mir guys here (kdub, anpok, AlbertA etc)
<AlbertA> in pastebin format:
<AlbertA> http://paste.ubuntu.com/7583845/
<kgunn> thanks AlbertA
<kgunn> note: it'll be a short window...assuming all is good, we'll land tomorrow
<josharenson> Anyone tested on nex7
<josharenson> I'm having bad issues
<kgunn> josharenson: what kind ?
<josharenson> I added the ppa, did a dist upgrade (which failed). I resolved the failure, and the screen won't turn on. Tried the exact same method w/ a clean flash and got same results.
<josharenson> kgunn, let me look at logs/dmesg
<kgunn> josharenson: did you try just a clean flash first...to make sure n7 isn't having issues clean ?
<josharenson> kgunn, well thats what I tried second
<josharenson> saw same thing.. device is responsive via cli, but screen won't turn on
<kgunn> josharenson: oh, that's what you meant "clean flash"
<kgunn> josharenson: lemme flash real quick here
<AlbertA> what does /var/log/lightdm/unity-system-compositor.log say?
<kgunn> josharenson: curious also, did you do ubuntu-device-flash --channel=devel-proposed --bootstrap ?
<kgunn> or something else ?
<josharenson> alberta http://pastebin.ubuntu.com/7584119/
<josharenson> kgunn, just devel
<josharenson> kgunn, I can try w/ proposed
<kgunn> josharenson: mos def
<kgunn> the last 3 were nasty
<josharenson> only other remarkable thing was '# phablet-network' never returned correctly... had to set up wifi manually... could be my wifi situation though on my host machine
<kgunn> well..i guess, devel should be an ok image...
<AlbertA> umm closing session-0...
<AlbertA> that's shouldn't happen
<kgunn> yeah...that log looks not so great
<josharenson> flashing devel-proposed... gotta download it so stay tuned
<josharenson> brb in 5
<AlbertA> it looks like terminal is acting wonky, I'm not getting copy/paste things
<AlbertA> with clean image
<AlbertA> phablet-screenshot is broken
<kgunn> AlbertA: copy/paste has been broken for last few images...
<kgunn> i filed a handful of bugs
<kgunn> the latest was the worst... https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1321034
<ubot5> Ubuntu bug 1321034 in Ubuntu UI Toolkit "[regression] copy/paste prompt inactive" [Undecided,New]
<AlbertA> is the phablet-screenshot broken filed? or where would I file that?
<kgunn> AlbertA: unsure if phalet-screenshot already broken...wonder if split greeter might have broke it ?
<AlbertA> kgunn: it must have been broken since 0.1.9
<AlbertA> since we changed the default tmp file name
<AlbertA> for screencasting
<kgunn> AlbertA: or...didn't chris move the endpoint from /tmp/mir_socket to run/mir_socket
<kgunn> if that may effect it
<AlbertA> it seems to be file name only currently
<RAOF> If lightdm had landed, sure?
<RAOF> I didn't change the defaults, only what lightdm was specifying, so there shouldn't be any transition issues; lightdm will both ask for /run/mir_socket and tell unity8 to use /run/mir_socket at the same time.
<AlbertA> kgunn: vis "remote object '/tmp/mir_screencast_768x1280.rgba' does not exist"
<AlbertA> kgunn: this is on a clean image
<kgunn> AlbertA: oh, then yeah...its busted :)
<kgunn> already
<kgunn> unsure if there's a bug
<kgunn> josharenson: my clean N7 flash coming up ok here...
<josharenson> with devel or devel-proposed
<josharenson> ?
<kgunn> josharenson: devel-proposed
<kgunn> running unity8 AP test, gonna step away for a bit...back in a while
<josharenson> ill let you know what happens, download just finished. I'm about to leave for dinner though.
<kgunn> josharenson: no worries, its not a mandate
 * kgunn makes note to fire josharenson
<josharenson> lol ok
<AlbertA> https://bugs.launchpad.net/ubuntu/+source/phablet-tools/+bug/1326191 for phablet tools...
<ubot5> Ubuntu bug 1326191 in phablet-tools (Ubuntu) "[phablet-screenshot] Fails to capture screenshot" [Undecided,New]
<josharenson> kgunn, alberta. Didn't get any errors w/ the dist-upgrade this time. UI comes up after a reboot, all looks well.
<camako> that's good news..
<camako> AlbertA, on N4 windows carousel (I think that's what it's called -- when you have windows stacked at an angle), is the background supposed to be solid black?
<RAOF> Heh. Mir's support for external touchscreens isn't currently great, but then again neither is X's :)
<anpok> RAOF: hi!
<RAOF> anpok: Yo!
<RAOF> What can I do you for?
<anpok> RAOF: i followed the code path of gbm initialization, and now I am back where I started looking..
<anpok> which is the pipe-loader module
<anpok> I now try to add swrast as a fallback if no vendor id matches..
<anpok> no problems so far .. just distractions, that should be gone today
<RAOF> anpok: Sweet
<alan_g> alf_: @std::this_thread::yield() - interesting. It tempts me to try to root cause the bug.
<alan_g> dandrader: Are you picking up https://code.launchpad.net/~mir-team/mir/trusted_sessions/+merge/221191/comments/531459?
<dandrader> alan_g, I know close to nothing about trusted sessions
<alan_g> dandrader: ack. Finger trouble. Sorry
 * alan_g wonders where dednick is today
<dandrader> alan_g, enjoying holidays in Malta :)
<dandrader> alan_g, I think Saviq might have taken over his work...
<Saviq> alan_g, yeah, he's off, back on Monday, I was meaning to ping you - I built all the packages for trusted sessions, but it seems something moved and u-s-c crashes on startup, was just getting some symbols
<alan_g> Saviq: OK. I'll deal with the trivial coding stuff on trust sessions - but there are "why" questions I can't answer.
<Saviq> alan_g, sure
<AlbertA> camako: yes I see a black background on a clean image
<AlbertA> camako: on the carousel thingy
<racarr__> Morning
<anpok> hi
<camako> I'm compiling the test results for the 0.2.0 release. If anyone wants to share their results, let me know... Thank you.
<racarr__> Does anyone have a good solution for syncing working directories + some extra files (i.e. .bashrc) etc between computers
<racarr__> Trying to get laptop/desktop more seamless.
<racarr__> actually I guess technically im piddling around while android source tree builds :p
<alan_g> racarr__: I just use rsync.
<racarr__> alan_g: Mm...something transparent would be nice though
<alan_g> chron?
<alan_g> *cron
<racarr__> haha no like some magic combination of file watches and rsync
<racarr__> i.e. I am editing a file on my desktop then I come back from making tea and start editing on my laptop because who remembers what they were doing 5 minutes ago
<racarr__> and its already there
<alan_g> Ah! NFS
 * alan_g ducks
<racarr__> hahaha
<racarr__> closer...
<racarr__> I need a better offline degredation story though
<racarr__> I guess its just a distributed file system
<racarr__> clearly a job for hadoop
<anpok> git?
<racarr__> in the cloud
<racarr__> anpok: Yeah I think git is the answer lol. but I want a series of scripts to like configure certain directories to be watched
<racarr__> and handle the merging and perhaps even pop things up in my face if there are conflicts, etc
<AlbertA> racarr__: http://www.cis.upenn.edu/~bcpierce/unison/
<racarr__> AlbertA: Hey that sounds like it! Thanks
<racarr__> imma try it out this evening....
<racarr__> standup?
<racarr__> anpok: Standup ?
<anpok> racarr__: had to fiddle with usb cables of nexus 10 didnt want to stop the test
<camako> anpok: my N10 won't boot... Do you think you can run the unity8 AP test on N10 from a clean reboot?
<anpok> yup
<camako> thanks
<camako> AlbertA, would you mind running the unity8 AP test on N7 from a clean reboot?
<AlbertA> camako: sure, what's the command?
<camako> AlbertA, (on the host) phablet-test-run -n -p unity8-autopilot unity8
<camako> anpok, AlbertA (in the spirit of "a good deed never goes unpunished"   :-)  ) could you also run the browser test (also from clean reboot)?
<camako> phablet-test-run -p webbrowser-app-autopilot webbrowser_app
<AlbertA> ok
<anpok> ok
<anpok> the unity test is still running
<anpok> (had to restart because i touched the cable [again])
<anpok> http://paste.ubuntu.com/7588537/
<anpok> it looked like the unity8 instance was hanging.
<anpok> camako: ^ ... now runnig webbrowser tests
<camako> anpok, thanks... doesn't seem to happen on N4.. strange.
<camako> anpok, oh... and does this happen without mir 0.2.0?
<kdub_> alf_, with https://code.launchpad.net/~kdub/mir/unify-db-optimizations/+merge/221965/comments/531585
<kdub_> did you mean the logic in bypass.cpp or mgm::DisplayBuffer::post_renderables_if_optimizable() ?
<racarr__> lol...deadlock on cursor spike phase 4 was brackets around lock scope
<racarr__> being deleted in merge
<camako> racarr__,  yikes!
<alf_> kdub_: both I guess, it seems the code is less straightforward than it could for what it needs to do
<alf_> kdub_: (but that's only a note, not meant to be blocking)
<kdub_> alf_, sure, and I agree it still has scars from the old scene interface it was implemented around first
<anpok> camako: webbrowser tests on n10 ran OK
<camako> anpok... sounds good. Thanks for your help.
<anpok> hm can I simply downgrade
<racarr__> </lunch>
<anpok> k trying 0.1.9
<anpok> hm 6 failures o_O
<anpok> camako: http://paste.ubuntu.com/7589540/ this is from 0.1.9
<anpok> there also the same one that fails on 0.2.0 fails
<camako> anpok, wow.. I guess we're in good shape with 0.2.0 then :-)
<camako> thanks for your help
<kgunn> hey, has anyone updated from utopic and had weird cursor-jumping-around issues?
<kgunn> i'm not running xmir
<kgunn> something definitely weird
<kgunn> camako: forgot to mention, also, after we release mir0.2.0, and jenkins puts new info in the changelog on trunk...you'll need to remerge trunk back onto devel to pick that up....
<kgunn> just keep a watchful eye to make sure that's the only thing coming back onto devel (e.g. the 2 reverts shouldn't obviously)
<camako> kgunn, ack
<camako> kgunn, no need to merge it back to 0.2 branch, is there?
<kgunn> camako: nope
<camako> Thanks for everyone helping with the testing. Testing is now complete and the release is ready to be merged.
<kgunn> i'm gonna run this smemstat on my phone for the next 5 hours....lets see what happens
<racarr__>  no meeting today either?
<RAOF> racarr__: I've got a notification for one at 11?
<RAOF> racarr__: ...on next Tuesday :)
<RAOF> racarr__: So, as you were :)
#ubuntu-mir 2014-06-05
<racarr__> :)
<RAOF> Uh, why is lp:mir/devel failing 32 tests on my machine?
 * RAOF pulls again to see if it's transient.
<RAOF> Hm, no...
<RAOF> ...something fishy in the build/ directory.
<RAOF> Bah.
<RAOF> Bah. *Why* can't you find a vtable, damnit?
<RAOF> Oh, because the destructor definition is missing.
<RAOF> Good job, error message!
<alan_g> alf_: (if you're about) do you have headspace to help me think through bug 1317370?
<ubot5> bug 1317370 in Mir "[regression] [BufferQueue] BufferQueueTest.compositor_never_owns_client_buffers is very slow (up to 30 seconds) on fast machines" [Medium,Triaged] https://launchpad.net/bugs/1317370
<alf_> alan_g: sure
<alan_g> I've slightly rewritten BufferQueue::compositor_release() and instrumented the test...
<alan_g> What is happening is in the path current_compositor_buffer == buffer.get() && ready_to_composite_queue.empty()
<alan_g> If we don't release the lock and yield() then we see the slowdown
<alan_g> We don't do the slowdown if the test runs on a single core
<alan_g> s/do/see/
<alan_g> So something is slowing getting a client buffer into the ready queue - or at least making it visible to the compositor thread
<alf_> alan_g: does your instrumentation indicate any thread starvation issues?
<alan_g> When the slowdown happens the composite thread loops many more times
<alan_g> Normal:
<alan_g> DEBUG client looping: 0.014147
<alan_g> DEBUG server looping: 0.0141657, iterations: 5837
<alan_g> Slow:
<alan_g> DEBUG client looping: 10.1207
<alan_g> DEBUG server looping: 10.1208, iterations: 1922091
<alan_g> Here's the rewrite: http://paste.ubuntu.com/7593504/
<alan_g> Line 30 is the "fix"
<alan_g> Without the fix the *fewer* cores available the better. If I tie half of them up I can get
<alan_g> DEBUG client looping: 2.62574
<alan_g> DEBUG server looping: 2.62577, iterations: 509508
<alan_g> With one I get the "Normal" behaviour
<alan_g> I guess the client thread never gets a bite at the BufferQueue mutex - but there is an existing yield() while the compositor has a buffer
 * alan_g feels the facts are there and the conclusion will be obvious after it has been stated.
<alf_> alan_g: another interesting data point would be how the number of buffers in the queue affects the runtime (the test tries with 2 to 5 buffers)
<alan_g> unaffected
<alan_g> E.g. (output from each iteration)
<alan_g> DEBUG client looping: 8.67461
<alan_g> DEBUG server looping: 8.67464, iterations: 1657258
<alan_g> DEBUG client looping: 10.1207
<alan_g> DEBUG server looping: 10.1208, iterations: 1922091
<alan_g> DEBUG client looping: 7.21194
<alan_g> DEBUG server looping: 7.21197, iterations: 1391499
<alan_g> DEBUG client looping: 9.53182
<alan_g> DEBUG server looping: 9.53185, iterations: 1840078
<alan_g> Hmm. The problem scenario is when pending_client_notifications.empty() - I mis-thought that a pending notification would be the problem.
<alf_> alan_g: another data point: in my runs the primary cause of delay is waiting for client_buffer_guard at the end of the "for (int i = 0; i < 1000; ++i)" loop
<alan_g> alf_: the time is spent in contention over client_buffer_guard - the "compositor" keeps grabbing it while compositing the same buffer
<alan_g> snap!
<alan_g> alf_: thanks. I now understand what is wrong. Just need a valid test that doesn't have this issue
<alan_g> alf_: One last question: do you find the original BufferQueue::compositor_release() logic clearer or my rewrite?
<alf_> alan_g: I think the flow is a bit more straightforward in the original, i.e., if (can_and_should_replace_current) { do replace } if (should_release) { do release }
<alan_g> alf_: OK, I'll leave it alone
<kgunn> Saviq: if you're on, we had to rebuild/retest mir due to earlier mess up with ci train and papi2.0
<kgunn> but with hardly any change to our silo we're seeing lots of failures, is this expected? (due to "Define XDG_*_DIRS so that autopilot tests don't have to (and thus caused failures in unity8 autopilot)"
<Saviq> kgunn, fix for that just landed
<Saviq> kgunn, upgrade ubuntu-touch-session and reboot
<kgunn> thanks
<kgunn> AlbertA: anpok_ camako ^
<kgunn> rather than dist-upgrdae
<camako> kgunn, ack
<ogra_> Saviq, its still in proposed
<Saviq> ogra_, huh?
<ogra_> oh, i'm lying ... migrated this second
 * ogra_ starts an image build 
<Saviq> ogra_, yeah, I just cleared the silo :)
<Saviq> ogra_, says 25 minutes ago, not this second ;)
<ogra_> Saviq, argh
<ogra_> you wiped it
<ogra_> Saviq, its gone from proposed
<Saviq> ogra_, wdym? https://launchpad.net/ubuntu/+source/ubuntu-touch-session
<Saviq> ogra_, if anything, the train let me do something wrong
<Saviq> ogra_, having first informed me that I could
<ogra_> Saviq, if you clean before it moved from proposed (which it had not) then it vanishes
<Saviq> ogra_, wha? LP says it's there...
<Saviq> ogra_, train doesn't let you merge+clean unless it's in the destination
<Saviq> ogra_, I didn't "wipe_only"
<ogra_> Saviq, seems rmadison had a hiccup or something
<ogra_> never trust LP
<Saviq> ogra_, https://ci-train.ubuntu.com/job/landing-002-3-merge-clean/7/parameters/
<ogra_> the LP page tells you it migrated before it actually did
<Saviq> ogra_, tell the train that :|
<ogra_> that uses rmadison i hope
<ogra_> anyway, triggering a build ... 69 should be ready in ~1.5h with the fix
<camako> kgunn ^^
<kgunn> wow
<camako> kgunn, I'm just gonna test pre-0.2.0 (without unity8 fix)
<camako> we should get the same failures
<kgunn> camako: ack
<kgunn> ogra_: i think i have a new theme song for ci-train
<kgunn> http://www.youtube.com/watch?v=3MLp7YNTznE
<ogra_> kgunn, sadly blocked in germany :P
<kgunn> Ozzy Osbourne "Crazy Train"
 * ogra_ humms along 
<ogra_> :)
<kgunn> lol
<kgunn> me too
<kgunn> "its crazy,  but that's how it goes"
<ogra_> yeah
<AlbertA> lol...
<AlbertA> "Im going off the rails on a crazy train"
<anpok_> Saviq: thx
<fginther> josharenson, what is needed to run the glmark2 tests on a freshly flashed touch image?
<josharenson> fginther 1 min. making a pastebin
<fginther> thx
<josharenson> http://pastebin.ubuntu.com/7597245/
<josharenson> fginther ^
<fginther> josharenson, thx
<fginther> josharenson, do you know what package provides mir_performance_tests?
<josharenson> its part of the mir test suite
<josharenson> fginther ^
<fginther> josharenson, thx
<racarr__> :) Got some new fake event hub capabilities
<racarr__> synthetic touchscreens of various configurations
<AlbertA> anpok: yeah you were right the osk top letters was alpha^2 issue
#ubuntu-mir 2014-06-06
<DonkeyHotei> so i installed unity8-desktop-session-mir like you said, and now i get only a text console
<DonkeyHotei> oops, bad copypaste
<DonkeyHotei> anyway, does mir have logs?
<RAOF> DonkeyHotei: You can find some in /var/log/lightdm and ~/.cache/upstart/
<DonkeyHotei> RAOF: looks like lightdm and plymouth just aren't even started anymore
<DonkeyHotei> can someone tell me what's going on?
<DonkeyHotei> nvm
<anpok> yay egl_configs
<anpok> +no
<alan_g> greyback: Saviq - thoughts? https://code.launchpad.net/~vanvugt/mir/fatal-error/+merge/219471/comments/532638
<chrisccoulson> does the mir egl backend in mesa support pbuffer surfaces?
<chrisccoulson> actually, I think I already know the answer to this
<greyback> alf_: you there?
<alf_> greyback: yes
<greyback> alf_: quick question: if I turn on framedropping for a Surface,does swap buffers block for vsync or not?
<alf_> greyback: it should not block, are you seeing something different? (why are you enabling framedropping?)
<greyback> alf_: I'm not, I just wanted to know how it behaves
<greyback> alf_: so with Mir's renderer, if a surface is not visible, it is still the compositor that consumes the un-composited buffers generated by the client?
<alf_> greyback: In mir/devel the BufferQueue for a client drops buffers itself, so the compositor is no longer involved
<alf_> greyback: s/client/client surface/
<greyback> alf_: oh that's great
<DonkeyHotei> i get a black screen when i select the mir session in lightdm, how to troubleshoot?
<DonkeyHotei> hello?
<bschaefer> DonkeyHotei, for unity8 desktop session mir? On utopic? Or Trusty?
<DonkeyHotei> trusty
<bschaefer> check ~/.cache/upstart/unity8-*
<bschaefer> should complain about something
<bschaefer> or
<DonkeyHotei> i'll pastebin it
<bschaefer> /var/log/lightdm/unity-system-compositior
<bschaefer> .log
<DonkeyHotei> bschaefer: http://pastebin.com/YNB1qirT
<bschaefer> DonkeyHotei, what version of lightdm are you running?
<DonkeyHotei> whatever trusty has
<bschaefer> as I *think* there was a fix put out for that in 1.11.3
<bschaefer> DonkeyHotei, apt-cache policy lightdm
<DonkeyHotei> 1.10.1-0ubuntu1
<bschaefer> as if you are running unity-system-compositor version 0.3, and only lightdm version 1.11.2 you'll get a black screen
<bschaefer> hmm
<bschaefer> could you do apt-cache policy unity-system-compositor
<DonkeyHotei> 0.0.2+14.04.20140411-0ubuntu1
<bschaefer> DonkeyHotei, shouldn't be the issue then
<bschaefer> DonkeyHotei, looking at bugs: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1304959
<ubot5> Ubuntu bug 1304959 in unity8 (Ubuntu) "unity8 crashed with SIGABRT in qt_message_fatal()" [Critical,Won't fix]
<bschaefer> that one seems to match your assert
<bschaefer> in your log
<bschaefer> the
<bschaefer> ASSERT: "(eglContext_ = eglCreateContext( eglDisplay_, screen->eglConfig(), share ? share->eglContext() : EGL_NO_CONTEXT, attribs.constData())) != EGL_NO_CONTEXT" in file ../../../../src/platforms/base/context.cc, line 63
<bschaefer> bit
<bschaefer> so its failing to create an eglContext :(
<bschaefer> DonkeyHotei, did you have this working before?
<DonkeyHotei> no
<bschaefer> DonkeyHotei, it might be worth while to post on the bug report that you can reproduce this issue with your specs + unity8-mir log
<bschaefer> to hopefully get something rolling agian
<bschaefer> again*
<DonkeyHotei> here is /var/log/lightdm/unity-system-compositior.log:
<DonkeyHotei> GL_VENDOR = Intel Open Source Technology Center
<DonkeyHotei> GL_RENDERER = Mesa DRI Intel(R) 945GME x86/MMX/SSE2
<DonkeyHotei> GL_VERSION = OpenGL ES 2.0 Mesa 10.1.3
<DonkeyHotei> dm_connection_start
<DonkeyHotei> Unable to set active session, unknown client name
<DonkeyHotei> set_active_session 'x-0'
<DonkeyHotei> set_active_session
<DonkeyHotei> set_active_session 'session-0'
<DonkeyHotei> set_active_session
<DonkeyHotei> Unable to set active session, unknown client name session-0
<DonkeyHotei> pause
<bschaefer> DonkeyHotei, yeah, the unity8-mir log tells us what the issue is
<bschaefer> it hit an ASSERT because it was unable to create an egl context
<bschaefer> (which is pretty bad)
<DonkeyHotei> i can't change the status from won't fix
<bschaefer> yes, but adding comments helps others see its still an issue (with other machines?)
 * bschaefer will be back in ~15 min
<DonkeyHotei> bschaefer: found this too: https://bugs.launchpad.net/mir/+bug/1275398
<ubot5> Ubuntu bug 1275398 in Mir "i945: Mir GL clients are rendered as black or transparent windows when using i945 graphics" [High,Triaged]
<bschaefer> DonkeyHotei, yours is a bit different, thats a black screen but the eglContext is still being created
<bschaefer> in your case, you hit an assert and the program stops running
<bschaefer> (so you wont get the FPS stdout)
<bschaefer> DonkeyHotei, i moved that other bug back to confirmed, as if its old hardware, its still an issue
<bschaefer> vs a "We wont fix" but it wont be a focus atm though
<DonkeyHotei> the won't fix was set by the original reporter
<bschaefer> yes, which doesn't make much sense either, as its still confirmed :)
#ubuntu-mir 2014-06-07
<RAOF> chrisccoulson: No, no pbuffers. Presumably Chromium wants them?
<chrisccoulson> RAOF, see bug 1307709
<ubot5> bug 1307709 in mesa (Ubuntu) "webbrowser-app does not start in Unity 8 preview session" [High,Triaged] https://launchpad.net/bugs/1307709
<chrisccoulson> I don't really need them anymore
<RAOF> Good, good.
<RAOF> surfaceless contexts FTW
#ubuntu-mir 2015-06-01
<RAOF> What are our thoughts re: Boost::Signals?
<RAOF> No! Bad Chris!
<RAOF> No writing a half-assed implementation of C# events in C++!
<anpok_> RAOF: depends
<RAOF> On? :)
<anpok_> i guess depends on how you use it and
<anpok_> especially when you emit signals
<alan_g> kdub: can I tempt you to review this? https://code.launchpad.net/~alan-griffiths/mir/helptext-mentions-config-file/+merge/260439
<kdub> sure
 * kdub groans about our server initiated ipc being raw bytes
<alan_g> kdub: @"Recommending $XDG_RUNTIME_DIR" You mean adding "(E.g. $XDG_RUNTIME_DIR)"?
<kdub> alan_g, yeah
<alan_g> How else do you send a union? :^)
<kdub> haha, I just remember all the times I had to look up that env variable name many moons ago, but fine with the text as-is
<alan_g> Actually $XDG_CONFIG_HOME
<alan_g> I think
<bschaefer> racarr, if i get an event log from a unity8 app, those mir events are before it touches anything qt/mir related? Or after it goes through qt/mir and back to the client?
<bschaefer> as this is what im seeing when testing out repeating key through unity8 desktop: http://paste.ubuntu.com/11441144/
<bschaefer> i just get a bunch of ups
<bschaefer> looking at qt/mir it doesnt seem to support repeating key (all it supports is turning repeat into a down key)
<racarr> MIR_CLIENT_INPUT_RECEIVER_REPORT run on unity8 would output the stream before
<racarr> qt stuff yeah
<bschaefer> racarr, sooo that means mir it self is sending all the up events?
<bschaefer> strange...as this only fails when running through unity8 desktop
<bschaefer> if i run a mir server from mir-demos, the repeat key works
<bschaefer> (which should use the same libs as unity8 desktop)
<bschaefer> racarr, theres this bug report: https://bugs.launchpad.net/qtmir/+bug/1420271
<ubot5> Launchpad bug 1420271 in QtMir "Missing events in qtmir with the port-to-event-2.0 branch" [Undecided,New]
<bschaefer> which supports what im seeing as well
<racarr> bschaefer: Sorry I've been getting some flack about not finishing my own assigned stuff lately so I'm not really paying attention...I can take it in my backlog :)
<bschaefer> racarr, sorry! I can try to take a look as well but for the most part i just need to make sure its not the patch im making for sdl1.2
<bschaefer> racarr, thanks!
<racarr> I think as long as the output from mir demos is safe you are fine...and I can track the bug.
<bschaefer> racarr, sounds good
<racarr> I'm pretty sure it must be broken in qtmir -.-
<racarr> but maybe laso in mir!
<bschaefer> its a bit of a strange event loop :)
<bschaefer> cool soo i can get the sdl1.2 patch finally proposed :)
<racarr> :D
<RAOF> Actually, that should totally be here:
<RAOF> I propose that we build a bikeshed! https://code.launchpad.net/~raof/mir/optional-check-precondition/+merge/260672
#ubuntu-mir 2015-06-02
<RAOF> Hm. Has anyone else noticed the arale backlight not being turned off?
<duflu> RAOF: Historically when that happens on any device most people don't notice :)
<duflu> But it's not good
<RAOF> Oh, well. LP# 1460898 filed.
<RAOF> Oh, hey.
<RAOF> Our GMainLoop alarm implementation blatantly ignores the specified behaviour of various calls.
<RAOF> I'm pretty sure I relied on that behaviour in the FrameDroppingPolicy...
<anpok> hm?
<anpok> RAOF: I think something like SceneObserver could be replaced in a nicer way with signal/slot
<RAOF> anpok: This is indeed what I was thinking, yes.
<RAOF> anpok: Oh, AlarmImpl unconditionally returns true on cancel() (even if it didn't actually cancel), and likewise on reschedule.
<RAOF> While the documentation says that they return true iff they cancelled something, rescheduled a pending alarm respectively.
<anpok> in a previous system signal(event) / slot registrations with functor objects were the #1 memory consumers
<anpok> but there we had hundreds of them
<anpok> and most of them did not fit into the functor payload..
<anpok> oh
<alan_g> alf_: happy now? https://code.launchpad.net/~alan-griffiths/mir/helptext-mentions-config-file/+merge/260439
<alan_g> greyback: tvoss do we want to reschedule the WM discussion? When?
<greyback> alan_g: today is bad for me, am traveling. Wed & Thurs my timetable is uncertain, lots of meetings. Friday traveling again!
<alan_g> greyback: OK. np.
<greyback> best I can do is next week, Wed the earliest
<alan_g> Fine by me. Today I'm more interested in how lp:~alan-griffiths/mir/only-visible-surfaces-change-scene/ might affect Qt clients and qtmir.
<greyback> alan_g: let me have a look and I'll get back to you
<tvoss> alan_g, we definitely should, next Wednesday is fine by me, too
<kdub> alan_g, fixed the test name on: https://code.launchpad.net/~kdub/mir/multistream-protobuf-additions/+merge/259970
<alan_g> kdub: TA'd
<kdub> thanks alan_g
<racarr> kdub: I've also run in to some problems with the event RPC lately...
<kdub> racarr, which sort of problems?
<racarr> kdub: oh I guess just that the memcpy to a flat buffer doesn't work for
<racarr> some of the event cleanup I am doing as well
<racarr> whic hsort of relates to your can't pass FD's over events perhaps
<kdub> racarr, right, so if i'm scrubbing may as well scrub in a way thats helpful to that concern too
<kgunn> vogons any running mir on nouveau lately ?
<kdub> intel for me
<camako> kgunn, yes I am on nouveau
<kgunn> popey: ^
<kgunn> camako: i think popey is trying to run unity8-desktop-session-mir on  nouveau
<popey> gah, just logging into unity7 with nouveau gives me 1280x1024 not 1920x1080 :(
<kgunn> i was telling him, mir + nouvea might be ok
<kgunn> camako: so i figure your probably running mir+nouvea frequently
<camako> kgunn, I'm not running U8 dektop session recently
<kgunn> right...so problem might lie in the unity8 part
<camako> kgunn, just mir
<camako> and examples
<kgunn> sure
<kgunn> so popey, that answers that ^
<popey> hmm, sudo mir_demo_server fails
<popey> failed to load libraries from path /usr/lib/x86_64-linux-gnu/mir/server-platform
<popey> following http://unity.ubuntu.com/mir/using_mir_on_pc.html Running Mir natively
<popey> kgunn: so if I want to actually test Unity8 (specifically apps) what am I to do? Buy an intel laptop / tablet?
<kgunn> popey: that might be easier :-P but seriously, let's see if we can get you some help....what's your gpu ?
<kgunn> camako: ^ can i leave popey in your capable hands...
<popey> nVidia GeFprce GTX 460
<popey> *GeForce
<camako> kgunn, don't really work on U8 desktop, so not sure how helpful I can be
<kgunn> camako: he's failing on mir-demo-server
<kgunn> please read
<camako> kgunn, ah ok
<camako> sorry
<camako> popey, are you running in a vt?
<popey> http://paste.ubuntu.com/11524763
<popey> yes
<camako> popey, let's step back, did you install the packages yourself? Or running from binaries you built from the tree?
<AlbertA> popey: is this mir 0.13?
<popey> i have a clientplatform in /usr/lib/x86_64-linux-gnu/mir but not a server-platform
<popey> this is on wily, from repo
<AlbertA> popey: apt-get install mir-platform-graphics-mesa2
<popey> maybe I'm missing a package?
<kgunn> ah yeah..isn't there a dumb issue about having to install graphics platform
<popey> ok, it fails differently now :)
<popey> http://paste.ubuntu.com/11524864/
<kgunn> popey: i had to do this the other day, i did apt-get install mir-graphics-drivers-desktop
<popey> ok
<popey> same error after doing that
<camako> popey do you have drm devices in your system?
<camako> ls -l /dev/dri <<---
<popey> ls: cannot access /dev/dri: No such file or directory
<camako> popey that's the problem
<camako> camako@camako-MacBookPro:~$ ls /dev/dri/
<camako> card0       card1       controlD64  controlD65  renderD128  renderD129
<camako> popey ^ ... mir needs card* devices to run
<camako> popey, kernel version?
<popey> Linux wopr.popey.com 3.19.0-20-generic #20-Ubuntu SMP Fri May 29 10:10:47 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
<camako> popey at the top of the "Running Mir natively" page there are checks for hw
<camako> what do they return?
<popey> oh, i skipped that bit because kgunn told me to do the Running Mir natively bit, sorry.
<popey> http://paste.ubuntu.com/11524937/
<camako> popey, so I guess you don't really have a nouveau driver
<camako> camako@camako-MacBookPro:~$ lsmod | grep drm
<camako> drm_kms_helper        122880  2 i915,nouveau
<camako> drm                   344064  9 ttm,i915,drm_kms_helper,nouveau
<camako> camako@camako-MacBookPro:~$ sudo pmap `pidof X` | grep dri.so
<camako> [sudo] password for camako:
<camako> 00007fb9b76e5000   7620K r-x-- nouveau_dri.so
<camako> 00007fb9b7e56000   2048K ----- nouveau_dri.so
<camako> 00007fb9b8056000    348K r---- nouveau_dri.so
<camako> 00007fb9b80ad000     48K rw--- nouveau_dri.so
<popey> :(
<camako> popey, I'm surprised your distro doesn't have it.... I guess it should be as simple as installing xserver-xorg-video-nouveau package... But proceed cautiously as you're meesing with the video driver
<popey> ii  xserver-xorg-video-nouveau  1:1.0.11-1ubuntu2b amd64              X.Org X server -- Nouveau display driver
<popey> it _is_ installed
<popey> I'm on Ubuntu 15.10 (wily)
<popey> aha, it's not being used. It's using FBDEV!
<camako> popey, I'm still on vivid... perhaps this is a new (wily) nouveau issue
<popey> that's why the resolution is wonky I guess.
<popey> hmmm
<camako> popey, some help here : http://nouveau.freedesktop.org/wiki/UbuntuPackages/
<popey> aha https://wiki.ubuntu.com/X/Troubleshooting/VideoDriverDetection#Problem:__Need_to_fully_remove_-nvidia_and_reinstall_-nouveau_from_scratch
<popey> need to _re_ install nouveau
<camako> there you go...
<popey> thanks for the help!
<camako> yw
<popey> silly software :)
<popey> has mir_socket moved? I don't see it in /tmp
<popey> aha! /run/user/1000/mir_socket
<popey> Ok, so I have managed to get mir running, and ran a mir demo (mir_demo_client_eglplasma)
<popey> so we have proved the video driver works now.
<bschaefer> is there  a way to poke for the ABI version of mir?
<bschaefer> with the new mir lib, i need to check what version of code I compile depending on the ABI version
<popey> rebooting to lightdm, and choosing unity8 lxc session fails though.
<popey> bunch of apparmor failures... http://paste.ubuntu.com/11525449/
<popey> balloons: you tried this?
<camako> bschaefer, mir version is printed to stdout (by default)
<bschaefer> camako, ill need it through configure.ac though, is there a function that prints out the version?
<bschaefer> there seems to be: mir_toolkit/version.h:65:    MIR_VERSION_NUMBER(MIR_CLIENT_MAJOR_VERSION, \
<camako> bschaefer, there is a cmake variable MIR_VERSION
<bschaefer> camako, o cool, thanks!
<camako> yw
<bschaefer> that works for cmake :), ill have to hack something for autogen
<AlbertA> camako: alan_g|EOD: so the qtubuntu updates to match mir 0.13 made it to wily right?
<AlbertA> shouldn't the branch be merged then?
<camako> AlbertA, kgunn said that LT was investigating why it didn't get merged
<camako> yes it should be merged
<kdub> after the buffer semantics changes, we dont really have a stream anymore... but will cross that bridge later
<AlbertA> camako: so should we merge it manually? or do we need to ask somebody?
<camako> AlbertA, I am assuming LT will do it once they are through with their investigation. kgunn
<camako> kgunn ^^
<AlbertA> camako: ok...who is LT though?
<kgunn> camako: AlbertA so we added that MP to the rotation silo4, mzanetti is working on landing it....which should merge it
<camako> AlbertA, landing team
<kgunn> is there another issue currently ?
<AlbertA> camako: kgunn: ok...
<AlbertA> kgunn: no just want to rebase my branch
<AlbertA> @vogons: since technically we broke client API in mir 0.13.1 (like mir_surface_set_event_handler), the client/mir_toolkit/version.h should have bumped it's major number right?
<RAOF> Yes. I thought we did the backwards-compatibility symver trick for that, though?
<AlbertA> RAOF: yes we did
<AlbertA> so I'll be attempting a mir 0.13.2 for entirely unrelated reasons (have to get the vegetahd quirk in)...
<AlbertA> was wondering if I should fix it then.
<RAOF> Oh, but we don't expose both in the API, right.
<RAOF> Yeah, we should have bumped version.
<RAOF> Otherwise there's no good way for client code to know what to build against.
<AlbertA> RAOF: right which is what bschaefer wanted
<racarr> and robert_ancell!
<RAOF> Ding!
<robert_ancell> yep
<AlbertA> vogons: ok so mir 0.13.2 =  client 2.0.0, and lp:mir: client 3.0.0 since we broke for good there ?
<bschaefer> thanks!
<AlbertA> @vogons: just FYI I've requested a silo for mir 0.13.2 - with the intention of landing to vivid+overlay and wily
<camako> AlbertA, sounds good. The freeze should be over soon.
<camako> AlbertA, is only Mir in the silo?
<AlbertA> camako: yes. with only the vegetahd quirk and the client API version fix
<camako> great
<AlbertA> camako: https://code.launchpad.net/~mir-team/mir/0.13/+merge/260902
<camako> ok
<bschaefer> strange crash... http://paste.ubuntu.com/11531043/ only seems to fail on SDL2 tests (if i run my own SDL2 app it works fine)
<bschaefer> something in dynamic loader must be doing something strange...hmm
#ubuntu-mir 2015-06-03
<RAOF> bschaefer: Well, that looks like protobuf being unnecessarily hateful.
<RAOF> Do you at any point dlclose anything? :)
<bschaefer> RAOF, yeah when we UnLoad the object
<bschaefer> RAOF, hmm i wonder if its failing then does a Unload then gives me a nothing stack trace
<RAOF> So, I'm not entirely sure how nicely protobuf is going to play with load/unload cycles.
<bschaefer> RAOF, o...
<bschaefer> hmm
 * bschaefer tests if its right before the unload
<bschaefer> RAOF, the thing is, im getting the stack trace on a DLOpen
<bschaefer> soo it never actually hits the UnLoad
<RAOF> Has it previously done an unload, though?
<bschaefer> RAOF, not that i saw (had print statements)
<bschaefer> RAOF, yeah no unload
<RAOF> Ok, so it's probably not a âthe second time you load protobuf it explodesâ problem.
<bschaefer> RAOF, naw, i actually have an example of that working :)
<popey> Does anyone know if Mir runs on the Acer C720 chromebook?
<popey> http://www.reddit.com/r/chrubuntu/comments/1yd74w/c720_has_anyone_managed_to_get_the_touchpad/cfk4cjw suggests it does, but that's a year old
<alan_g> popey: I've no idea. But if e.g. Unity7 works well (I don't know that either) then I'd expect the drivers to be good enough for Mir.
<popey> alan_g: i have seen videos of unity 7 running on it, so could be.
<alan_g> In that case, it probably works. But I don't know of anyone who can try it. Why are you asking?
<popey> alan_g: just looking for a device I can test mir / unity 8 on
<popey> trying yesterday on my nouveau nvidia desktop was less than successful
<alan_g> :-/
<alan_g> I've an intel setup, but can try to help. (If you didn't get help yesterday.)
<popey> I installed the unity8-lxc package and set that up, then logged out and when i try to login it seems to start the session but I end up with a blank desktop
<popey> I can see lots of interesting processes running - unity related
<popey> willcooke: how good is unity8 / desktop-next wily? Is it known broken?
<willcooke> popey, the original Desktop Next - the one based on .debs is, I'd say, unmaintained right now.
<willcooke> The new one based on Snappy is a work-in-progress
<willcooke> seb128 was having a few issues getting it to boot, but they're being worked through atm
 * popey wonders which one unity8-lxc installs
<popey> http://cdimage.ubuntu.com/ubuntu-desktop-next/daily-live/ gets it from there
<willcooke> yeah
<willcooke> try this URL instead:
<popey> is that deb or snappy?
 * willcooke looks for the URL
<willcooke> deb
<popey> this isn't going to work I don't think
<popey> via unity8-lxc anyway
<willcooke> http://cdimage.ubuntu.com/ubuntu-desktop-next/backup-20150422/
<popey> is that something I can dd onto a usb stick and boot from willcooke ?
<willcooke> yah
<popey> ok
<kgunn> camako: hey look...you got one you asked for (i think this was your idea)
<kgunn> https://code.launchpad.net/~cjwatson/launchpad/bmp-show-diffstat/+merge/260921
<kdub> gah! client code
 * alan_g wonders which client
<kdub> src/client/
<camako> kgunn, o cool
<alan_g> kdub: AlbertA - you guys approved an earlier version, but I've added stuff. Could you re-review? https://code.launchpad.net/~alan-griffiths/unity-system-compositor/debug-without-dm/+merge/247815
<kdub> alright
<kdub> that mircommon abi thing has been pushed to lp:mir, right? (about to kick off some CI)
<alan_g> kdub: yes
<kdub> mk, thanks
<kdub> @vogons, any more takers on: https://code.launchpad.net/~kdub/mir/add-streams-to-surface/+merge/259776 ?
 * kdub will merge it shortly if no
<kdub> thanks AlbertA
<AlbertA> @vogons, good wiki page to understand the image channels when flashing devices: http://developer.ubuntu.com/en/start/ubuntu-for-devices/image-channels/
 * camako bookmarks it
<AlbertA> and recovery images (needed for ubuntu-device-flash) krillin: http://people.canonical.com/~jhm/barajas/recovery.img
<AlbertA> vegetahd: http://people.canonical.com/~jhm/barajas/recovery-vegetahd.img
<AlbertA> arale: http://people.canonical.com/~alextu/tangxi/recovery/recovery.img
<camako> all over the place
<bschaefer> are there any examples/demos for dlopening libmir and running it that way?
 * bschaefer has some for SDL2 but now they are failing...on a crash in dlopen through protobuff
<AlbertA> bschaefer: libmirclient?
<bschaefer> AlbertA, yeah, i forgot i had a different example for dlopening mir and its working :(
<bschaefer> the crash i see in SDL2: http://paste.ubuntu.com/11531043/
<bschaefer> and the example that doesn't crash on mir: https://github.com/BrandonSchaefer/RA/blob/master/src/linux/RA_mir_driver.c
 * bschaefer has to dig some more through SDL2
 * bschaefer wonders if it gets angry after trying to open libmirclient a second time
<AlbertA> bschaefer: umm looks like: https://bugs.launchpad.net/mir/+bug/1391976
<ubot5> Launchpad bug 1391976 in mir (Ubuntu) "Loading libmircommon.so twice leads to a segfault in libprotobuf.so" [High,Confirmed]
<bschaefer> AlbertA, shoot, that'll be fun to get around... i need to look into why SDL2 likes to load it twice
<bschaefer> AlbertA, as thats what it does atm
<bschaefer> AlbertA, thanks! I should have looked for a bug :)
<bschaefer> (though it doesn't do a close in my example from what i see
<bschaefer> i could have missed it though... i should double check as RAOF asked about that yesterday as well
<bschaefer> eeek it is doing an unload before loading again
<AlbertA> bschaefer: but it's there a path where you load libmirclient and close it and then load it again?
<bschaefer> AlbertA, so yes it is that bug, ill make a comment, thanks again
<AlbertA> bschaefer: ok
<bschaefer> yeah it needs to load the libraries in to test for 3d acceleration
<bschaefer> then unloads, then loads again when the app starts
<bschaefer> fun
<kgunn> AlbertA: hey so the qtubuntu mir backend update you're working on, will that address the multiwindow aspect i was questioning earlier ?
<AlbertA> kgunn: yeah it will use the apis we currently have
<AlbertA> for menus/dialogs
<kgunn> awesome
<AlbertA> not quite sure how tooltips behave yet
<AlbertA> in qt
<kgunn> AlbertA: are you basically using Qt creator as your test bed?
<AlbertA> kgunn: and some simple qml tests apps too
<infinity> Hey, did whoever added the new abi-compliance-checker build-dep to Mir think of filing an MIR for it (it's in universe)?
#ubuntu-mir 2015-06-04
<RAOF> infinity: Huh, sorry. I didn't notice us adding that to Build-Deps. :(
<RAOF> Grr, wireless.
<infinity> RAOF: Oh hai.
 * RAOF has just given up on working out why wifi is continuously associationg and disassociating and has just gone cat5
<infinity> RAOF: BTW, I'm about to push an MP to build on PPC.  I assume that even if that lands on trunk, if I want this in the distro in a timely fashion, I need to land it elsewhere too?
<RAOF> That's... a fair question.
<RAOF> I think you actually just want to land on trunk and do a manual upload to distro.
<infinity> RAOF: I can just upload directly, of course, but since it touches the orig, that's a bit annoying.
<infinity> Well, annoying if someone else does something goofy on top.
<infinity> But yeah, I can just do that.
<RAOF> You shouldn't *need* to touch the .orig, right? It should be patchable.
<RAOF> But trunkâdistro is a fair distance for us.
<RAOF> Or, at least, is a manual step.
<infinity> RAOF: No, I need to re-roll the orig because of the stupid binary data in the testsuite.
<infinity> RAOF: Which I've already done, FWIW, so no big deal.
<RAOF> Copy it from debian/ :) ?
<infinity> RAOF: So, uhm.  Gross.
<RAOF> :P
<infinity> RAOF: Oh, and still wouldn't work, cause it's a v1 package.
<infinity> RAOF: If diff can't represent it, you lose.
<RAOF> Seriously? We don't set v3? Sadface.
<RAOF> Yeah, the binary data is somewhat annoying, but I don't see a way around it.
<infinity> RAOF: It's not world-ending.
<infinity> RAOF: In another MP, I might add a few more Debian arches (ppc64, s390x, etc) for potential future-proofing.
<RAOF> AlbertA: Have you rolled 0.13.2 yet? Could we roll infinity's changes into it for convenience?
<infinity> RAOF: https://code.launchpad.net/~adconrad/mir/powerpc-porting/+merge/261055
<infinity> RAOF: And, of course, I'd love to do a direct upload, but it'll end up dep-wait because of your new build-dep.  Grr.
<infinity> I guess I can cheat with a PPA, since that's how you guys got it in there in the first place. :P
<RAOF> Oh, ooooh.
<RAOF> Yay multiple parallel semi-synched processes!
<infinity> RAOF: Hrm.  Now that I think about future-proofing, I should probably invert pretty much every arch spec in there.
<infinity> RAOF: As in, x86 and armhf are actually the unique snowflakes, and linux-any should be the norm.
<RAOF> Yeah.
<infinity> RAOF: But I can worry about that when I add more arches later.
<RAOF> I've also added a todo card to make the testsuite not fail on archs we don't have a lib$ARCH.so for, which should make adding more archs easier.
<RAOF> We can then opportunistically add lib$ARCH.so blobs.
<infinity> RAOF: Would be slick if the test code was generated on the fly based on `ls -1 test_data/*.so` so enabling that test was just a matter of dropping the blob in without editing code.
<infinity> RAOF: Then, on arches that don't ship the blob, you could just generate one on the fly.
<RAOF> infinity: Actually, we could always generate one on the fly...
<infinity> RAOF: Right, you can generate one on the fly, but see the note about the code needing manual mangling right now. :)
<RAOF> Yeah.
<infinity> RAOF: Fix the code to be dynamic based on the available content, then make the testsuite depend on libarch.so with a rule to make it if it doesn't exist, and done.
<infinity> RAOF: THen someone can just add them later.
<RAOF> Oh, by the way, what are our big-endian failures? I thought we were paying attention to endianness :(
<infinity> RAOF: Anyhow, I think I'll build this in a clean PPA and copy it in, and let you guys deal with the fallout, since I have no clue how you go from bzr to distro branches to uploads.
<RAOF> Convolutedly.
<infinity> RAOF: There's one function that no one ported, and intentionally bails because of it.
<infinity> http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/src/server/scene/gl_pixel_buffer.cpp#L59
<RAOF> Oh, hah.
<RAOF> At least it fails at compile time, then :)
<infinity> RAOF: It's probably not hard to port, but I imagine it might take pen and paper and a bit of thought.
<infinity> RAOF: No, it compiles fine.  Just fails the testsuite.
<RAOF> Hm, no. At least it dies at runtime rather than giving incorrect results.
<infinity> RAOF: Also, my OpenGL is weak, but I vaguely recall that it's little-endian across the board (much like network is always big-endian), so it's really just a matter of GL<->host swaps if you intend to operate on things using the host CPU.
<infinity> RAOF: At least, that sounds like a familiar thing from a past life.
 * infinity double-checks there's no taint in his PPA and uploads the wily package.
<RAOF> That's the class that's doing GPUâCPU translation, so it does actually need some work. :)
<infinity> RAOF: Oh, also, not sure who maintains the toolkit integration bits (eg: gtk3 links to libmirclient), but enabling that on powerpc while Mir is known-broken might be dumb. ;)
<RAOF> It'd actually be fine - that's a server-side issue, and all the toolkit integration is client-side.
<infinity> Oh, that's good news.
<RAOF> So it'd be not very useful, because no-one could run ppc GTK against a Mir server, but it'd equally be harmless.
<infinity> RAOF: Right, if the client stuff is all harmless, then I guess once this lands, we can slowly stop arch-restricting the world.
<RAOF> Yes.
<infinity> RAOF: And put "fix the endian bug" on the TODO before someone decides a Mir server on a BE arch is fun.
<RAOF> armhfbe!
<infinity> RAOF: Well, I intend to sent a followup to enable ppc64 and s390x at some point.  At which point, I'll switch that testsuite-disabling to check for DEB_HOST_ARCH_ENDIAN instead of DEB_HOST_ARCH, and clean everything up so that !x86/!armhf is the norm, and those unique snowflakes get their own brand of special.
<infinity> s/sent/send./
<infinity> RAOF: So, then we'll have 3 BE arches.
<RAOF> And I'll have the testsuite do the generate-a-dso thing soon.
<infinity> RAOF: Sure.  Doesn't block me doing those two, since I'll generate the .so on Debian porter boxes, but still nice future-proofing.
<infinity> Actually, I may as well just add all the Debian non-ports arches while I'm in there.
<infinity> So, armel, mips, mipsel,  s390s, sparc, ppc64.
<infinity> I assume Mir is Linux-specific, and attempting to build it on kfreebsd or hurd would end in tears?
<bschaefer> make snap fails in lp:mir :(
<bschaefer> http://paste.ubuntu.com/11554636/
<infinity> mir_0.14.0_amd64.snap: FAIL
<infinity> Generated 'mir_0.14.0_amd64.snap' snap
<infinity> Brilliant.
<infinity> IT BROKE, HERE'S A PACKAGE.
<bschaefer> infinity, yeah haha i tried installing it as well
<RAOF> :)
<RAOF> I think deb2snap is a better bet for the moment.
<bschaefer> it didnt install anything that i could find haha
<bschaefer> RAOF, i was just trying the 0.12 branch
<bschaefer> if that fails... ill look into that :)
<RAOF> infinity: We use epoll and such; it's linux-any, yes.
<bschaefer> eek 0.12 doesnt have snappy in ith
<bschaefer> it*
 * bschaefer tries copying lp:mir snap
<infinity> RAOF: Kay, noted.  Next time I'm bored, I'll submit that MP to enable it on effectively all linux-any, then.
<RAOF> bschaefer: deb2snap; it's how we built the demo snap.
<bschaefer> RAOF, o nice, yeah just saw it https://launchpad.net/deb2snap
<bschaefer> RAOF, hopefully it still works :)
<RAOF> It worked a couple of days ago :)
<bschaefer> RAOF, excellent :)
<bschaefer> thanks!
<infinity> RAOF: Other than fixing the testsuite and adding blobs (I'll whip those up later), this looks like it should fix the arch brain damage: http://paste.ubuntu.com/11555020/
<RAOF> WTF is install_ld_so_conf.sh there for?
<infinity> RAOF: ellifiknow.
<RAOF> I'm *pretty* sure that's unnecessary now.
<infinity> RAOF: rgrep doesn't seem to find any references to it...
<RAOF> Hm. I guess we just didn't delete the various workaround helpers when we fixed the platform loading code.
<infinity> RAOF: Well, I'll leave that to you to delete. :P
<RAOF> Yeah, will do.
<infinity> RAOF: I'll push this as a formal MP after the current one's merged, and once I get a bunch of blobs and twiddle the testsuite to match them.
<RAOF> I'll be proposing the dynamic blob generation before you do.
<RAOF> (It's almost finished)
<infinity> RAOF: Including dynamic code?  Shiny.
<RAOF> Yeah. The dynamic code is done, just need the cmakery to generate libARCH.so
<infinity> RAOF: When I see that land, then, I'll push this, and we'll call it good.  Ulterior motive on my part, since there may be some new ports coming up soon, and I *hate* dealing with arch-restricted nonsense when bootstrapping the world.
<infinity> And Mir has weaseled its way pretty low in the stack by now.
<RAOF> Who'd've thought the display server would be low in the stack! :P
<infinity> RAOF: Okay, screw it, if you're fixing the test, I pushed the rest just now.
<infinity> RAOF: If you need to re-ACK the MP or something.
<RAOF> Will do.
<bschaefer> :(, cant find libmirclient8.so hmm o well time to eod
<infinity> RAOF: And hacked up build on all arches copied to wily-proposed.
<infinity> tedg: ^
<tedg> Cool!
<infinity> tedg: I retried the builds in silo 008.  Was that the ones you needed?
<tedg> Yup, it is.
<infinity> Alright.  We'll see how they fare.
<tedg> Oh, you did it in the PPA. I was looking at the dashboard :-)
<tedg> Thanks infinity!
<infinity> tedg: Yeah, I don't believe in this bizarre "reupload the source and force rebuilds on all arches" madness when I have a nice "retry" button for individual builds. :P
<infinity> Oh, pay-service depends on app-launch.  Guess I need to wait a bit and hit more buttons. ;)
<infinity> But app-launch built, so that's a good sign.
<RAOF> Stupid damn cmake.
<infinity> RAOF: But cmake is the way and the light, or something.
<infinity> RAOF: Oh, and I know we got all sidetracked and such, but someone still needs to file that abi-checky-thingee MIR.
<infinity> RAOF: Once jenkins is happy, does a human need to intervene to do the actual merge, or does something magical happen?
<RAOF> infinity: Automerge once someone hits the Accepted status on the top.
<RAOF> ...which I'll do once I've re-reviewed it.
<RAOF> And done.
<infinity> RAOF: Ta.
<RAOF> infinity: Oh, you seem like the sort of person who knows this arcana:
<RAOF> How does one re-export a symbol with a different version?
<RAOF> (In the case of moving a symbol versioned LIB_A_1 to libb, a dependency of liba)
<RAOF> infinity: unping, the answer turns out to be obivous.
<duflu> Holy crap. FreeSync monitors exist. In my local store even! https://www.ple.com.au/ViewItem.aspx?InventoryItemId=617352
<duflu> This affects my choice of algorithm
 * alan_g finds https://wiki.ubuntu.com/Unity8inLXC and thinks it would be cool to set up a similar ppa for mir_demo_server et alia
<Mirv> greyback: bug #1403758 for quick overview. comments #6 and #8 have copy-pasted IRC logs
<ubot5> bug 1403758 in gcc-defaults (Ubuntu) "Unity8 shows black screen with Qt 5.4.0" [Undecided,New] https://launchpad.net/bugs/1403758
<greyback> Mirv: interesting, ta
<alan_g> alf_: could you review a small refactoring in USC? https://code.launchpad.net/~alan-griffiths/unity-system-compositor/decouple-WindowManager-from-DMMessageHandler/+merge/260979
<alf_> alan_g: done
<alan_g> alf_: is that even better?
<kdub> we now have next_buffer, exchange_buffer, and 'the new buffer semantics'... pondering whether to deprecate next_buffer in this process
<kdub> and even exchange_buffer and 'new buffer semantics' are incompatible with working at the same time, even
 * alan_g knows the feeling: "I wouldn't start from here if I were you".
<AlbertA> RAOF: yeah mir 0.13.2 is already pending on QA approval
<alan_g> kdub: I'm seeking GL advice again: I've done something daft but can't see what. (Confused color and alpha channels I think.) Could you look at why the spinner looks weird: lp:~alan-griffiths/unity-system-compositor/incorporate-logo-into-spinner-binary (You can run this bin/unity-system-compositor-spinner as a Mir client, no need to mess with USC - the old one needed pngs installed)
<kdub> alan_g, sure
<kdub> alan_g, just figuring out the fastest way to cross compile :)
<alan_g> kdub: I just build and run on the desktop
<kdub> yeah, probably will go faster, trying that
<alan_g> kdub: gotta go but will pick up again in morning. If you spot my idiocy let me know, if not thanks for looking.
<kdub> alan_g|EOD, sure, no problem
#ubuntu-mir 2015-06-05
<RAOF> Woot! Overlayfs works on mainline kernels now!
<RAOF> Hm, odd.
<RAOF> I can't build lp:mir.
<RAOF> It takes *quite* a long time to build mir on a virtualised armhf.
<duflu> RAOF: If just Mir, cross-compile?
<RAOF> Want to build packages :)
<duflu> RAOF: Would getting one of those Exynos chromebooks help?
<RAOF> Yes.
<RAOF> Or a beaglebone, probably.
<duflu> Well, chromebook has a keyboard, screen etc.
<duflu> And rooting a chomebook is relatively friendly
<RAOF> And costs > 4Ã as much :)
<duflu> RAOF: Sure, but how much for a case + keyboard + display + ... ?
<RAOF> Why would I need any of those?
<duflu> Ha. On another note: Why does Android let you set the year back to 1970? Seems like a waste of scroll menu space
<duflu> The obvious answer is because it's Linux (Unix), but still...
<alan_g> duflu: do you happen to know a quick way to convert a gimp-generated image struct from unpremultiplied-alpha to premultiplied (to avoid doing the runtime computation)?
<duflu> alan_g: Runtime would be "free" because you only need to do it once on startup
<duflu> (modify it in place)
<alan_g> duflu: I realise its cheap at runtime. Was just wondering
 * duflu didn't really want to spend Friday afternoon triaging graphics glitches on the phone, but is...
<duflu> alan_g: I think best to store the image in pure alpha format and pre-multiply in code (where the requirement for premultiplied exists)
<alan_g> duflu: OK. Thanks
<duflu> Hmm, doesn't alpha pre-multiplication mean we lose colour precision?
<duflu> (colour precision in the final blended result)
<alan_g> Possibly. Although in this case it is no worse than the code I'm trying to kill.
<duflu> alan_g: Any update to make in this? https://bugs.launchpad.net/mir/+bug/1341490
<ubot5> Launchpad bug 1341490 in Mir "Bumping the client ABI causes CI failures" [Medium,Triaged]
<alan_g> duflu: I'll write something
<duflu> Man, I think I wrote about 10 lines of code today. And spent the rest of the time re-discovering long-standing bugs that I needed to remember to work around
 * alan_g has a simple 22.6K line MP up for review: https://code.launchpad.net/~alan-griffiths/unity-system-compositor/incorporate-logo-into-spinner-binary/+merge/261181
<anpok_> ah yes line 4979 looks supicious
<alan_g> It's just steganography
#ubuntu-mir 2016-06-06
<alan_g> greyback: I'm very tempted to land a few MPs to anchor upcoming discussions. Are you content with these?
<alan_g> lp:~alan-griffiths/miral/move-WM-logic-into-BasicWindowManager
<alan_g> lp:~alan-griffiths/miral/move-fullscreen-logic-into-BasicWindowManager
<alan_g> lp:~alan-griffiths/miral/another-alternative-touch-resize-algorithm
<greyback> alan_g: I think I was largely ok with those, with a few smaller objections
<greyback> alan_g: yes it would be best to land, we can discuss from there
<alan_g> greyback: landed.
<ranguli> Hey all, I'm looking for a starting point of reference on porting an X application to run on Mir. Any leads?
<alan_g> ranguli: native X? or using a toolkit like gtk?
<alan_g> greyback: here's the first feature you were missing: https://code.launchpad.net/~alan-griffiths/miral/set_window_managment-policy/+merge/296591
<greyback> alan_g: looks ok to me, thanks
<alan_g> greyback: merged. (That was faster than QtMir)
<alan_g> greyback: second feature - https://code.launchpad.net/~alan-griffiths/miral/advise-new-delete-application/+merge/296595
 * alan_g needs tests to detect when MirAL breaks
#ubuntu-mir 2016-06-07
<kdub> hmm, network problem?
<duflu> kdub: Canonical? Yeah
<kdub> duflu, ah, not just me then
<duflu> kdub: Also Launchpad git
<duflu> And bzr is down too
<mariogrip> can i have both mir and xorg running? VT is not working with nvidia drivers
<alan_g> mariogrip: depends what you want. E.g. mir will happily run on X.
<mariogrip> alan_g: I want to try out the eglstream platform
<alan_g> RAOF: you're probably best placed to answer that ^
<RAOF> mariogrip: https://code.launchpad.net/~raof/mir/eglstream-platform/+merge/296389 would be worth trying, then.
<mariogrip> RAOF: yeah, I already have that builded, but how do I test it? VT is not working
<RAOF> (You might need to remove the graphics-mesa-kms.so to get the eglstream platform to autoload)
<RAOF> Ah, you'll also need to reload the nvidia drivers with kms enabled.
<mariogrip> RAOF: like this right? sudo modprobe -r nvidia-drm ; sudo modprobe nvidia-drm modeset=1
<RAOF> That seems about right.
<mariogrip> <DEBUG> platform-eglstream: System does not support EGL_EXT_device_base, eglstream platform is unsupported
<RAOF> Huh. You've got the right drivers?
<mariogrip> 367
<mariogrip> from the ppa https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa
<mariogrip> this also give about the same result https://github.com/aritger/eglstreams-kms-example
<RAOF> Ah, well then that's obviously not the Mir platform being worng.
<RAOF> I don't have my nvidia system with me at this sprint.
<mariogrip> can the problem be that i use ppa?
<RAOF> Maybe?
<RAOF> I've actually forgotten the specific version that I know works.
<mariogrip> <DEBUG> platform-eglstream: EGLStream platform is unsupported: Missing required extensions: EGL_EXT_platform_device EGL_EXT_device_base
<mariogrip> Now I got that, tried starting server with ssh with --vt
<mariogrip> RAOF: ^
<RAOF> I think the libEGL you've got is wrong.
<mariogrip> What should I install?
<RAOF> mariogrip: Sorry, I can't remember what driver version you need.
<mariogrip> RAOF: ok, I installed from nvidia.com now I get this: std::exception::what: Failed to acquire DRM master: Bad file descriptor
<mariogrip> Btw, now it uses the eglstream platform
<mariogrip> something is wrong.... https://usercontent.irccloud-cdn.com/file/vm3qvJqy/IMG_20160608_002038.jpg
<mariogrip> RAOF, it flickers fast
<mariogrip> That was running _to_fb
<mariogrip> this is running _overlays https://usercontent.irccloud-cdn.com/file/HaUqIrm0/IMG_20160608_002327.jpg
<mariogrip> http://paste.ubuntu.com/17103216/
#ubuntu-mir 2016-06-08
<RAOF> mariogrip: Hm. Yeah, that's clearly not working right.
<RAOF> mariogrip: I continue to not have access to my nvidia machine; I won't until next week.
<mariogrip> RAOF: ok, i'll try "hacking" on it a bit an see what i can do, i'll ping you if i get something new
<RAOF> It doesn't look like anything is actually rendering there; it looks like you've just got bits of previously-initialised vram being scanned out of.
<RAOF> This is not something I encountered while developing, so I'm not sure what's causing it. :)
<mariogrip> but, do you have an idea what the link error can be? http://paste.ubuntu.com/17103216/ that happens when i try to start the server or mir_demo_standalone_render_surfaces.
<RAOF> mariogrip: Oh! That's from src/renderers/gl/program_family.cpp - it's failing to link a shader.
<RAOF> That's likely the reason you're not seeing any rendering :)
<mariogrip> RAOF: oh? how do i fix that?
<RAOF> It would be nice if the driver returned any sort of reason for that link failure - we capture any failure message they provide...
<RAOF> mariogrip: I don't know what shader it is, nor why it's failing to link; I'm not sure how you'd fix that. Probably work out what shader is trying to link would be a first go :)
<mariogrip> ok :)
<alan_g> greyback: https://code.launchpad.net/~alan-griffiths/miral/WindowManagementPolicy-advise_raise/+merge/296799
<greyback> alan_g: thanks
<alan_g> greyback: the simple part: https://code.launchpad.net/~alan-griffiths/miral/WindowManagementPolicy-advise_move_to/+merge/296805
<alan_g> greyback: https://code.launchpad.net/~alan-griffiths/miral/WindowManagementPolicy-advise_begin-end/+merge/296817
<alan_g> anpok: back
<anpok> alan_g: unset QT_QPA_PLATFORMTHEME
<alan_g> anpok: https://code.launchpad.net/~alan-griffiths/miral/fix-running-Qt-apps/+merge/296838
#ubuntu-mir 2016-06-10
<Trevinho> https://github.com/GNOME/gtk/commit/d76bba5cb42bed9716fdcf9e58fd074d4aee0cf5
