[08:33] <alan_g> alf_: any opinion? https://code.launchpad.net/~alan-griffiths/mir/more-surface-resize/+merge/256912/comments/641407
[11:46] <alan_g> anpok_: any opinion? https://code.launchpad.net/~alan-griffiths/mir/more-surface-resize/+merge/256912/comments/641407
[11:52] <anpok_> yes
[11:52] <anpok_> posting
[13:06] <alan_g> kdub AlbertA: any opinion? https://code.launchpad.net/~alan-griffiths/mir/more-surface-resize/+merge/256912/comments/641407
[13:07]  * kdub looks
[13:59] <alan_g> camako: I just came across some TODO comments in src/server/frontend/buffer_stream_tracker.h - are they a legacy of your (now abandoned) effort to change the buffer ownership logic?
[14:14] <kdub> alan_g, I think that comment was mine at some point
[14:15] <kdub> alan_g, and I think it was about how if the frontend code held a shared_ptr somewhere in there, we could re-bury the acquire/release (wrapped by swap_buffers() nowadays)
[14:16] <kdub> but its kinda dusty, as we've gotten rid of TemporaryClientBuffer
[14:16] <alan_g> kdub: I was wondering if the comments should go
[14:17] <anpok_> kdub: do you want to have another look on the resubmitted MP here: https://code.launchpad.net/~andreas-pokorny/mir/dispatchable-event-hub/+merge/256445
[14:17] <kdub> alan_g, yeah, it probably can
[14:17] <kdub> anpok_, okay
[14:19] <kdub> anpok_, with that, what was the lockup that was happening in the test?
[14:20] <alan_g> kdub: for avoidance of doubt you're referring to both the first two TODOs in that file. (The third one looks wrong too, but is different)
[14:21] <kdub> alan_g, ah, yeah, i was referring to the third one
[14:21] <kdub> what? a mir file with more than one todo in it? :)
[14:21] <kdub> well, the part about the shared ptr is part about it
[14:22] <kdub> doh, mispoke, reorienting...
[14:23] <kdub> alan_g, so the 1st and 2nd todo are about how originally, i thought a unique_ptr should get deposited there, and released when the client message came back, so its pretty old, as the BufferQueue hasn't quite evolved that way
[14:25] <anpok_> lockup? the problem the first time since landed was that no initial scan happened and then that after the scan there would be blocking call to epoll_wait, instead of just testing for pending events
[14:25]  * alan_g thinks he should leave it to kdub to revise these comments.
[14:25] <anpok_> *the first time this MP landed..
[14:26] <kdub> alan_g, mk, easy to do today
[14:26] <alan_g> ;)
[14:26] <anpok_> hum I guess the new input dispatcher will need another round.. so I guess I have to fit the old one meanwhile
[14:26]  * kdub is prodding around the {mf,mc}::BufferStream interface today anyways
[14:27] <kdub> anpok_, re lockup https://bugs.launchpad.net/mir/+bug/1444061 said a freeze, but that sounds like what you described up there
[14:28] <anpok_> yes redid it by splitting the changes up into hm two iirc
[14:35] <kdub> anpok_, right, but how does splitting it up into two fix it?
[14:35] <anpok_> well .. i changed it along the lines of splitting it up :)
[14:36] <anpok_> the one that already landed siwtches the timeout handling to a timer fd (which is a new addition) and this change now ensure that there is an initial call to do the device scan
[14:36] <kdub> anpok_, ah, well, lgtm I suppose, maybe a comment in the bug about what the root cause was would be helpful though
[14:37] <kdub> anpok_, ah, yes, thats what I was asking about
[14:38] <kdub> anpok_,  +1 then from me
[16:35] <alan_g> kdub: still need info? https://code.launchpad.net/~alan-griffiths/mir/more-surface-resize/+merge/256912
[16:37] <kdub> alan_g, switched to abstain, probably enough for top-approval now
[16:37] <kdub> but if not, i'll re-review later today
[16:39] <alan_g> kdub: I'm happy to leave it for later
[16:39] <kdub> alright, just in the thick of reorganizing some tests, will check later