RAOF | Oh, of course! | 00:36 |
---|---|---|
RAOF | mir_surface_spec_set_event_handler! | 00:36 |
=== chihchun_afk is now known as chihchun | ||
* RAOF always gets confused navigating our Shell hierarchy. | 05:47 | |
RAOF | For example: why do we have two independent ShellWapper hierarchies, mf::ShellWrapper and ms::ShellWrapper, each with an identical (but not derived) interface? | 05:48 |
RAOF | I think adding an extra argument to session::create_surface is going to be a thousand-line diff. | 06:17 |
anpok | havent you thought about using variant to simplify that? | 06:22 |
anpok | or was that a different proble | 06:22 |
anpok | +m | 06:22 |
RAOF | anpok: I don't understand? | 06:31 |
RAOF | Specifically - I want to pass the EventSink for the surface in from SessionMediator, rather than inheriting the ApplicationSession's event sink. | 06:32 |
anpok | ok, i believe i understood - my suggestion was nonsense | 06:41 |
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:43 |
RAOF | Why isn't there a C++ type for “shared pointer, but guaranteed non-null”? | 06:44 |
RAOF | Likewise: unique_ptr. | 06:44 |
RAOF | Well, that's a strange indictment of our test coverage. | 06:55 |
RAOF | Replace 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 | ||
mcphail | http://unity.ubuntu.com/mir/ is still not working. Can someone give it a kick please? | 09:20 |
duflu | mcphail: It's automagical. I can't remember who updated it. alan_g? | 09:24 |
alan_g | Me neither. :( | 09:26 |
=== chihchun_afk is now known as chihchun | ||
duflu | alan_g: My email history says it's a Jenkins job. So maybe just down temporarily with the rest of Jenkins | 09:33 |
duflu | Paul Larson fixed it last time (December) | 09:34 |
* mcphail loves things which work automagically :) | 09:34 | |
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:35 |
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:36 |
duflu | mcphail: Completely agree. We'd have to wait for USA to wake up it appears | 09:37 |
mcphail | duflu: OK, cheers :) | 09:37 |
=== vesar__ is now known as vesar-lunch | ||
=== guest42315 is now known as pixelr0 | ||
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:23 |
greyback_ | popey: it won't install correctly on a newish image any more. we're not maintaining it any more | 10:25 |
greyback_ | are trying to land all the code instead | 10:26 |
pixelr0 | popey, do you mind if i use your pics for karma? | 10:30 |
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: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_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:34 |
popey | pixelr0: sure | 10:35 |
pixelr0 | popey, thanks ;D | 10:35 |
alan_g | And, 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 config | 10: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 increases | 10:40 |
alan_g | Sure, but we can deliver some value with the blob slice and consider hardware IDs as the next "user story". | 10:42 |
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: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 saved | 10:49 |
greyback_ | but this is solving future problems we've not decided we have yet | 10:49 |
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:51 |
alan_g | Got a better name? | 10:52 |
greyback_ | alan_g: not really, and it is used in database context a lot | 10:54 |
greyback_ | will do, ignore me & carry on | 10:54 |
=== pixelr0 is now known as guest42315 | ||
alan_g | MirSerializedData | 10: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 correct | 11:40 |
=== chihchun is now known as chihchun_afk | ||
* alan_g spies a missing acceptance test | 11:45 | |
greyback_ | it might be more a kdub question, since it's an android thing | 11:48 |
kdub | so the nested server doesnt get another display buffer? | 11:49 |
kdub | from the above description, i'd guess this would happen on mesa too | 11:50 |
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: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.cpp | 11:53 |
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:54 |
alf_ | greyback_: Can you verify that output.used is set for both displays when your tiled config runs? | 11:55 |
greyback_ | alf_: ack | 11:55 |
alf_ | greyback_: (I mean after the wrapped policy is applied) | 11:56 |
greyback_ | yep | 11:56 |
=== alan_g is now known as alan_g|lunch | ||
greyback_ | kdub: alf_: yeah I can repro on mesa also | 12:07 |
greyback_ | alf_: I'm not seeing my display config policy being consulted at all as a nested server after startup | 12:12 |
greyback_ | it is if I run as host server tho | 12: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: used | 12:15 |
greyback_ | because host server needs time to prepare the new display. So 2 separate events | 12:15 |
greyback_ | nope, just checked, that's not happening | 12: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 policy | 12: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 case | 12:28 |
greyback_ | alf_: I logged bug https://bugs.launchpad.net/mir/+bug/1491816 | 12:28 |
ubot5 | 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:28 |
greyback_ | alf_: perhaps I've forgot to do something in my code? | 12:29 |
alf_ | greyback_: your code looks fine too | 12:31 |
alf_ | greyback_: Let me try to reproduce locally with Mesa and demo servers and I will get back to you | 12:32 |
greyback_ | thanks | 12:34 |
greyback_ | alf_: dunno if relevant, but I was testing with host mir server with --display-config=sidebyside set | 13: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 that | 13:31 |
greyback_ | alf_: no change here | 13: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 changes | 13:34 |
alf_ | greyback_: which callback is that? | 13:37 |
greyback_ | Display::register_configuration_change_handler | 13:37 |
alf_ | greyback_: you shouldn't touch that :) | 13:38 |
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:39 |
greyback_ | alf_: it doesn't support registering multiple change handlers?? | 13:40 |
greyback_ | come on | 13: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 sec | 13:43 |
alan_g | greyback_: WindowManager::add_display()? | 13:43 |
greyback_ | alan_g: possibly | 13:45 |
greyback_ | alf_: ok, removing that fixes my problem | 14:19 |
alf_ | greyback_: great | 14:20 |
alf_ | greyback_: are you able to use compositor start/stop? | 14:20 |
greyback_ | yeah | 14: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 | |
bregma | Saviq, do you know what is the status of the branch-synch problem kgunn was working on yesterday? | 14:48 |
Saviq | bregma, in silo | 14:52 |
Saviq | silo 14 | 14:52 |
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:54 |
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:55 |
Saviq | kk | 14:56 |
=== dandrader is now known as dandrader|afk | ||
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? | 15:20 |
=== dandrader|afk is now known as dandrader | ||
Saviq | bregma, any word? | 16:45 |
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:46 |
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? | 16:48 |
Saviq | bregma, please do | 17:03 |
Saviq | bregma, note the silo is dual | 17:03 |
Saviq | but your MPs look fine for that | 17: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!