| tmpRAOF | Hm. So, the libmirprotobuf rabbit-hole. | 01:56 |
|---|---|---|
| === tmpRAOF is now known as RAOF | ||
| RAOF | I have a number of possible hacks, each more awkward than the last. | 02:02 |
| * duflu wonders if a swear jar is required for lib*protobuf | 02:26 | |
| 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”. | 02:30 |
| === chihchun_afk is now known as chihchun | ||
| RAOF | if (id & 1<<31) | 05:42 |
| RAOF | Aww, yeah. | 05:42 |
| RAOF | Huh. | 06:21 |
| RAOF | Why do we have both SurfaceCreationParameters and SurfaceModifications, I wonder. | 06:22 |
| RAOF | s/SurfaceModification/SurfaceSpecification/ | 06:22 |
| === ara is now known as Guest36049 | ||
| greyback | "SurfaceParameters" to be consistent? | 06:30 |
| 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. | 06:31 |
| * RAOF decides not to write a test that Mir correctly returns an error when a client tries to create 2^31 surfaces. | 07:45 | |
| alf_ | RAOF: Hi! Did you have a chance to take a look at the glmark2 package? | 07:48 |
| 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:49 |
| RAOF | alf_: Any reason for it to be arch restricted anymore? Mir builds everywhere now. | 07:52 |
| alf_ | RAOF: Even the archive version? | 07:53 |
| 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:54 |
| RAOF | Yup. | 07:55 |
| alf_ | RAOF: ok, I will update the package then | 07:55 |
| 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! | 07:56 |
| RAOF | alf_: glmark2 uploaded. Enjoy. | 08:08 |
| alf_ | RAOF: thanks | 08:45 |
| 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:56 |
| greyback | alan_g: I can think of no reason why it would want a non-fullscreen surface | 08:57 |
| alan_g | Thanks. | 08:57 |
| duflu | alan_g: Fullscreen also means we get bypass/overlays, which is a very good thing | 09:07 |
| alan_g | duflu: yes, my thinking was that for a system compositor we disallow anything else | 09:08 |
| 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:09 |
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| alan_g | Hmm. Would an OSK be a client of the system compositor? | 09:12 |
| 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:15 |
| alan_g | duflu: I was referring to surfaces a client can create, not what the host can do internally | 09:16 |
| dednick | tvoss: https://docs.google.com/spreadsheets/d/1g1u3RjukeEdTAk0WPHsVuf42apVm3iepMdC82oJ1TcA/edit#gid=1176402920 | 10:27 |
| dednick | ah, actually, the server is a mix of two. let me separate | 10:30 |
| tvoss | dednick, mind increasing the sample size such that distribution characteristics become a bit more apparent? | 10:32 |
| dednick | tvoss: ok | 10:33 |
| tvoss | greyback_, ^ | 10:34 |
| greyback_ | +1 | 10:34 |
| tvoss | dednick, any chance you automate creation of those histograms? R is pretty helpful in doing that stuff | 10:39 |
| 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:40 |
| 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:43 |
| greyback_ | we were discussing this at our sprint in dallas, so it's a work item somewhere on the mir team's plate | 10:44 |
| 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:47 |
| 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:56 |
| dednick | tvoss, greyback_ : updated with increased sample size | 10:59 |
| tvoss | dednick, does that have the difference, yet? | 11:00 |
| dednick | tvoss: difference? | 11:00 |
| 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:01 |
| 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:03 |
| 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:04 |
| anpok_ | kernel version? | 11:06 |
| anpok_ | @vt switching problem? | 11:06 |
| anpok_ | oh ok scrolling back .. i only experienced system freezes and kernel panics. | 11:07 |
| dednick | tvoss, greyback_ , anpok_ : diff is on now. | 11:11 |
| tvoss | dednick, greyback_ so seems like the majority lies around 15ms | 11:11 |
| 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:12 |
| 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:13 |
| 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:18 |
| greyback_ | yep | 11:19 |
| dednick | excellent... | 11:19 |
| dednick | tvoss, greyback_ , anpok_ : diff is on a new sheet | 11:28 |
| tvoss | dednick, awesome | 11:28 |
| greyback_ | interesting long tail | 11:29 |
| greyback_ | dednick: I'd be curious if turning off Qt's input event resampling has any impact on that graph | 11:30 |
| 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:31 |
| 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:32 |
| 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:35 |
| dednick | although that's just measuring latency | 11:40 |
| 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:45 |
| dednick | between 500ms and 1300ms. | 11:46 |
| anpok_ | O_O | 11:46 |
| 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). | 11:47 |
| === alan_g is now known as alan_g|lunch | ||
| tvoss | anpok_, could you provide your packages for the non-resampling version to dednick? | 12:15 |
| 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:21 |
| dednick | are the stamps at start of a mir log timestamps? | 12:22 |
| dednick | [1434111685.022267] input: Received event finished .... | 12:23 |
| anpok_ | yes | 12:28 |
| anpok_ | seconds.microseconds | 12:29 |
| dednick | graphed the android input channel as well. | 12:36 |
| tvoss | anpok_, you sure that those are milliseconds? | 12:39 |
| tvoss | dednick, is that server or client? | 12:40 |
| anpok_ | micro | 12:41 |
| anpok_ | code does "tv_sec and tv_usec/1000 | 12:41 |
| 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:42 |
| 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:44 |
| tvoss | anpok_, sure, asking for the unit :) | 12:45 |
| 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:49 |
| ChrisTownsend | ahayzen: Ok, I'll look over your log. Just ping me later when you have some time. | 12:50 |
| ahayzen | thanks | 12:50 |
| 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:53 |
| === alan_g|lunch is now known as alan_g | ||
| anpok_ | average time diff between events is 13ms in my sample set .. but like 93% are in the range of 8ms to 10ms | 12:58 |
| dednick | tvoss: the andoid channel? it's u8 process. MIR_SERVER_INPUT_REPORT | 14:04 |
| tvoss | dednick, ack | 14:07 |
| 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) | 14:22 |
| === infinity1 is now known as infinity | ||
| === chihchun is now known as chihchun_afk | ||
| === alan_g is now known as alan_g|EOW | ||
| 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:16 |
| 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:18 |
| 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:19 |
| 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:20 |
| attente | anpok: ok, i see what happened thanks. i was in an older source directory | 17:25 |
| === tvoss is now known as tvoss|test | ||
| === tvoss|test is now known as tvoss | ||
| === Trevinho is now known as Trevinho|Holiday | ||
| 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:03 |
| 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:06 |
| ahayzen | right time to switch sessions and see if it does its normal thing... | 19:07 |
| ahayzen | ChrisTownsend, OMG it works \o/ | 19:10 |
| 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:11 |
| ChrisTownsend | ahayzen: That touchpad issue is probably something in Mir. | 19:12 |
| ahayzen | ChrisTownsend, thanks for your help getting me running anyway :-) | 19:26 |
| ChrisTownsend | ahayzen: Sure, you're welcome! | 19:27 |
| anpok | tvoss: i think i really had corrupted data sets.. | 19:39 |
| anpok | but only a few measurements are affected | 19:40 |
| anpok | two of the timestamps i care about are in the distant future | 19:40 |
| === chihchun_afk is now known as chihchun | ||
| === mibofra is now known as Guest93939 | ||
| === ahayzen_ is now known as ahayzen | ||
| === Guest93939 is now known as mibofra | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!