[00:12] Buffer stream is supposedly done gonna let it sit for a day then do some self review/iteration though [00:12] don't want it to turn in to the 4500 line MR where everyone comes to hate me [00:12] :p [00:12] or rather It hink that may be what it is now [00:12] and want to turn it in to something else [00:13] Pfft! [00:13] :)- [00:52] deleting code is definitely the best way to spend last hour or so of work day === chihchun_afk is now known as chihchun [03:01] OK, now bzr diff is lying to me === duflu_ is now known as duflu [03:03] What the?! My whole fix got merged over without conflicts? [03:04] That's a new and scary bzr bug [03:12] * duflu longs for git [03:33] duflu, Thank you! https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1400580 [03:33] Launchpad bug 1400580 in Mir " Color Inverse on display. Toggle Negative Image" [Wishlist,Triaged] [03:34] mikodo: No problem === chihchun is now known as chihchun_afk [06:43] alf__: Could you have another look at nice-log? [09:34] duflu: FYI, client-api-platform-operation-* branches updated [09:36] alf__: got a moment to review this? https://code.launchpad.net/~alan-griffiths/mir/publish-server-examples-and-docs/+merge/244026 [09:37] alan_g: sure [09:37] duflu: oops, just a moment [09:40] alf__: Thanks. Not sure if I'll have time to try and land them again today [09:40] But anyone can do it [09:41] duflu: np, thanks [09:42] * alan_g looks to see who has... interesting: http://paste.ubuntu.com/9454116/ [09:44] aargh, merging back the trunk which contains the revert of the client-platform-* removes files from my branch! [09:45] why bzr, why? [09:46] alf__: Yeah I meant to warn you of that. Need to resubmit under a different name [09:46] Because bzr is awesome [09:46] But it was my mistake not testing x-compile [09:47] alf__: I had the same thing happen (with less explanation) this morning. I had to download the diff from LP and patch it back in :S [09:49] duflu: no worries, I should have checked x-compile to, but I forgot (I am used to CI checking it) [09:49] s/to/too [09:49] alf__: I *thought* building all platforms covered the Android code on desktop [09:50] Must have been in #ifdef ANDROID [09:51] duflu: it builds the all production code, but the tests only for the first platform [09:51] alan_g: Ah [09:51] alan_g: We *could* build tests for both [09:52] duflu: there's stuff with different implementations that we'd need to split out [09:52] But we *should* [09:52] * alan_g can't be motivated to log a bug [10:17] alf__: any opinion on mir_demo_server[_basic|_example|]? [10:20] alan_g: +1 for "mir_demo_server" [10:21] I'll roll that into the update then. :) [10:35] alf__: pushed [10:50] alf__: hey, on a displayconfiguration change, is there any chance existing DisplayBuffers are all destroyed and re-created? [10:53] greyback: they are [10:54] alf__: ok, explains things on my end [10:54] thanks [10:55] greyback: Do you know which channel I should use to get the latest phone image? vivid-proposed? [10:55] alf__: yes, that's it [10:55] greyback: ta [10:55] np === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === alan_g is now known as alan_g|a === alan_g|a is now known as alan_g|lunch === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === alan_g|lunch is now known as alan_g === ogra_` is now known as ogra_ [15:37] racarr_: how's mirevent 2.0 coming along? === dandrader is now known as dandrader|lunch === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === dandrader|lunch is now known as dandrader [17:15] seb128: did you file a bug the other day on relative screen position ? [17:15] i was just chatting with alf__ and it seems we already have this :) [17:16] * kgunn is also curious about racarr_'s answer re mirevent2.0....as is anpok [17:43] Have we defined any version macros that users can use to conditionally compile server code? [17:49] mlankhorst: The new accessors landed but we hav to port everything and make a release before we can rip out hte old event and start making more detailed changes [17:49] e.g. mir event-2.0 is there now but [17:49] equivalent to mir event 1.0 still basically [17:50] kgunn, not yet [17:50] kgunn, I had to call it a day yesterday and was not working today, going to do that tomorrow [17:58] racarr_: so anpok should start to conform to the new mirevents structures for the libinput work ?....i mean since they're in there [17:59] seb128: ack...so i think tomorrow your morning, just chat with alf__ [17:59] before bugging [18:00] kgunn: Not yet, he still outputs the old mir event structures and clients see the new one (or the old one) [18:00] I think we talked about it yesterday and are on the same page [18:00] unless this is something else... [18:00] :) [18:01] could be, just trying to help things along === alan_g is now known as alan_g|EOD [18:01] no worries. I am wondering if I should speed up any bits to help [18:01] libinput [18:20] kgunn__, k, thank you [18:28] re [18:28] racarr_: ah ok, wasnt sure about outputting the old one.. [18:28] thought the new ones were just around the corner [18:30] racarr_: ok [18:31] anpok: Well...I dunno...like I said the new ones are there for clients [18:31] but even if something was mped to port every client now [18:31] it would be what, 2 weeks at least before we could drop the old code [18:31] and right now the old event is used over the wire [18:31] :/ [18:31] for accessing MirEvent though you should [18:32] hm for input .. we still have the mapping .. [18:32] use the new mir_input_event* [18:32] stuff [18:32] yeah [18:32] mapping to droidinput structures.. [18:32] mm [19:17] anpok, racarr_ any more thoughts on the namespace stuff from yesterday? [19:18] iirc, we were thinking about changing mir::input to mir::event because "input" is somewhat vague [19:22] aha thats not what I was thinking ;) [19:22] I was thinking that mir::input is fine as it is because its understood to mean input devices [19:22] and that if we put everything related to events [19:22] in the same namespace [19:22] we lose that meaning [19:22] so if you wantt o have stuff related to MirEvent, but don't want it in the mir:: namespace [19:22] maybe it belongs in a mir::events:: namespace [19:22] or something [19:23] but certainly for example, an input device prober, or the input dispatcher, etc [19:23] I think those make more sense in mir::input:: [19:26] okay, I see the distinction, although from the graphics side of the fence... all looks like input to me :) [19:27] kdub: You are right a generalization could be made I just think its more confusing than helpful [19:27] e.g. mir::output::logging, mir::output::graphics [19:27] wouldn't be helpful ;) [19:27] lol [19:28] right, but mir::hid or mir::events might be [19:29] anyways, so dropping the namespace stuff... I guess we're still looking for what to do with the 3 EventSink interfaces [19:37] kdub: I dunno...sorry ill think about it in a sec...furiously debugging [19:39] does anyone know why we don't have a mir_surface_spec_set_output_id? we have a set_fullscreen_on_output.... [19:40] AlbertA, just a fuzzy memory, but iirc, something having to do with helping more mesa bypass happen [19:41] ok...I'm just wondering so I can migrate the examples.... [19:41] to the new spec api [19:41] since eglapp uses the output id parameter to place a non-fullscreen surface [19:42] in a specific output id [19:42] if the user sets up that option [19:42] Interesting [19:42] I thought output_id was equivalent [19:42] to fullscreen on output [19:42] and didnt know the other behavior was allowed [19:43] so perhaps we just want to deprecate that behavior? [19:43] although reading the windowing spec [19:44] the system needs to support restoring the previous client context.... [19:44] which may include being in a certain monitor and non-fullscreen [19:44] but I guess that can just be done in the server side [19:44] I think thats opaque [19:44] to the client [19:44] yeah [19:44] ikf there is any client involvement [19:45] its through an opaque [19:45] cookie [19:45] im not sure apps are even allowed to use fullscreen_on_output [19:45] afaik the approved use case is: xmir [19:45] and nested [19:46] and eglspinner? [19:48] maybe what that means is that USC allows clients to do that (returns true), but U8 does not (returns false) [19:48] ah probably [19:49] ok, I think I have my answer :) change eglapp....:) [20:13] kdub: no further thoughts so far === chihchun is now known as chihchun_afk [20:40] kdub, nothing I've checked and I've the same problems/errors of the last time. But I think, also wayland on the framebuffer library works well xD . Is there an option to force mir to use only the framebuffer (as /dev/graphics/fb0)? [20:40] *or the rendering method of the render_to_fb demo [20:42] "--disable-overlays true" (argv) or "MIR_SERVER_DISABLE_OVERLAYS=true" (env) forces the render_to_fb demo rendering method [20:42] let's try (again [20:42] ) [20:43] MIR_SERVER_DISABLE_OVERLAYS=true , well, It's visible that it's an env specification xD [20:49] kdub as usually segfault on egl demo, and nothing displayed on the screen for others [20:49] just a thing, I launch the compositor in this way: [20:49] unity-system-compositor --file '/run/mir_socket' --from-dm-fd 0 --to-dm-fd 1 --disable-overlays true [20:50] try mir_demo_server_shell [20:52] the same result [20:54] any kernel or logcat error msgs? [20:57] kdub, http://paste.ubuntu.com/9467210/ from dmesg, but I think is not really useful [20:57] nah, so thats okay [20:59] http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/doc/android_new_device_bringup.md [20:59] has some more suggestions... one day it'll make it to unity.ubuntu.com/mir [21:01] kdub, from logcat: http://paste.ubuntu.com/9467244/ [21:01] and try the mir_integration_tests [21:02] ok [21:07] well, kdub it doesn't accept the filters, anyway the integration test segfault after [ RUN ] StaleFrames.are_dropped_when_restarting_compositor and fail at http://paste.ubuntu.com/9467332/ [21:09] how does this one do?: mir_integration_tests --gtest-filter="TestClientIPCRender.test_accelerated_render_double" [21:10] kdub, it returns the help of mir_integration_tests [21:11] oh, sorry, --gtest_filter [21:12] kdub, http://paste.ubuntu.com/9467365/ [21:13] mibofra, so, the render_overlays one won't output anything for hwc 1.0, but the server should still work (and the render_to_fb works, so thats good) [21:14] kdub, anyway on the android_new_device_bringup.md there is also --gtest-filter instead of --gtest_filter [21:14] right, should be updated [21:53] kdub, http://paste.ubuntu.com/9467658/ , line 55 [21:53] is normal that the compositor stops before the drawing? [21:56] mibofra, no, its strange [21:56] I guess if that integration test is working, and the render_to_fb works, the driver components are working... something else is going on [21:58] kdub, does the compositor need some tty? [21:58] like the tty1? [21:58] no, it doesnt [21:58] ok [21:59] * kdub hasnt seen StaleFrames be the failing test for a new device before [22:00] kdub, I had an idea [22:01] kdub, it uses /dev/ump as part of the driver (egl) no? [22:02] perhaps, that's abstracted to mir and different on each chipset [22:02] I've fusered /dev/ump to see if there was something using it, and I've found something with lsof [22:02] I've found Binder_1 , kdub [22:02] maybe it interferences in a way? [22:03] not sure [22:05] kdub, other process too are using ump [22:10] AlbertA: Requests for output_id that _weren't_ fullscreen were denied. [22:11] kdub, _render_to_fb access in another way, I think is not only problem of setting --disable-overlays true, because it doesn't solve the problem on the other mir servers (demo or not) [22:11] AlbertA: mir_surface_spec didn't change that, it just meant that you couldn't make a request that we'd automatically deny :) [22:15] RAOF: ack [22:16] hi AlbertA, hi RAOF [22:17] hi there [22:23] RAOF: Linux is about choice and MirSurfaceSpec is ruining it. [22:23] :p [22:23] Good morning [23:31] Ok. Naming problem. [23:32] I've got an interface, currently called Dispatchable, which has “get pollable fd” and dispatch() operations. [23:33] I need to name an interface for something that has a create_dispatchable_for_me() operation. [23:41] RAOF: DispatchableFactory? :) [23:41] Yeah, possible, but you only ever want to produce one Dispatchable from it. [23:41] The interface is more create_a_dispatchable_that_will_dispatch_me() [23:42] And it very rarely makes sense to have more than one of those. [23:52] DispatchableProgenitor [23:52] hmm [23:52] Sorry what is a dispatachable? [23:52] or rather what does dispatch() do [23:53] for whom [23:57] dispatch() does whatever should be done when there's something ready.