=== bschaefer_ is now known as bschaefer [00:32] What? xmir_submit_rendering_for_window is never called? [01:08] Ahem. [01:08] I don't *call* xmir_submit_rendering_for_window. [01:08] Oops. [01:24] Well, that's really annoyingly stupid. [01:46] RAOF, whoops? [01:47] I've found out why radeon and nouveau don't work. [01:47] It's because I don't call xmir_submit_rendering_for_window. [01:47] That sounds important. How did intel work? [01:49] Because I do call xmir_submit_rendering_for_window there. [01:50] robert_ancell: So, there'll be radeon -MM3 and nouveau -MM3 that are more likely to actually work in the PPA soon :) [01:50] RAOF, cool, I'll give Jenkins a kick when they're ready [01:59] does anyone know how we disable ppc builds of mir? [01:59] Because u-s-c is waiting for libmirserver-dev to appear for PPC, and that's never going to happen [02:00] robert_ancell: I think you need to modify the Architecture of u-s-c, right? [02:01] RAOF, ah, true - thanks! [02:02] argh [02:03] australia tax [02:03] ? [02:03] * RAOF needs to get his tax in order; there should be a juicy refund out of it. [02:03] RAOF: I need to buy new headlights for my car [02:03] there's like a 200% markup over shipping them from the UK [02:03] RAOF, for your good deed, I present you with https://code.launchpad.net/~robert-ancell/unity-system-compositor/same-arch-as-mir/+merge/182240 in return [02:04] RAOF: but the shipping cost kinda negates buying them from there [02:05] Oh, australia tax. Right. [02:05] RAOF: its like 7 pounds vs $AUD35 [02:05] * RAOF now gets it. [02:05] smspillaz, yeah, we get that too [02:05] though, does Australia allow parallel imports? [02:06] Starting to more, yh. [02:06] RAOF: I think so. Its more just the RRP here is much higher [02:06] erm, robert_ancell [02:06] yeah, we're in the same boat there [02:09] robert_ancell: Do we build mir on arm64? [02:10] RAOF, copy and paste says yes [02:10] perhaps it's just ignored for now [02:10] Ok then. [02:22] hey RAOF, when you get a moment, I wonder if I could ask for your help with an X11 issue I'm having? [02:23] errr, not work related :-/ [02:23] thomi: Sure. [02:51] RAOF, qa-testing2 is good for ati/nouveau testing? [03:17] robert_ancell: qa-testing2 is good for ati/nouveau testing. === chihchun_afk is now known as chihchun [03:33] Lunch time! [03:57] RAOF, two of the radeon machines have completed on Jenkins, which is good [03:57] RAOF, and confirmed that VT switching doesn't drop focus, :( [04:32] mir doesn't like my radeon :-( [04:34] [ 34.161] (EE) Failed to map vb -2 [04:35] that's the only error from xorg [04:35] rsalveti, from ppa:mir-team/system-compositor-testing? [04:35] from dmesg: http://paste.ubuntu.com/6031250/ [04:35] robert_ancell: yes [04:35] rsalveti, yeah, ati and nouveau don't work in there yet [04:36] 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV620/M82 [Mobility Radeon HD 3450/3470] [04:36] anything I can do for better debugging or a confirmed issue already? [04:37] rsalveti, you could try the MM3 xserver-xorg-video-ati package from https://launchpad.net/~mir-team/+archive/qa-testing2 [04:38] that's the PPA we copied to ppa:mir-team/system-compositor-testing. It has updated ati and nouveau drivers [04:38] cool, let me give that a shot [04:39] kgunn, RAOF, I think we should copy in the ati/nouveau drivers into the system-compositor-testing PPA given the existing ones don't work - any reason not to? [04:42] alright, let me try another reboot :-) [04:42] brb [04:47] duflu_, ping [04:47] olli_, ping [04:51] yeee, progress [04:51] robert_ancell: with mm3 I works better [04:51] I'm using xmir now, but while it works, had to use xfce [04:51] unity fails to load it seems [04:51] and it's quite a bit slower [04:52] tvoss__: pong? === duflu_ is now known as duflu [04:54] to the luncheon [04:57] RAOF, looks like the new nouveau driver didn't work on Jenkins [05:00] cool, now with unity [05:00] just took a bit more to load, not sure why it failed when I tried it the first time [05:01] so it seems ati is working with mm3 [05:01] at least single-monitor [05:39] Why does no store in Hobart stock mDP → DP cables? [05:39] rsalveti: If you get the failure again, please take a copy of ~/.xsession-errors before logging out/in again and log a bug [05:39] RAOF: apple.com.au ? [05:39] That's what I use [05:49] duflu: Apparently apple.com.au don't have mDP → DP cables?! [05:49] RAOF: Yeah just noticed. Only mDP to DVI [05:50] RAOF: Shipping from Perth :) http://ple.com.au/ViewItem.aspx?InventoryItemID=609956&CategoryID=427 [05:51] I've ordered https://www.google.com.au/shopping/product/7302603727339146726?gs_rn=25&gs_ri=psy-ab&tok=z0nEokW4iYZnceCF5gU2YA&ds=sh&pq=google+shopping&cp=22&gs_id=2o&xhr=t&q=mini+displayport+to+displayport&pf=p&sclient=psy-ab&oq=mini+displyport+to+dis&pbx=1&bav=on.2,or.r_cp.r_qf.&bvm=bv.51156542,d.aGc&biw=1920&bih=994&tch=1&ech=22&psi=VT4cUvL_M4TriAedt4DoCg.1377582678489.3&sa=X&ei=Xj4cUqikHIXriAe5sYCgCA&sqi=2&ved=0CG8Q8wIwAA [05:53] RAOF: Oh. Actually would have only been $30 delivered from PLE [05:53] It's $26 direct from lenovo.com [05:53] Ah yes [05:54] Supports all your 4K monitors ;) [05:56] bug 1217195 [05:56] bug 1217195 in XMir "xmir multimonitor crash when docking/undocking T400, external DVI monitor (ATI Mobility Radeon HD 3450/3470)" [Undecided,New] https://launchpad.net/bugs/1217195 [05:56] bug 1217199 [05:56] bug 1217199 in XMir "xmir multimonitor crash when booting with dual not mirrored with T400 (ATI Mobility Radeon HD 3450/3470)" [Undecided,New] https://launchpad.net/bugs/1217199 [05:57] multimonitor works here only in mirrored mode [05:59] * duflu also notes he's slightly closer to Lenovo factories (Shenzhen)... Seems the East is more isolated ;) [06:10] * duflu ignores the fact that his Lenovos are second-hand and came from the eastern states [06:24] RAOF: did you figure out the issue yet? [06:25] mlankhorst: Yup, failure to call xmir_submit_rendering_for_window. [06:25] https://www.youtube.com/watch?v=zTHhwvTJyMU [06:28] mlankhorst: Please feel free to try the new new nouveau; I've not seen testing of it. [06:28] Hey, I think I can reproduce the glitches with egltriangle. I was just testing the wrong dual monitor combo [06:30] Woot! [06:30] I was about to try a build of your timerless MM to see if that fixed it; shall I not do that now? [06:35] RAOF: It's worthwhile for MM even if it doesn't fix that bug. [06:35] * duflu builds on the *correct* machine this time [06:36] Excellent. I've lost the ability to VT switch. That's an annoying Mir/X bug that's happened before [06:39] RAOF: Nope. Still happens. But at least I seem to have a test case now [06:47] duflu: Wow. Have you tried MM XMir on your timerless branch? [06:47] RAOF: No... ? [06:48] It generates the most awesome visual artefacts ever! [06:48] RAOF: It includes bypass. You're sure that's not it? [06:48] I guess it might be bypass? [06:48] RAOF: You mean single (short) line artefacts? [06:49] But rendering comes in over a couple of frames in horizontal stripes. [06:49] Yeah, I might mean that. [06:49] RAOF: Yeah I noticed that with qa-testing. Something about bypass+XMir [06:49] That is really odd; I don't have any intuition for what the problem might be there. [06:50] RAOF: Same. Can you verify bypass does the same, and also with no buffer_age? [06:52] Sure. [06:59] RAOF: Hmm, actually I am only seeing glitches which match up with the expected aliasing interval of the two different refresh rates. Still can't reproduce real lag using plain Mir [07:02] duflu:Huh! [07:02] Turns out I *have* been testing without buffer_Age [07:06] RAOF: Great. Still no leads on lag. Though the glitches seem to match up perfectly with (1.0 / (refresh_rate1 - refresh_rate2)) seconds [07:07] Beat frequency! [07:07] At least for egltriangle [07:07] It's a beat alright [07:07] Only happens on the slower monitor [07:10] Back in a tick [07:10] Or a few beats [07:23] RAOF: Suggestions for avoiding beats? Sync to the slowest output instead? [07:25] Though I'm not too sure how such an algorithm would go... [07:29] RAOF: oh btw tiling fail on nouveau [07:29] bigtime :P [07:30] and the screen is now reduced to random noise [07:32] looks like freed b uff [07:32] buffers are being copied to the screen, or something [07:33] .. which might not be different from the ati case I was hitting.. [07:34] mlankhorst: Running what? [07:35] qa-testing2 on a single monitor setup [07:38] Hmm [07:38] mlankhorst: Hrm. Works fine for me on ati single [07:39] -monitor. [07:40] RAOF: oops ati panicked on me, looks like I need to fix something first. I'm fairly sure nouveau was using freed memory at least :P [07:40] RAOF: Interestingly, each beat pops out to stdout from egltriangle as "61 FPS" [07:43] I've poked upstream a bit about the vsync fixes I was working on [07:43] they make glxgears a nice 65.4 fps :-) [07:44] mlankhorst: Sounds close to perfect. Seen any X/Compiz problem like I did? [07:44] duflu: well considering my screen was overclocked to 65.4 it was perfect [07:44] mlankhorst, Sweet [07:49] RAOF: hm radeon is correct now, I'll poke nouveau a bit more [07:50] Ta. [07:50] Actually, now that I think of it, radeon is probably broken for multi-monitor, care of references to the front buffer being invalid after xmir_resize :( [07:53] single monitor resize worked, but I don't know if it resizes when lowering the resolution.. [07:55] Hm. [07:56] Maybe only the dri2 code that we don't hit uses the front buffer reference... [07:56] RAOF: did you push your nouveau changes? [07:57] mlankhorst: I have now :) [07:57] or the ati changes for that matter :P [08:00] That's new. My VT font is now only 8px high [08:10] hikiko: good morning. How are things? [08:12] hi alan_g [08:12] RAOF: .. [08:12] how are you? [08:12] -+ damage_box->x1 - output_box->x1, [08:12] -+ damage_box->y1 - output_box->y1, [08:12] alan_g, did you see my MPs? [08:12] why such a creative way of writing 0? [08:13] hikiko: I see them. will review with all the others [08:13] :) [08:13] hikiko: we have an MP backlog - are you doing your reviews? [08:13] what do you mean alan_g ? [08:14] hikiko: All team members, including you, have a responsibility to review MPs [08:14] you mean all the mps? [08:15] hikiko: if no-one reviews them they don't land and we get a backlog [08:16] where can I find this backlog? [08:16] I wasn't aware to be honest [08:16] hikiko: https://code.launchpad.net/mir/+activereviews [08:17] ok, so I guess I have to start reviewing? [08:18] For reviews, just keep in mind this week the priorities are multi-monitor and bypass proposals [08:19] hikiko: start with any easy ones (small & things you know) - it make the list smaller. [08:21] ok [08:21] duflu: what's the current rule about landing bypass? [08:21] alan_g: Top approval is deferred till more PPA testing I think [08:23] RAOF: oh btw I'm worried about your handling of multi monitor, it seems to add yet another copy pass in the single monitor case.. [08:23] hikiko: If you're looking at mine, don't overlook the pre-requisites - if you top-approve they land too. [08:41] RAOF: heh all that silly stuff about bo creation in nouveau.. there are easier ways to do so :P [08:50] mlankhorst: I don't think it adds an extra copy for the single-monitor case? [08:51] mlankhorst: damage_box->x1 - output_box->x1 is zero iff the damage occurs on a display with top-left at (0,0) [08:51] RAOF: OK, I've written a key repeat simulator native client. And no bugs. Still only happens in XMir ?! [08:52] mlankhorst: On a display at (x, y), output_box->x1 will be x, but damage_box->x1 will be >= x [08:53] RAOF: I mean that the current path requires always making a copy.. [08:54] oh hm this could explain why xorg didn't work.. [08:54] [ 50.333352] nouveau E[ PGRAPH][0000:01:00.0] DATA_ERROR XY_OUT_OF_BOUNDS [08:54] [ 50.334335] nouveau E[ PGRAPH][0000:01:00.0] DATA_ERROR [08:54] [ 50.334335] nouveau E[ PGRAPH][0000:01:00.0] ch 3 [0x003f9a4000 unity-system-co[1087]] subc 0 class 0x5039 mthd 0x0328 data 0x00000000 [08:54] Whoops. [08:54] mlankhorst: The current path already requires always making a copy, though? [08:55] RAOF: yeah but ideally it'd just be a flip [08:56] Yeah, but we can't do that. [08:56] Or, we could, but would require significant mir-side work to enable. [08:56] I think it's generally understood XMir will have copies, for now... [08:57] Well, that's rather odd. [08:57] RAOF: any idea where the XY_OUT_OF_BOUNDS is coming from at least? [08:58] Ahem. [08:59] pScreen->ModifyPixmapHeader(dst, dst_box->x2 - dst_box->x1, [08:59] dst_box->y2 - dst_box->y1, pScrn->depth, pScrn->depth, [08:59] pScrn->virtualX, NULL); [08:59] Spot the odd one out... [08:59] RAOF: well I did get rid of it in my version [08:59] Although for the single monitor case, pScrn->virtualX should be right. [08:59] anbd it's unity-system-compositor failing, not xorg [09:00] RAOF: http://paste.debian.net/30763/ [09:00] Woohoo! [09:00] ? [09:01] Oh, it's just an implementation of copy_to_mir that doesn't go through EXA [09:01] it's the default m2mf implementation for nouveau anyway, depends on hw which implementation it uses [09:02] but unity-system-compositor is still complaining about XY_OUT_OF_BOUNDS.. Hmmz [09:02] Yeah; that's odd. [09:02] That couldn't be because xmir is submitting something strange? [09:03] it's unity-system-compositor, not xorg complaining.. [09:03] duflu: Did you find that the crazy horizontal artefacts only occurred when you had two displays enabled? [09:04] Yeah, but could unity-system-compositor be complaining because it's trying to access something that xorg screwed up? [09:04] The other option is that usc is, in fact, doing something wrong. [09:04] RAOF: I think so. Because we all tested bypass XMir single monitor a while back and no one had any issues [09:04] But I don't really know what that would be, particularly if other Mir clients work. [09:05] RAOF: there is no command validation in the kernel, it's literally the hardware saying your parameters for M2MF transfer do not make sense :P [09:05] RAOF: I should have realized, but yes the crazy horizontal artefacts are multimonitor only AFAIK [09:05] Multimonitor+bypass I mean [09:06] mlankhorst: Hrm. When you run regular Mir clients against usc things work? [09:07] hm it does [09:09] "Your x/y coords exceed the size of your surface." [09:09] o.O [09:10] oh right, not on 9.2 yet.. [09:10] I'll try mesa 9.2 first before digging further [09:16] tvoss: is anything happening with https://code.launchpad.net/~thomas-voss/mir/fix-fd-sharing/+merge/180801? [09:16] kgunn: hi! Any news on https://bugs.launchpad.net/unity-system-compositor/+bug/1216979 ? [09:16] Launchpad bug 1216979 in Unity System Compositor "Failing unity.tests.test_dash.DashMultiKeyTests.test_multi_key_delete autopilot test" [Undecided,New] [09:16] sil2100: Good luck. He's at 4am I think [09:17] kgunn: since right now it's blocking unity-system-compositor from releasing [09:17] duflu: lovely, thanks [09:18] RAOF: lol, fail in nv50_m2mf_transfer_rect [09:18] What's it doing? [09:19] not setting X/Y at all [09:19] ;D [09:20] Ahem. Yeah, that doesn't seem particularly likely to work :) [09:20] That's clearly not something that I did. Yay! [09:24] Might work at defaulting to 0,0 on some machines, if you're lucky [09:26] RAOF: Was there any technical reason (other than performance) why XMir couldn't be switched to being a dumb Mir software client? [09:26] No [09:26] RAOF: Because I'm starting to think that would be nice to test [09:26] But "other than performance" is a pretty big "other than" [09:28] We could whip up a sw-rendering DDX reasonably quickly. [09:28] hikiko: https://code.launchpad.net/~hikiko/mir/mir.gbm-buffer-allocator-modifications/+merge/182049 is pretty trivial to fix. Want to do that quickly? [09:28] RAOF: Yeah, I mean just for debugging. Smells like some issues still lurk in XMir trying to be super fast [09:29] RAOF: Yes please. Otherwise I may well end up trying to learn it and do it myself [09:31] I did it already alan_g I am building before I push [09:33] RAOF: BTW, my key repeat simulator runs glitch-free in USC over the top of XMir. XMir's the only client with the glitches still :( [09:33] RAOF: it's probably not a usc bug anyway, even if feeding invalid date the state tracker is supposed to deal with it [10:03] oops, nouveau has betrayed me :P [10:03] it was xserver after all [10:04] yeah there we go, all working now.. mostly [10:04] hi [10:04] i am testing MM [10:05] here on my x220 in a dock and the external monitor being the primary [10:05] i get wrong resolution (that of the front screen) stretched [10:10] asac: Yes we have a bug logged for that. I get it too [10:14] duflu: cool. once fixed can you ping me? happy to give it a try :) [10:15] asac: Probably best if you just subscribe: https://bugs.launchpad.net/xmir/+bug/1216224 [10:15] Launchpad bug 1216224 in XMir "[multimonitor] XMir defaults to wrong resolution 1152x864 instead of 1920x1200." [Undecided,Confirmed] [10:15] asac: Though once logged in you can change the resolution [10:17] RAOF: well that was easy to fix once I caught the kernel module lying about the source :P [10:17] duflu: i can? how? [10:17] wait ... cant copy/paste here anymore :(( [10:18] RAOF: http://paste.debian.net/30796/ --- enjoy! [10:18] asac: Log in and look on the right hand side of https://bugs.launchpad.net/xmir/+bug/1216224 where you will find subscription links [10:18] Launchpad bug 1216224 in XMir "[multimonitor] XMir defaults to wrong resolution 1152x864 instead of 1920x1200." [Undecided,Confirmed] [10:23] duflu: was asking how to change resolution, but found that it can be done with just the normal preferences dialog [10:23] something is really tslow though [10:24] asac: Slow? Yes there's at least one bug for that too [10:25] i think its better now [10:25] after reboot [10:25] still, movig windows is a bit laggy [10:25] but so far i can survive... cool [10:28] seems i also get some texture artifacts while moving windows [10:28] as if the window is split up in multiple pieces and they move out of sync :) === alan_g is now known as alan_g|vt [10:30] asac: You may wish to comment on the issues: https://bugs.launchpad.net/xmir/+bugs?field.tag=multimonitor === alan_g|vt is now known as alan_g [10:35] * duflu goes to organise dinner [10:36] mlankhorst: Heh. Stride Strikes Again! [10:36] asac: That sounds pretty cool! [10:39] yeah i am happy :) [10:39] RAOF: yes :P [10:39] bleeding edge :) [10:39] mlankhorst: I don't suppose you tried copying just the region that's damaged? [10:40] RAOF: hm is it clipped against the output? :P [10:40] but I guess I could.. [10:40] Yeah. [10:41] region is always fully contained within dst_box (we do the intersection in the xmir module) [10:42] So it's not *wrong* to always copy dst_box, but it's a wasteful. [10:42] hm sure [10:43] RAOF: is it guaranteed to be non-zero? [10:43] eg no 0x0,0x0 copy [10:43] Yes [10:43] kk [10:44] * RAOF has weeded out all of these cases by testing on Intel, which uses region :) [10:44] Man, the NVAccelM2MF declaration is not exactly self-documenting code :) [10:45] it is [10:46] the ofs refers to offset from start of bo, in case of scratch bo usage [10:46] Aaah. [10:46] And the rest you can mostly guess. [10:47] source domain, source pitch, source height, x/y [10:47] source_depth, source_pitch, source_height, source_x, source_y [10:47] domain not depth :p [10:47] Hah, source *domain*. [10:48] What does M2MF stand for? Something like Mem 2 Mem copy with Format? [10:49] memory to memory function was my guess, but yours is just as good I suppose [10:49] hm format is probably the right one [10:49] it can convert some formats to others and do some swizzling [10:51] RAOF: oh btw what coordinates is damage_box in then? [10:51] Screen coordinates. [10:51] so same coordinate system as damage_box ? [10:52] dst_box? Yes. [10:52] Hm. We may have been confusing there :) [10:52] you don't say! [10:52] _region_ is in the same coordinate space as dst_box :) [10:52] And region is the damage region. [10:53] Both are in the window coordinate space of the window. [10:54] http://paste.debian.net/30803/ [10:55] just guessing.. I'll give it a shot [10:56] That looks roughly right? [10:57] even seems to draw correctly [10:57] Hm. I think you might have some things the wrong way around, but that might be because I've been using Exa->Copy too much. [10:57] Ah, well. If it works, it's clearly not that wrong :) [10:57] The ideal test client is an xterm on a raw X session. [10:59] hm let me find a mouse for that machine, it didn't put focus on the xterm :P [10:59] Fire up metacity? [11:02] hm xterm -e 'find /' works [11:04] RAOF: first client for x works, but if I kill it and screen returns to black the next client does not.. [11:04] mlankhorst: Yeah, loss of the sole client triggers a server regeneration, and XMir doesn't handle that well at all. [11:05] Fortunately that should only hit people like us, who test clients on raw X. [11:05] And, obviously, KDE, should they feel like porting. :) [11:05] RAOF: oh and a major derp was not using damage_box->x1 for src :P [11:06] hm and then not removing dst_box from dst coordinates [11:06] Ah, right. [11:06] Yes, I did wonder a bit about that :) [11:07] http://paste.debian.net/30811/ this version is more correct right? [11:08] Yeah, that looks like what I'd expect. [11:08] Particularly: it looks like the radeon code :) [11:11] ricmm: tvoss: there? [11:12] ricmm: tvoss: unping [11:12] tsdgeos, ;) === chihchun is now known as chihchun_afk [11:15] RAOF: odd, does compiz always do full-screen repaints then? [11:15] mlankhorst: I think compiz is mostly doing glXSwapBuffers now (although you can turn that off) [11:16] And SwapBuffers implies full-screen repaints. [11:16] * RAOF wonders whether it'd be worth teaching Compiz about swap_buffers_with_damage [11:16] it's also very nice for bypass though :P [11:16] mlankhorst: Indeed. [11:17] It means that, once we actually implement the sucker, our normal-case overhead is going to be just protocol overhead. [11:18] RAOF: but I'm mostly worried about the vblanking timestamp stuff, I still want accurate vblank on video [11:19] Yeah, we need to hook that up. [11:19] I was planning on doing it as a part of glx bypass, where it'd naturally fall out, but it's not necessary to do it there I guess. [11:20] You don't get scanline accuracy out of it, but you can approximate vblank with buffer-received. [11:21] that's not accurate vblank :p [11:21] Yeah, that requires more involved compositor support :) [11:21] Which I want to do, but is obviously a "not now" thing :/ [11:22] the drivers can get that information directly without going through the compositor.. [11:22] Only if the compositor isn't compositing, though? [11:22] they just need to have the correct drm fd for the crtc, and the crtc id.. [11:23] And where on the crtc the window is, yes? [11:23] And that'll only give you an accurate vblank signal; it won't tell you when the window is actually displayed, which is more interesting, right? [11:23] not really, they just need to know for scheduling decisions [11:24] As in: what-client-should-get-GPU-time-next decisions? [11:26] I mean something like a media player might want to see the time of the last vblank, know exactly when the next vblank is going to happen, and queue a frame 1 or 2 vblanks in advance to sync on the correct frame [11:26] mlankhorst: Right, but that really wants compositor support. [11:27] Because the compositor might introduce a delay [11:27] what about the case of fullscreen bypass? [11:28] Then can do it, yes. [11:28] Which is, I agree, a common case. [11:31] But it's also the case that a client doesn't know if it's bypassed or not. [11:32] RAOF: hm crash when I plugged in a second monitor to ati :P [11:32] mlankhorst: Yeah. Need to implement a SetScreenPixmap hook for ATI to update info->front* [11:32] As far as I can tell nouveau doesn't do anything annoying like that. [11:32] Good job! [11:33] lol [11:33] nvidia does everything in hardware where it can.. [11:36] hikiko: what are you working on? [11:51] mlankhorst, tvoss: Nouveau uploaded to qa-testing2 PPA. Happy multi-monitor testing! [11:55] alan_g, I am looking at your branch + I am trying to find out where we get the crash if we add gbm/drm in native platform [11:56] hikiko: ack [11:56] alan_g, is there any way to check the changes in the display? [11:56] hikiko: I'm not sure what you're asking [11:56] or we have to fully implement the native/nested platform first? [11:59] hikiko: we should be writing tests for the functionality we are working on [12:00] alan_g, ok but let's first add the functionality :) [12:01] I have a question on your branch actually [12:01] + make_current(); // This duplicates what Eleni's original code did - but is it needed? [12:01] what do you mean? [12:01] do we swap buffers elsewhere? [12:04] hikiko: I'm not sure why we'd do this when constructing the object (as opposed to when we render to it) [12:04] I guess that if we don't we ll see nothing [12:04] because we render to the back surface [12:04] and we have to make it current [12:05] let me see [12:05] hikiko: rendering calls "make_current()" [12:06] let me see what make_current does 1 sec [12:07] make_current binds the context to the current rendering thread [12:07] and to the draw and read surfaces [12:09] RAOF: erm you failed somewhere [12:09] ;P [12:10] that src pixmap is definitely not covering the entire screen on my multimonitor setup [12:10] proof.. [12:10] #0 NVAccelM2MF (pNv=pNv@entry=0x7f160085fc60, w=w@entry=1280, h=h@entry=1024, cpp=4, srcoff=srcoff@entry=0, dstoff=dstoff@entry=0, [12:10]