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