[00:36] Oh, of course! [00:36] mir_surface_spec_set_event_handler! === chihchun_afk is now known as chihchun [05:47] * RAOF always gets confused navigating our Shell hierarchy. [05:48] 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] I think adding an extra argument to session::create_surface is going to be a thousand-line diff. [06:22] havent you thought about using variant to simplify that? [06:22] or was that a different proble [06:22] +m [06:31] anpok: I don't understand? [06:32] Specifically - I want to pass the EventSink for the surface in from SessionMediator, rather than inheriting the ApplicationSession's event sink. [06:41] ok, i believe i understood - my suggestion was nonsense [06:43] 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] Why isn't there a C++ type for “shared pointer, but guaranteed non-null”? [06:44] Likewise: unique_ptr. [06:55] Well, that's a strange indictment of our test coverage. [06:56] 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... === chihchun is now known as chihchun_afk [09:20] http://unity.ubuntu.com/mir/ is still not working. Can someone give it a kick please? [09:24] mcphail: It's automagical. I can't remember who updated it. alan_g? [09:26] Me neither. :( === chihchun_afk is now known as chihchun [09:33] alan_g: My email history says it's a Jenkins job. So maybe just down temporarily with the rest of Jenkins [09:34] Paul Larson fixed it last time (December) [09:34] * mcphail loves things which work automagically :) [09:35] duflu: the Jenkins job pushes updates...doesn't explain why the page has gone. [09:35] 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] alan_g: True. Maybe null got pushed [09:36] 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] mcphail: Completely agree. We'd have to wait for USA to wake up it appears [09:37] duflu: OK, cheers :) === vesar__ is now known as vesar-lunch === guest42315 is now known as pixelr0 [10:23] 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] popey: it won't install correctly on a newish image any more. we're not maintaining it any more [10:26] are trying to land all the code instead [10:30] popey, do you mind if i use your pics for karma? [10:31] greyback_: does this (unimplemented) API work for you? https://code.launchpad.net/~alan-griffiths/mir/MirBlob/+merge/269949 [10:31] popey, this one is nice! http://i.imgur.com/xQRZtRS.jpg [10:33] 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] As many as you like [10:34] then it should do the job nicely [10:34] But not per monitor, per configuration [10:34] greyback_: ah, okay [10:35] pixelr0: sure [10:35] popey, thanks ;D [10:36] And, of course, if the hardware has changed the configuration may no longer make sense, [10:38] alan_g: yeah, which is why I need to save a configuration per hardware config [10:38] to do that, I need unique identifier for each display hardware (EDID maybe) [10:39] * alan_g senses scope creep. ;) [10:40] and then save something like: ((EDID1, EDID2), MirBlob1), (EDID1, MirBlob2)... [10:40] sure, but there's no point making something which will be thrown away when the scope increases [10:42] Sure, but we can deliver some value with the blob slice and consider hardware IDs as the next "user story". [10:48] greyback_: do you really want to identify specific hardware? If an alternative monitor can support the same mode does the user care? [10:49] 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] but this is solving future problems we've not decided we have yet [10:51] dunno if this relevant, but when I see Blob in a linux context, I immediately think of binary blobs and proprietary stuff [10:51] 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] Got a better name? [10:54] alan_g: not really, and it is used in database context a lot [10:54] will do, ignore me & carry on === pixelr0 is now known as guest42315 [10:55] MirSerializedData === vesar-lunch is now known as vesar === vesar is now known as vesar__ [11:39] 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] should I definitely be getting a displaybuffer for newly added displays, or do I need to do something? [11:40] if I start the server with the external monitor connected, I get display buffer for both, which is correct === chihchun is now known as chihchun_afk [11:45] * alan_g spies a missing acceptance test [11:48] it might be more a kdub question, since it's an android thing [11:49] so the nested server doesnt get another display buffer? [11:50] from the above description, i'd guess this would happen on mesa too [11:51] kdub: that's how it appears to me. The new display doesn't get a new displaybuffer. [11:51] will check mesa [11:52] greyback_: Does the configuration policy enable that second monitor? [11:53] alf_: I think so: http://bazaar.launchpad.net/~gerboland/qtmir/multimonitor/view/head:/src/platforms/mirserver/tileddisplayconfigurationpolicy.cpp [11:54] I'm just tweaking the default display config to have displays side-by-side [11:54] works if I start nested server with both displays connected anyway [11:54] only if I start without external display, then plug it in, do I get this issue [11:55] greyback_: Can you verify that output.used is set for both displays when your tiled config runs? [11:55] alf_: ack [11:56] greyback_: (I mean after the wrapped policy is applied) [11:56] yep === alan_g is now known as alan_g|lunch [12:07] kdub: alf_: yeah I can repro on mesa also [12:12] alf_: I'm not seeing my display config policy being consulted at all as a nested server after startup [12:13] it is if I run as host server tho [12:13] greyback_: that's a problem :) [12:15] 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] because host server needs time to prepare the new display. So 2 separate events [12:17] nope, just checked, that's not happening [12:19] 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] alf_: so I suppose it should consult the nested server's display config policy [12:28] 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] alf_: I logged bug https://bugs.launchpad.net/mir/+bug/1491816 [12:28] Ubuntu bug 1491816 in Mir "[nested server] plug in monitor, display config change fires, but no DisplayBuffer ready for that new display" [Undecided,New] [12:29] alf_: perhaps I've forgot to do something in my code? [12:31] greyback_: your code looks fine too [12:32] greyback_: Let me try to reproduce locally with Mesa and demo servers and I will get back to you [12:34] thanks [13:14] alf_: dunno if relevant, but I was testing with host mir server with --display-config=sidebyside set === alan_g|lunch is now known as alan_g [13:28] 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] alf_: hmm, lemme try that [13:33] alf_: no change here [13:33] greyback_: at which point do you expect a display buffer to exist? [13:34] alf_: in the callback fired when the DisplayConfiguration changes [13:37] greyback_: which callback is that? [13:37] Display::register_configuration_change_handler [13:38] greyback_: you shouldn't touch that :) [13:39] greyback_: that's a notification that the hardware configuration has changed [13:39] greyback_: and the default handler is what takes that new configuration and applies policy etc in a safe way [13:40] alf_: it doesn't support registering multiple change handlers?? [13:40] come on [13:41] greyback_: no, but that's not the point. "This is not the callback you are looking for" (probably) [13:42] greyback_: I say probably because I am not sure what's needed for qt integration... [13:43] greyback_: quick hangout so I can understand the architecture? [13:43] alf_: sure, 1 sec [13:43] greyback_: WindowManager::add_display()? [13:45] alan_g: possibly [14:19] alf_: ok, removing that fixes my problem [14:20] greyback_: great [14:20] greyback_: are you able to use compositor start/stop? [14:20] 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] Saviq, do you know what is the status of the branch-synch problem kgunn was working on yesterday? [14:52] bregma, in silo [14:52] silo 14 [14:54] bregma, so mir an usc needs to be there as well, or can they get there later/ [14:54] ? [14:54] (there - in a silo) [14:55] 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] kk === dandrader is now known as dandrader|afk [15:20] Saviq, can we add https://code.launchpad.net/~mir-team/mir/released-rebuild-for-vivid-overlay/+merge/269918 to landing-014 for a start? === dandrader|afk is now known as dandrader [16:45] bregma, any word? [16:46] 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] https://code.launchpad.net/~mir-team/unity-system-compositor/no-change-rebuild-mir-0.15.1/+merge/269102 [16:48] just put them in silo 14 and rebuild -- shall I do it? [17:03] bregma, please do [17:03] bregma, note the silo is dual [17:04] but your MPs look fine for that === alan_g is now known as alan_g|EOD === dandrader is now known as dandrader|afk === greyback_ is now known as greyback|eod === dandrader|afk is now known as dandrader === tvoss is now known as tvoss|test === tvoss|test is now known as tvoss === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader