/srv/irclogs.ubuntu.com/2015/09/03/#ubuntu-mir.txt

RAOFOh, of course!00:36
RAOFmir_surface_spec_set_event_handler!00:36
=== chihchun_afk is now known as chihchun
* RAOF always gets confused navigating our Shell hierarchy.05:47
RAOFFor example: why do we have two independent ShellWapper hierarchies, mf::ShellWrapper and ms::ShellWrapper, each with an identical (but not derived) interface?05:48
RAOFI think adding an extra argument to session::create_surface is going to be a thousand-line diff.06:17
anpokhavent you thought about using variant to simplify that?06:22
anpokor was that a different proble06:22
anpok+m06:22
RAOFanpok: I don't understand?06:31
RAOFSpecifically - I want to pass the EventSink for the surface in from SessionMediator, rather than inheriting the ApplicationSession's event sink.06:32
anpokok, i believe i understood - my suggestion was nonsense06:41
RAOFThis 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:43
RAOFWhy isn't there a C++ type for “shared pointer, but guaranteed non-null”?06:44
RAOFLikewise: unique_ptr.06:44
RAOFWell, that's a strange indictment of our test coverage.06:55
RAOFReplace the scene::Surface's event sink with nullptr and no tests (other than the ones this branch adds) fail.06:56
* RAOF does some Zoë time for an hour before my 6pm meeting...07:01
=== chihchun is now known as chihchun_afk
mcphailhttp://unity.ubuntu.com/mir/ is still not working. Can someone give it a kick please?09:20
duflumcphail: It's automagical. I can't remember who updated it. alan_g?09:24
alan_gMe neither. :(09:26
=== chihchun_afk is now known as chihchun
duflualan_g: My email history says it's a Jenkins job. So maybe just down temporarily with the rest of Jenkins09:33
dufluPaul Larson fixed it last time (December)09:34
* mcphail loves things which work automagically :)09:34
alan_gduflu: the Jenkins job pushes updates...doesn't explain why the page has gone.09:35
duflumcphail: 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 too09:35
duflualan_g: True. Maybe null got pushed09:35
mcphailduflu: Is it possible to push a placeholder for the time being? Dare I say, it doesn't look vry professional just now...09:36
duflumcphail: Completely agree. We'd have to wait for USA to wake up it appears09:37
mcphailduflu: OK, cheers :)09:37
=== vesar__ is now known as vesar-lunch
=== guest42315 is now known as pixelr0
popeyon 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.jpg10:23
greyback_popey: it won't install correctly on a newish image any more. we're not maintaining it any more10:25
greyback_are trying to land all the code instead10:26
pixelr0popey, do you mind if i use your pics for karma?10:30
alan_ggreyback_: does this (unimplemented) API work for you? https://code.launchpad.net/~alan-griffiths/mir/MirBlob/+merge/26994910:31
pixelr0popey, this one is nice! http://i.imgur.com/xQRZtRS.jpg10:31
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:33
alan_gAs many as you like10:34
greyback_then it should do the job nicely10:34
alan_gBut not per monitor, per configuration10:34
popeygreyback_: ah, okay10:34
popeypixelr0: sure10:35
pixelr0popey, thanks ;D10:35
alan_gAnd, of course, if the hardware has changed the configuration may no longer make sense,10:36
greyback_alan_g: yeah, which is why I need to save a configuration per hardware config10:38
greyback_to do that, I need unique identifier for each display hardware (EDID maybe)10:38
* alan_g senses scope creep. ;)10:39
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 increases10:40
alan_gSure, but we can deliver some value with the blob slice and consider hardware IDs as the next "user story".10:42
alan_ggreyback_: do you really want to identify specific hardware? If an alternative monitor can support the same mode does the user care?10:48
greyback_alan_g: if Ishare my laptop with 2 different external monitors, and configure each one differently, I'd like those configurations to be saved10:49
greyback_but this is solving future problems we've not decided we have yet10:49
greyback_dunno if this relevant, but when I see Blob in a linux context, I immediately think of binary blobs and proprietary stuff10:51
alan_gIf I plug in a projector wherever I'm visiting I'd like my "usual" projector config to be chosen. Not the hardware defaults.10:51
alan_gGot a better name?10:52
greyback_alan_g: not really, and it is used in database context a lot10:54
greyback_will do, ignore me & carry on10:54
=== pixelr0 is now known as guest42315
alan_gMirSerializedData10:55
=== vesar-lunch is now known as vesar
=== vesar is now known as vesar__
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:39
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 correct11:40
=== chihchun is now known as chihchun_afk
* alan_g spies a missing acceptance test11:45
greyback_it might be more a kdub question, since it's an android thing11:48
kdubso the nested server doesnt get another display buffer?11:49
kdubfrom the above description, i'd guess this would happen on mesa too11:50
greyback_kdub: that's how it appears to me. The new display doesn't get a new displaybuffer.11:51
greyback_will check mesa11:51
alf_greyback_: Does the configuration policy enable that second monitor?11:52
greyback_alf_: I think so: http://bazaar.launchpad.net/~gerboland/qtmir/multimonitor/view/head:/src/platforms/mirserver/tileddisplayconfigurationpolicy.cpp11:53
greyback_I'm just tweaking the default display config to have displays side-by-side11:54
greyback_works if I start nested server with both displays connected anyway11:54
greyback_only if I start without external display, then plug it in, do I get this issue11:54
alf_greyback_: Can you verify that output.used is set for both displays when your tiled config runs?11:55
greyback_alf_: ack11:55
alf_greyback_: (I mean after the wrapped policy is applied)11:56
greyback_yep11:56
=== alan_g is now known as alan_g|lunch
greyback_kdub: alf_: yeah I can repro on mesa also12:07
greyback_alf_: I'm not seeing my display config policy being consulted at all as a nested server after startup12:12
greyback_it is if I run as host server tho12:13
alf_greyback_: that's a problem :)12:13
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: used12:15
greyback_because host server needs time to prepare the new display. So 2 separate events12:15
greyback_nope, just checked, that's not happening12:17
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:19
greyback_alf_: so I suppose it should consult the nested server's display config policy12:20
alf_greyback_: I am going through the nested code, but everything seems in order, not sure why the policy is not used in your case12:28
greyback_alf_: I logged bug https://bugs.launchpad.net/mir/+bug/149181612:28
ubot5Ubuntu bug 1491816 in Mir "[nested server] plug in monitor, display config change fires, but no DisplayBuffer ready for that new display" [Undecided,New]12:28
greyback_alf_: perhaps I've forgot to do something in my code?12:29
alf_greyback_: your code looks fine too12:31
alf_greyback_: Let me try to reproduce locally with Mesa and demo servers and I will get back to you12:32
greyback_thanks12:34
greyback_alf_: dunno if relevant, but I was testing with host mir server with --display-config=sidebyside set13:14
=== alan_g|lunch is now known as alan_g
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:28
greyback_alf_: hmm, lemme try that13:31
greyback_alf_: no change here13:33
alf_greyback_: at which point do you expect a display buffer to exist?13:33
greyback_alf_: in the callback fired when the DisplayConfiguration changes13:34
alf_greyback_: which callback is that?13:37
greyback_Display::register_configuration_change_handler13:37
alf_greyback_: you shouldn't touch that :)13:38
alf_greyback_: that's a notification that the hardware configuration has changed13:39
alf_greyback_: and the default handler is what takes that new configuration and applies policy etc in a safe way13:39
greyback_alf_: it doesn't support registering multiple change handlers??13:40
greyback_come on13:40
alf_greyback_: no, but that's not the point. "This is not the callback you are looking for" (probably)13:41
alf_greyback_: I say probably because I am not sure what's needed for qt integration...13:42
alf_greyback_: quick hangout so I can understand the architecture?13:43
greyback_alf_: sure, 1 sec13:43
alan_ggreyback_: WindowManager::add_display()?13:43
greyback_alan_g: possibly13:45
greyback_alf_: ok, removing that fixes my problem14:19
alf_greyback_: great14:20
alf_greyback_: are you able to use compositor start/stop?14:20
greyback_yeah14:20
* 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:27
bregmaSaviq, do you know what is the status of the branch-synch problem kgunn was working on yesterday?14:48
Saviqbregma, in silo14:52
Saviqsilo 1414:52
Saviqbregma, 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:54
bregmashould be OK to put no-change rebuilds in there now, but I'll ask at the Mir standup in a few minutes to make sure14:55
Saviqkk14:56
=== dandrader is now known as dandrader|afk
bregmaSaviq, can we add https://code.launchpad.net/~mir-team/mir/released-rebuild-for-vivid-overlay/+merge/269918 to landing-014 for a start?15:20
=== dandrader|afk is now known as dandrader
Saviqbregma, any word?16:45
bregmaSaviq, 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-c16:46
bregmahttps://code.launchpad.net/~mir-team/unity-system-compositor/no-change-rebuild-mir-0.15.1/+merge/26910216:48
bregmajust put them in silo 14 and rebuild -- shall I do it?16:48
Saviqbregma, please do17:03
Saviqbregma, note the silo is dual17:03
Saviqbut your MPs look fine for that17:04
=== 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

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!