=== beidl_ is now known as beidl === chihchun_afk is now known as chihchun [03:41] RAOF: When I sleep the phone clients correctly scale down to 10Hz. Do we have sleep/resume messages yet? [03:42] ... because obviously clients should be told to sleep properly [03:42] I believe so? [03:43] RAOF: I don't see any Mir*Event [03:44] Oh hang on [03:45] No, can't see it [03:51] RAOF: Were we planning on utilizing any GL error codes? [03:51] No [03:51] Or does that require Khronos changes/blessing? [03:51] We could absolutely do it, but I think we ended up deciding that it's not an EGL thing. [03:52] OK. What I do remember is that argument being complex enough I don't want to remember it right now === chihchun is now known as chihchun_afk [04:57] Man, this is going to provoke conflicts with _everything_ [05:16] Oh, _arse_ [05:16] We can't hide anything. [05:19] Because we expect (server) clients to subclass DefaultConfiguration, which means they need to be able to resolve everything that DefaultConfiguration includes. [05:39] Hm. [05:39] Doesn't that make much of the headers in src/ implicitly ABI? [05:40] (The _best form_ of ABI) === Aki-Thinkpad is now known as snakes === snakes is now known as _snakes === _snakes is now known as D8 === D8 is now known as _8D === _8D is now known as _8D[_] [07:12] RAOF: Hey it looks like Android-input drops/deduplicates events when we're not keeping up [07:12] That's good... we don't have to do anything [07:12] Huzzah! [07:15] Sweet. So, I very nearly have a libmirclient with an ABI equal to the ABI we expect to expose.. [07:42] RAOF: @break-out-rpc-transport, so ancillary socket data are queued separately from normal socket data? [07:42] alf_: Correct. [07:42] It's all very complicated. [07:43] If you sendmsg(300 bytes, 1 fd), send(300 bytes) and recvmsg(600 bytes, , MSG_WAITALL) your recvmsg will read 300 bytes and 1 fd. [07:43] If you sendmsg(300 bytes, 1 fd), send(300 bytes) and then recv(301 bytes), you'll (a) receive 301 bytes, and (b) never be able to get at that fd. [07:44] For added annoyance, if you recvmsg(300 bytes, , MSG_WAITALL) *and get interrupted* you'll receive some data < 300 bytes and an fd, and your next recvmsg will receive the fd again. [07:45] That seems likely to be a bug, though. [07:48] RAOF: What about MSG_TRUNC ? Is this when we sendmsg(300,2) and recvmsg(300,1) ? [07:48] MSG_CTRUNC, yeah. [07:49] Well, as long as you haven't run into CMSG_SPACE aliasing :) [07:51] RAOF: (trying to understand how queuing ancillary data works), if we sendmsg(300,1) and recv(299) is the fd lost? [07:52] I don't think so, no. [07:52] RAOF: or do we need to move on reading to a subsequent message for the fds to be discarded [07:52] We need to move on to reading a subsequent message. [07:53] I don't think there's a test for that behaviour in the unit tests, though. [07:54] RAOF: I wonder how the fd-data association is maintained since we are using a stream socket, so no strict message boundaries [07:55] alf_: There are message boundaries in the kernel. [07:55] RAOF: true [07:55] Internally it's got a bunch of skbs, and SOCK_STREAM just reads on to the next one when the current one's done. [08:01] RAOF: I don't need to keep you late, but if you have time to help with packaging... [08:01] alan_g: Just commenting now :) [08:09] alan_g: Oh, and other than the CI failure bit, the packaging seems fine. [08:09] RAOF: thanks for looking. [08:14] alan_g: By the way, I've stripped all those symbols out of libmirclient locally by way of symbol visibility; we could probably do the same for libmirplatform.. [08:15] RAOF: but what about client code that needs the symbols? [08:15] RAOF: how does that work with testing (where we may need access to some of the internal symbols)? [08:15] alf_: I build a couple of things twice. [08:16] alan_g: What client code would need those symbols? [08:18] RAOF: Hmm. I was assuming that as the headers were published they were already needed in our public API [08:18] Right, but not from libmirclient.so [08:19] And we do use them in examples of "how to use Mir" [08:20] But, again, not from libmirclient.so [08:20] These symbols aren't being hidden from libmirserver.so, but we were *also* exporting them from libmirclient.so. [08:23] Hmm. So we could put them all into libmirplatform (and export then) and also put the ones used into libmirclient that it uses (internally). That could avoid the new lib [08:24] Could we also remove mircommon-dev from libmirclient-dev? [08:24] Possibly? [08:24] EOD for me today though, sorry. [08:25] I'll push the branch [08:25] You're looking for lp:~raof/mir/symbols-file. It's still a little WIP. [08:29] RAOF: ak [08:31] RAOF: scenario sendmsg(300, 1) sendmsg(300,1) recvmsg(300, 0) recvmsg(0, $Y) Y == ? [08:33] RAOF: i.e. if we ask for Y=1 fd will we get MSG_CTRUNC, or do we need to read at least one more byte to get into the next msg in order to get access to the second message's fd? [08:33] RAOF: I guess we need to experiment === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === pete-woods is now known as pete-woods|lunch === alan_g is now known as alan_g|lunch === dandrader_ is now known as dandrader === alan_g|lunch is now known as alan_g [13:19] mterry: After emailing you I removed the "Conficts:" to see if CI would then work. [13:19] alan_g, ah ok [13:21] AFACS the build script is using dpkg directly. BUt I don't know much about it === pete-woods|lunch is now known as pete-woods [13:44] anpok: You mentioned something about showing the previous frame instead of current? [14:00] mterry: I need advice. Removing "Conficts:" seems to satisfy CI (but is probably lying), and some documentation suggests "Break:" as a possible alternative. [14:04] alan_g, yeah... Breaks is I think generally recommended over Conflicts except in some cases I can't remember. But the documentation I was looking at used Conflicts so I recommended that on to you [14:04] I'm honestly not super clear on the difference [14:05] mterry: how bad is it to have neither? [14:06] alan_g, if they share files, it is bad but I don't quite know in which circumstances it will break [14:07] alan_g, one of those things I've never gone against recommendations for :) [14:08] I'll try "Breaks" and see if CI breaks. If it works I know what to do. If it fails... I'll consult another expert (RAOF) === dandrader is now known as dandrader|afk [14:19] alf_: yes [14:19] it was best to notice inside the pin entry dialog [14:20] I had a devel-proposed image + qt comp silo, removed the silo then upgraded [14:20] i mean I upgraded the image.. [14:21] and it was easy to reproduce in the pin entry [14:21] after another round of flashing devel-proposed the issue is gone === dandrader|afk is now known as dandrader [14:43] mterry, once upon a time you asked for nested lifecycle event support : [14:43] https://code.launchpad.net/~cemil-azizoglu/mir/nested_lifecycle_events/+merge/224426 [14:54] in a galaxy far far away [15:36] dednick, So I thought when we were talking with mdeslaur that we wanted the second socket AND a list of people to connect. [15:36] The second socket takes care of the connection restriction aspect. [15:36] But we still want to know who is connecting and if they're someone we expect. [15:37] That being said, that was my understanding, if mdeslaur is willing to sign off on not having the list, I'm happy not having to make it. :-) [15:37] there's not way of validating the list [15:37] we assume whatever is connecting there is trusted [15:38] tedg: ^ yeah. no point if you can get around it... [15:38] tyhicks could confirm [15:41] K [15:41] It seems a bit odd to me. [15:42] I guess in the future we'll restrict that socket to only being able to make trusted prompt sessions. [16:06] Morning === alan_g is now known as alan_g|EOD === chihchun is now known as chihchun_afk === rpadovani_ is now known as rpadovani