/srv/irclogs.ubuntu.com/2014/07/15/#ubuntu-mir.txt

=== beidl_ is now known as beidl
=== chihchun_afk is now known as chihchun
dufluRAOF: 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 properly03:42
RAOFI believe so?03:42
dufluRAOF: I don't see any Mir*Event03:43
dufluOh hang on03:44
dufluNo, can't see it03:45
dufluRAOF: Were we planning on utilizing any GL error codes?03:51
RAOFNo03:51
dufluOr does that require Khronos changes/blessing?03:51
RAOFWe could absolutely do it, but I think we ended up deciding that it's not an EGL thing.03:51
dufluOK. What I do remember is that argument being complex enough I don't want to remember it right now03:52
=== chihchun is now known as chihchun_afk
RAOFMan, this is going to provoke conflicts with _everything_04:57
RAOFOh, _arse_05:16
RAOFWe can't hide anything.05:16
RAOFBecause we expect (server) clients to subclass DefaultConfiguration, which means they need to be able to resolve everything that DefaultConfiguration includes.05:19
RAOFHm.05:39
RAOFDoesn'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[_]
dufluRAOF: Hey it looks like Android-input drops/deduplicates events when we're not keeping up07:12
dufluThat's good... we don't have to do anything07:12
RAOFHuzzah!07:12
RAOFSweet. 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
RAOFalf_: Correct.07:42
RAOFIt's all very complicated.07:42
RAOFIf 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
RAOFIf 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
RAOFFor 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
RAOFThat 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
RAOFMSG_CTRUNC, yeah.07:48
RAOFWell, 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
RAOFI 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 discarded07:52
RAOFWe need to move on to reading a subsequent message.07:52
RAOFI 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 boundaries07:54
RAOFalf_: There are message boundaries in the kernel.07:55
alf_RAOF: true07:55
RAOFInternally 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_gRAOF: I don't need to keep you late, but if you have time to help with packaging...08:01
RAOFalan_g: Just commenting now :)08:01
RAOFalan_g: Oh, and other than the CI failure bit, the packaging seems fine.08:09
alan_gRAOF: thanks for looking.08:09
RAOFalan_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_gRAOF: 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
RAOFalf_: I build a couple of things twice.08:15
RAOFalan_g: What client code would need those symbols?08:16
alan_gRAOF: Hmm. I was assuming that as the headers were published they were already needed in our public API08:18
RAOFRight, but not from libmirclient.so08:18
alan_gAnd we do use them in examples of "how to use Mir"08:19
RAOFBut, again, not from libmirclient.so08:20
RAOFThese symbols aren't being hidden from libmirserver.so, but we were *also* exporting them from libmirclient.so.08:20
alan_gHmm. 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 lib08:23
alan_gCould we also remove mircommon-dev from libmirclient-dev?08:24
RAOFPossibly?08:24
RAOFEOD for me today though, sorry.08:24
RAOFI'll push the branch08:25
RAOFYou're looking for lp:~raof/mir/symbols-file. It's still a little WIP.08:25
alan_gRAOF: ak08: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 experiment08: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_gmterry: After emailing you I removed the "Conficts:" to see if CI would then work.13:19
mterryalan_g, ah ok13:19
alan_gAFACS the build script is using dpkg directly. BUt I don't know much about it13: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_gmterry: I need advice. Removing "Conficts:" seems to satisfy CI (but is probably lying), and some documentation suggests "Break:" as a possible alternative.14:00
mterryalan_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 you14:04
mterryI'm honestly not super clear on the difference14:04
alan_gmterry: how bad is it to have neither?14:05
mterryalan_g, if they share files, it is bad but I don't quite know in which circumstances it will break14:06
mterryalan_g, one of those things I've never gone against recommendations for :)14:07
alan_gI'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
anpokalf_: yes14:19
anpokit was best to notice inside the pin entry dialog14:19
anpokI had a devel-proposed image + qt comp silo, removed the silo then upgraded14:20
anpoki mean I upgraded the image..14:20
anpokand it was easy to reproduce in the pin entry14:21
anpokafter another round of flashing devel-proposed the issue is gone14:21
=== dandrader|afk is now known as dandrader
camakomterry, once upon a time you asked for nested lifecycle event support :14:43
camakohttps://code.launchpad.net/~cemil-azizoglu/mir/nested_lifecycle_events/+merge/22442614:43
kgunnin a galaxy far far away14:54
tedgdednick, So I thought when we were talking with mdeslaur that we wanted the second socket AND a list of people to connect.15:36
tedgThe second socket takes care of the connection restriction aspect.15:36
tedgBut we still want to know who is connecting and if they're someone we expect.15:36
tedgThat 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
mdeslaurthere's not way of validating the list15:37
mdeslaurwe assume whatever is connecting there is trusted15:37
dednicktedg: ^ yeah. no point if you can get around it...15:38
mdeslaurtyhicks could confirm15:38
tedgK15:41
tedgIt seems a bit odd to me.15:41
tedgI guess in the future we'll restrict that socket to only being able to make trusted prompt sessions.15:42
racarr__Morning16: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!