[00:36] <RAOF> Oh, of course!
[00:36] <RAOF> mir_surface_spec_set_event_handler!
[05:47]  * RAOF always gets confused navigating our Shell hierarchy.
[05:48] <RAOF> For example: why do we have two independent ShellWapper hierarchies, mf::ShellWrapper and ms::ShellWrapper, each with an identical (but not derived) interface?
[06:17] <RAOF> I think adding an extra argument to session::create_surface is going to be a thousand-line diff.
[06:22] <anpok> havent you thought about using variant to simplify that?
[06:22] <anpok> or was that a different proble
[06:22] <anpok> +m
[06:31] <RAOF> anpok: I don't understand?
[06:32] <RAOF> Specifically - I want to pass the EventSink for the surface in from SessionMediator, rather than inheriting the ApplicationSession's event sink.
[06:41] <anpok> ok, i believe i understood - my suggestion was nonsense
[06:43] <RAOF> This will let me (a) send surface events during surface construction, which I want to do, (b) close a race where we might send an event for a surface before we've sent the creation completion, and (c) be useful in an unrelated thing.
[06:44] <RAOF> Why isn't there a C++ type for “shared pointer, but guaranteed non-null”?
[06:44] <RAOF> Likewise: unique_ptr.
[06:55] <RAOF> Well, that's a strange indictment of our test coverage.
[06:56] <RAOF> Replace the scene::Surface's event sink with nullptr and no tests (other than the ones this branch adds) fail.
[07:01]  * RAOF does some Zoë time for an hour before my 6pm meeting...
[09:20] <mcphail> http://unity.ubuntu.com/mir/ is still not working. Can someone give it a kick please?
[09:24] <duflu> mcphail: It's automagical. I can't remember who updated it. alan_g?
[09:26] <alan_g> Me neither. :(
[09:33] <duflu> alan_g: My email history says it's a Jenkins job. So maybe just down temporarily with the rest of Jenkins
[09:34] <duflu> Paul Larson fixed it last time (December)
[09:34]  * mcphail loves things which work automagically :)
[09:35] <alan_g> duflu: the Jenkins job pushes updates...doesn't explain why the page has gone.
[09:35] <duflu> mcphail: Yeah it's managed by the Jenkins service, and that's been down for all projects since last weekend. So I guess wait till Jenkins is back and maybe the website will be too
[09:35] <duflu> alan_g: True. Maybe null got pushed
[09:36] <mcphail> duflu: Is it possible to push a placeholder for the time being? Dare I say, it doesn't look vry professional just now...
[09:37] <duflu> mcphail: Completely agree. We'd have to wait for USA to wake up it appears
[09:37] <mcphail> duflu: OK, cheers :)
[10:23] <popey> on nexus 7 with silo 0, should I expect the external display to be oriented correctly? (I get half a display, rotated incorrectly) http://i.imgur.com/S5WckVx.jpg & http://i.imgur.com/xQRZtRS.jpg
[10:25] <greyback_> popey: it won't install correctly on a newish image any more. we're not maintaining it any more
[10:26] <greyback_> are trying to land all the code instead
[10:30] <pixelr0> popey, do you mind if i use your pics for karma?
[10:31] <alan_g> greyback_: does this (unimplemented) API work for you? https://code.launchpad.net/~alan-griffiths/mir/MirBlob/+merge/269949
[10:31] <pixelr0> popey, this one is nice! http://i.imgur.com/xQRZtRS.jpg
[10:33] <greyback_> alan_g: it allows saves/restores a single DispConf. I presume I can have multiples of these saves, yes? (so save different configs with different monitors)
[10:34] <alan_g> As many as you like
[10:34] <greyback_> then it should do the job nicely
[10:34] <alan_g> But not per monitor, per configuration
[10:34] <popey> greyback_: ah, okay
[10:35] <popey> pixelr0: sure
[10:35] <pixelr0> popey, thanks ;D
[10:36] <alan_g> And, of course, if the hardware has changed the configuration may no longer make sense,
[10:38] <greyback_> alan_g: yeah, which is why I need to save a configuration per hardware config
[10:38] <greyback_> to do that, I need unique identifier for each display hardware (EDID maybe)
[10:39]  * alan_g senses scope creep. ;)
[10:40] <greyback_> and then save something like: ((EDID1, EDID2), MirBlob1), (EDID1, MirBlob2)...
[10:40] <greyback_> sure, but there's no point making something which will be thrown away when the scope increases
[10:42] <alan_g> Sure, but we can deliver some value with the blob slice and consider hardware IDs as the next "user story".
[10:48] <alan_g> greyback_: do you really want to identify specific hardware? If an alternative monitor can support the same mode does the user care?
[10:49] <greyback_> alan_g: if Ishare my laptop with 2 different external monitors, and configure each one differently, I'd like those configurations to be saved
[10:49] <greyback_> but this is solving future problems we've not decided we have yet
[10:51] <greyback_> dunno if this relevant, but when I see Blob in a linux context, I immediately think of binary blobs and proprietary stuff
[10:51] <alan_g> If I plug in a projector wherever I'm visiting I'd like my "usual" projector config to be chosen. Not the hardware defaults.
[10:52] <alan_g> Got a better name?
[10:54] <greyback_> alan_g: not really, and it is used in database context a lot
[10:54] <greyback_> will do, ignore me & carry on
[10:55] <alan_g> MirSerializedData
[11:39] <greyback_> alf_: hey, I've query about DisplayBuffers and the nested platform. On android, for a nested server, when I plug in external monitor, I get notification displayconfig has changed, but I don't appear to be getting a new DisplayBuffer for that external display.
[11:40] <greyback_> should I definitely be getting a displaybuffer for newly added displays, or do I need to do something?
[11:40] <greyback_> if I start the server with the external monitor connected, I get display buffer for both, which is correct
[11:45]  * alan_g spies a missing acceptance test
[11:48] <greyback_> it might be more a kdub question, since it's an android thing
[11:49] <kdub> so the nested server doesnt get another display buffer?
[11:50] <kdub> from the above description, i'd guess this would happen on mesa too
[11:51] <greyback_> kdub: that's how it appears to me. The new display doesn't get a new displaybuffer.
[11:51] <greyback_> will check mesa
[11:52] <alf_> greyback_: Does the configuration policy enable that second monitor?
[11:53] <greyback_> alf_: I think so: http://bazaar.launchpad.net/~gerboland/qtmir/multimonitor/view/head:/src/platforms/mirserver/tileddisplayconfigurationpolicy.cpp
[11:54] <greyback_> I'm just tweaking the default display config to have displays side-by-side
[11:54] <greyback_> works if I start nested server with both displays connected anyway
[11:54] <greyback_> only if I start without external display, then plug it in, do I get this issue
[11:55] <alf_> greyback_: Can you verify that output.used is set for both displays when your tiled config runs?
[11:55] <greyback_> alf_: ack
[11:56] <alf_> greyback_: (I mean after the wrapped policy is applied)
[11:56] <greyback_> yep
[12:07] <greyback_> kdub: alf_: yeah I can repro on mesa also
[12:12] <greyback_> alf_: I'm not seeing my display config policy being consulted at all as a nested server after startup
[12:13] <greyback_> it is if I run as host server tho
[12:13] <alf_> greyback_: that's a problem :)
[12:15] <greyback_> alf_: could this happen: plug in external monitor: client gets displayConfigChange with output: *not* used. Then after host server gets ready, another displayConfigChange event with output: used
[12:15] <greyback_> because host server needs time to prepare the new display. So 2 separate events
[12:17] <greyback_> nope, just checked, that's not happening
[12:19] <alf_> greyback_: right, so in this setup the host server will wait for the nested server to tell it what to do when a configuration change happens (since it is focused and has set per-session/custom configuration)
[12:20] <greyback_> alf_: so I suppose it should consult the nested server's display config policy
[12:28] <alf_> greyback_: I am going through the nested code, but everything seems in order, not sure why the policy is not used in your case
[12:28] <greyback_> alf_: I logged bug https://bugs.launchpad.net/mir/+bug/1491816
[12:29] <greyback_> alf_: perhaps I've forgot to do something in my code?
[12:31] <alf_> greyback_: your code looks fine too
[12:32] <alf_> greyback_: Let me try to reproduce locally with Mesa and demo servers and I will get back to you
[12:34] <greyback_> thanks
[13:14] <greyback_> alf_: dunno if relevant, but I was testing with host mir server with --display-config=sidebyside set
[13:28] <alf_> greyback_: With the exception of some mouse cursor issues, demo servers work as expected (using mir_demo_server from lp:mir though, not mir_proving_server from ??)
[13:31] <greyback_> alf_: hmm, lemme try that
[13:33] <greyback_> alf_: no change here
[13:33] <alf_> greyback_: at which point do you expect a display buffer to exist?
[13:34] <greyback_> alf_: in the callback fired when the DisplayConfiguration changes
[13:37] <alf_> greyback_: which callback is that?
[13:37] <greyback_> Display::register_configuration_change_handler
[13:38] <alf_> greyback_: you shouldn't touch that :)
[13:39] <alf_> greyback_: that's a notification that the hardware configuration has changed
[13:39] <alf_> greyback_: and the default handler is what takes that new configuration and applies policy etc in a safe way
[13:40] <greyback_> alf_: it doesn't support registering multiple change handlers??
[13:40] <greyback_> come on
[13:41] <alf_> greyback_: no, but that's not the point. "This is not the callback you are looking for" (probably)
[13:42] <alf_> greyback_: I say probably because I am not sure what's needed for qt integration...
[13:43] <alf_> greyback_: quick hangout so I can understand the architecture?
[13:43] <greyback_> alf_: sure, 1 sec
[13:43] <alan_g> greyback_: WindowManager::add_display()?
[13:45] <greyback_> alan_g: possibly
[14:19] <greyback_> alf_: ok, removing that fixes my problem
[14:20] <alf_> greyback_: great
[14:20] <alf_> greyback_: are you able to use compositor start/stop?
[14:20] <greyback_> yeah
[14:27]  * alan_g finds another bug in the configure_display() logic: the server replies with the "active configuration" without having waited for changes to take effect (on another thread),
[14:48] <bregma> Saviq, do you know what is the status of the branch-synch problem kgunn was working on yesterday?
[14:52] <Saviq> bregma, in silo
[14:52] <Saviq> silo 14
[14:54] <Saviq> bregma, so mir an usc needs to be there as well, or can they get there later/
[14:54] <Saviq> ?
[14:54] <Saviq> (there - in a silo)
[14:55] <bregma> should be OK to put no-change rebuilds in there now, but I'll ask at the Mir standup in a few minutes to make sure
[14:56] <Saviq> kk
[15:20] <bregma> Saviq, can we add https://code.launchpad.net/~mir-team/mir/released-rebuild-for-vivid-overlay/+merge/269918 to landing-014 for a start?
[16:45] <Saviq> bregma, any word?
[16:46] <bregma> Saviq, I think we need to add https://code.launchpad.net/~mir-team/mir/released-rebuild-for-vivid-overlay/+merge/269918 to landing-014 for a start, and another MP for u-s-c
[16:48] <bregma> https://code.launchpad.net/~mir-team/unity-system-compositor/no-change-rebuild-mir-0.15.1/+merge/269102
[16:48] <bregma> just put them in silo 14 and rebuild -- shall I do it?
[17:03] <Saviq> bregma, please do
[17:03] <Saviq> bregma, note the silo is dual
[17:04] <Saviq> but your MPs look fine for that