[05:54] <RAOF> Hey, would anyone have any objection to putting an event_time member in the MirEvent union?
[06:09] <racarr> RAOF: I tried to think of reasons to object and cant
[06:28] <duflu> RAOF: I have wanted that myself too. Just feared the necessary client ABI break. Maybe first thing next cycle?
[06:29] <duflu> Although we're still at a point where breaking the client ABI isn't a huge deal
[06:31] <RAOF> duflu: I'll queue it up; I'd like it for some testings.
[06:58] <duflu> Votes wanted: https://code.launchpad.net/~vanvugt/mir/frontend-server/+merge/207602
[07:14] <RAOF> duflu: Given that we agree that the code itself is bad, is renaming it worthwhile?
[07:14] <duflu> RAOF: Yes I think so. Less bad :)
[07:14] <RAOF> That's my 2¢; it's after 6 here, so tootleooo!
[07:14] <duflu> RAOF: Night
[10:26] <alan_g> anpok: has you "Needs Information" been answered? https://code.launchpad.net/~alan-griffiths/mir/introducing-SurfaceObserver/+merge/213431
[10:34] <anpok> not really, but looking at the question it is not something that we can answer now..
[10:35] <anpok> users will tell us
[10:44] <anpok> alf__: final opinions on https://code.launchpad.net/~andreas-pokorny/mir/no-initial-display-configuration-sent-to-hosting-server/+merge/213126?
[10:47] <alf__> anpok: I think creating the surfaces with the changed configuration is problematic
[10:47] <alf__> anpok: without applying the configuration
[10:49] <alf__> anpok: for example, what if the changed configuration says two outputs, but the host configuration is a single output, or outputs of different sizes etc?
[10:54] <alan_g> alf__: there are already problems in that area. Try running a host as sidebyside and a nested render_surfaces with the defaults
[10:56]  * alf__ tries
[10:58] <anpok> hm tried the new greeter without applying the policy
[10:58] <anpok> it still works
[10:58] <anpok> it also seems to still get a transparent surface
[11:01] <alf__> anpok: is this on android?
[11:02] <anpok> yes
[11:02] <alf__> anpok: it could be that the host configuration pixel format is RGBA (instead of RGBX)?
[11:03] <anpok> ah yes the first (default) one it is..
[11:07] <alf__> anpok: alan_g: I think that since we are not using the initial display configuration for nested any more, we should change to use other information. For example a bool prefer_translucent_formats?
[11:09] <alan_g> alf__, anpok: I don't know the "right" answer - we have a design choice as to how the control (and any negotiation) splits between the host and nested systems.
[11:12] <anpok> we could also look at the other side - should focus changes apply the complete configuration?
[11:14] <alf__> anpok: alan_g: My understanding is that we have made the decision that the nested server won't touch the host configuration by default. This also means that we need to keep it in sync with it.
[11:14] <anpok> alf__: what if the nested seat only wants to use a single diplay, while the other display should be reserved for another user?
[11:15] <alan_g> My understanding is that we have made the decision that the nested server won't touch the host configuration *on startup*
[11:15] <anpok> but it is still alowed to make changes to that configuration
[11:15] <alf__> alan_g: anpok: right, on startup, that's what I actually meant
[11:15] <anpok> i.e. we want full screen applications run with different modes?
[11:15] <anpok> ok
[11:15] <anpok> and that I consider to be only a band aid
[11:16] <anpok> short lived..
[11:16] <anpok> because this discussion will take a few roundtrips and will lead to some rework..
[11:16] <anpok> i assume
[11:16] <alf__> anpok: band aid == proposed MP?
[11:16] <anpok> yes
[11:17] <anpok> just what split greeter needs for now
[11:17] <alf__> anpok: alan_g: I am just worried that we are pushed into a lot of band aid solutions lately, and gathering tenchnical debt.
[11:18] <alan_g> alf__: agreed. (Although I'm trying to fix the Surfaces debt ATM)
[11:19] <alan_g> anpok: are you able to drive a discussion about nesting and display configuration? E.g. Write down some key scenarios?
[11:20] <anpok> ok
[11:21] <alan_g> In that case, how about circulating those and scheduling a hangout?
[11:22] <alan_g> alf__: We ought to start putting debt items where we (and especially kgunn) will be reminded of them. I know some are in the bugs.
[11:23] <anpok> alan_g: google drive document?
[11:23] <alf__> alan_g: anpok: [technical-debt] bug tag?
[11:23] <anpok> for the scenarios to discuss..
[11:25] <alan_g> Whatever works
[11:26] <anpok> alf__: so yes both ways turn out to provide a transparent surface format, so no need to call initial policy inside that (temporary) fix
[11:26] <alf__> anpok: both ways?
[11:28] <anpok> yes, with and without applying the initial policy in the greeter and unity8 nested shells
[11:31] <alf__> anpok: that will not work on mesa though, because it uses an rgbx format for the host server
[11:53] <anpok> cannot test, thought the array of supported formats might also be led by a transparent format..
[12:02] <kgunn> greyback: alf__ got to thinking in my slumber...it might not matter what mir does wrt egl, since qt is interfacing directly, we can effect the u-s-c
[12:03] <kgunn> but i don't even think we'll be able to effect the session compositor
[12:03] <kgunn> esp with our effort to plug in qt sg
[12:03] <anpok> alf__: you are right
[12:04] <greyback> kgunn: you lost me. Can you rephrase please?
[12:07] <kgunn> greyback: egl is a hw vendor specific implementation (unfortunately eglswapbuffers is up for interpretation)
[12:07] <kgunn> so whomever is interfacing with egl directly can be effected by those choices, and blocking might be occuring anyway
[12:08] <kgunn> or "other errors"....context lost could be one
[12:08] <greyback> kgunn: I see what you mean
[12:09] <kgunn> greyback: i was thinking mir could arbitrate for qt, but that's only really true for the compositor...not the the apps
[12:09] <kgunn> right ?
[12:09] <kgunn> and even the compositor...we're looking at using qt sg
[12:13] <anpok> i thought we can decide about the behavior of eglswapbuffers in every system mir will be shipped?
[12:14] <kgunn> anpok: we can decide as long as we're the ones dealing with swapbuffers, but if the app is native (which think of toolkits as native gl apps)..they're dealing with egl directly
[12:15] <greyback> I guess there's no way to prevent that
[12:16] <alf__> kgunn: We are implementing the EGL platform though, so we do have at least some control of what's happening, although perhaps not full control.
[12:16] <kgunn> alf__: the egl platform, but not the egl driver per se
[12:16] <kgunn> right ?
[12:16] <greyback> and since it is vendor specific, there's little we can do other than document that we recommend people use Mir's client API, which does what we want
[12:17] <kgunn> alf__: anpok greyback happy to be proven wrong...
[12:18] <kgunn> morning duties, bbiab
[16:06] <dandrader> should I feel bad about casting a shell::Surface to a scene::Surface?
[16:07] <alan_g> dandrader: maybe
[16:07] <dandrader> on the QPA, MirSurfaceItem has a shell::Surface and it uses the shell:Surface::lock_compositor_buffer()  hack
[16:07] <alan_g> The usual rule is that "if you destroy type information you can restore it".
[16:08] <dandrader> but that hack is to be removed in favor of the new scene::Renderable::buffer
[16:09] <dandrader> which is implemented only by scene::Surface
[16:09] <alan_g> I think it would probably be better to have a scene::Surface in the first instance
[16:09] <alan_g> But I've not looked at what that involves
[16:09] <dandrader> the qt compositor QPA is getting surfaces from shell::SessionListener::surface_created
[16:10] <dandrader> which gives shell surfaces, not scene surfaces
[16:10] <dandrader> naturally
[16:10] <alan_g> dandrader: yeah, that hasn't been fixed (yet)
[16:11] <alan_g> I'm still fixing scene::Surface et al. scene::Session comes next
[16:11] <dandrader> alan_g,  hmmm, so in the meantime I can just do the cast from shell::Surface to scene::Surface because later mir interfaces will change in a way that I won't have to do it anymore?
[16:12] <alan_g> dandrader: there ought to be a scene::Session and a scene::SessionObserver and we'll obsolete the shell stuff
[16:12] <dandrader> alan_g, ok, sound good
[16:12] <alan_g> At least that's the current "vision"
[16:13] <alan_g> *that shell stuff (there's still a role for shell)
[19:10] <dansuf> Hello once again. I still have got this error in mir that it fails to bind buffer to texture and also in logcat W/Adreno200-EGL( 1576): <qeglDrvAPI_eglCreateImageKHR:4526>: EGL_BAD_PARAMETER
[19:11] <dansuf> Is there any possibility to see more exactly what is the problem?
[19:13] <dansuf> Surfaceflinger also doesn't work so it may be also something device-specific, but I still don't know what.
[19:40] <kgunn> dansuf: judging from this...
[19:41] <kgunn> https://bugs.launchpad.net/mir/+bug/1272041
[19:41] <kgunn> most likely a color buffer mismatch ?
[19:41] <dansuf> kgunn: i don't have this unsupported buffer format line
[19:43] <kgunn> AlbertA: ok..so, i'm a little confused...
[19:43] <AlbertA> kgunn: ?
[19:44] <kgunn> so looking at qtubuntu...i 1/2 expected to find some code
[19:44] <kgunn> that said something like qt->mir.swap_buffers, that would in turn call the eglSwapBuffers....
[19:44] <kgunn> but instead...i only find
[19:45] <kgunn> qtubuntu/src/platforms/base/context.cc
[19:45] <kgunn> calling it direct...
[19:45] <kgunn> am i searching wrong?
[19:45] <dansuf> kgunn: there's this bad_match like in the bug report, bad_context in eglSwapInterval and also
[19:45] <dansuf> W/Adreno200-ES20( 3349): <get_simple_queries:1360>: GL_INVALID_ENUM
[19:46] <dansuf> kgunn: this one appeared amongs other errors when running lightdm
[19:47] <AlbertA> kgunn: no I think that's expected
[19:47] <AlbertA> kgunn: because then the egl will foward the call to the native window type
[19:47] <AlbertA> kgunn: which is where the mir platform will get hooked on
[19:47] <kgunn> dansuf: so in all this instance are you using the mir qt plugin ?
[19:49] <dansuf> kgunn: I'm not sure but if you mean if the variable QT_QPA_PLATFORM contains ubuntumirclient then yes
[19:54] <kgunn> dansuf: can you share your exact device name once more ? i recal you said Sony....but model #?
[19:55] <dansuf> kgunn: live with walkman, a'ka coconut
[19:55] <dansuf> kgunn: but I'm not using official cyanogenmod repos as they dropped support for the device
[19:58] <kgunn> dansuf: so where do you get your gpu drivers from ?
[19:58] <dansuf> kgunn: I got gpu drivers from adreno's site
[19:59] <kgunn> dansuf: so binary i assume ? your not building from source?
[19:59] <dansuf> kgunn: generally, w-flo who ported desire z also did an update of his drivers and in a commit wrote it helped him with some issues
[19:59] <dansuf> kgunn: yes, a binary
[20:00] <kgunn> dansuf: so this is only a guess...but you might be careful of binaries compiled on differing kernel & android versions vs what you have...e.g. do you know which android version those were compiled against ?
[20:01] <dandrader> Have you guys seems this error before? http://paste.ubuntu.com/7191321/ this is a symbol from libboost_program_options.so.
[20:01] <kgunn> AlbertA: so even tho it looks like qtubuntu calls eglSwapBuffers directly...this call actually gets rerouted ? (i don't see how)
[20:02] <AlbertA> kgunn: right because mir is the one providing the egl native display
[20:02] <dandrader> so it seems libmirplatformgraphics.so should have a depencendy on it but ldd says there's none..
[20:04] <dansuf> kgunn: adreno says its for Android 4.2 Jelly Bean MR1 and also in logcat there's some info that suggests it was compiled for mako
[20:05] <dansuf> kgunn: and before w-flo updated his drivers he needed to make changes in mir's source to make it working
[20:05] <kgunn> dansuf: hmmm sounds fishy (no pun intended :)
[20:06] <kgunn> dandrader: are you changing mir config? or is it bombing out even on the default ?
[20:08] <dandrader> kgunn, you mean the DefaultServerConfiguration class?
[20:10] <kgunn> gotta run...
[20:10] <kgunn> kdub: ^ can you assist dandrader
[20:11] <kdub> you mean dansuf?
[20:11] <kgunn> kdub: dandrader
[20:11] <kgunn> dansuf: i think we're on to android 4.4.2...dunno if that might be an issue
[20:11] <kdub> okay :) lets see
[20:12] <dansuf> kgunn: we're on cm10.1 which i believe is 4.2
[20:12] <dansuf> kgunn: 4.4 is kitkat, the newest
[20:12] <kdub> dandrader, there was a MP that added a boost dependency to mirplatform graphics
[20:13] <dandrader> kdub, still under review?
[20:13] <dansuf> kgunn: anyway, thank you
[20:14] <kdub> dandrader, merged yesterday
[20:14] <kdub> to devel
[20:14] <dandrader> hmm
[20:14]  * dandrader checks
[20:14] <dandrader> because I just rebased my stuff on top of latest devel...
[20:14] <kdub> dandrader, although, that looks more like a build time problem that was being averted
[20:15] <kdub> yours looks a bit different
[20:19] <kdub> dandrader, but I don't see the packages listing program-options as a dependency though too
[20:20] <kdub> dandrader, does installing program-options fix the error?
[20:21] <dandrader> kdub, no it was already installed. I'm now trying this http://paste.ubuntu.com/7191409/
[20:21] <dandrader> kdub, but I have  a feeling I might have messed up my installation somehow....
[20:23] <dandrader> because the problem only happens when running unity8. mir examples work fine....
[20:23] <kdub> dandrader, i'll see if I can reproduce the problem today
[21:03] <racarr> dandrader: I ran in to this
[21:03] <racarr> I worked around it by LD_PRELOADING libmirserver
[21:03] <racarr> becuase it wasnt ust boost option stuf (LD PRELOADING boost options give
[21:04] <racarr> other errors)
[21:04] <racarr> hoping the
[21:04] <racarr> inflight MP would fix it
[21:04] <racarr> I cant figure out what caused it to happen though so dont really understand
[21:05] <racarr> maybe libmirplatform graphics needs to be explicitly linked against libmirserver...I dont think it is? but since we load it dynamically its been fine
[21:05] <racarr> and that stopped working because <some explanation goes here>
[21:05] <dandrader> racarr, true. After I added boost options I get miroptions missing symbols. after I also add miroptions I get missing _ZN3mir21default_server_socketE and so on
[21:06] <dandrader> will try your workaround now
[21:06] <racarr> I cant remember in the end if I ended up LD_PRELOADING libmirserver or linking in CMake but either should work
[21:06] <dandrader> racarr, yeah LD_PRELOADING libmirserver works!
[21:08] <racarr> dandrader: Ok ill send an email to the list or make an MP or something in ust a few thanks.
[21:09] <racarr> I originally thought maybe it was ust an isolated issue on my phone
[21:09] <racarr> because of something dumb I did :p
[21:09] <racarr> about 9/10 times its that.
[21:11] <racarr> 17 conflicts encountered.
[21:11] <racarr> ...lovely
[21:16] <kdub> I'll look into that program options today, getting my stuff out the door
[21:55] <kdub> dandrader, racarr is there a bug about that program options stuff? (if not, ill file one)
[21:56] <dandrader> kdub, not that I'm aware of
[21:56] <kdub> okay, i'll file
[22:01] <dandrader> kdub, thanks!
[22:01] <kdub> no problem
[22:30] <kdub> hey racarr, if you can still repro that symbol problem, I posted a fix here https://code.launchpad.net/~kdub/mir/fix-1301040/+merge/213739
[22:31] <racarr> kdub: Not sure if I can reproduce it still...will check in a sec...should be able to
[22:31] <racarr> I dont think that will fix it though because
[22:31] <racarr> if you LD_PRELOAD boost options
[22:31] <racarr> you then go on to get missing symbols in mir options
[22:31] <racarr> i you link mir options as well
[22:32] <racarr> you go on to get missing symbols in default server conf
[22:57] <kdub> racarr, ack, i'll keep seeing if i can get a build