[00:24] <kdub_> RAOF, ping
[00:34] <RAOF> kdub_: Pong!
[00:36] <kdub_> RAOF, so I guess I still feel pretty neutrally about that exchange_buffer message signature
[00:36] <kdub_> other than the fact there are a few other branches I have waiting in the wings based around the no-surface-id variant
[00:37] <RAOF> Eh, ok.
[00:38] <RAOF> It just seemed like you were doing a fair bit of work to match the Buffer to the Surface when the client already has that mapping (and the only interface for submitting the buffer goes through the surface anyway)
[00:39] <RAOF> So, I guess I'm saying that I think the (SurfaceId, buffer) signature is lower total complexity, and should therefore be favoured :)
[00:39] <kdub_> yeah, I guess what tipped my hand in thinking about it is that the other signature seem like a cleaner addition to the protocol
[00:41] <RAOF> Eh. The protocol's there to make the code's life easier :)
[00:41] <kdub_> hah, yeah :) well, I'm convinced enough to trim that MP down to just being a BufferId->Buffer* lookup
[00:42] <kdub_> instead of BufferId->Buffer* lookup and a BufferId->SurfaceId lookup as well
[00:42] <kdub_> and change the using the surfaceid/bufferid request
[00:42] <RAOF> Sounds planworthy.
[00:43] <kdub_> still somewhat on the fence on the whole as to which one is better, but may as well have less mappings
[00:43] <kdub_> cool, thanks
[01:08] <Wellark> when can I have screencapture recording of AP tests running on mako?
[01:08] <Wellark> is there support for screen recording in Mir?
[01:09] <Wellark> if there is then I will go bugging the QA team
[01:09] <Wellark> + I might finish my unity8 input visualizer which will show graphically what input is applied by the AP tests and put the QML Particle system in good use
[01:10] <RAOF> There's screen recording right now.
[01:10] <Wellark> RAOF: sweet
[01:10] <Wellark> so now it's only a tooling issue
[01:11] <RAOF> https://code.launchpad.net/~mir-team/mir/touchspot-renderable/+merge/230555 for input visualisation (on the Mir side)
[01:11] <Wellark> RAOF: ok. will that also show wipes ?
[01:11] <Wellark> it's super easy to implement in Unity9
[01:11] <Wellark> *8
[01:12] <RAOF> It'll show where Mir thinks the touchpoints are.
[01:12] <Wellark> just throwing a couple of Mouse, Touch and KeyboardAreas
[01:12] <Wellark> to the root of unity8 shell
[01:12] <Wellark> I was bored last weekend so I prototyped it
[01:12] <Wellark> would make a nice addition to the developer mode
[01:13] <Wellark> RAOF: sure, but no "higher level" information like "swipe start, swipe end"
[01:13] <RAOF> Indeed.
[01:13] <Wellark> or which keys are pressed
[01:14] <Wellark> implementing a full featured input visualizer is better to be implemented inside unity8 shell with QML
[01:14] <Wellark> as it would be like couple of hundreds of lines on QML code
[01:15] <Wellark> including the shiny particles :)
[01:15] <RAOF> You get different information out of the Mir visualiser; they're probably both useful.
[01:15] <Wellark> sure.
[01:15] <Wellark> Mir visualizer is probably very usefull for device bringups and touch calibration
[01:15] <Wellark> like the low level stuff
[01:16] <Wellark> but I want something shiny for the (end user) app developers :)
[01:16] <Wellark> RAOF: thanks for the info
[01:16] <Wellark> I go now to harrash the QA team
[06:58] <RAOF> Ah. So StubConnectionConfiguration is actually a lie.
[06:58] <RAOF> Oops.
[07:03] <anpok_> RAOF: regarding cmake and rpath - so the issue was that there was a libmirclient.so.8 linking against mircommon.1 and another one linking against mircommon.2...
[07:03] <anpok_> hm where is that build dependency coming that makes ci install mir
[07:04] <anpok_> through egl -> mesa -> mir?
[07:04] <RAOF> At least that, yes.
[07:12] <RAOF> anpok_: Note that this is only the case for the uninstalled tests - once we install them the rpath gets stripped.
[07:12] <anpok_> yes
[07:13] <anpok_> i was just curious if we are fixing the right problem
[07:14] <anpok_> i.e. shouldnt we bump mirclient if mircommon changes .. but I guesswe shouldnt since users will only rely on mirclients ABI...
[07:14] <anpok_> or then instead fix the dependency cycle..
[07:15] <RAOF> It's not really a dependency cycle.
[07:16] <anpok_> only a build dependency
[07:16] <anpok_> yes.. b
[07:16] <anpok_> -b
[07:16] <RAOF> Right.
[07:16] <RAOF> And it's only a problem when uninstalled because of the rpath issue..
[07:21] <anpok_> RAOF: did you find the time to have a look at the updated mir platform patch?
[07:21] <RAOF> I haven't yet sorry.
[07:21] <anpok_> that and a one liner in i915 fixes the issues we have on netbooks and those intels that come withan integrated 945 gpu.
[07:24] <anpok_> ok
[07:26] <RAOF> Sweet..
[07:26] <RAOF> Want to send me the updated thing and I'll look at it after making dinner.
[07:26] <RAOF> BAH!
[07:26] <RAOF> StubConnectionConfiguration is a dirty, dirty lie, and making it not a lie is nontrivial.
[07:26] <anpok_> RAOF: I know have another one for 10.2..
[07:27] <anpok_> -k
[07:27] <anpok_> and I think I can actually remove the changes to brw_context.c
[07:27] <RAOF> If we use the image loader, yes.
[07:28] <anpok_> but I havent tested yet... but yes due to the partially copy-paste-designed drivers it would then work like 915
[13:41] <alan_g> alf__: I've just noticed that libmirclientlttng.so and libmirserverlttng.so are packaged in mir-test-tools. Does that mean the lttng reports are not available without installing the tests?
[13:47] <alf__> alan_g: yes
[13:49] <alan_g> I hadn't been aware of that. I hope there's a sensible error message.
[19:56] <ahayzen> AlbertA, ping
[19:58] <AlbertA> ahayzen: pong
[19:58] <ahayzen> Hi, I have been advised to talk to about bug 1337239, jhodapp and rsalveti have both looked at the bug but believe it is mir/compositor's responsibility. Would you mind having a look at the bug and adding and comments that you have?
[20:02] <AlbertA> ahayzen: yep, I just dup it to https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1359264
[20:02] <AlbertA> ahayzen: the next mir release should have a fix for it
[20:03] <ahayzen> AlbertA, hah awesome :) is that in a silo that i can test now?
[20:03] <AlbertA> ahayzen: camako is getting one ready
[20:04] <ahayzen> AlbertA, ok thanks rsalveti ^^