[03:14] <mterry> duflu_, heyo!
[03:14] <duflu_> mterry! sup?
=== duflu_ is now known as duflu
[03:15] <mterry> duflu_, so maybe I don't understand C++ well enough, but the code in ./include/server/mir/compositor/scene.h doesn't seem to give access to CompositingCriteria...
[03:16] <duflu> mterry: It's a bit ugly, but all designed to work with a filter/applicator interface. I think all those are defined in scene.h?
[03:16]  * duflu checks
[03:17] <mterry> duflu, it looks like they *take* a criteria, not give one
[03:18] <duflu> mterry: All you need is a Scene object. Then... scene->for_each_if(filter, operator) to do your rendering. The instances will be provided by the underlying scene implementation in Mir
[03:19] <duflu> That's a bit of an ugly way to iterate though. I'd like to replace it with something else
[03:19] <duflu> You will need to create implementations of FilterForScene and OperatorForScene :P
[03:19] <mterry> duflu, oh I see.  I write a filter, and the for_each_if will call operator() giving a criteria
[03:20] <duflu> mterry: Yep. The instances implementing those interfaces are hidden, but you will get called with them
[03:20] <mterry> duflu, then I also need to get a Rectangle for the surface to pass the criteria...
[03:20] <mterry> this is really roundabout
[03:21] <duflu> mterry: Your display_buffer->view_area() is good for that
[03:21] <mterry> ah ok
[03:21] <duflu> mterry: I know. I found it this way :)
[03:21] <duflu> "It was like that when I found it"
[03:21] <mterry> duflu, :)
[03:22] <duflu> mterry: So a minimal filter would call should_be_rendered_in
[03:22] <mterry> duflu, so my Filters get called...  But how do I match a filter call to a given surface?
[03:23] <duflu> mterry: You can't right now. We all want that fixed up and I think kdub is most likely to do it soonest
[03:23]  * mterry is trying to imagine how I use these pieces together
[03:25] <duflu> mterry: Our immediate desire is to replace both the CompositingCriteria and BufferStream parameters with some *Surface interface which implements both. We just need to restructure the Surface class hierarchy
[03:30] <mterry> Whoops, disconnected.  duflu, don't know where we stopped
[03:30] <mterry> <mterry> duflu, yeah, so I can iterate and ask the criteria, but without being able to differentiate between what the various iterate calls *mean* (i.e. what surfaces they match), I don't know how that API is useful to a 3rd party
[03:30] <duflu> mterry: You missed nothing
[03:30] <mterry>  hmm
[03:31] <mterry>  maybe I'm missing a piece of the puzzle
[03:31] <mterry>  I guess the Operator sees a BufferStream..
[03:31] <mterry>  But that's not super informative
[03:31] <mterry> duflu, cool
[03:31] <mterry> duflu, so kdub is working in this space?
[03:31] <duflu> mterry: Even the built-in renderer treats it as a TODO. I had to use "&criteria" as a dummy surface ID :(
[03:32] <duflu> mterry: Better check with kdub. He's always likely to get pulled into more pressing Android work
[03:33] <mterry> kdub, if I don't get to you first, poke me tomorrow!
[03:33] <mterry> duflu, thanks so much!
[03:33]  * mterry is very slowly grokking Mir
[03:33] <duflu> mterry: No problem. Sorry you're stuck on something that we already planned to redesign :/
[06:54] <RAOF> Ok. That should really, truly, absolutely be the last umockdev merge request in a while!
=== mpt_ is now known as mpt
[09:45] <mlankhorst> RAOF: erm can you now at a mainloop api like in pulseaudio? :P
[09:52] <duflu> So many things I'd like to move around. But the weekend is in the way.
[09:52] <duflu> Till next time
=== lool- is now known as lool
[12:20] <alan_g> alf_: were you looking at an intermittent failure in MesaDisplayTest recently? https://jenkins.qa.ubuntu.com/job/mir-clang-trusty-amd64-build/1007/console
[12:27] <alf_> alan_g: yes, but it was a clean failure, no exceptions, and fixed (by all appearances) by r1401
[12:28] <alan_g> alf_: thanks, will try to reproduce this one then
[12:37]  * alan_g reproduces intermittent failures in MesaDisplayTest.drm_device_change_event_triggers_handler
[12:42] <alf_> alan_g: exceptions, or other test failure?
[12:42] <alan_g> Segmentation fault (core dumped)
[12:43] <alan_g> I'll look deeper after lunch
=== alan_g is now known as alan_g|lunch
=== alan_g|lunch is now known as alan_g
[13:51] <alan_g> alf_: still happy with the updates to https://code.launchpad.net/~alan-griffiths/mir/make-ConfigurationOptions-a-dependency-of-DefaultServerConfiguration/+merge/206996?
[13:51] <alf_> alan_g: looking
=== Trevinho_ is now known as Trevinho
[15:11] <alf_> rsalveti: Hi! I am trying to run the x86 emulator to get more information about https://bugs.launchpad.net/mir/+bug/1282248 , but all I am getting is a blank screen in the emulator
[15:11] <ubot5> Launchpad bug 1282248 in Mir "Unity8 crashes when using latest mir/android backend with system-compositor" [High,In progress]
[15:11] <alf_> rsalveti: Any ideas?
[15:15] <rsalveti> alf_: hm, getting a black screen with my guide?
[15:15] <rsalveti> *blank
[15:15] <rsalveti> alf_: are you using it with a proprietary gl driver at your host?
[15:21] <alf_> rsalveti: yes, your guide, free drivers, radeon and intel (tried with both)
[15:21] <rsalveti> alf_: weird, trying it again locally
[15:23] <alf_> rsalveti: I do get related errors: http://paste.ubuntu.com/6971401/
[15:24] <rsalveti> oh, alright
[15:26] <alf_> rsalveti: hmm, I think I need to install the i386 mesa drivers (running on amd64)?
[15:26] <rsalveti> alf_: yes
[15:27] <alf_> rsalveti: isn't there an amd64 version of this?
[15:27] <rsalveti> alf_: not yet
[15:28] <rsalveti> there will be sson
[15:28] <rsalveti> *soon
[15:28] <alf_> rsalveti: ok
[15:34] <alf_> rsalveti: works now great!
[15:34] <rsalveti> alf_: great!
[15:35] <alf_> rsalveti: does the image have persistent storage?
[15:35] <rsalveti> alf_: any idea of what might be wrong with that bug?
[15:35] <rsalveti> alf_: yes
[15:36] <alf_> rsalveti: I have found the exact commit that introduces it (on a real device at least), but the armhf backtraces I can get are less than helpful...
[15:36] <rsalveti> alf_: yeah =\
[15:37] <alf_> rsalveti: the commit is the one that changes the client platform to be dynamically loaded instead of built-in, not sure why that would cause a failure, though. Running nested tests with mir_demo_* works...
[15:38] <alf_> rsalveti: anyway, hopefully the x86 backtraces will be more helpful
[15:39] <rsalveti> alf_: yeah, it's quite weird, at least the x86 image doesn't have any issue with android TLS
=== dandrader is now known as dandrader|afk
[16:16] <alf_> fginther: Thanks for preparing the jobs. I realized that this is something I could by myself in the future if I want to try something, if I branch the hooks, right?
=== dandrader|afk is now known as dandrader
[16:17] <fginther> alf_, yes, I did have to configure the job first to allow the hooks, but once they are there you can substitute in your own branch / hooks for testing
[17:15] <kdub> mterry, ping
[17:15] <mterry> kdub, hello!
[17:16] <mterry> kdub, I had some questions for you.  Is that what this ping is?
[17:16] <kdub> yeah, saw some chatter about the surface stack iteration stuff
[17:18] <mterry> kdub, so my ultimate goal is to be able to tell when a session/surface actually has posted their first frame to render.  This has been harder than I'd thought
[17:18] <mterry> kdub, recently I tried to go down the CompositingCriteria route
[17:18] <mterry> kdub, but it isn't exposed in a particularly meaningful way
[17:18] <mterry> kdub, but I was told you were working in that space?
[17:19] <kdub> well, I have to revise the surface stack to enable android bypass/overlays
[17:19] <kdub> the interfaces now have been out-grown by the way they are being used, and need some reassessment
[17:20] <mterry> kdub, well.  I am highly interested in being able to tell when a (at least first) frame has been rendered
[17:23] <mterry> kdub, what is priority of your work?  Like, how likely is it to happen soonish?
[17:23] <kdub> mterry, that's a bit different area than refactoring the surfacestack/compositingcriteria system
[17:24] <mterry> kdub, well, I can probably get what I need from actual access to CompositingCriterias and being able to match them to a surface
[17:24] <kdub> let me see if there's a way to do that in the public interfaces
[17:24] <kdub> or if there's a quick way to add a fn
[17:24] <mterry> kdub, because they have the should_be_rendered_in() call
[17:24] <mterry> kdub, and I can iterate over the CompositingCriterias via the Scene object and its for_each_if calls
[17:25] <mterry> kdub, but I can't actually tell which Surface they each match with
[17:26] <kdub> thats kinda a heavyweight solution though, as we lock the surfacestack during the iteration over the surfaces
[17:28] <mterry> kdub, well I'm all for better ways.  It's literally the only way to get at Criterias right now though
[17:28] <alan_g> kdub: also, that locking is something we plan to rip out - along with the associated code
[17:30] <kdub> alan_g, sure
[17:30] <kdub> mterry, what is the larger problem? (eg, trying to coordinate some animation or something)
[17:31] <alan_g> I've still not understood why waiting for swap_buffers(Not(nullptr)) doesn't work
[17:32] <alan_g> duflu found a Mesa bug while looking into this. But mterry is on the android drivers
[17:32] <mterry> alan_g, there are internally several buffers posted before the client gets to run
[17:32] <mterry> alan_g, so maybe that's just a bug.  But it's not usable at the moment
[17:33] <mterry> alan_g, that's all in the bug
[17:33] <alan_g> mterry: yeah, I don't understand why
[17:33] <mterry> alan_g, meaning that you think it's a bug that Mir is swapping buffers so early?
[17:36] <mterry> kdub, https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1280842 explains my ultimate goal in all this
[17:36] <alan_g> mterry: mir should only be getting a buffer once it has been drawn. I don't know exactly what your scenario is doing to send buffers from the client before they are ready.
[17:36] <ubot5> Launchpad bug 1280842 in mir (Ubuntu) "[enhancement] Need a method of hiding surfaces until they are ready to draw themselves" [Medium,Opinion]
[17:37] <mterry> alan_g, it's not even *my* scenario. It's just a client calling mir::run_mir
[17:37] <mterry> alan_g, something about constructing/running a DisplayServer causes 4 buffers to be swapped
[17:37] <alan_g> mterry: so this client is a nested server?
[17:37] <mterry> alan_g, yeah
[17:38] <mterry> alan_g, (this is all in the context of USC which just deals with nested servers)
[17:39] <alan_g> mterry: I strongly suspect a bug in the nested code then
[17:40] <alan_g> With a second possibility that the android client code is the cause
[17:41] <alan_g> *internal* client
[17:41] <mterry> alan_g, would that be work-around-able?
[17:43] <alf_> alan_g: mterry: Hmm, when the compositor starts up it triggers itself, each trigger being 3 compositings. In a nested server, swapping the buffer when compositing means sending the buffer to usc.
[17:46] <alan_g> And the 4th could be something like the Mesa "advance_buffer" bug?
[17:47] <alf_> alan_g: yeah
[17:47] <mterry> I do only get 3 if I hide() the surface first, FYI
[17:47] <alan_g> mterry: that makes sense
[17:48] <kdub> iirc, android shouldnt do that 'advance_buffer'
[17:49] <kdub> rather, the same sort of bug as the Mesa "advance_buffer". it does request a buffer on eglCreateWindowSurface, but it should get the buffer associated with the surface creation
[17:50] <kdub> (nexus 10 does something different)
[17:51] <alan_g> kdub: ok, but I'll buy alf_ explanation - we need to something different when compositing in nested mode.
[17:52] <alan_g> If no-one else grabs it I can have a go on Monday
[17:52]  * mterry hugs alan_g
[17:52]  * alan_g blushes
[17:53] <mterry> alan_g, so the idea would be that USC could call hide(), watch for buffer swaps, and when it gets a non-null one, show() again?
[17:53] <mterry> or maybe it wouldn't need to call hide if it weren't getting buffer swaps in the first place
[17:54] <alan_g> mterry: yes, nested clients ought to behave like regular ones
[17:54] <mterry> alan_g, sounds perfect
[17:55]  * alan_g decides to cut & paste the above discussion into the bug
=== alan_g is now known as alan_g|EOW
[18:06] <greyback> why are surfaces visible if client hasn't drawn to them yet? To me makes more sense for mir to tell a shell that a Surface was created, only when that surface was drawn to by the client
[18:07] <greyback> not when the surface buffer was allocated for that client
[18:07] <greyback> anyway, gotta run, good weekend all!
=== dandrader is now known as dandrader|lunch
=== dandrader|lunch is now known as dandrader
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader