| kgunn | robert_ancell: yep...i'm getting the same change in perf you see with glmark2 | 00:00 |
|---|---|---|
| bschaefer | oo i see, yup :), i've still a lot to learn the graphics stack.... | 00:01 |
| robert_ancell | kgunn, cool, hopefully duflu can also reproduce | 00:01 |
| RAOF | !!! | 00:04 |
| RAOF | Ok, it's really mirclient leaking. | 00:05 |
| RAOF | racarr: Can you see anything obviously wrong with http://paste.ubuntu.com/6008432/ ? | 00:07 |
| RAOF | Or, alternatively, bschaefer - can *you* see anything obviously wrong with http://paste.ubuntu.com/6008432/ ? | 00:07 |
| * bschaefer looks | 00:08 | |
| bschaefer | RAOF, well I don't see the surfaces getting cleaned up, but it could happen after the while loop | 00:09 |
| bschaefer | + line 53-54 has a small tabbing issue | 00:09 |
| RAOF | There's nothing obviously crazy about the EGL usage, though? | 00:10 |
| RAOF | Because with that patch, mir_demo_client_accelerated quickly runs out of fds. | 00:10 |
| bschaefer | lots of make current calls | 00:10 |
| RAOF | If I was aiming for efficiency I'd have spun off a pair of render threads ;) | 00:11 |
| racarr | RAOF: gl_animation.init_gl(); | 00:11 |
| racarr | doesn't make sense anymore | 00:11 |
| racarr | or does it | 00:11 |
| RAOF | I think it does; AFAIK it only affects the current context. | 00:12 |
| RAOF | And both surfaces are on rendered to from that context | 00:12 |
| bschaefer | RAOF, that would speed thing up ... but cant you just swap surfaces? | 00:12 |
| * bschaefer isn't to familiar with egl apps | 00:13 | |
| racarr | RAOF: Yeah | 00:13 |
| racarr | ok nothing obviously rong | 00:13 |
| racarr | hats happening? | 00:14 |
| RAOF | It leaks the fds received from Mir. | 00:14 |
| RAOF | So, if you kill it after a while, it's got > 1024 open fds. | 00:14 |
| racarr | agh | 00:14 |
| RAOF | This only happens for clients with multiple surfaces. | 00:14 |
| bschaefer | o yeah its in an infinite loop... | 00:14 |
| RAOF | Such as... XMir with two heads. | 00:15 |
| bschaefer | err I don't see anything being cleaned up | 00:15 |
| rsalveti | let me past again as it seems I got disconnected | 00:15 |
| rsalveti | <rsalveti> kgunn: so there are quite many intrusive changes comparing 4.2.2 with 4.2.1, not trivial to find what is the issue in there | 00:15 |
| rsalveti | <rsalveti> I noticed it was also giving a enomem in logcat, which is fixed with the latest kernel driver (which I tested locally) | 00:15 |
| rsalveti | <rsalveti> but unfortunately still getting a black screen | 00:15 |
| rsalveti | <rsalveti> I suspect it's something mir is not yet doing by default when handling the hwcompositor from android | 00:15 |
| RAOF | bschaefer: eglSwapBuffers will call mir_surface_swap_buffers internally, which should clean up the fds. | 00:15 |
| rsalveti | <rsalveti> as it works just fine with surfaceflinger, even when it gives the enomem error (which seems to happen when setting up the overlay for fb2) | 00:15 |
| rsalveti | <rsalveti> as this seems a bit critical, I'd vote to just change the branch of the qcom display git repo to be based on phablet-10.1, which was the previous branch used | 00:15 |
| rsalveti | <rsalveti> that would get it to work again, but it'd be good to get someone involved at this later on as well, so we can use the right branch | 00:15 |
| rsalveti | <rsalveti> guess kdub would probably have a better idea about what is going on there | 00:15 |
| rsalveti | <rsalveti> what do you think? | 00:15 |
| rsalveti | <rsalveti> racarr: ^? | 00:15 |
| bschaefer | RAOF, oo i see, but if it get cleaned up on eglSwapBuffers, shouldn't it be getting cleaned up each time? | 00:17 |
| RAOF | bschaefer: Yes indeed; this is the bug ☺ | 00:18 |
| bschaefer | RAOF, o :), I remember those memory leaks that were dealing with multiple surfaces but I was thinking it was something else :) | 00:18 |
| RAOF | :) | 00:18 |
| bschaefer | rather, I was looking for what was wrong with the egl calls | 00:18 |
| RAOF | Yeah, I just wanted a quick sanity check that the test wasn't doing something that's not meant to work. | 00:28 |
| racarr | rsalveti: I agree | 00:29 |
| rsalveti | racarr: will do a clean build and will update the bug | 00:29 |
| racarr | It ould be good to get it working, land unity 8, and we can investigate after FF | 00:29 |
| racarr | we even have a sprint coming up :) | 00:29 |
| kgunn | rsalveti: totally...and kdub will be back Sept 2 | 00:31 |
| robert_ancell | kgunn, what resolution did you do the openarena benchmarks on? I'm not getting any significant change at 800x600 | 01:05 |
| bschaefer | kgunn, i get 30-60 fps on ATI | 01:22 |
| bschaefer | RAOF, also just realized I cant gdb the mir ... my laptop has a fried gpu/motherboard soo i don't have a second machine to ssh in... | 01:26 |
| bschaefer | yay | 01:26 |
| RAOF | bschaefer: :( | 01:26 |
| bschaefer | RAOF, ill try to barrow the ATI machine from QA tomorrow and dig into it | 01:27 |
| bschaefer | as hopefully I can get a card that can reproduce this problem... | 01:27 |
| bschaefer | or if thomi has one I can use right now... | 01:28 |
| bschaefer | thomi, ping :) | 01:28 |
| bschaefer | duflu, i also have a question for you about a problem im running into when trying to do software rendering with SDL 1.2 | 01:31 |
| duflu | bschaefer, yes? | 01:32 |
| bschaefer | duflu, sooo something strange is happening only for 1.2 framebuffers: http://imgur.com/a/0S012#0 | 01:32 |
| bschaefer | duflu, each time it attempts to draw more then 1 rectangle, it starts hmm | 01:32 |
| bschaefer | its hard to explain, but each from it doesn't seem be apply the mask when its bliting? | 01:32 |
| bschaefer | (if that makes sense), so when im redrawing an the smily face it draws it with the black screen, then the gradient and the 2nd redraw | 01:33 |
| bschaefer | causing a bunch of flashing | 01:33 |
| bschaefer | duflu, and the only way around it is to redraw the entire screen vs just the place that is being updated | 01:34 |
| bschaefer | redrawing the entire screen == copying the entire SDL screen over to mirs region | 01:36 |
| RAOF | bschaefer: Are you taking into account the age of the buffer? | 01:36 |
| bschaefer | RAOF, hmm im not sure how you would take that into account? | 01:37 |
| RAOF | bschaefer: Well, if you try to only copy updates you'll need to track what is in the buffer you get (ie: via the .age field). | 01:38 |
| RAOF | bschaefer: Because what you drew last frame *will not* be in the buffer you receive. | 01:38 |
| bschaefer | RAOF, oo...but whats strange this same logic works with SDL 2.0...but I think things could be handled differently... | 01:38 |
| * bschaefer pastebins the function | 01:39 | |
| bschaefer | http://paste.ubuntu.com/6008647/ | 01:39 |
| duflu | bschaefer: Yes what RAOF said. You _can_not_ make assumptions that your previous frame, or even n-2 is the one you get back. You either have to redraw everything or use the "age" field to calculate how old the buffer you're updating is | 01:40 |
| bschaefer | RAOF, as that could be the problem, as it seems like its missing what was put into the last frame | 01:40 |
| bschaefer | that is very interesting! I didn't actually know about the age of buffers...so there could well very be a bug in my 2.0 code as well | 01:41 |
| duflu | bschaefer: The assumption probably broke recently as Mir now defaults to triple buffering | 01:41 |
| RAOF | Although even with double buffering you'd get incorrect rendering. | 01:41 |
| RAOF | But differently incorrect rendering :) | 01:41 |
| bschaefer | duflu, well i haven't tested it in a bit, i need to test it with new mir (ie. look at the cursor) | 01:41 |
| duflu | Yes, unless you consider "age" | 01:41 |
| duflu | bschaefer: Yeah your Mir is clearly very old from that cursor. Much has changed | 01:42 |
| bschaefer | im assuming its fairly simple to calculate how old the buffer is? | 01:42 |
| duflu | bschaefer: It's an integer :) | 01:42 |
| bschaefer | duflu, yup, I just haven't found time to poke someone about it | 01:42 |
| bschaefer | duflu, haha | 01:42 |
| bschaefer | well | 01:42 |
| RAOF | You don't need to (and cannot) calculate it. You pull it out of MirNativeBuffer | 01:42 |
| bschaefer | RAOF, i've not looked over the new API changes, but IIRC all I could get was a MirGraphicsRegion? | 01:43 |
| duflu | Right. You don't calculate age. But based on age you will need to calculate your changes | 01:43 |
| RAOF | See http://www.khronos.org/registry/egl/extensions/EXT/EGL_EXT_buffer_age.txt for the semantics. | 01:43 |
| bschaefer | awesome, so if the age is to old, i my need to do a redraw | 01:44 |
| duflu | I think in many cases calculating age-based changes is infeasibly complex. Better to redraw everything. | 01:44 |
| * bschaefer reads link | 01:44 | |
| bschaefer | duflu, i've noticed no problems with redrawing the screen (performance wise) | 01:44 |
| bschaefer | vs redrawing rectangles around the screen | 01:44 |
| bschaefer | im sure there are cause... i mean you have to touch all the pixels vs just select few | 01:45 |
| duflu | bschaefer: Yeah, though "copies" are slow. And should usually be avoided | 01:45 |
| duflu | bschaefer: Though if you're using software buffers and Mir, then you have little choice but to copy. See: demo_client_fingerpaint | 01:45 |
| bschaefer | duflu, o awesome, yeah, i have to copy all the changes over to a mir region ie. the whole screen :( | 01:46 |
| bschaefer | (awesome about the example) | 01:46 |
| bschaefer | you always seem to have so many useful ones! | 01:46 |
| duflu | bschaefer: That's the intention. Though the practical use isn't obvious to everyone when I propose a new example :) | 01:46 |
| bschaefer | duflu, haha, its practical time seems to always show up :) | 01:47 |
| bschaefer | RAOF, thanks for the link! Age now makes more sense :) | 01:48 |
| bschaefer | 0 == no back buffer so that'll be a good thing to check | 01:48 |
| RAOF | 0 == no current buffer content | 01:49 |
| bschaefer | duflu, RAOF thanks! I think I can actually make some progress on that problem now... | 01:49 |
| * duflu wonders if age is still accurate. Where do we set it? | 01:49 | |
| bschaefer | RAOF, which means the last buffer has been drawn and freed? | 01:49 |
| RAOF | duflu: In ClientBufferDepository | 01:49 |
| duflu | bschaefer: We don't free buffers right now. They get recycled eventually. But they could be freed in theory | 01:50 |
| RAOF | bschaefer: Which means you've got a shiny new buffer; it doesn't really imply anything more than that. Mir is free to send you a new buffer each frame, or to recycle. | 01:50 |
| RAOF | In practice your first 3 swaps will return buffers with age == 0, as we're triple-buffeering. | 01:50 |
| bschaefer | cool, I was think if the age was > 0 then we should redraw the screen | 01:50 |
| duflu | RAOF: Right so not affected by SwitchingBundle changes? | 01:50 |
| bschaefer | thinking* | 01:51 |
| bschaefer | err...well in this case redraw, as something odd is happing in sdl 1.2 as far as I can tell... | 01:51 |
| bschaefer | as the some logic I had is handle fine in 2.0, but ill need to look some more | 01:52 |
| thomi | bschaefer: hey | 01:52 |
| thomi | bschaefer: you're looking for a machine? | 01:52 |
| bschaefer | thomi, correct! An ati one preferable one with a card less then 7000 | 01:52 |
| bschaefer | thomi, I can also poke Chris about it tomorrow morning | 01:53 |
| thomi | bschaefer: how about a radeon 5750? | 01:53 |
| bschaefer | as its near my EOD (or a bit over) | 01:53 |
| bschaefer | thomi, that would be perfect | 01:53 |
| thomi | bschaefer: well, if you'd rather do it tomorrow.... | 01:54 |
| bschaefer | thomi, yeah, Ill wait till tomorrow, i really should eat something :) | 01:54 |
| thomi | bschaefer: OK | 01:54 |
| thomi | bschaefer: well, we have a 5750 in the mir test pool | 01:54 |
| bschaefer | thomi, thanks! | 01:54 |
| thomi | so speak with Chris Gagnon and I'm sure he can hook you up | 01:54 |
| bschaefer | cool, that should be easy to snag tomorrow then | 01:54 |
| bschaefer | hopefully :) | 01:55 |
| thomi | heh | 01:55 |
| * bschaefer heads out for the night | 01:56 | |
| bschaefer | RAOF, duflu thanks again! | 01:57 |
| duflu | RAOF: What swapinterval does XMir use? | 01:57 |
| duflu | bschaefer, no problem | 01:57 |
| RAOF | duflu: Whatever's the default. Presumably 1? | 02:03 |
| duflu | RAOF: Yep | 02:03 |
| * RAOF goes to make coffee, then will finish augmenting the acceptance tests so that they can expose fd leaks. | 02:05 | |
| duflu | Coffee instead of lunch? Almost as good as coffee instead of dinner | 02:06 |
| robert_ancell | duflu, have you seen the testing results for bypass? | 02:08 |
| duflu | robert_ancell: Only one brief email | 02:08 |
| robert_ancell | duflu, can you try glmark2 and see if you get the ~50% framerate when using bypass? | 02:08 |
| RAOF | Coffee *before* lunch :) | 02:09 |
| duflu | robert_ancell: That sounds very wrong... Umm it will take me a while to get to a point where I have glmark2 and Mir and bypass on the same machine again | 02:09 |
| duflu | robert_ancell: For what driver? | 02:09 |
| robert_ancell | duflu, there is a PPA - ppa:mir-team/qa-testing | 02:09 |
| robert_ancell | duflu, intel for me, I think kgunn is intel too | 02:10 |
| duflu | robert_ancell: That's really wrong. Intel has been nothing but sped up for me | 02:10 |
| duflu | Hmm | 02:10 |
| robert_ancell | duflu, kgunn is also getting a slowdown with openarena, but I can't reproduce that | 02:10 |
| duflu | robert_ancell: You're using XMir though? I have only tested native Mir clients so far | 02:11 |
| robert_ancell | duflu, I tested XMir and vanilla X | 02:11 |
| robert_ancell | for phoronix. For glmark2 I tested XMir from archive vs XMir with bypass | 02:11 |
| robert_ancell | I'm going to run phoronix with XMir from archive now | 02:12 |
| robert_ancell | brb | 02:12 |
| duflu | robert_ancell: What Mir revision is this all based on. Obviously it *requires* the switch branch to be in there too | 02:15 |
| duflu | ? | 02:16 |
| robert_ancell | duflu, this is lp:~vanvugt/mir/bypass | 02:16 |
| duflu | robert_ancell: You used it as is or did some merging? | 02:16 |
| robert_ancell | as is | 02:16 |
| duflu | Cool | 02:16 |
| robert_ancell | The first build last night seemed to do bad things (TM) but since rebuilding this morning with the switch branch changes it seems to be working better | 02:17 |
| * robert_ancell runs a benchmark, be back soon | 02:17 | |
| duflu | robert_ancell: I don't understand. How is the switch branch optional? It's been merged into the bypass branch for a long time. | 02:19 |
| RAOF | Woot! Acceptance test now fails, and for the right reason! | 02:20 |
| === chihchun_afk is now known as chihchun | ||
| robert_ancell | duflu, the switch branch isn't optional | 02:27 |
| duflu | robert_ancell: Right. Just trying to verify that we're not trying to merge bypass into a slightly old mir branch. Which will succeed, but with stuttuer/freeze bugs | 02:28 |
| robert_ancell | duflu, oh, I mean the old package was lp:~vanvugt/mir/bypass rev 927, the one this morning is lp:~vanvugt/mir/bypass rev 930 | 02:29 |
| robert_ancell | I'm not doing any merging, just debuild from the branch | 02:30 |
| * robert_ancell -> more benchmarking | 02:30 | |
| duflu | robert_ancell: Functionally that should be OK. It's been feature complete without known bugs for at least 7 days | 02:32 |
| duflu | I just lost a few days panicking about nouveau and radeon, which turned out are slightly broken but OK in kernel 3.11 | 02:32 |
| duflu | RAOF: Right, so XMir is an EGL/GLES client with default swap interval? | 02:37 |
| RAOF | It's a raw gbm client with default swap interval. | 02:37 |
| * duflu wonders if that matters | 02:37 | |
| RAOF | You keep asking if it's an EGL client, and it keeps not being one :) | 02:38 |
| duflu | RAOF: I forget. I also thought you had made changes.... | 02:38 |
| RAOF | XMir is not going to be an EGL client for the forseeable future. | 02:38 |
| duflu | RAOF: Right, but even as a GBM client it never uses buffers outside of the standard swapping semantics, surely? | 02:39 |
| RAOF | Correct. | 02:39 |
| RAOF | Certainly not before 13.10, and it'll probably keep a not-EGL-client mode indefinitely. | 02:39 |
| duflu | RAOF: Yeah, it's only important that it's a hardware surface | 02:39 |
| RAOF | And it only interacts with Mir through mir_surface_swap_buffers | 02:40 |
| * duflu also wonders if and how X unredirected windows might conflict with bypass | 02:40 | |
| kgunn | robert_ancell: so when you run phoronix on standalone X (but with xmir bypass "in the system") what kind of fps you get with open arena ? | 02:41 |
| duflu | All - If you know how to build lp:mir then please test bypass that way without X first. It sounds like the issue is XMir-specific | 02:41 |
| duflu | Although if you're using nouveau/radeon then the drivers have issues too | 02:42 |
| kgunn | duflu: do you mean using some libmirclient ? or do you mean build it as the base for my running xmir ? | 02:42 |
| duflu | kgunn: I mean native Mir clients. Test without X/XMir first | 02:42 |
| duflu | So we can focus on "why is XMir different"? | 02:43 |
| duflu | -"? +?" | 02:43 |
| duflu | I'm mostly concerned about intel. Intel should be flawless and if not then there's definitely a bug | 02:44 |
| kgunn | duflu: sure...so i'm gonna branch trunk, then merge vanvugt/mir/bypass on top...then build | 02:44 |
| kgunn | which mir demo client to run ? | 02:45 |
| duflu | kgunn: Needs to be a hardware surface and fullscreen, so eglplasma/egltriangle with: -f | 02:45 |
| duflu | And "-n" to test maximum frame rates | 02:46 |
| kgunn | ack | 02:50 |
| kgunn | RAOF: dare i ask...how are you feeling about xmir multimon ? like...ready to build a ppa? or close ? or days away ? | 02:51 |
| duflu | It could also be "what's different about unredirected X windows inside XMir?" | 02:51 |
| duflu | RAOF: Unredirected fullscreen windows in Compiz will generate zero damage. I imagine that could be a problem?... | 02:58 |
| RAOF | kgunn: Ish | 03:02 |
| RAOF | baby annacx! | 03:02 |
| kgunn | good greif...i'm hating verizon fios today....kb/s what the hell | 03:03 |
| rsalveti | racarr: kgunn: tvoss_: updated bug 1211694 | 03:04 |
| ubot5 | bug 1211694 in Mir "Black screen on Nexus4" [High,Confirmed] https://launchpad.net/bugs/1211694 | 03:04 |
| duflu | rsalveti: Can you add package details and a Fix Committed to the top? | 03:07 |
| rsalveti | duflu: there's no package involved, just part of the android build | 03:07 |
| rsalveti | didn't want to add as fix commited because this is actually just a workaround | 03:07 |
| rsalveti | let me update the title | 03:07 |
| duflu | rsalveti: Maybe also affects "phablet project" whatever that is? | 03:08 |
| === sam113101 is now known as sam113101_afk | ||
| === sam113101_afk is now known as sam113101 | ||
| rsalveti | duflu: I'm not sure this is an android issue, as surface flinger works just fine | 03:08 |
| rsalveti | could be something missing in mir itself | 03:08 |
| duflu | rsalveti: Yeah fair point. But even a workaround being committed somewhere should show up as Fix Committed to /some/ project | 03:09 |
| rsalveti | yup, agreed, but we're not yet using the android package in ubuntu | 03:09 |
| rsalveti | which we should hopefully move later this week | 03:09 |
| rsalveti | that would have the LP:# link and fix commited | 03:10 |
| rsalveti | but I can add a bugtask to our touch-images at least | 03:10 |
| rsalveti | so we can have it recorded someshow | 03:10 |
| rsalveti | *somehow | 03:10 |
| RAOF | duflu: Unredirected fullscreen windows will generate fullscreen damage on SwapBuffers | 03:11 |
| rsalveti | duflu: done | 03:11 |
| RAOF | kgunn: The read side of xmir multimon works, the write side exposes a bug in mirclient when a client has multiple surfaces, the write side needs alf's surface bind-to-output branch to land before it'll work properly, and I need to work out why the write side doesn't cause Mir to actually change modes. | 03:13 |
| RAOF | kgunn: All in all, reasonably close, at least for a first test. | 03:13 |
| RAOF | kgunn: PPA-able by my EOD tomorrow would seem like a reasonable prediction. | 03:14 |
| duflu | rsalveti: Cool thanks | 03:14 |
| duflu | RAOF: Sounds right. you mean on "glXSwapBuffers"? | 03:15 |
| RAOF | duflu: Yes, ish. Actually I mean “on DRI2SwapBuffers”, but that's how the client would call it. | 03:15 |
| duflu | RAOF: Sounds good in theory. I need to set up for more practical XMir testing... | 03:16 |
| === sam113101 is now known as kline_afk | ||
| === kline_afk is now known as sam113101 | ||
| kgunn | rsalveti: thanks for the work...and to me, yes its a workaround & effectively they broke behavioral compatibility | 03:23 |
| kgunn | rsalveti: as you say, its a matter of bug fixing when kdub returns to "update" to the new changes from android | 03:23 |
| kgunn | we're effectively the client they don't know they have...and don't care :) | 03:24 |
| kgunn | they being google | 03:24 |
| kgunn | RAOF: that's an exciting prediction (i hope it holds better than other predictions we've been making ;) | 03:25 |
| RAOF | ☺ | 03:25 |
| * duflu struggles to remember everything he used to use every day to test compiz | 03:26 | |
| kgunn | um...sorry for the lag, so branched trunk, merged bypass branch on top...went to build, but fails looking for egl/egl.h ? | 03:29 |
| kgunn | ring any bells | 03:29 |
| duflu | kgunn: doc/building_source_for_pc.md | 03:30 |
| duflu | kgunn: AKA http://unity.ubuntu.com/mir/building_source_for_pc.html | 03:30 |
| kgunn | following that....but might've f'd up my system from ealier (like mesa-dev uninstalled...) | 03:32 |
| RAOF | Oh, yeah. That's why. The server side of ClientBufferTracker is session-local, rather than surface-local. | 03:36 |
| duflu | robert_ancell: I get nothing but /more speed/ from glmark2 using the bypass PPA. It just works. And this is a machine I haven't tested it on before | 03:36 |
| * duflu will have to install openarena | 03:36 | |
| duflu | Fragging for science, once again | 03:37 |
| duflu | Annoying and satisfying. OpenArena under bypass works flawlessly | 03:50 |
| kgunn | duflu: which ppa ? qa-testing ? | 04:05 |
| duflu | kgunn: Yep. Boosts performance in everything for me | 04:06 |
| duflu | And that's on a machine I've never tested bypass on | 04:06 |
| duflu | Roughly speaking, the bypass PPA puts performance halfway between standard saucy/XMir and legacy X | 04:07 |
| duflu | Which is what we expected, pending more optimizations in XMir | 04:08 |
| duflu | But in the grand scheme of things, it's unimportant. Native mir clients on a native Mir server are a whole new ballgame | 04:09 |
| kgunn | duflu: sure....just wondering aloud, possible diff it works well for you but no one else...got any funky xorg.conf there ? | 04:10 |
| kgunn | sorry my simple test taking so long...un-f'ing my machine... | 04:10 |
| duflu | kgunn: It's just a thinkpad with saucy I'm testing no customizations | 04:13 |
| duflu | Oh, wait. I do have a xorg.conf. Will have to delete that and retest :/ | 04:14 |
| kgunn | duflu: hmm...considering reimaging my machien | 04:14 |
| kgunn | wondering is robert, olli and i were totally clean now... | 04:14 |
| kgunn | but gagnon would've definitely been clean on the lexington machines...hmm | 04:15 |
| robert_ancell | kgunn, openarena is showing no performance hit on my system and an improvement over XMir without bypass. It just seems to be glmark | 04:15 |
| robert_ancell | results in https://code.launchpad.net/~vanvugt/mir/bypass/+merge/181003 | 04:16 |
| kgunn | robert_ancell: that sounds good | 04:16 |
| kgunn | ok..i'm building successfully now...officially un-f'd | 04:18 |
| duflu | That's odd. I get a significant improvement in glmark2. | 04:19 |
| kgunn | robert_ancell: i'm gonna try qa-testing on this machine...i know its state very well....not sure i completely trust where my 2nd one was when i started... | 04:21 |
| robert_ancell | duflu, I'll retest to confirm | 04:21 |
| robert_ancell | thomi, do you know what jenkins job is building unity-greeter into ppa:mir-team/staging? | 04:26 |
| duflu | robert_ancell: Also remember bypass can only work at your *native* monitor resolution | 04:26 |
| robert_ancell | duflu, for XMir you're always at the native resolution right? | 04:27 |
| thomi | robert_ancell: I can check, one second | 04:27 |
| duflu | robert_ancell: Yeah should be actually | 04:27 |
| robert_ancell | brb | 04:29 |
| robert_ancell | duflu, yeah, re-running glmark tests doesn't show such a significant change. Though the numbers are all over the place so I don't know how reliable a benchmark it is | 04:39 |
| kgunn | robert_ancell: ok...so i'm on qa-testing on my well known machine....glmark2 numbers look insane like 2K fps | 04:43 |
| kgunn | openarena....looks pretty sane | 04:44 |
| kgunn | haven't compared in detail...but its not crawling at 10fps | 04:44 |
| robert_ancell | kgunn, ok, so we're just seeing bad numbers from olli and robotfuel now? | 04:44 |
| kgunn | robotfuel never tried the second ppa | 04:44 |
| kgunn | unsure about olli | 04:44 |
| kgunn | ...altho he had kernel stuff going on | 04:45 |
| kgunn | on a side note...i'm seeing some visual artifacts that looks like cache management sync issues | 04:46 |
| thomi | robert_ancell: to answer your question, unity-greeter is configured for autolanding, so there's a bunch of jobs that dput to the PPA | 04:46 |
| thomi | robert_ancell: not sure why you were asking? | 04:46 |
| robert_ancell | thomi, just looking at broken builds and builds for raring | 04:47 |
| robert_ancell | thomi, unless there was a particular reason for that it should probably only do saucy builds | 04:47 |
| thomi | robert_ancell: hmm, i agree | 04:48 |
| duflu | robert_ancell: glmark2 results are very stable. I have used them for long term comparisons over months and now years | 04:48 |
| thomi | robert_ancell: I can't see why it would be doing raring builds | 04:48 |
| * duflu heads off to lunch | 04:49 | |
| robert_ancell | thomi, the package is old, I'll just delete the raring one and perhaps nothing will repopulate it | 04:49 |
| thomi | robert_ancell: yeah, that would be my guess | 04:49 |
| robert_ancell | thomi, the other thing is the saucy version is out of date - so perhaps the autolanding config was removed entirely? | 04:51 |
| thomi | robert_ancell: we're still talking about unity-greeter? | 04:52 |
| robert_ancell | thomi, yes | 04:52 |
| robert_ancell | https://launchpad.net/~mir-team/+archive/staging/+packages | 04:52 |
| thomi | robert_ancell: it's still configured, let me check the jenkins jobs | 04:52 |
| robert_ancell | because trunk says 13.10.2 | 04:52 |
| thomi | robert_ancell: in debian/changelog? | 04:53 |
| robert_ancell | thomi, yes | 04:53 |
| thomi | that's a separate process | 04:53 |
| thomi | landing into the PPA is one thing, landing into distro is another | 04:54 |
| thomi | debian/changelog only gets updated when you land into distro | 04:54 |
| thomi | the last landing into the PPA was on the 13th of aug, and was to land this branch: bzr+ssh://ps-jenkins@bazaar.launchpad.net/~dbarth/unity-greeter/remote-login-only | 04:54 |
| robert_ancell | thomi, but it should have been rebuilt once the bzr branch was updated to rev 950 | 04:54 |
| robert_ancell | staging is rev 941 | 04:55 |
| thomi | robert_ancell: hmmm, I just noticed this: http://10.97.2.10:8080/job/unity-greeter-autolanding/3/console | 04:56 |
| thomi | robert_ancell: does debian/changelog have UNRELEASED perhaps? | 04:56 |
| robert_ancell | nope | 04:56 |
| thomi | hmmm | 04:58 |
| RAOF | Why doesn't C++ do automatic tuple unpacking? | 04:58 |
| robert_ancell | thomi, the thing is there's packages like unity-greeter, unity-greeter-session-broadcast, unity-notifications that have nothing to do with Mir in there. They probably should be going to another PPA | 04:58 |
| thomi | so both unity-greeter and unity-greeter-session-broadcast are currently configured to land in that PPA | 04:59 |
| thomi | if you have a different PPA you'd like to nominate, I can configure that | 04:59 |
| robert_ancell | I'd say make a unity-greeter staging PPA | 05:00 |
| robert_ancell | I'll do that | 05:00 |
| robert_ancell | thomi, redirect them to ppa:unity-greeter-team/staging | 05:01 |
| kgunn | duflu: ok...finally...in addition...i tested trunk+bypass native mir, eglplasma demo getting ~70fps | 05:01 |
| thomi | ok, will CC you in the email to francis | 05:01 |
| robert_ancell | kgunn, is that good? | 05:02 |
| kgunn | dunno | 05:03 |
| robert_ancell | kgunn, is eglplasma from glmark or phoronix? | 05:03 |
| kgunn | mir demo client (full screen, unlocked from vsync) | 05:03 |
| kgunn | guess i need a baseline...which means a rebuild...ug | 05:04 |
| kgunn | oh...wait...nvmd...its in main, yea! | 05:04 |
| robert_ancell | kgunn, why are you rebuilding? Why not use PPA versions? | 05:04 |
| kgunn | at duflu 's request | 05:04 |
| robert_ancell | kgunn, are you trying a variation on lp:vanvugt/mir/bypass? | 05:05 |
| kgunn | just native client vs xmir | 05:05 |
| robert_ancell | thomi, one last thing - do you know why/how unity-notifications is getting into the staging PPA? | 05:07 |
| robert_ancell | thomi, it also seems out of date | 05:08 |
| robert_ancell | I might just delete it and see if anyone makes a noise | 05:08 |
| RAOF | Man, how many _Surface_ classes do we have? | 05:08 |
| thomi | robert_ancell: it's not configured to autoland there | 05:08 |
| thomi | perhaps it once awas | 05:08 |
| kgunn | yo dawg i heard you like surfaces | 05:08 |
| thomi | *was | 05:08 |
| robert_ancell | RAOF, would you like some more? | 05:08 |
| robert_ancell | thomi, ok, it's gone now. | 05:09 |
| * RAOF is indeed adding one more. | 05:09 | |
| kgunn | oh the irony | 05:09 |
| robert_ancell | thomi, do you want/need the raring and quantal versions of runbench in there? | 05:10 |
| thomi | robert_ancell: not any more | 05:11 |
| robert_ancell | thomi, gone | 05:11 |
| robert_ancell | I'm also going to delete the raring version of glmark | 05:11 |
| robert_ancell | hope no-one wanted that | 05:11 |
| kgunn | dude raring's dead | 05:12 |
| robert_ancell | staging PPA actually looks useful again - latest versions of mir and u-s-c, experimental builds of SDL and runbench | 05:12 |
| robert_ancell | you could almost actually use if IF we had a stable ABI between u-s-c and mir | 05:13 |
| thomi | robert_ancell: erp, forgot to CC you in, but I've sent those upstream-merger configuration tweaks off to francis | 05:13 |
| tvoss_ | robert_ancell, kgunn good morning | 05:13 |
| robert_ancell | and it's all saucy | 05:13 |
| robert_ancell | tvoss_, hello | 05:13 |
| thomi | hello tvoss_ | 05:13 |
| tvoss_ | robert_ancell, kgunn so what is the status on bypass? | 05:13 |
| kgunn | tvoss_: so it is | 05:13 |
| robert_ancell | thomi, ok, cool. I'll just stomp on any packages that end up in the PPA in the meantime :) | 05:13 |
| kgunn | tvoss_: can you try ppa:mir-team/qa-testing ? | 05:14 |
| kgunn | first we had some bumps...i think i had a dodgey setup | 05:14 |
| kgunn | and not sure what robert's story is | 05:14 |
| kgunn | both of us seeing good perf now | 05:14 |
| kgunn | duflu worked right off the bat | 05:14 |
| tvoss_ | robert_ancell, what is the qa testing ppa build against? | 05:15 |
| kgunn | we missed gagnon before robert rebuilt it | 05:15 |
| robert_ancell | tvoss_, it's lp:~vanvugt/mir/bypass + u-s-c trunk | 05:15 |
| kgunn | olli has a naff kernel situtation.... | 05:15 |
| robert_ancell | I rebuilt it with the changes duflu made while I was sleeping | 05:15 |
| tvoss_ | robert_ancell, kgunn I tested it yesterday on the ati machine with expected results and all being fine | 05:16 |
| tvoss_ | kgunn, what means a naff kernel situation? | 05:16 |
| robert_ancell | I was seeing bad glmark2 numbers, but good phoronix numbers. The glmark2 tests are working now, so I'm not putting too much faith in them being valid | 05:16 |
| kgunn | tvoss_: from his conversation with leann ", I am on a x220 and have experienced hard locks when running >3.10.0-6." | 05:17 |
| kgunn | so 3.11 is kind of a prob for him.. | 05:17 |
| tvoss_ | kgunn, true but I wouldn't think that that is the actual issue | 05:19 |
| tvoss_ | robert_ancell, bad numbers in terms of? | 05:19 |
| robert_ancell | tvoss_, ftp | 05:19 |
| robert_ancell | fps | 05:19 |
| robert_ancell | rather | 05:19 |
| tvoss_ | robert_ancell, I think it's not bypass causing those numbers, glmark2 is slower without bypass, at least for me | 05:19 |
| robert_ancell | tvoss_, yeah, that's what duflu was seeing too | 05:20 |
| tvoss_ | robert_ancell, kgunn so which ppa has the bypass mir and usc now? | 05:20 |
| robert_ancell | tvoss_, ppa:mir-team/qa-testing | 05:20 |
| kgunn | duflu: just last bit o' data...mir native egl plasma was 50fps w/o bypass...bypass was 70fps...so bueno | 05:22 |
| kgunn | which is kinda irrelevant now...but...anyway | 05:23 |
| duflu | kgunn, I've come to realize eglplasma is a bad test for /some/ GPUs because the excessive shader calculations often limit the framerate before anything else | 05:43 |
| duflu | So best test is: egltriangle -n -f | 05:43 |
| duflu | Why am I the only one in the hangout? | 06:00 |
| robert_ancell | racarr, tvoss, kgunn, meeting | 06:02 |
| robert_ancell | hikiko, meeting | 06:03 |
| kgunn | robert_ancell: grabbing a water.... | 06:04 |
| robert_ancell | kgunn, wasn't actually expecting you to make it! | 06:04 |
| tvoss | robert_ancell, kgunn coming | 06:05 |
| kgunn | duflu: egltriangle w/o bypass ~173 fps, w/bypass 264 fps | 06:09 |
| duflu | Woo | 06:09 |
| duflu | 50% increase is better than my best observed benefit of 25% so far | 06:12 |
| === jono is now known as Guest36288 | ||
| duflu | Everyone always seems so down when we say goodbye | 06:32 |
| duflu | I'm sure there's a song about that | 06:32 |
| racarr | duflu: I was thinking the same thing! | 06:32 |
| racarr | very somber feeling ending | 06:32 |
| alf__ | RAOF: MirConnection::validate_user_display_config() is the function I was referring to | 06:32 |
| hikiko | I have a completely irrelevant question: where is lexington? I found at about 4 lexingtons... | 06:32 |
| duflu | hikiko: Boston | 06:33 |
| RAOF | alf__: Ta. | 06:33 |
| duflu | (?) | 06:33 |
| alf__ | hikiko: Lexington, MA | 06:33 |
| racarr | Does anyone | 06:33 |
| racarr | need help with anything | 06:33 |
| racarr | I am pretty aake | 06:33 |
| hikiko | :D | 06:33 |
| racarr | awake* | 06:33 |
| RAOF | :) | 06:33 |
| racarr | lol | 06:33 |
| duflu | racarr: Go sleep. It's the right time :) | 06:33 |
| RAOF | racarr: I'll soon have something for you to review if you want. | 06:33 |
| racarr | RAOF: okk we will see if I get tired :) | 06:35 |
| robert_ancell | RAOF, You said there were two Mir patches needing to land for XMir+MM right? https://code.launchpad.net/~afrantzis/mir/place-surface-in-output/+merge/181051 and ? | 06:36 |
| RAOF | robert_ancell: And this "don't leak fds" branch that I'm just finishing. | 06:36 |
| robert_ancell | RAOF, is it pushed yet? | 06:36 |
| RAOF | No | 06:37 |
| robert_ancell | RAOF, then with git branch of xserver we're done? | 06:37 |
| RAOF | And the various drivers, yes. Modulo fixes. | 06:38 |
| robert_ancell | RAOF, but the drivers are all in saucy right? | 06:38 |
| RAOF | No, not that work with the git branch of xserver. | 06:38 |
| duflu | kgunn: You commented in the wrong MP :) | 06:38 |
| robert_ancell | RAOF, ah, which drivers? | 06:38 |
| kgunn | duflu: oh crap....too many tabs | 06:38 |
| robert_ancell | RAOF, I'm thinking I'm going to stuff this up uploading to a PPA... Perhaps you'll have to do it | 06:39 |
| RAOF | robert_ancell: The ones that I haven't pushed yet, because I was still testing & ensuring I don't need to break XMir API again ;) | 06:39 |
| RAOF | robert_ancell: Yeah, I'm happy to do the push to a PPA. | 06:39 |
| duflu | kgunn, robert_ancel: I notice that OpenArena is very erratic with its results. Better to use glmark2 | 06:39 |
| duflu | robert_ancell ^ | 06:39 |
| robert_ancell | duflu, the opposite of me! | 06:40 |
| RAOF | alf__: I kind of feel like the place-surface-in-output could do with having the last entry of MirSurfaceParameters be a variable-length array of optional attributes. Having every client set the "I don't care where this goes" flag seems smelly. | 06:40 |
| duflu | Hmm | 06:40 |
| kgunn | duflu: i've noticd the opposite | 06:40 |
| duflu | Maybe I need to use a longer timedem | 06:40 |
| duflu | +o | 06:40 |
| alf__ | RAOF: well, ideally the whole surface parameter list would be a variable-lenght array ala EGL | 06:42 |
| * duflu votes for that | 06:42 | |
| duflu | or va_list even | 06:43 |
| RAOF | alf__, duflu: Almost. I think it's reasonable to mandate width, height. | 06:43 |
| duflu | RAOF: Not when things are resizable later | 06:43 |
| duflu | RAOF: Perhaps just buffer_usage | 06:43 |
| RAOF | That is truly immutable. | 06:43 |
| RAOF | But still, reasonable defaults say "hardware" | 06:43 |
| duflu | Oh, actually, resizable means we could vary buffer usage too :) | 06:43 |
| duflu | Heh. You /could/ switch between software and hardware rendering between frames once we have buffer resize/reallocation | 06:45 |
| robert_ancell | RAOF, ok, you can push XMir+MM changes to ppa:mir-team/qa-testing2. Then we need to merge the bypass stuff into that, then we can copy to ppa:mir-team/system-compositor-testing | 06:45 |
| dholbach | good morning | 06:45 |
| RAOF | robert_ancell: And that should be the XMir stuff that's actually expected to work, right? | 06:46 |
| robert_ancell | RAOF, I think ideally we'd just push in what we have now, then update it when it's ready for testing | 06:46 |
| RAOF | Ok. | 06:46 |
| robert_ancell | No-one should be pulling from that PPA until we give the signal | 06:46 |
| RAOF | Ok. I'll do so shortly. | 06:47 |
| alf__ | RAOF: if you feel strongly about changing surface params to be a variable-length array now (or perhaps the last element) I have no objections, and I actually prefer it, but no time to do it :/ | 06:47 |
| duflu | Morning dholbach | 06:47 |
| dholbach | hi duflu | 06:47 |
| RAOF | alf__: Yeah, FF sucks :) | 06:47 |
| duflu | Add it to the list of things we would like to do "next ABI" | 06:47 |
| RAOF | alf__: I think I'll see how much effort it is. While we're breaking ABI... | 06:48 |
| * robert_ancell hears the ABI floodgates open | 06:48 | |
| * RAOF dislikes the way mock testing makes tests sensitive to internal details they shouldn't be insensitive to. | 06:49 | |
| duflu | robert_ancell: If and when we branch, and it's clear which branch we can safely change such things in, it will be easier for everyone | 06:49 |
| duflu | RAOF: +1 | 06:49 |
| robert_ancell | RAOF, +1 | 06:49 |
| duflu | Mocking is useful definitely, but that's a big disadvantage | 06:50 |
| robert_ancell | duflu, branch? | 06:50 |
| duflu | robert_ancell: I mean, when we branch Mir for 14.04 then we can break ABIs (for a while) | 06:50 |
| alf__ | robert_ancell: What's the process for breaking ABI after FF? Is it allowed? More difficult? | 06:50 |
| duflu | Or rather, when a maintenance branch for 13.10 slits from lp:mir | 06:51 |
| duflu | *splits | 06:51 |
| robert_ancell | duflu, well, unfortunately there's not really any good time to break ABI - because each Ubuntu development release is meant to be stable we can't break anything linking against libmirserver | 06:51 |
| duflu | robert_ancell: I know. But the goal is to make changes which then lead to fewer changes in future | 06:51 |
| RAOF | We can reasonably break A*B*I pretty frequently before feature freeze. | 06:52 |
| duflu | "one" goal... | 06:52 |
| RAOF | It's more troublesome to break API. | 06:52 |
| robert_ancell | RAOF, only because we're carefully rebuilding everything that depends on libmirserver | 06:52 |
| robert_ancell | We wont have that luxury forever | 06:52 |
| RAOF | Oh, that's because we don't currently ensure libmirserver's ABI *at all* | 06:53 |
| RAOF | Once we ensure that *each upload* doesn't change ABI we could pretty happily change ABI once a month or so. | 06:53 |
| RAOF | For the first couple of months of Ubuntu development, at least :) | 06:53 |
| duflu | Surely we can always make ABI/API changes somewhere. It just might be in a branch that doesn't get released for multiple cycles :/ | 06:54 |
| robert_ancell | RAOF, oh yes, exactly. As long as we bump the SONAME when we do | 06:54 |
| RAOF | Right. | 06:55 |
| didrocks | as long as you bump SONAME and handle the transition, no issue from here :) | 06:55 |
| robert_ancell | RAOF, so as I see it we can't *break* ABI, but we can *change* ABI. | 06:55 |
| RAOF | We can *add* ABI at will, yes. | 06:56 |
| robert_ancell | To me breaking ABI means changing it without changing the soname thus potentially breaking all the dependent applications | 06:56 |
| RAOF | We could also *break* ABI at reasonable intervals; once a month isn't too excessive. But that is once our SONAME actually means something. | 06:57 |
| robert_ancell | I think we have different breaks | 06:57 |
| RAOF | robert_ancell: Ah, whereas I'm going from "you increment the SOVERSION each time you break ABI" | 06:57 |
| robert_ancell | yep :) | 06:57 |
| RAOF | Yeah, you can never break ABI without also changing SONAME | 06:57 |
| duflu | tsdgeos: Morning. Nexus4 is fixed, apparently. Or worked around. | 06:57 |
| RAOF | s/can never/should never/ | 06:57 |
| robert_ancell | RAOF, I think you have the correct lingo | 06:58 |
| robert_ancell | alf__, does that answer your question? | 06:58 |
| robert_ancell | alf__, in short, it's much the same as now, except we need to bump soname if MPs change the interface | 06:58 |
| alf__ | robert_ancell: ok | 07:00 |
| didrocks | and you need to rebuild the rdepends | 07:00 |
| mlankhorst | g'morning! | 07:00 |
| RAOF | mlankhorst: g'day | 07:00 |
| didrocks | (so making a MP bumping the build-dep version normally) | 07:00 |
| robert_ancell | alf__, and what didrocks said | 07:00 |
| RAOF | But the rebuilding-the-rdepends step is not time-critical. | 07:00 |
| didrocks | RAOF: well, it needs to be done in the following hours | 07:01 |
| didrocks | RAOF: as Mir is on top of the stack, everything will be blocked in proposed | 07:01 |
| didrocks | because Mir won't go from proposed -> release pocket | 07:01 |
| didrocks | (as long as all rdepends are not rebuilt) | 07:01 |
| RAOF | didrocks: Really? That seems unnecessarily aggressive. | 07:01 |
| didrocks | RAOF: it's what britney is forcing us | 07:02 |
| didrocks | we don't create NBS package | 07:02 |
| didrocks | (which is the package with the previous ABI) | 07:02 |
| RAOF | Ah, ok. That's quite agressive :) | 07:02 |
| didrocks | RAOF: yeah, basically we don't have anymore libfoo1 and libfoo2 | 07:02 |
| didrocks | in the release pocket together | 07:03 |
| mlankhorst | well mesa 9.2 is ready for testing :P | 07:03 |
| didrocks | (apart if we have 2 sources of course) | 07:03 |
| mlankhorst | I should probably kill off the xorg-server in the ppa now | 07:03 |
| RAOF | didrocks: Including *all* rdepends, such as things in universe? | 07:03 |
| RAOF | That's going to get really annoying should things start supporting Mir. | 07:04 |
| didrocks | RAOF: yeah, everything in the archive | 07:04 |
| didrocks | RAOF: I guess the fundation team got fed up to ping people to help cleaning NBS | 07:05 |
| didrocks | at least, for dailies, it's quite easy, we can "force rebuild" some components | 07:05 |
| didrocks | it will prepare the changelog | 07:05 |
| didrocks | rebuild it | 07:05 |
| didrocks | test it and upload it | 07:05 |
| didrocks | so it's just some "push button" | 07:05 |
| alf__ | RAOF: so, I guess having non-API/ABI breaking mechanisms (like the variable parameter list) becomes even more important... | 07:06 |
| didrocks | more annoying for things outside dailies, indeed | 07:06 |
| didrocks | yeah, padding and so on is useful | 07:06 |
| RAOF | alf__: Yeah :) | 07:06 |
| didrocks | I guess you all know the KDE C++ ABI handling page :) | 07:06 |
| duflu | ? | 07:06 |
| * RAOF doesn't | 07:06 | |
| RAOF | My working assumption is “C++ does not have a stable ABI” | 07:07 |
| didrocks | http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ | 07:07 |
| didrocks | there are various links and pages with technics on their wiki | 07:07 |
| duflu | didrocks: Oh, I knew the details. Just never seen that page | 07:08 |
| didrocks | duflu: it's a good reference, didn't find anything more concise (if you have a link, that would be helpful ;)) | 07:08 |
| didrocks | ABI in C++ is so easy to break contrary to C | 07:08 |
| duflu | didrocks: No, it's all learned from experience, supporting C++ ABIs over many years | 07:09 |
| didrocks | duflu: just the way you are telling it make sound painful ;) | 07:10 |
| tsdgeos | duflu: yeah saw that, going to flash the phone now and see if it hit the reease yet | 07:10 |
| duflu | tsdgeos: Not sure what image if any has the fix yet | 07:10 |
| didrocks | fix in Mir? | 07:11 |
| duflu | -fix +workaround | 07:11 |
| duflu | didrocks: No workaround/fix to the phablet image | 07:11 |
| tsdgeos | didrocks: in the android side | 07:11 |
| didrocks | ah ok | 07:11 |
| tsdgeos | duflu: nothing is lost by trying :D | 07:11 |
| didrocks | kgunn: come on! | 07:11 |
| didrocks | robert_ancell: kgunn: first run on ati -> fail :/ | 07:11 |
| didrocks | Mirv: FYI ^ | 07:12 |
| didrocks | Mirv: deprovisionning ati as well… | 07:12 |
| didrocks | let's freeze the state of this fdfdsoifdsjfs machine | 07:12 |
| duflu | mlankhorst: I have noticed with nouveau (and radeon) that flooding one GL client starves others. This is a big problem when "others" includes the display server. Are you aware of such problems? | 07:13 |
| mlankhorst | duflu: sync to vblank helps :-) | 07:13 |
| duflu | mlankhorst: Yes it certainly does help. But many people run benchmarks without sync | 07:13 |
| mlankhorst | and a bit of frame throttling | 07:13 |
| duflu | In fact, sleep(10ms) helps too | 07:14 |
| duflu | mlankhorst: Just seems like nouveau and radeon might have very conservative locking | 07:14 |
| duflu | Which limits concurrency | 07:14 |
| mlankhorst | duflu: well benchmarks are weird, card just wants to execute things as fast as possible and has set up some time slices, but it cannot context switch during execution | 07:14 |
| duflu | Oh. I didn't think about the GPU being a platform with its own timeslices | 07:15 |
| didrocks | tvoss_: around? | 07:15 |
| tvoss_ | didrocks, ack | 07:15 |
| duflu | mlankhorst: Not sure how intel avoids such things. Strategic yields? | 07:15 |
| mlankhorst | usually command buffers are all about setting up state and then firing it off by flipping the switch. during the execution of that switch it cannot switch, and it tries to be 'fair', but if there are no other commands running most of the time it will just dedicate itself entirely to that single command stream :P | 07:15 |
| mlankhorst | duflu: single command buffer I guess | 07:16 |
| * duflu didn't think to try std::this_thread::yield() when testing GPUs | 07:16 | |
| mlankhorst | there's some stuff not figured out, it might be possible to give certain command buffers higher priority but that requires an abi change | 07:19 |
| RAOF | mlankhorst: Not thinking of writing a deadline scheduler for nouveau? :) | 07:19 |
| duflu | mlankhorst: Is process priority used? | 07:19 |
| mlankhorst | duflu: nah it's dark magic :P | 07:20 |
| duflu | Excellent | 07:20 |
| mlankhorst | Not sure how it works tbh | 07:20 |
| Mirv | ouch :( | 07:20 |
| mlankhorst | there's a lot of nvidia hw not understood yet | 07:20 |
| mlankhorst | but as kepler support has shown you don't really need to for rendering basic 3d :P | 07:21 |
| mlankhorst | (3d support was working before 2d was) | 07:21 |
| * robert_ancell -> EOD | 07:30 | |
| duflu | Dear Nvidia: Where are your docs? | 07:31 |
| tvoss_ | duflu, RAOF mlankhorst need your help | 07:32 |
| duflu | tvoss_? | 07:32 |
| RAOF | What's up? | 07:32 |
| mlankhorst | nah lol | 07:32 |
| duflu | mlankhorst: Surely life would be less exciting if it was as simple as being documented | 07:33 |
| mlankhorst | I don't even think there is a per fifo time slice adjustment | 07:33 |
| mlankhorst | besides bypass will support a lot of issues | 07:34 |
| duflu | mlankhorst: I will try inserting some strategic yield calls next time I'm playing with nouveau or radeon. Since I found success with sleeping a few millisec | 07:41 |
| duflu | tvoss_: On it now, in fact | 07:43 |
| tvoss_ | duflu, we have unity not starting with compiz trying to load the core plugin | 07:47 |
| tvoss_ | didrocks, ^ | 07:47 |
| didrocks | the first run stuck on opengl though | 07:48 |
| duflu | tvoss_: "core" is not a real plugin. "core" is unity's main really. It can't fail to load | 07:48 |
| duflu | Sorry, "core" is compiz's main | 07:48 |
| alan_g | hikiko: how's it coming along? | 08:07 |
| duflu | RAOF: drm_auth_magic... is that called repeatedly or only once? | 08:07 |
| hikiko | hi alan_g | 08:09 |
| hikiko | I just started :) didn't do much, I was arranging my trip, no problems yet :) | 08:10 |
| duflu | hikiko: At least I *hope* it's the one near Boston :) | 08:12 |
| alan_g | hikiko: as you're not in deep yet could you review https://code.launchpad.net/~alan-griffiths/mir/a-surface-for-each-output/+merge/181095? | 08:15 |
| alan_g | alf__: @place-surface-in-output do you want to react to ra's comment, or shall I top-approve? | 08:15 |
| alan_g | duflu: +1 | 08:15 |
| hikiko | sure alan_g! (pulling) | 08:15 |
| duflu | RAOF: Never mind. Logs answered that question | 08:16 |
| alf__ | alan_g: looking | 08:19 |
| duflu | ping RAOF | 08:32 |
| duflu | alf__, do you have any understanding of xmir_auth_drm_magic ? | 08:35 |
| alf__ | duflu: some | 08:35 |
| alf__ | duflu: oh, do you mean the specific xmir implementation? | 08:35 |
| duflu | alf__: I mean the context in which it is called, not the Mir implementation | 08:35 |
| duflu | alf__: Is it called for multiple screens/threads? | 08:36 |
| duflu | Because it looks like it... and also the client API looks unsafe to use in such a way | 08:36 |
| alf__ | duflu: I don't know the context details, sorry | 08:40 |
| duflu | alf__, Can you explain the high-level purpose for me? | 08:41 |
| alf__ | duflu: It is a mechanism to allow clients to perform some privileged DRM operations (to authenticate them). | 08:44 |
| duflu | alf__, OK thanks. Any idea which project/branch calls the function? I can't find it yet | 08:44 |
| duflu | alf__, Nevermind. Found it in the hardware-specific xorg drivers | 08:47 |
| * RAOF spots the blatantly obvious logic error in his patch. | 08:49 | |
| RAOF | duflu: Pong. | 08:49 |
| RAOF | duflu: X is resolutely single-threaded. | 08:49 |
| duflu | RAOF: Hmm, I'm suspicious of the reuse/concurrency of xmir_auth_drm_magic. Is it once per screen/monitor/GPU? | 08:50 |
| RAOF | duflu: There *is* some SIGIO madness possible, but that will never cause DRI2Authenticate, which is the only place that calls xmir_auth_drm_magic, to be reentrant. | 08:50 |
| RAOF | We call xmir_auth_drm_magic once per client DRI2Authenticate request. | 08:51 |
| alf__ | duflu: (for some background: the idea is that the client asks DRM for a magic cookie with drmGetMagic(), and then sends it to the DRM master, which marks it as authenticated with drmAuthMagic(). After this, the client is considered authenticated by DRM and can perform some privileged ops.) | 08:51 |
| duflu | RAOF: I mean MirConnection::drm_auth_magic() looks very un-threadsafe. And we seem to be requiring that multiple calls to it work in close succession | 08:51 |
| RAOF | duflu: But never twice at once, because we mir_wait_for() it. | 08:52 |
| duflu | RAOF: OK, so in theory only one thread | 08:52 |
| RAOF | The only threads in the X server are the ones libmirclient imposes. | 08:52 |
| RAOF | And xmir proxies all of those callbacks to the X mainloop, via the madness of xmir_thread_proxy. | 08:53 |
| smspillaz | RAOF: this design pattern feels very ... familiar | 09:29 |
| * smspillaz looks at GdkMirEventListener | 09:30 | |
| smspillaz | yep, familiar | 09:30 |
| smspillaz | just dealing with the pain that is the gmain.c | 09:30 |
| RAOF | Yeah, we should totally have a generic to-event-loop-fd handler. | 09:30 |
| smspillaz | RAOF: I think what there really needs to be is some kind of kernel system call that can listener on fds and pthread conditions at the same time | 09:31 |
| smspillaz | kevents doesn't count | 09:31 |
| smspillaz | wakeup pipes are just ... awkward | 09:32 |
| alan_g | alf__: Quick Q: as client I request a change to the display config...when the change succeeds do I get a change notification? | 09:32 |
| katie | tvoss_, or anyone else, I'm writing up the bit about focus stealing, and want to know how Mir handles the focus queue.. is there still an idea of a focus queue? | 09:35 |
| katie | tvoss_, mpt has another idea, of a probably-opening-a-window flag | 09:35 |
| tvoss_ | katie, haven't heard of that before | 09:35 |
| katie | the example is slow opening attachments in Thunderbird | 09:36 |
| katie | tvoss_, the attachment can request to be focussed, but if it takes a long time, and the user focusses something else, the attachment can't steal focus | 09:36 |
| RAOF | katie: That was roughly equivalent to desrt's “You hand out an obfuscated timestamp on start” idea, right? I remember mpt and him being in violent agreement in Bluefin. | 09:39 |
| katie | RAOF, yes, that was the discussion | 09:40 |
| RAOF | We should totally get desrt to implement that. 'Twas a good idea. | 09:42 |
| katie | RAOF, have you heard any discussion since? | 09:42 |
| RAOF | katie: No | 09:42 |
| RAOF | That's likely to be the shell's purview. Although maybe it should be ours. | 09:43 |
| tvoss_ | katie, RAOF I think we need something on two levels | 09:43 |
| tvoss_ | katie, will have lunch, with you after that | 09:43 |
| katie | tvoss_, ok :) | 09:43 |
| === tvoss_ is now known as tvoss|lunch | ||
| duflu | RAOF: Is it normal to xmir_auth_drm_magic multiple times per Screen? | 10:14 |
| RAOF | Yes. | 10:14 |
| RAOF | duflu: It will be called each time a client calls DRI2Authenticate, which every GL client will call at startup. | 10:15 |
| === hikiko is now known as hikiko|lunch | ||
| alf__ | alan_g: sorry, missed the ping... no because you change only your session's config as things are now. You only receive events for hardware changes. | 10:51 |
| tvoss|lunch | RAOF, duflu ping | 10:51 |
| duflu | tvoss|lunch: pong | 10:51 |
| === tvoss|lunch is now known as tvoss_ | ||
| tvoss_ | duflu, RAOF I'm pretty sure the issue arises from the radeon kernel module giving up after some time | 10:52 |
| tvoss_ | duflu, RAOF at least on the daily release machine | 10:52 |
| duflu | tvoss_: Sounds like it. But I don't know why that would make the Mir socket code suddenly fail; message goes in one end and never received at the other | 10:53 |
| alan_g | alf__: thanks (the answer was quick enough - I haven't started on that bit yet) | 10:53 |
| tvoss_ | duflu, are we really sure that the message goes in? I'm unsure that that is the case | 10:53 |
| tvoss_ | duflu, plus: didrocks and me have seen some weird behavior for waitpid as well | 10:54 |
| tvoss_ | duflu, which hints towards a deeper issue somewhere | 10:54 |
| duflu | tvoss_: Yes, line 65: http://paste.ubuntu.com/5981035/ | 10:54 |
| duflu | tvoss_: waitpid?! | 10:54 |
| tvoss_ | duflu, not related to mir, but when compiz is started | 10:54 |
| tvoss_ | duflu, that only indicates that the request is sent @pastebin | 10:55 |
| duflu | tvoss_: Oh, yes, I gave didrocks a fix for that. | 10:55 |
| didrocks | duflu: a fix? | 10:55 |
| didrocks | duflu: you mean the unity_support_test? | 10:56 |
| didrocks | (to remove from compiz) | 10:56 |
| duflu | didrocks: Yes, externalizing the script | 10:56 |
| didrocks | duflu: already done for 2 weeks | 10:56 |
| didrocks | duflu: as pinged you back, didn't change a thing | 10:56 |
| duflu | didrocks: Cool | 10:56 |
| didrocks | so not what tvoss_ saw | 10:57 |
| duflu | didrocks: But that should also involve removing any waitpid call from compiz | 10:57 |
| didrocks | just told, the code which stuck on waitpid didn't invoke unity_support_test as we don't have the call anymore | 10:57 |
| duflu | tvoss_: didrocks says the waitpid call does not exist any more... ? | 10:58 |
| didrocks | duflu: I did say that we saw a waitpid | 10:58 |
| didrocks | but it's not on unity_support_test | 10:58 |
| duflu | Oh. Strange | 10:58 |
| didrocks | as this code is removed | 10:58 |
| tvoss_ | duflu, yeah, I think we are seeing symptoms of the kernel being in a weird state ... cannot prove that, though | 10:59 |
| duflu | I think it will take me some days yet to understand the Mir socket code. And it's not definitely clear that's the problem.... I'm debugging from heresay still | 11:00 |
| tvoss_ | duflu, I really don't think we have a problem there | 11:01 |
| tvoss_ | anyway, let's just make sure we keep releasing | 11:01 |
| duflu | OK, I'm out of ideas. The mind is fried and the stomach empty. Till next time... | 11:02 |
| RAOF | If anyone is in the mood for a review, https://code.launchpad.net/~raof/mir/fix-multi-surface-buffer-tracking/+merge/181259 | 11:04 |
| alan_g | RAOF: alf__ - I've a couple of MPs depending on place-surface-in-output - are you still discussing changes? Or can we land it? | 11:19 |
| alf__ | alan_g: RAOF: I am OK with it landing as is and changing the API again in a future MP (hopefully before the freeze). | 11:23 |
| alan_g | alf__: RAOF - then I'll top approve | 11:27 |
| === alan_g is now known as alan_g|afk | ||
| === hikiko|lunch is now known as hikiko | ||
| === alan_g|afk is now known as alan_g|lunch | ||
| smspillaz | hmm | 12:18 |
| smspillaz | mir seems to be sending mir_surface_hover_leave and mir_surface_hover_enter whenver a button is pressed or released respectively | 12:18 |
| smspillaz | is that a bug or a feature? | 12:19 |
| smspillaz | sending such events confuses gtk | 12:19 |
| smspillaz | (which think that the pointer is no longer over the surface once a button is pressed) | 12:19 |
| smspillaz | but we have to track enter and leave event to figure out which surface the pointer actually *is* over | 12:20 |
| smspillaz | s/leave/exit/ | 12:21 |
| === alan_g|lunch is now known as alan_g | ||
| alan_g | smspillaz: that sounds like a bug - but I'm surprised that RAOF hasn't come across it. | 12:54 |
| kgunn | tvoss_: you've got to be kidding... :-| | 12:58 |
| tvoss_ | kgunn, why is that? | 13:00 |
| kgunn | tvoss_: ati back... | 13:01 |
| tvoss_ | kgunn, well, didrocks and me have been looking into it for hours, it turns out rebooting the physical machine fixes it. I'm still inclined to push it towards the driver/kernel as we were seeing a massive slow-down even for vanilla x | 13:02 |
| didrocks | kgunn: look at the emails on ue-leads | 13:02 |
| kgunn | tvoss_: is that vanilla x (meaning w/o u-s-c ever being installed once ?) | 13:02 |
| kgunn | tvoss_: ack...will get coffee and read mail | 13:03 |
| tvoss_ | kgunn, yeah, all good, so have a coffee | 13:03 |
| kgunn | ;) | 13:03 |
| * kgunn won't really understand anything until he has coffee | 13:03 | |
| hikiko | alan_g: ping | 13:38 |
| alan_g | hikiko: how's it coming along? | 13:38 |
| hikiko | well, I have some issuesd | 13:38 |
| hikiko | I started from create_buffer_allocator which is the exception called right now | 13:39 |
| alan_g | yes? | 13:39 |
| hikiko | but it seems that I have to do more than this because atm if I run nested mir | 13:39 |
| hikiko | I | 13:39 |
| hikiko | "grab" | 13:39 |
| hikiko | the drm device | 13:40 |
| hikiko | and then even if I kill all mir instances | 13:40 |
| hikiko | I can't switch tty, go to X etc | 13:40 |
| hikiko | I can only reboot using ssh | 13:40 |
| hikiko | I guess I have to do some trick at the drm initialization but I am still looking at it | 13:42 |
| hikiko | if you have any ideas... | 13:42 |
| alan_g | hikiko: what did you do in the original spike? | 13:42 |
| hikiko | you mean the very first branch? | 13:43 |
| alan_g | I mean lp:~hikiko/mir/mir.nested-gbm | 13:44 |
| hikiko | I didn't have that problem there | 13:44 |
| hikiko | because the nested platform | 13:44 |
| katie_ | hi tvoss_ | 13:45 |
| alan_g | hikiko: are there not two issues? drm and keyboard input? | 13:45 |
| hikiko | wasn't dependant of the native gbm platform, it was implementing the Platform and it was just using the gbm buffers instead of the mir buffers | 13:45 |
| hikiko | I don't know alan_g | 13:46 |
| hikiko | I don't know how to debug actually because I don't have a tty, what do you do in a similar case? | 13:46 |
| hikiko | maybe I have to start gdb on a screen | 13:46 |
| hikiko | and grab it when I ssh | 13:46 |
| hikiko | resume* | 13:47 |
| alan_g | hikiko: you can stop the nested Mir grabbing input with "--enable-input off" (like it does in the test) | 13:47 |
| alan_g | That should avoid problems with VT switching | 13:49 |
| alan_g | I don't know what's needed for drm | 13:50 |
| tvoss_ | didrocks, got a daily-realease question fo ryou | 13:50 |
| hikiko | I'll try alan_g thanks | 13:50 |
| didrocks | tvoss_: sure | 13:50 |
| tvoss_ | didrocks, let's assume the platform api links in something like boost, then the symbols are picked up by the dh machinery, but I don't want to expose them ... what is the default approach? | 13:51 |
| didrocks | tvoss_: it's more a gcc question in fact :) normally the boost symbols are not exposed but your API | 13:52 |
| didrocks | you don't leak them, right? | 13:52 |
| tvoss_ | didrocks, nope, but they show up when compiling the package | 13:52 |
| alan_g | hikiko: why are you trying to run a nested mir and not using the test framework? | 13:53 |
| didrocks | tvoss_: do you use -fvisibility=hidden? | 13:53 |
| tvoss_ | didrocks, nope | 13:53 |
| tvoss_ | could do that ... | 13:53 |
| didrocks | tvoss_: there was a good gcc wiki page, hold on | 13:53 |
| didrocks | tvoss_: here is it: http://gcc.gnu.org/wiki/Visibility | 13:53 |
| hikiko | alan_g: --enable-input off didn't help | 13:54 |
| tvoss_ | didrocks, I know -fvisibility,will tackle in then in lp:~thomas-voss/platform-api/location-service | 13:54 |
| didrocks | great :) | 13:54 |
| hikiko | but ok I'll find something :) | 13:54 |
| alan_g | hikiko: The current "nested" code doesn't do anything with drm does it? This is something you're adding? | 13:57 |
| smspillaz | alan_g: tvoss_: know where I'd go to find the code responsible for sending button down events ? | 13:57 |
| tvoss_ | smspillaz, with you in a few ... | 13:58 |
| tvoss_ | smspillaz, you interested in the actual handover to clients? | 13:58 |
| smspillaz | tvoss_: just where button down events are generated in the server | 13:58 |
| smspillaz | I imagine that's probably where the problem I'm having lies | 13:58 |
| hikiko | alan_g: I think it does | 13:58 |
| smspillaz | tvoss_: context: the server sends surface_hover_enter and surface_hover_leave on button up / down events which tends to confuse gtk+ a lot | 13:59 |
| smspillaz | (because it thinks the pointer is no longer in the surface at the time of the button event) | 13:59 |
| tvoss_ | smspillaz, let me have a look | 13:59 |
| smspillaz | cheers | 14:00 |
| smspillaz | I'll keep poking around too, though I've not found anything yet | 14:00 |
| tvoss_ | cheers katie :) | 14:00 |
| hikiko | alan_g: http://bazaar.launchpad.net/~hikiko/mir/mir.create-buffer-allocator/revision/990 | 14:01 |
| hikiko | here is what I did | 14:01 |
| hikiko | to have it working | 14:01 |
| hikiko | so now it initializes the drm/gbm in the gbmplatform constructor | 14:01 |
| hikiko | what I can do is to pass an option in case we are nested and change <something I don't know yet> to not grab the devic | 14:02 |
| hikiko | e | 14:02 |
| alan_g | hikiko: This is code you've added. The current code doesn't do anything with drm. | 14:05 |
| alan_g | By including GBMPlatform in NativeGBMPlatform you're trying to be the host system | 14:06 |
| smspillaz | tvoss_: ah, I think the problem is in the android input stack | 14:06 |
| smspillaz | tvoss_: hover_enter/hover_exit doesn't really map completely to the traditional X11 EnterNotify/LeaveNotify | 14:07 |
| tvoss_ | smspillaz, that might well be, it is the entity doing the actuall processing | 14:07 |
| smspillaz | the latter is to do with the cursor position, the former is probably to do with the touch "clicking" state | 14:07 |
| tvoss_ | smspillaz, ah, got it: so hover_leave on button click actually makes sense | 14:07 |
| alan_g | hikiko: I don't think you should be implementing NativeGBMPlatform using GBMPlatform | 14:07 |
| smspillaz | tvoss_: except not for gtk+ ;-) | 14:08 |
| tvoss_ | smspillaz, as it actually leaves hovering state when clicking the button ... | 14:08 |
| hikiko | alan_g: the problem is that I cant use the enable_shared_from_this otherwise | 14:08 |
| hikiko | I have to either inherit Platform | 14:08 |
| hikiko | or GBMPlatform | 14:08 |
| smspillaz | tvoss_: are mouse events handled like touch events at the moment ? | 14:08 |
| tvoss_ | smspillaz, hmmm ... let me think ... so what you want is. hover_enter and then button_clicked? | 14:08 |
| tvoss_ | smspillaz, I'm pretty sure, yes | 14:08 |
| smspillaz | tvoss_: no, what I need is something similar to X11's EnterNotify/LeaveNotify | 14:09 |
| tvoss_ | smspillaz, we run qt with a special "translate touch to mouse events" | 14:09 |
| alan_g | enable_shared_from_this is evil - why would you want to use it? | 14:09 |
| smspillaz | which is generated whenever a cursor enters and leaves a surface (geometrically) | 14:09 |
| hikiko | because we have it in every create_buffer_allocator so I guessed that it does some sort of magic we need :) | 14:10 |
| hikiko | do you think I should remove it alan_g ? | 14:10 |
| tvoss_ | smspillaz, okay ... so you don't receive these events right now? or what is the actual problem? sorry, if I missed the description :/ | 14:10 |
| smspillaz | tvoss_: so at the moment in gtk+ I'm treating hover_enter/hover_exit as if it had exactly the same semantics as EnterNotify/LeaveNotify | 14:11 |
| smspillaz | eg, whenever some "input device" is hovering over a surface (in this case, the cursor) | 14:11 |
| alan_g | hikiko: Well, I've not looked in detail at that code - so it might be useful. | 14:11 |
| smspillaz | gtk+ uses that to determine which window the pointer is currently in side of | 14:11 |
| smspillaz | *inside of | 14:11 |
| smspillaz | on button press mir does something like | 14:11 |
| smspillaz | hover_exit -> button_down -> button_up -> hover_enter | 14:12 |
| smspillaz | which confuses gtk+ because by the time it gets button_down it thinks there is no longer a cursor in the surface | 14:12 |
| smspillaz | (arguably, this is something stupid about gtk+ and I had to work around it in compiz too for a different reason) | 14:12 |
| tvoss_ | smspillaz, okay, so I think it is actually correct to send hover_exit in case of a button click ... as it really indicates that the hover state ended ;) | 14:13 |
| hikiko | alan_g: no prob I ll try a few tricks and tell yu if I made any progress at the meeting | 14:13 |
| alan_g | But, even if it is needed, I don't see why you'd use the GBMPlatform implementation. As I said yesterday, copy the code you need from there and we can refactor later. | 14:13 |
| tvoss_ | smspillaz, for a work-around: why not ignore hover_exit? | 14:13 |
| smspillaz | tvoss_: I can't | 14:13 |
| smspillaz | tvoss_: gtk+ needs that in order to determine when a cursor is no longer inside a surface | 14:14 |
| smspillaz | well ... I'll revise that statement. Maybe I can just ignore hover_exit. But I'm not so sure what it'll break subtly | 14:14 |
| alan_g | hikiko: this is what kills your VT switching: 216 auto vt = std::make_shared<mgg::LinuxVirtualTerminal>(real_fops, options->get("vt", 0), report); | 14:15 |
| tvoss_ | smspillaz, hmm, I'm thinking, that means you only want to pass on LeaveNotify to gtk iff hover_exit has happened and a subsequent event is not button clicked, right? | 14:15 |
| hikiko | alan_g: then I need to have the Platform | 14:15 |
| smspillaz | tvoss_: yes (although implementing it like that would be very clunky) | 14:16 |
| tvoss_ | smspillaz, agreed | 14:16 |
| smspillaz | tvoss_: what I really need is for the server to send me something like EnterNotify and LeaveNotify, and only when the actual cursor itself goes into and out of a surface (geometrically) | 14:16 |
| alan_g | hikiko: only because GBMBufferAllocator isn't quite as you need it | 14:17 |
| smspillaz | tvoss_: though I think the broader problem here is that pointer input and touch input are amalgamated into a "motion" concept and it doesn't really work all that well | 14:17 |
| smspillaz | (which was probably inherented from android) | 14:18 |
| alan_g | hikiko: AFAICS all it really needs is a GBMDevice - but it takes a std::shared_ptr<GBMPlatform> to have access to it | 14:18 |
| hikiko | then I have to do it exactly like in the first spike (there wasnt vt etc there) | 14:19 |
| hikiko | but in that case | 14:20 |
| hikiko | I still need to have a public Platform | 14:20 |
| alan_g | hikiko: Could you check that GBMBufferAllocator doesn't really need the GBMPlatform? And if I'm right MP a change that just gives it the device? | 14:20 |
| alan_g | Why do you need a public Platform? | 14:21 |
| hikiko | it doesnt | 14:21 |
| hikiko | alan_g: only to use enable_shared_from_this | 14:21 |
| hikiko | if we don't need it | 14:21 |
| hikiko | then I don | 14:21 |
| hikiko | t need the platform | 14:22 |
| alan_g | hikiko: If you can first change GBMBufferAllocator to just take the device then the rest becomes easy. | 14:23 |
| tvoss_ | smspillaz, I have put it on the list | 14:24 |
| hikiko | that shouldn't be difficult alan_g I ll try | 14:24 |
| alan_g | hikiko: If GBMBufferAllocator doesn't really need the GBMPlatform MP a change that just gives it the device. | 14:25 |
| smspillaz | tvoss_: cheers :) | 14:25 |
| hikiko | alan_g it doesn't I didn't use the GBMPlatform in my first branch | 14:26 |
| hikiko | so, I will try it | 14:26 |
| alan_g | hikiko: :) | 14:27 |
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| ricmm | tvoss_: | 15:02 |
| tvoss_ | ricmm, ? | 15:03 |
| ricmm | alan_g: greyback | 15:03 |
| ricmm | we believe there is a problem with commit 982, it breaks some behaviour we were using before | 15:03 |
| ricmm | two issues: | 15:03 |
| ricmm | 1. the_input_configurator() is called many times in the_surface_stack_model() before we hold a ref to it in displayServer | 15:03 |
| ricmm | this results in many objects, and a wrong input initialization later due to that | 15:04 |
| hikiko | bye people :) | 15:04 |
| ricmm | http://paste.ubuntu.com/6008216/ sorts that issue, with help from racarr | 15:04 |
| ricmm | 2. client apps stopped working in our shell after 982, the we were failing to create a eglSurfaceWindow on the nativeWindow returned by mir | 15:05 |
| ricmm | moving the_graphics_platform() around shows breakage in the creation of native windows, makes me think we are perhaps hitting a similar thing as with the input configurator? spurious instantiations | 15:06 |
| ricmm | and therefore different objects used to create other configs, in contrast with the one stored in the DisplayServer itself | 15:06 |
| ricmm | we create stuff in this order in unity-mir http://paste.ubuntu.com/6010579/ | 15:07 |
| ricmm | both the stack() and the builder() poke into the_graphics_platform() before it has been stored in the DisplayServer, perhaps theres a hole there somewhere | 15:08 |
| ricmm | ok thats it :) ping me when you are around | 15:08 |
| alan_g | ricmm: looking... | 15:15 |
| alan_g | ricmm: OK, so the problem stems from your ShellServerConfiguration holding state for itself rather than reacting as a builder for DisplayServer. Which means that it relies on the DefaultServerConfiguration holding state. | 15:23 |
| alan_g | And -c 982 broke that assumption | 15:24 |
| ricmm | so, not hold refs to anything but instead dynamically return out objects in the overriden methods? | 15:26 |
| ricmm | our* | 15:26 |
| ricmm | alan_g: maybe this is right for the_graphics_platform(), but is it also right for the_surface_stack_model()? the spurious objects are only valid within the lambda's context | 15:27 |
| ricmm | it happens even if I dont manually call into it | 15:27 |
| ricmm | so perhaps that one does need to hold an internal ref to *one* the_input_configuration() | 15:28 |
| alan_g | ricmm: If that makes sense in the rest of your code. Otherwise, you could hold your own std::shared_ptr<input::InputConfiguration> input_configuration; | 15:28 |
| greyback | alan_g: in order to use Qt signal/slot mechanism, the receiver needs a pointer to the object emitting the signal. I don't see how I can get that through this design | 15:29 |
| alan_g | The way DefaultServerConfiguration works is that it keeps a weak pointer to objects it constructs - so if anyone is holding them the same one is returned | 15:29 |
| alan_g | But if no-one holds it then it can be destoyed. | 15:30 |
| alan_g | greyback: I understand that you need to control object lifetime - it is just that DefaultServerConfiguration shouldn't have been doing that. | 15:32 |
| ricmm | alan_g: so a quick solution would be to store std::shared_ptr<> for the_graphics_platform() | 15:34 |
| alan_g | I'd guess that the minimal fix would be to have a std::shared_ptr<input::InputConfiguration> input_configuration; member in ShellServerConfiguration and initialize it first. But that would extend its life beyond that of the server object (which can also cause problems). | 15:35 |
| ricmm | and that should ensure consistency in the ones returned across all config and then in the DisplayServer builder | 15:35 |
| ricmm | right, for the input_config I was using the ref internal to the_input_configuration() lambda | 15:35 |
| ricmm | but it should be the same result | 15:36 |
| alan_g | Oops I meant virtual std::shared_ptr<graphics::Platform> graphics_platform; | 15:36 |
| alan_g | ricmm: yeah, but that one goes out of scope - so if nothing holds it... | 15:37 |
| ricmm | true, but for some reason it works | 15:37 |
| ricmm | I'll try holding both objects | 15:38 |
| ricmm | how dangerous is it to hold these beyond the lifetime of the DisplayServer object? | 15:38 |
| ricmm | I dont think we do any direct access to them | 15:38 |
| ricmm | only during construction of the config, so should be fine | 15:38 |
| ricmm | will use the config methods to get the objects anyways, not really our refs | 15:39 |
| ricmm | greyback: sounds good for a try? | 15:39 |
| alan_g | ricmm: I was finding problems when an exception was propagated from the DisplayServer constructor. | 15:39 |
| greyback | alan_g: so objects constructed by DefaultServerConfiguration can be destroyed at any time. Can those objects be created & destroyed repeatedly? | 15:39 |
| greyback | ricmm: should do yes. | 15:40 |
| ricmm | I think they wont be destroyed *before* the DisplayServer's life ends | 15:40 |
| ricmm | as long as we hold the refs | 15:40 |
| alan_g | greyback: What should be happening is they exist for as long as the DisplayServer is using them | 15:40 |
| ricmm | after, I dont know. but we dont really need any direct access on input_config and graphics_plat | 15:40 |
| ricmm | I think the question here is does the DisplayServer exist until the compositor/server process dies? | 15:42 |
| alan_g | But before -c 982 the input_configuration was held on the configuration object instead | 15:42 |
| greyback | ricmm: exactly my question | 15:42 |
| alan_g | When the DisplayServer is destroyed everything should be closed down | 15:43 |
| alan_g | (But you could write a program that then created a new one) | 15:43 |
| tsdgeos | ricmm: when you have a minute i have a question regarding how/where to wrap url-dispatcher in platform api. I'll be eod'ing soon though, so maybe you prefer me to send an email? | 15:43 |
| ricmm | alan_g: sounds good enough for a normal shell | 15:47 |
| ricmm | tsdgeos: please send an email, sorry if I'm unresponsive | 15:47 |
| ricmm | really busy | 15:47 |
| tsdgeos | ricmm: ok, will do | 15:47 |
| ricmm | thanks | 15:47 |
| tsdgeos | ricmm: also commented on your unity-mir MR | 15:48 |
| tsdgeos | ricmm: there's a few nitpicks you are free to ignore, but the singleshot signal seemed a bit dangerous | 15:48 |
| tsdgeos | s/signal/timer | 15:48 |
| alan_g | ricmm: have you got what you need? (For now) | 15:49 |
| ricmm | looks like, we'll do a test and let you know | 15:50 |
| ricmm | alan_g: thanks for the help | 15:50 |
| alan_g | sorry for breaking your code | 15:50 |
| smspillaz | does mir have an inbuilt screenshot functionality? | 16:06 |
| smspillaz | eg, a keybinding to dump an image to the disk? | 16:06 |
| greyback | smspillaz: it has API for screenshotting, not tied into anything tho | 16:08 |
| smspillaz | lol | 16:08 |
| === chihchun is now known as chihchun_afk | ||
| olli | kgunn, alan_g do you guys know if the fix for input showing up on VTs has hit trunk yet? (iirc it's the switch branch) | 16:47 |
| olli | tvoss_, ^ | 16:47 |
| alan_g | olli: the switch branch has landed. Do you have a bug id? | 16:48 |
| olli | alan_g, xubuntu is just curious if it's in archive yet | 16:48 |
| olli | alan_g, is that part of the 0.0.9+13.10.20130821-0ubuntu1 release from today | 16:48 |
| racarr | Morning | 16:54 |
| alan_g | olli: switch was in -c 948 - today's release was 989. But I don't know if it has anything to do with input on VTs | 16:54 |
| olli | alan_g, ok, so maybe I am wrong | 16:55 |
| olli | let me rephrase | 16:55 |
| olli | do we still see input on VTs in todays release or is that fixed meanwhile | 16:55 |
| alan_g | olli: I can't find the bug you mean, I don't know if it is fixed | 16:58 |
| olli | alan_g, ok, don't have a bug id | 16:58 |
| olli | was one of the prominent ones... where a password entered in U7 would show up in clear text on VT | 16:59 |
| olli | password and other text | 16:59 |
| kgunn | olli: i saw it 100% before...i think it got fixed early last week...let me test (after our meeting :) | 17:00 |
| racarr | I think the same thing but don't have time to test at this exact instantg | 17:00 |
| === alan_g is now known as alan_g|EOD | ||
| forestpiskie | olli: this is what I'm seeing - not that bug http://imgur.com/cPAmyNC,irF8k6K,DCfJ9j0#0 | 17:07 |
| forestpiskie | olli - forestpiskie is elfy | 17:07 |
| olli | forestpiskie, ack | 17:08 |
| olli | kgunn, tvoss_^ | 17:08 |
| racarr | So what's going on with n4? | 17:09 |
| racarr | olli: Do you still need someone to test this VT input thing? | 17:19 |
| olli | racarr, no | 17:20 |
| racarr | Oh :p | 17:21 |
| racarr | well I did anyway it's totally fixed | 17:21 |
| robert_ancell | racarr, Just waiting on duflu for https://code.launchpad.net/~robertcarr/mir/client-focus-notifications/+merge/180903? | 20:35 |
| robert_ancell | I asked alf yesterday, so if he hasn't said anything to you I think we take him as abstain | 20:37 |
| racarr | robert_ancell: He is only listed as pending because | 20:44 |
| racarr | he reviewed it like a month ago | 20:44 |
| racarr | and it was resubmitted | 20:44 |
| racarr | ...4 times | 20:44 |
| robert_ancell | racarr, do you know if duflu has any remaining concerns? Otherwise you should just land it | 20:44 |
| racarr | robert_ancell: I don't know. | 20:49 |
| racarr | I think there are some things he doesn't like which range from "unclear to adress" to "likely to lead to more needs fixing from Alan" :p | 20:49 |
| racarr | robert_ancell: I'm landing it :p | 20:51 |
| thomi | robert_ancell: the upstream-merger changes you requested were deployed earlier today, just FYI | 22:02 |
| robert_ancell | thomi, awesome, thanks | 22:02 |
| robert_ancell | thomi, I notice there's a u-s-c raring build from 47 mins ago - was that change missed or did it happen just after that build? | 22:03 |
| robert_ancell | https://launchpad.net/~mir-team/+archive/staging | 22:03 |
| thomi | robert_ancell: that shouldn't have happenbed, WTF is going on !? | 22:03 |
| thomi | robert_ancell: ahhhh, I see | 22:05 |
| thomi | it's landing from a totally different stack | 22:05 |
| thomi | I'll talk to Francis about that now | 22:05 |
| thomi | robert_ancell: we still want it built, but just for saucy, right? | 22:08 |
| robert_ancell | thomi, yes | 22:08 |
| thomi | robert_ancell: ok, config change made: https://code.launchpad.net/~thomir/cupstream2distro-config/u-s-c-saucy/+merge/181420 | 22:11 |
| robert_ancell | thomi, thanks! | 22:12 |
| thomi | any time | 22:12 |
| robert_ancell | racarr, did you notice the autolanding failed for the client focus notification branch? | 22:18 |
| thomi | robert_ancell: change deployed, shouldn't get any more darn raring builds | 22:18 |
| robert_ancell | RAOF, are you still working on that fd MP for mir? | 22:58 |
| RAOF | robert_ancell: Yeah; looks like it failed jenkins. | 22:59 |
| robert_ancell | RAOF, which branch? lp:~raof/mir/fix-multi-surface-buffer-tracking? | 23:00 |
| RAOF | robert_ancell: Yeah, that one. | 23:05 |
| === mhall119_ is now known as mhall119 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!