| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| 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:50 |
| 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:51 |
| 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:52 |
| anpok_ | so right now this code will always report which libraries have been tested and loadded independent of any log setting | 13:56 |
| 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:14 |
| alan_g | ml::log() provides a way for unimportant messages to be written to the logger (which is the same one). | 14:15 |
| 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:22 |
| 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:24 |
| kdub | alan_g, ah, I was unaware | 14:25 |
| 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 | 14:27 |
| === chihchun is now known as chihchun_afk | ||
| 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 | 17:48 |
| alan_g | AlbertA: I think this is OK now? https://code.launchpad.net/~nick-dedekind/mir/1355173.trust-prompt-suspend/+merge/241588 | 18:00 |
| AlbertA | alan_g: oh yeah I forgot to flip it yesterday... | 18:03 |
| === alan_g is now known as alan_g|EOD | ||
| 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:06 |
| AlbertA | racarr: I mean at the client level why do I care that it's MirSurface vs MirBufferStream? | 18:07 |
| === chihchun_afk is now known as chihchun | ||
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| racarr | but it should eventually reduce some code duplication | 18:14 |
| 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:21 |
| AlbertA | racarr: add-more-event-getters is a pre-requisite of port-examples-off-mir-event-access right? | 18:31 |
| 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:34 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| racarr | Maybe ill take a peek at it the next time I get some time for a cleanup branch | 18:42 |
| anpok_ | hmm | 18:56 |
| anpok_ | those to probing branches.. | 18:56 |
| anpok_ | *two | 18:56 |
| 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:58 |
| anpok_ | ah ok thats just install vs output.. | 18:59 |
| === ara is now known as Guest47294 | ||
| 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:28 |
| racarr | err grr I forgot | 22:29 |
| racarr | the dep | 22:29 |
| racarr | https://code.launchpad.net/~alan-griffiths/mir/mir-server-version-macros/+merge/244577 may be a TA candidate | 22:33 |
| AlbertA | racarr: yeah just waiting to discuss with daniel | 22:35 |
| AlbertA | on the dep branch | 22:35 |
| racarr | camako: lol you sure you dont want to block on the cow?! | 23:23 |
| racarr | :p | 23:23 |
| camako | racarr... It's not a longhorn so I thought about it, but naah :-) | 23:32 |
| racarr | https://code.launchpad.net/~mir-team/platform-api/expose-mir-connection/+merge/245054 is a thing | 23:36 |
| 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:46 |
| 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:50 |
| 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:57 |
| racarr | then qtubuntu can land | 23:58 |
| racarr | seems unlikely to happen by holidays ;( | 23:58 |
| === chihchun is now known as chihchun_afk | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!