[01:56] <tmpRAOF> Hm. So, the libmirprotobuf rabbit-hole.
[02:02] <RAOF> I have a number of possible hacks, each more awkward than the last.
[02:26]  * duflu wonders if a swear jar is required for lib*protobuf
[02:30] <RAOF> I think I'm going to plump for “assert that we'll be able to fix this before we need more than 2^31 surface IDs and abuse the highest bit of output_id to indicate that there's a follow up message coming”.
[05:42] <RAOF> if (id & 1<<31)
[05:42] <RAOF> Aww, yeah.
[06:21] <RAOF> Huh.
[06:22] <RAOF> Why do we have both SurfaceCreationParameters and SurfaceModifications, I wonder.
[06:22] <RAOF> s/SurfaceModification/SurfaceSpecification/
[06:30] <greyback> "SurfaceParameters" to be consistent?
[06:31] <RAOF> Yeah.
[06:31] <RAOF> I'm not sure why we have two different structs for ‘here are the properties of this new surface’ and ‘here are the new properties of this surface’
[06:31] <RAOF> Hm.
[06:31] <RAOF> Now that I say that... apart from the only-these-properties changed thing.
[06:31] <RAOF> So, yeah, that's actually totally fine.
[07:45]  * RAOF decides not to write a test that Mir correctly returns an error when a client tries to create 2^31 surfaces.
[07:48] <alf_> RAOF: Hi! Did you have a chance to take a look at the glmark2 package?
[07:49] <RAOF> alf_: Oh, sorry. Not yet.
[07:49] <RAOF> I'll just get to that before EOD.
[07:49] <alf_> RAOF: no worries, thanks
[07:52] <RAOF> alf_: Any reason for it to be arch restricted anymore? Mir builds everywhere now.
[07:53] <alf_> RAOF: Even the archive version?
[07:54] <alf_> RAOF: (no reason on the glmark2 side)
[07:54] <RAOF> I'm pretty sure wily has an everywhere-built mir, but rmadison is being *super* slow to verify that for me :)
[07:55] <RAOF> Yup.
[07:55] <alf_> RAOF: ok, I will update the package then
[07:56] <RAOF> I can do it if you like.
[07:56] <RAOF> It otherwise looks fine, so I'll upload.
[07:56] <alf_> RAOF: Sure, go ahead then. Thanks!
[08:08] <RAOF> alf_: glmark2 uploaded. Enjoy.
[08:45] <alf_> RAOF: thanks
[08:56] <alan_g> greyback: I'm working on the "system compositor" logic and just wanted to check something you probably know. Mir's nested server logic creates a fullscreen surface in the host for each display it uses. I don't see that U8 would want anything else, but could it?
[08:57] <greyback> alan_g: I can think of no reason why it would want a non-fullscreen surface
[08:57] <alan_g> Thanks.
[09:07] <duflu> alan_g: Fullscreen also means we get bypass/overlays, which is a very good thing
[09:08] <alan_g> duflu: yes, my thinking was that for a system compositor we disallow anything else
[09:09] <duflu> alan_g: "Disallow" is probably too strong a word. Examples of non-fullscreen surfaces could be transitions between sessions, or on-screen keyboards for login
[09:12] <alan_g> Hmm. Would an OSK be a client of the system compositor?
[09:15] <duflu> alan_g: Perhaps. But one of the main reasons for nesting is transitions. And that can involve sliding (hence surfaces not fullscreen briefly)
[09:15] <duflu> Oh, actually they are fullscreen. Just animated to not look fullscreen
[09:16] <alan_g> duflu: I was referring to surfaces a client can create, not what the host can do internally
[10:27] <dednick> tvoss: https://docs.google.com/spreadsheets/d/1g1u3RjukeEdTAk0WPHsVuf42apVm3iepMdC82oJ1TcA/edit#gid=1176402920
[10:30] <dednick> ah, actually, the server is a mix of two. let me separate
[10:32] <tvoss> dednick, mind increasing the sample size such that distribution characteristics become a bit more apparent?
[10:33] <dednick> tvoss: ok
[10:34] <tvoss> greyback_, ^
[10:34] <greyback_> +1
[10:39] <tvoss> dednick, any chance you automate creation of those histograms? R is pretty helpful in doing that stuff
[10:40] <tvoss> dednick, also: validateAndDeliverTouch - dispatchTouch is interesting
[10:40] <tvoss> dednick, probably more interesting than the per event timings, although we could leave those in, too
[10:43] <dednick> tvoss: probably could do. if you think it's worth putting the effort in. never used R though, so may take some time.
[10:43] <tvoss> dednick, okay, let's do this in gdocs for now, but we should look into automatically generating reports like this
[10:43] <tvoss> dednick, not necessarily you, though :)
[10:43] <dednick> tvoss: :) ok
[10:44] <greyback_> we were discussing this at our sprint in dallas, so it's a work item somewhere on the mir team's plate
[10:47] <tvoss> greyback_, I think want similar reports for u8, too
[10:47] <tvoss> greyback_, it's probably as easy as emitting an lttng event
[10:47] <greyback_> tvoss: ofc, I wanted them to have a reporting interface u8 could link into
[10:56] <alan_g> alf_: I've been playing with system compositing/guest compositor on my desktop and have seen some intermittent problems with vt switching, closing the nested session and fatal errors in RealKMSOutput::clear_crtc(). Is there any chance that the "platform" in the nested session if fighting with the host over the hardware? Do you know where I should start looking?
[10:59] <dednick> tvoss, greyback_ : updated with increased sample size
[11:00] <tvoss> dednick, does that have the difference, yet?
[11:00] <dednick> tvoss: difference?
[11:01] <alf_> alan_g: The nested platform doesn't (shouldn't) have access to the display hardware at all, so it's unlikely that there is a conflict there. At some point Intel had some problems with VT switching, and perhaps it still does.
[11:01] <tvoss> dednick, the difference between validateAndDeliverTouch and dispatchTouch for server
[11:01] <dednick> tvoss: ah. no
[11:03] <alan_g> alf_: that's how I thought it should be. I'll see if I can nail down a repeatable scenario (ideally without a VT switch).
[11:04] <anpok_> dednick: Diff is the time the event spends within the event loop?
[11:04] <anpok_> or the qtquick scene dispatch..
[11:04] <dednick> i'm adding now
[11:06] <anpok_> kernel version?
[11:06] <anpok_> @vt switching problem?
[11:07] <anpok_> oh ok scrolling back .. i only experienced system freezes and kernel panics.
[11:11] <dednick> tvoss, greyback_ , anpok_ : diff is on now.
[11:11] <tvoss> dednick, greyback_ so seems like the majority lies around 15ms
[11:12] <anpok_> diff is difference between two events?
[11:12] <dednick> ya. problem is that it's not the majority we're worried about. most of scrolling is smooth, but it's the outliers that's causing the problems.
[11:12] <tvoss> dednick, I think you are not calculating the diff between timestamps, but the diff between event timestamp deltas
[11:13] <dednick> hm. actually not sure if diff is showing anything in this case. we need to do timestamps
[11:13] <dednick> ya
[11:13] <tvoss> dednick, yup
[11:13] <anpok_> oh so diff is between receive and send?
[11:18] <dednick> greyback_: what do we get first? the qtmir event feeder event? or the MirSurfaceItem event? it's the feeder right? just need to make sure things are actually in sync
[11:18] <greyback_> dednick: feeder
[11:18] <greyback_> that pushes the events onto qt's event loop, which trickle through the scene, until they hit a MirSurfaceItem, where they dispatched to client
[11:18] <dednick> right. that's from u8 surface as client in usc
[11:19] <greyback_> yep
[11:19] <dednick> excellent...
[11:28] <dednick> tvoss, greyback_ , anpok_ : diff is on a new sheet
[11:28] <tvoss> dednick, awesome
[11:29] <greyback_> interesting long tail
[11:30] <greyback_> dednick: I'd be curious if turning off Qt's input event resampling has any impact on that graph
[11:31] <dednick> greyback_: the compression?
[11:31] <greyback_> dednick: yea
[11:31] <greyback_> h
[11:31] <dednick> greyback_: this is without compression
[11:31] <greyback_> dednick: ah ok
[11:31] <dednick> might be interesting to see it with.
[11:32] <dednick> although i wonder if the events won't line up anymore
[11:32] <dednick> not 1 to 1?
[11:32] <greyback_> that is what we're using right now
[11:35] <greyback_> would be nice to know what the main loop is doing on those slow dispatch times
[11:35] <dednick> so the diff here is between the QtEventFeeder and the MirSurfaceItem, both on server. need to check between QtEventFeeder and client as well probably.
[11:40] <dednick> although that's just measuring latency
[11:45] <dednick> majority is around 25ms latency between server->client. But plenty outliers. Particularily worring are a few in the order of 100's of ms.
[11:46] <dednick> between 500ms and 1300ms.
[11:46] <anpok_> O_O
[11:47] <dednick> assuming all my data is correct. but should be able to see if it wasn't (should slowly go totally out of sync if it wasn't aligned).
[12:15] <tvoss> anpok_, could you provide your packages for the non-resampling version to dednick?
[12:21] <anpok_> tvoss: i used the MIR_CLIENT_INPUT_RATE=0 setting
[12:21] <anpok_> which passes -1 to the consumer..
[12:21] <tvoss> anpok_, okay
[12:22] <dednick> are the stamps at start of a mir log timestamps?
[12:23] <dednick> [1434111685.022267] input: Received event finished ....
[12:28] <anpok_> yes
[12:29] <anpok_> seconds.microseconds
[12:36] <dednick> graphed the android input channel as well.
[12:39] <tvoss> anpok_, you sure that those are milliseconds?
[12:40] <tvoss> dednick, is that server or client?
[12:41] <anpok_> micro
[12:41] <anpok_> code does "tv_sec and tv_usec/1000
[12:42] <anpok_> what are you looking at?
[12:42] <tvoss> andyrock, https://docs.google.com/spreadsheets/d/1g1u3RjukeEdTAk0WPHsVuf42apVm3iepMdC82oJ1TcA/edit#gid=2092414509
[12:42] <tvoss> anpok_, https://docs.google.com/spreadsheets/d/1g1u3RjukeEdTAk0WPHsVuf42apVm3iepMdC82oJ1TcA/edit#gid=2092414509
[12:44] <anpok_> thats the time difference between two event..
[12:44] <ChrisTownsend> ahayzen: Hey, are you around?  Following up on your unity8-lxc issue from yesterday.
[12:45] <tvoss> anpok_, sure, asking for the unit :)
[12:49] <ahayzen> ChrisTownsend, i'm at work at the moment so will be about later, but i managed to get a full unity8 log http://pastebin.ubuntu.com/11698632/ which shows some errors, and it was unity8 and ms2 using ~90% cpu each
[12:50] <ChrisTownsend> ahayzen: Ok, I'll look over your log.   Just ping me later when you have some time.
[12:50] <ahayzen> thanks
[12:53] <ChrisTownsend> ahayzen: Sure.  Just looking at that error, it seems the Mir version in the container is out of date.  When you begin to look at this, let' start from a fresh baseline.  Do 'sudo unity8-lxc-setup --rebuild-all --redownload' and then try it again.  If it still fails, then we'll dig deeper.
[12:53] <ahayzen> ChrisTownsend, cool thanks
[12:58] <anpok_> average time diff between events is 13ms in my sample set .. but like 93% are in  the range of 8ms to 10ms
[14:04] <dednick> tvoss: the andoid channel? it's u8 process. MIR_SERVER_INPUT_REPORT
[14:07] <tvoss> dednick, ack
[14:22] <alan_g> alf_: the Ctrl+Alt+Fn event to request VT switch ought to be handled in the host server right? I've discovered a way to hang input in a *nested* server and that prevents the request being serviced. (I can 'chvt n' perfectly well from ssh)
[17:16] <attente> hi, is the mir demo server working for anyone? i'm getting an error: <ERROR> mircommon: Failed to load libraries from path: /home/william/Code/jhbuild/install/lib/mir/server-platform (error was:No such file or directory)
[17:18] <anpok> attente: you might not have the mir-graphics-drivers-desktop installed?
[17:18] <anpok> oh
[17:18] <anpok> thats from a build dir..
[17:18] <attente> anpok: i just built it from trunk
[17:18] <attente> for some reason it didn't install into that directory but i'm not sure why
[17:18] <anpok> ok .. you can either change CMakeCache.txt by switching the platforms built to :
[17:19] <anpok> MIR_PLATFORM:=STRING=mesa-kms;android
[17:19] <anpok> (it was renamed)
[17:19] <anpok> or redo the build directory
[17:19] <attente> anpok: oh ok, thanks. should i file a bug for that?
[17:19] <anpok> hm
[17:20] <attente> oh. it's already like that in CMakeLists.txt though
[17:20] <anpok> it is not really a bug.. in theory MIR_PLATFORM is a developer setting..
[17:20] <anpok> so since that value already exists
[17:20] <anpok> when the change came
[17:20] <anpok> cmake did not overwrite it..
[17:25] <attente> anpok: ok, i see what happened thanks. i was in an older source directory
[19:03] <ahayzen> ChrisTownsend, if your about, i totally forgot I got this when i installed http://pastebin.ubuntu.com/11703788/ not sure if it affects the welcome wizard not working?
[19:06] <ChrisTownsend> ahayzen: That looks normal.  I have to install upstart and remove systemd in order for it to work.  LXC and systemd do not mix in this instance, at least the last time I tried.
[19:06] <ahayzen> ChrisTownsend, ok just wanted to check :-)
[19:06] <ChrisTownsend> ahayzen: Yeah, kind of looks scary if you don't now what's going on.
[19:07] <ahayzen> right time to switch sessions and see if it does its normal thing...
[19:10] <ahayzen> ChrisTownsend, OMG it works \o/
[19:11] <ChrisTownsend> ahayzen: Awesome!
[19:11] <ahayzen> now onto the next issue... why when i hold my finger in a static position on the touchpad does my mouse move? lol
[19:11] <ChrisTownsend> ahayzen: popey is also all taken care of, so my work is done:)
[19:11] <ahayzen> \o/
[19:12] <ChrisTownsend> ahayzen: That touchpad issue is probably something in Mir.
[19:26] <ahayzen> ChrisTownsend, thanks for your help getting me running anyway :-)
[19:27] <ChrisTownsend> ahayzen: Sure, you're welcome!
[19:39] <anpok> tvoss: i think i really had corrupted data sets..
[19:40] <anpok> but only a few measurements are affected
[19:40] <anpok> two of the timestamps i care about are in the distant future