[00:00] robert_ancell: OK, cool. I'm kind of here, kind of not, depending on how long this coffee keeps me awake [00:10] thomi, :) [00:10] ricmm, I'm trying to manually get mir out of proposed - it seems to be in a deadlock due to some build ordering issues [00:22] robert_ancell: I don't see that corruption on ati with mir from -proposed (and usc built against that mir) === chihchun_afk is now known as chihchun [01:06] robert_ancell: awesome, thaks [01:06] lemme know how that goes [01:10] ricmm, packages are built, just waiting for the job that migrates them from -proposed to universe [01:11] \o/ [01:23] ricmm, seems to have worked, I'm upgrading now and pulling in the new versions [01:23] great! [01:49] duflu, have you tested bypass on an ati machine? [01:50] robert_ancell: No, it proved impossible. Multiple kernel bugs prevent me from being able to. Alf tested it for me [01:50] duflu, it's failing in the lab [01:50] we've set up ppa:mir-team/qa-testing to just contain bypass, then you can run it in the lab and watch the screen there [01:50] has lots of corruption [01:50] robert_ancell: Hmm. OK. I was relying on Alexandros' testing. Got kernel 3.11.0+? [01:51] the main archive version works [01:51] duflu, I don't think I can check until the test completes [01:51] thomi, (if still awake) is that true? [01:51] robert_ancell: Because corruption is expected. You need the "DMA-buf" fix wherever that was... in kernel 3.11 [01:51] robert_ancell: Im still awake [01:52] robert_ancell: you should be able to ssh in to the machine while the test is running [01:52] robert_ancell: To clarify... I have radeon hardware, but can't test saucy due to saucy being unbootable on my desktop (regardless of graphics) [01:52] robert_ancell: obviously you run the risk of affecting the result, but if all you need to do is check package versions it should be OK [01:53] duflu, it's running saucy right now and seems to work [01:53] robert_ancell: oh, also, the machine may reboot under you :) [01:53] IP addresses are all on the wiki, in case you need them [01:53] thomi, ta [01:53] duflu, so the dma-buf fix is required only for bypass? [01:54] robert_ancell: Seems so. Because I can test raring and it fails there. alf said it worked for him on saucy+radeon. [01:54] duflu, do you have a bug number? [01:55] robert_ancell: We're not also testing XMir at the same time are we? XMir adds new bugs which we would have to exclude [01:55] duflu, yes, with xmir [01:55] robert_ancell: I wish I had a bug number, or a commit to point to. All anyone has been able to tell me is "you need kernel 3.11". Which seems true for nouveau too [01:56] duflu, but saucy is kernel 3.11 [01:56] I've also tried kernel 3.11 on raring but ran into other graphics bugs before I could test Mir [01:57] robert_ancell: It would be unproductive to debug XMir+radeon+bypass right now. I need someone to test just radeon+bypass [01:57] I'm already in the boat of having too many variables at once with another bug [01:57] duflu, ok, to be clear. On one of the QA ATI boxes running standard saucy + xmir enabled it works fine, but standard saucy + lp:~vanvugt/mir/bypass + xmir does not [01:57] so this is only one variable... [01:58] robert_ancell: Not true. We've spent the past few days finding and fixing XMir bugs only revealed by new Mir features (which themselves are bug free) [01:59] Maybe we have working saucy images I can boot now. Will retry today [02:00] thomi, what is the wiki link [02:06] robert_ancell: https://wiki.canonical.com/UbuntuEngineering/QA/Lab [02:43] robert_ancell: is the failure in the mode of the funky stripes? or black screen ? [02:44] kgunn, looks like just the funky stripes - the test completed otherwise [02:45] robert_ancell: that is strange as it keeps changing [02:45] kgunn, I'm just running saucy without XMir for completeness so we are sure we're comparing apples with apples [02:45] yeah [02:45] this remote camera is awesome :) [02:45] robert_ancell: so what i'm looking at right now is saucy X [02:46] ? [02:46] well...then... [02:46] kgunn, you were looking at saucy + XMir+bypass [02:46] oh [02:46] it is awesome [02:46] our mir packages were all out of date - there was some deadlock in the autolanding system [02:47] They're up to date now, so running the three cases with these packages [03:18] robert_ancell: i stepped away...did it run yet? [03:19] kgunn, yes, just collecting the results [03:22] kgunn, emailed you the results [03:23] kgunn, what were you looking for? [03:36] robert_ancell: The radeon issue, looks like vertical stripes right? [03:36] duflu, there's a link to an image in the MP [03:36] If that means incorrect pixel format then I have a reasonable theory as to the cause. But haven't been able to reproduce any such issue yet [03:37] duflu, that QA machine is at your disposal :) [03:37] robert_ancell, OK. I was hoping to not have to invest the time setting up VPNs etc :/ [03:38] duflu, I recommend getting the QA VPN set up - it makes life easier [03:38] thomi, asleep yet? [03:38] I used to... before reinstalling [03:40] robert_ancell: Shall I remove the prereq of bypass for timerless? [03:40] Just means bypass will conflict for a while [03:40] duflu, sounds like a good idea [03:46] Bypass breaks intel XMir too, even single head. [03:47] robert_ancell: asleep at my desk, does that count? [03:48] RAOF, is it the mir side or the xmir side? [03:48] duflu, do you have all the info for the VPN? [03:48] robert_ancell: No idea. And now I'm a couple of hours from trying :/ [03:49] thomi, can you send any links info to duflu about setting up the QA VPN [03:49] sure, let me see where I can find it [03:50] duflu: robert_ancell: https://wiki.canonical.com/InformationInfrastructure/IS/VPN [03:50] worth noting that it's not so much a 'QA VPN' as a 'Canonical VPN' [03:50] robert_ancell: Possibly a combination of the two [03:51] my understanding is that almost everyone who was in the old PS dept. should have an email in their inbox with their private key [03:52] otherwise, IS can send you new keys, or help you get it set up [03:53] I may get more value sooner by trying to find a way to boot saucy on my desktop (where I have radeon). Haven't succeeded yet but it's worth another try [03:54] duflu: otherwise, I may be able to give you SSH access to my radeon laptop, although it will be slow [03:54] thomi: If that blurry screenshot is to be trusted then it looks like vertical lines? That one I might have a clue about already [03:55] duflu: uhh, I'm not sure what screenshot you refer to [03:56] http://imgur.com/1k7tQE5 [03:56] oh [03:56] ok, well, let me know if you need annything [03:56] although for VPN-related things, IS is probably a better bet :) [04:06] robert_ancell: i don't understand how those results can be like that... [04:07] the thing that's supposed to be the crappiest is the best ? [04:10] kgunn, yeah... [04:10] kgunn, please double check the results but I *think* it was run correctly [04:11] bob [04:11] beLUmaya [04:11] DISPLAY=:0 xev [04:24] duflu, ping [04:26] RAOF, ping [04:26] tvoss: Pong. [04:27] tvoss, pong [04:27] mlankhorst: Oooh, you're awake? [04:27] RAOF, I notice X doesn't drop focus when you VT switch away - do you think this should be a system compositor special option? [04:28] Hm, I don't know. [04:28] I don't think it makes a huge amount of difference either way. [04:28] But a client really isn't focused if it doesn't display or get input. [04:38] robert_ancell, RAOF the benchmarking results for radeon seem to suggest that X touching the framebuffer makes things slower? [04:38] duflu, kgunn ^ [04:39] I've forwarded them to duflu and RAOF [04:39] Does it render correctly? [04:39] robert_ancell, ? [04:40] RAOF, not with bypass [04:40] I'm not sure that we should trust the benchmark numbers then. [04:41] RAOF, true [04:42] I know that software rendering + bypass is often slower. Which is why bypass is disabled for software surfaces [04:52] RAOF: If XMir does any "copies" it's really a software renderer then... ? [04:52] And it's lying to Mir in saying this is a hardware surface? [04:53] I remember a while back I said we should distinguish between "hardware" buffer residency and hardware blitting, but my suggestion was rejected :/ [04:54] * duflu *shrugs* and goes to lunch [04:59] duflu: It's does hardware blitting, from hardware-rendered other buffers. [05:00] duflu: It's as much a hardware surface as any EGL app. [05:27] RAOF, duflu back [05:31] RAOF: OK. Though this "copy" I keep hearing about, is that on the CPU? What stage is it? [05:32] duflu: It's on the GPU; X is basically acting as a compositor. [05:32] Except rather than going through GL, it's speaking raw GPU command streams. [05:33] RAOF: Sounds fast. I guess if it actually was software copying I would not see the nice reduction in mouse lag with qa-testing(bypass) [05:33] As far as Mir is concerned, though, it's not different than an EGL client. The difference between X and and EGL client is an EGL client has the mesa library to produce the command streams. [05:34] RAOF: Oh, BTW, any idea why single-buffering desktop environments would *not* exhibit the frame ordering bug? [05:35] No, and are you certain that they don't? Last time I checked I could get the frame-ordering problem on raw X + xterm. [05:35] But I guess that was a while ago. [05:37] RAOF: Almost certain. I could not get it to happen with Compiz doing single buffering, or plain Xfce [05:37] RAOF, can we disable buffer age in X? [05:37] tvoss: Yes, but it doesn't help. [05:37] RAOF, ah [05:37] But that could be timing too... single buffer damage-only updates are faster [05:38] I have tried making intentionally slow clients, but didn't reproduce it that way [05:39] RAOF, duflu so trying to understand: somewhere the buffer order inside X gets fucked up, and n+1 is submitted before n [05:40] It looks like it. I still can't reproduce it with any demo client, no matter how I try to change variables [05:40] I don't believe that is the case - smspillaz was seeing the same problem with his GTK implementation, and he dumped the frames to disc before submitting them and they were correct. [05:40] tvoss: ^^^ [05:41] RAOF: No, Sam reported lag only, not buffer misordering. Hence it's still a separate bug. Also that was fixed by ignoring buffer age [05:41] Huh, I thought he'd tried that and it didn't work. [05:41] I'm clearly not up on that bug. [05:41] smspillaz, ping [05:42] I have other theories as to where bad ordering could come from. But I will have to learn new Mir code I've never really looked at [05:42] duflu, which one? how can I help? [05:42] tvoss: pong, but I gotta go soon [05:43] smspillaz, quick x-check: ignoring buffer age in your gtk port fixed the lag? [05:43] duflu: I'm not so sure if that was "fixed" by ignoring buffer age [05:43] at least - I didn't see it when I did full repaints but it appears to be a race condition [05:43] and furthermore, the symptoms I'm seeing are not consistent with incorrect buffer ages being sent [05:44] I'd suggest running the gtk demo to see if you can reproduce it on your end [05:44] duflu, sounds like a simpler client than X [05:44] smspillaz: Yes, sorry, bad choice of words. But at least "worked around" by not using the buffer age [05:44] tvoss: Different bug [05:44] Hence not a valid test case [05:46] duflu, ack [05:46] We have at least three lag/ordering bugs and they are all most definitely separate. It takes careful analysis to know they're different tho [05:46] duflu: like I said, I'm not sure that not using buffer age would actually fix it [05:46] it just seems that here it does not trigger that race [05:47] duflu, so for the ordering bug: do we have a frame counter per surface? [05:47] tvoss: No, we have a unique ID you can track tho [05:48] duflu, how do we know it's an ordering bug then and not an unfinished rendering? [05:48] tvoss: mir_debug_surface_current_buffer_id should be sufficient [05:48] tvoss: Unfinished rendering *usually* appears as tearing [05:48] But it could also be related to a missing flush/finish or equivalent [05:49] duflu, true, but we are making an assumption here, and at such high frame rates, I would actually want to make sure that it is really ordering :) [05:49] tvoss: Well, we have tests for it already in lp:mir. You could also ask the client to check the order it's getting, with mir_debug_surface_current_buffer_id [05:50] Of course, tests are never foolproof [05:50] That's how I tracked down the ordering problem last time; by dumping the surface ID all over the place. [05:50] RAOF: That was a while ago... we fixed that one right? [05:51] Yeah. [05:52] At least for single outputs and clients with single surfaces :) [05:52] But I don't think that code cared where the buffer came from. [05:52] I have had more theories as to how order might be violated. However can't yet find any theoretical reason why it would be in the buffer swapper. That part is now designed to make ordering theoretically guaranteed [05:53] We might be racing/messing up in the protocol/threading somewhere though [05:53] ... but if it was that easy then you'd think some mir_demo_client could show a similar bug. [05:54] Maybe? [05:55] I think we might want to write a one-surface-per-output version of progressbar that uses GL rather than CPU mapping. [05:56] RAOF: egltriangle should be sufficient. Just need to add a parameter to populate output_id methinks [05:57] RAOF: I also keep thinking if your surfaces usually only map to one monitor each, then only one compositor thread should be getting each surface. It should behave like single monitor... unless we've messed up the region calculation [05:57] RAOF, duflu, kgunn, racarr|desert, hikiko, tvoss, thomi, meeting time... [05:58] omw [05:59] robert_ancell, not on broadband, will try to join, though [06:00] ugh, RAGE! [06:00] stupid technology [06:00] duflu, do we see the ordering issue only on multi-monitor or also on single output? [06:01] robert_ancell: can someone link me the hangout url please? It's now showing up in my calendar [06:01] tvoss: Multimonitor only [06:01] duflu, my understanding: it's trunk + bypass exposing it when used with XMir? [06:02] tvoss: No, multimonitor only. And even without bypass [06:03] duflu, ah, that helps a lot [06:03] tvoss: It happens on qa-testing2 (no bypass) [06:05] duflu, ack. So to land bypass, we need to check the weird ati numbers [06:08] tvoss: And corruption [06:08] tvoss: I will be in a better state to test and fix when I can boot saucy on my desktop. Which I cannot yet :( [06:11] duflu, ack, what is blocking you from booting saucy on your desktop? [06:12] tvoss: Kernel/BIOS issues new in saucy. Cannot even start to boot it [06:12] robert_ancell, which ppa did you use to run the openarena benchmarks? qa-testing? [06:12] duflu, got a bug report? [06:12] tvoss, ye [06:12] s [06:12] tvoss: https://bugs.launchpad.net/bugs/1212977 [06:12] Launchpad bug 1212977 in linux (Ubuntu) "saucy daily-live images are unbootable on Dell Optiplex 990; stuck in BusyBox shell" [High,Incomplete] [06:13] duflu, thx [06:13] RAOF: yeah [06:13] RAOF: did you get my message and video? :P [06:13] mlankhorst: Yes [06:14] ah good [06:14] mlankhorst: I had a couple of questions. Mainly - is that pixmap the screen pixmap? [06:14] no idea, considering the code it was from i would assume so :P [06:22] tvoss: xorg-server is unmodified for bypass right? [06:22] robert_ancell, mir/archive should be unblcoked [06:23] mlankhorst, ack [06:23] olli, yeah, it was another issue, fixed now [06:23] ok [06:24] mlankhorst: gdb and print out (screen->GetScreenPixmap)(screen)? [06:25] RAOF: oh right it might be very much possible that it switches the front buffer in fullscreen gl case [06:25] tvoss: hm interesting noise pattern :P [06:25] could anyone review this branch: https://code.launchpad.net/~hikiko/mir/mir.native-gbm-platform-class/+merge/182074 ? [06:25] I can vaguely make out the details [06:26] tiling or pixel format is messed up [06:26] mlankhorst: And I've just noticed that nouveau *does* keep a track of what it thinks is the front buffer that is wrong as soon as xmir_resize hits... [06:26] RAOF: hah! [06:26] later all [06:26] SetScreenPixmap hooks for everybody! [06:26] robert_ancell: 'night! [06:26] bye robert_ancell [06:27] Also, I really really really really hate the way xf86-video-ati has an open coded "set up this radeon_surface" struct in like 2032232332342342 different places. [06:27] That's right. There are more copies of that code than there are lines of code. [06:27] tvoss: actually on closer look it looks like there are vertical lines that look correct, 4 pixels? then another vertical line with garbage [06:27] It's very quantum. [06:27] so dno [06:28] * RAOF goes and get groceries for dinner. [06:28] RAOF: welcome to radeon ;) [06:28] RAOF: don't look at the kernel! [06:28] it has 5 copies of 'is this command ring working' [06:28] one for each ring [06:30] duflu, did you see mlankhorst's findings? [06:30] afk [06:30] duflu, ack [06:31] nothing in dmesg this time [06:31] mlankhorst, can you check with a mir demo client if the corruption shows up with that? [06:33] mlankhorst, you can use lp:~thomas-voss/glmark2/mir-no-deprecated-functions and run it in fullscreen [06:33] hm crash on eglplasma :P [06:33] hah [06:34] http://paste.debian.net/31210/ [06:34] that's the eglplasma thing crashing, i think usc went too [06:34] mlankhorst, thx [06:34] mlankhorst, can you verify that usc did really crash? [06:35] Program received signal SIGABRT, Aborted. [06:35] [Switching to Thread 0x7f165cafe700 (LWP 2149)] [06:35] 0x00007f1669126f77 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 [06:35] 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: Bestand of map bestaat niet. [06:36] http://paste.debian.net/31211/ [06:37] lol, crashes on closing egltriangle too [06:37] but the triangle looks fine, fwiw [06:38] mlankhorst, okay, thanks for the hints [06:38] back to the drawing board for you? :P I'm going to test for raof a bit [06:39] mlankhorst, ack, calling some people to get an amd machine now [06:41] mlankhorst, okay, I'm mostly interested in the corruption right now [06:49] tvoss: oh I'm still on mesa 9.2 fwiw [06:50] mlankhorst, mind switching to default saucy? [06:51] Sorry... had to get a quick fix for my leaky roof. Done I think [06:52] tvoss: What am I looking at? [06:52] tvoss: actually I do, need to finish testing on that first :P [06:52] but fine [06:54] mlankhorst: Yes I suspect the vertical lines might just be the drm fb using the wrong pixel format to the attached bo [06:55] Since we don't actually set it yet... [06:56] mlankhorst: Also, compiz _will_ switch front buffers, when it decides a fullscreen window can be "unredirected" [06:56] that probably sounds about right :P [06:58] tvoss: "did you see mlankhorst's findings?" .... where? [06:59] actually it looks like even worse garbage on 9.1.6 :P [06:59] might just be freed memory being displayed [07:00] hm then again it looks too much like what should be displayed, so i dont know [07:00] but there's definitely some garbage on top of it [07:01] mlankhorst, sounds like what I saw with radeon doing bypass on raring. Still could never test saucy [07:11] duflu, where would we need to set the pixel format? [07:12] tvoss: DRM calls. I will put together an attempt momentarily... which I have done before but never found a need to modify that code till now [07:12] I mean, it's something I've tried before but never found a system where it was necessary, yet [07:13] $6 = {drawable = {type = 1 '\001', class = 0 '\000', depth = 24 '\030', bitsPerPixel = 32 ' ', id = 0, x = 0, y = 0, width = 2720, height = 1024, pScreen = 0x7f92f1e1b700, serialNumber = 2589}, [07:13] devPrivates = 0x7f92f264ef38, refcnt = 1, devKind = 10880, devPrivate = {ptr = 0x0, val = 0, uval = 0, fptr = 0x0}, screen_x = 0, screen_y = 0, usage_hint = 2, master_pixmap = 0x0} [07:13] RAOF: screen pixmap^ [07:13] but the pixmap the function is called with is this [07:13] $7 = {drawable = {type = 1 '\001', class = 0 '\000', depth = 24 '\030', bitsPerPixel = 32 ' ', id = 0, x = 0, y = 0, width = 1280, height = 1024, pScreen = 0x7f92f1e1b700, serialNumber = 2124}, [07:13] duflu, ack [07:13] devPrivates = 0x7f92f1e8aca8, refcnt = 1, devKind = 5120, devPrivate = {ptr = 0x0, val = 0, uval = 0, fptr = 0x0}, screen_x = 0, screen_y = 0, usage_hint = 0, master_pixmap = 0x0} [07:16] mlankhorst: Thanks. [07:21] Silly question... "DMAbuf" I've never seen explicitly mentioned. Is it part of how we use drmModeAddFB ? [07:22] No. [07:22] dma-buf is our buffer IPC mechanism. [07:23] We go from a gem name (for use in drmModeAddFB et al) to a dma-buf fd and back. [07:25] RAOF: Umm, kay. So it is correct to pass in gbm_bo_get_handle(bo).u32 (the "gem" handle?) to AddFB? [07:25] Obviously it works for intel+nouveau... [07:26] Yup, that would be the right thing. [07:30] It's really confusing when people talk about "gem" this and that, even in naming variables, but "gem" isn't mentioned in the API at all. It's just uint32_t [07:31] duflu, sounds like we should have a wrapper for that then :) [07:31] * tvoss restarts [07:31] tvoss: Not Mir's fault. Just DRM... undocumented [07:31] duflu, ack [07:34] someone could check my two MP:s to get trunks in sync with the archive rebuilds https://code.launchpad.net/~timo-jyrinki/unity-mir/sync_to_archive/+merge/182553 + https://code.launchpad.net/~timo-jyrinki/unity-system-compositor/sync_to_archive/+merge/182554 [07:35] duflu: yeah gem predates dma-buf, fd's were too expensive at the time :P [07:35] not sure why robert changed that architecture line in a 'no change' rebuild, but it seems fine [07:37] duflu, is the bypass branch in sync with trunk? [07:37] mlankhorst: Fun story: randr resizes don't fix up the root window pixmap. [07:37] tvoss: Not sure about the LP one, but there have been no conflicts or logic changes since 14 Aug [07:37] tvoss: I'm working on it locally [07:38] RAOF: you don't say ;) [07:38] duflu, ack [07:43] mlankhorst: Would you kindly check the new xserver & nouveau? They're in qa-testing2 and also in git. [07:44] sure [07:47] RAOF, mlankhorst: Is it standard to use fourcc's for pixel formats now? I can't tell when pixel_format is just uint32_t [07:48] I guess so, just look at the source I guess [07:48] Ah, in place of documentation, interpret the source :) [07:49] mlankhorst: Is it generally considered valid to keep an alpha channel on scanout buffers? Or expected to fail? [07:51] duflu: Pixel format is always just a uint32_t. Sometimes it's just a uint32_t generated by concatenating 4 bytes... [07:52] dma-buf brought drm in to the magical world of fourccs, because it implies interop with v4l stuff. [07:52] To the Zoë! [07:53] RAOF, :) [07:59] mlankhorst, what's the status of https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1214066 [07:59] ? [07:59] Launchpad bug 1214066 in xorg (Ubuntu) "phoronix benchmarks on nouveau is 4 times slower today than it was last thursday" [Undecided,Incomplete] [08:00] as it says in the status, undecided, incomplete [08:01] :P [08:01] mlankhorst, have you seen similar behavior on your machine? [08:01] not really, but I'm planning on releasing 9.2 soon [08:01] mlankhorst, okay, eta? [08:02] mlankhorst, is there a ppa with 9.2 such that I can test with Mir and XMir? [08:02] ppa:canonical-x/x-staging [08:02] mlankhorst, ack [08:02] mlankhorst, so that has got all our mesa patches for Mir, too? just x-checking [08:03] mlankhorst: The bypass corruption issue... could that be because nothing is marked as dirty? [08:03] I just noticed the "dirty" feature [08:03] no idea [08:03] i think xorg only sends stuff when marked as dirty [08:05] The more I read, the more it sounds like bypass might /require/ it for some hardware [08:10] I guess mir needs to be at least told a buffer is dirty :P [08:18] mlankhorst: I find some platforms fail to page flip with pixel_format's containing alpha. Can I tell if it's going to work before attempting the flip? Seems like I can't [08:19] duflu: dno, I think if you can create a fb with the format flip should work [08:20] mlankhorst: FB creation always succeeds. But the drivers only check if the pixel_format is compatible later when the flip is attempted :( [08:22] duflu, do you have some time to review a branch? (sorry I need to merge it and alf is on holidays so it's approved only by alan and jenkins) could you get a quick look? it's a very small change... [08:22] hikiko: Maybe. Not sure. I'm already way overloaded for the next day or two [08:22] duflu: well strictly speaking ARGB would be compatible for flipping.. [08:22] but as XRGB [08:23] mlankhorst: Apparently not. intel rejects AR24, only flips XR24. [08:23] duflu, only if you have some free time (here it is: https://code.launchpad.net/~hikiko/mir/mir.native-gbm-platform-class/+merge/182074) +thank you :) [08:23] duflu: kernel or userspace? [08:23] mlankhorst: Userspace [08:23] then fix userspace.. [08:32] hi alan_g :) [08:32] hikiko: hi [08:33] alan_g, I was waiting for you! :) can I merge this one: https://code.launchpad.net/~hikiko/mir/mir.native-gbm-platform-class/+merge/182074 [08:33] ? [08:34] hikiko: Yeah, autolanding failed for "unrelated reasons". I'll top-approve again [08:35] thank you alan_g :) [08:35] hikiko: can you do the same for https://code.launchpad.net/~alan-griffiths/mir/spike-NestedOutput/+merge/182405? [08:35] yes [08:36] I thought it was merged.. done alan_g :) [08:37] hikiko: there are some intermittent test failures that we see in CI. No-one has got to the bottom of them yet [08:38] what is the Cl? [08:38] CI == Continuous Integration [08:39] I see [08:56] duflu, RAOF back [08:56] duflu, any more insights? [08:57] tvoss: I have an experimental change that might fix radeon. But lots of mocks are now broken :( [08:57] duflu, okay, can you get packages over to mlankhorst? disable tests in the package build if need be [08:58] just to verify that the change fixes radeon [08:58] tvoss: I will test it with everything I have first. Make sure nothing regressed [08:59] duflu, ack [08:59] duflu, I have got an amd machine now [08:59] duflu, need to set it up with 13.04 [09:00] mlankhorst: How'd testing go? === chihchun is now known as chihchun_afk [09:03] RAOF: oops was waiting for the build [09:03] Slacker :) [09:07] mlankhorst, xmir from archive working fine with mesa 9.2 on intel === chihchun_afk is now known as chihchun [09:10] tvoss: yeah noticed the same with nouveau + radeon [09:19] Wow, I hate gmock more than ever now [09:19] Its sharing of details you shouldn't know and should be free to modify is absurd [09:20] duflu, could you verify locally that things work fine on intel? [09:20] tvoss: Yes, about to start hardware testing. Given up trying to fix all the DRM mocks [09:21] brb [09:29] mlankhorst: Still waiting for the build? :) [09:36] nah was setting up my site [09:36] with ssl.. https://mblankhorst.nl/ [09:40] the mir+mirslave on't publish next cu2d run if https://code.launchpad.net/~timo-jyrinki/unity-system-compositor/sync_to_archive/+merge/182554 + https://code.launchpad.net/~timo-jyrinki/unity-mir/sync_to_archive/+merge/182553 don't get merged [09:41] RAOF: hm your build is a fail :P [09:42] it built against the wrong mir? [09:42] Both build locally!!!!! [09:42] of course but there's a newer mir in the distro archive [09:42] which it built against [09:42] Arse [09:43] Just force dependencies; mirclient ABI hasn't changed. [09:48] boom, dead [09:50] #0 NVSetScreenPixmap (ppix=0x7f84f7000490) at ../../src/nv_driver.c:613 [09:53] no bo attached yet, har har [09:54] (gdb) print (struct nouveau_pixmap *)exaGetPixmapDriverPrivate(ppix) [09:54] $6 = (struct nouveau_pixmap *) 0x0 [09:54] did you mean: nouveau_pixmap_bo ? :P [09:56] I think you're worrying too much about scanout, tbh.. [09:57] RAOF: where do you see nouveau actually _using_ scanout? [09:58]