[13:50] <anpok_> kdub, alan_g: can I have your opinion on the LoggingSharedLibraryProberReport here:
[13:50] <anpok_> https://code.launchpad.net/~mir-team/mir/server-platform-probing/+merge/244982
[13:51] <anpok_> line 1122 in the MP currently defined anonymously inside the graphics part of the server configuration
[13:51] <kdub> sure
[13:51] <anpok_> I was wondering whetyer MIR_SERVER_*_REPORT=log should use ml::log instead of logger?
[13:52] <alan_g> ok
[13:52] <alan_g> no
[13:52] <anpok_> i was about to move that class somewhere else since I would use the same impl for input platform loading
[13:52] <anpok_> ok then this wont be the =log report..
[13:56] <anpok_> so right now this code will always report which libraries have been tested and loadded independent of any log setting
[14:14] <alan_g> anpok_: I think you have misunderstood something. The reason reports (like LoggingSharedLibraryReport) should have a dependency on ml::Logger is so that they can be tested - and we can ensure the output is correct and meaningful
[14:15] <alan_g> ml::log() provides a way for unimportant messages to be written to the logger (which is the same one).
[14:22] <kdub> its also so we can plug different loggers in (like glog in the examples), or we could have a file-writer logger one day
[14:24] <alan_g> kdub: of we plug in glog that also affects ml::log()
[14:24] <alan_g> *if
[14:24] <anpok_> hm so the LoggingSharedLibraryReport part needs fixing
[14:25] <kdub> alan_g, ah, I was unaware
[14:27] <alan_g> The last thing mir::Server::apply_settings() does is ml::set_logger() - so by the time the system starts initialization the logger has been changed
[17:48] <alan_g> camako: here is the extension to mir_demo_server we talked about yesterday. Can you check it can supersede  mir-demo-tester? https://code.launchpad.net/~alan-griffiths/mir/enable-running-tests-in-mir_demo_server/+merge/245021
[18:00] <alan_g> AlbertA: I think this is OK now? https://code.launchpad.net/~nick-dedekind/mir/1355173.trust-prompt-suspend/+merge/241588
[18:03] <AlbertA> alan_g: oh yeah I forgot to flip it yesterday...
[18:06] <AlbertA> racarr: so I'm trying to understand the need for buffer stream...like why not just add additional methods to fill in a buffer obtained from a MirSurface?
[18:07] <AlbertA> racarr: I mean at the client level why do I care that it's MirSurface vs MirBufferStream?
[18:09] <racarr> AlbertA: You can't make WM requests on a buffer stream, it can't receive input, etc
[18:09] <racarr> so the question is it better to pull out the buffer stream abstraction or
[18:09] <racarr> make a highly special cased surface
[18:09] <AlbertA> racarr: couldn't we do a MirSurfaceType cursor or such?
[18:10] <racarr> I mean we could, and it would work for this despite adding a lot of extra semantics...
[18:10] <racarr> e.g. now it probably requires documentation, setting cursor on MirSurfaceType cursor always fails, setting orientation, etc.
[18:10] <racarr> but then, the intention is that its not just cursor...
[18:10] <racarr> e.g. perhaps the auxillary decoration surfaces
[18:11] <racarr> the other example is from RAOF and that's a client attaching multiple buffer streams to a single surface.
[18:11] <anpok_> hmm
[18:11] <anpok_> like a nested shell?
[18:11] <racarr> essentially
[18:11] <racarr> except say
[18:11] <racarr> I mean chromium is the only app I can think of that may do something like that
[18:11] <racarr> I think maybe RAOF has another example
[18:12] <AlbertA> racarr: well I do think it goes nicely with screencasting
[18:12] <AlbertA> so we don't have to do the egl dance and glREadPixels
[18:12] <racarr> that too
[18:12] <racarr> eventually mir_screencast.cpp and
[18:12] <AlbertA> lends itself for easier integration with h/w encoders
[18:12] <racarr> mir_surface/surfaceless_buffer_stream.cpp
[18:13] <racarr> parts of it can
[18:13] <racarr> be shared
[18:13] <racarr> as the client machinery
[18:13] <racarr> but...
[18:13] <racarr> i.e. in terms of code duplication
[18:13] <racarr> but the diff is already kind of painful
[18:13] <racarr> and I was scared to touch any more critical path code lol
[18:14] <racarr> but it should eventually reduce some code duplication
[18:21] <racarr> AlbertA: p.s. thanks for reviewing buffer stream :)
[18:21] <racarr> I know its kind of a long review for the tagline of...upload pixels to the cursor
[18:21] <racarr> lol
[18:31] <AlbertA> racarr: add-more-event-getters is a pre-requisite of port-examples-off-mir-event-access right?
[18:34] <racarr> AlbertA: Yeah, because of the new
[18:34] <racarr> header structure
[18:34] <racarr> that doesn't require including each event header individually
[18:36] <racarr> AlbertA: I realized a lot of my concerns about protocol validation in your branch (don't feel you have to do this though because it already exists too...)
[18:36] <racarr> could be solved by using a different way of structuring the protobox requests
[18:37] <racarr> e.g. message MenuRequest { required int top; required int left} message SurfaceRequest {optional int MenuRequest}
[18:37] <racarr> err
[18:37] <racarr> optional MenuRequest
[18:37] <AlbertA> racarr: yeah I asked about that, but it was preferred
[18:37] <AlbertA> to add optional fields to SurfaceParameters
[18:37] <racarr> really weird
[18:38] <AlbertA> and required is probably not something we want to use now...as it would be a pain in the ass to retire it if we need to right?
[18:38] <racarr> nah. as long as the top level requests only feature optional membership of things that have required members
[18:39] <racarr> then you can always keep appending, MenuRequest2 MenuRequest3, etc...
[18:39] <AlbertA> racarr: ah I see...
[18:39] <AlbertA> still have it as part of SurfaceParameters
[18:39] <racarr> mm
[18:39] <AlbertA> but group them accordingly
[18:39] <AlbertA> ?
[18:39] <racarr> yes
[18:39] <racarr> you end up repeating the shared parameters
[18:39] <racarr> in the nested messages
[18:40] <racarr> I think? But that's not really
[18:40] <racarr> a problem
[18:40] <racarr> I mean some component has to contain these message groupings
[18:40] <racarr> in the current architecture its drifting towards a combination of SurfaceParameters and session
[18:41] <racarr> so I think it would be cool to just encode it in the protobuf layer.
[18:41] <racarr> actually the version of alan_g in my dream last night (100% serious lol) thought it would be cool but I agree.
[18:41] <AlbertA> racarr: :)
[18:42] <racarr> Maybe ill take a peek at it the next time I get some time for a cleanup branch
[18:56] <anpok_> hmm
[18:56] <anpok_> those to probing branches..
[18:56] <anpok_> *two
[18:58] <anpok_> they are a bit inconsistent.. the output dir for the loadable client and server libraries is {client,server}-modules but for the dpkg those paths get changed to {client,server}-platform
[18:59] <anpok_> ah ok thats just install vs output..
[22:28] <racarr> mp list is giant lets top approve https://code.launchpad.net/~albaguirre/mir/pref-orientation-at-create-time/+merge/244602
[22:28] <racarr> ?
[22:29] <racarr> err grr I forgot
[22:29] <racarr> the dep
[22:33] <racarr> https://code.launchpad.net/~alan-griffiths/mir/mir-server-version-macros/+merge/244577 may be a TA candidate
[22:35] <AlbertA> racarr: yeah just waiting to discuss with daniel
[22:35] <AlbertA> on the dep branch
[23:23] <racarr> camako: lol you sure you dont want to block on the cow?!
[23:23] <racarr> :p
[23:32] <camako> racarr... It's not a longhorn so I thought about it, but naah :-)
[23:36] <racarr> https://code.launchpad.net/~mir-team/platform-api/expose-mir-connection/+merge/245054 is a thing
[23:46] <racarr> lol im concerned if I submit any more MPs or become involved ina ny more reviews my head may explode
[23:46] <racarr> THERES ONLY ONE WAY TO FIND OU...*POP*
[23:50] <racarr> https://code.launchpad.net/~mir-team/mir/add-more-event-getters/+merge/243579 this is the branch I'd most like to land
[23:57] <racarr> I guess qtubuntu port is done but the dependency chain is
[23:57] <racarr> add-more-event-getters -> event-ref/unref + port-examples-off-mir-event -> release mir
[23:57] <racarr> papi/expose-mir-connection
[23:58] <racarr> then qtubuntu can land
[23:58] <racarr> seems unlikely to happen by holidays ;(