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