[00:32] <RAOF> What? xmir_submit_rendering_for_window is never called?
[01:08] <RAOF> Ahem.
[01:08] <RAOF> I don't *call* xmir_submit_rendering_for_window.
[01:08] <RAOF> Oops.
[01:24] <RAOF> Well, that's really annoyingly stupid.
[01:46] <robert_ancell> RAOF, whoops?
[01:47] <RAOF> I've found out why radeon and nouveau don't work.
[01:47] <RAOF> It's because I don't call xmir_submit_rendering_for_window.
[01:47] <duflu_> That sounds important. How did intel work?
[01:49] <RAOF> Because I do call xmir_submit_rendering_for_window there.
[01:50] <RAOF> robert_ancell: So, there'll be radeon -MM3 and nouveau -MM3 that are more likely to actually work in the PPA soon :)
[01:50] <robert_ancell> RAOF, cool, I'll give Jenkins a kick when they're ready
[01:59] <robert_ancell> does anyone know how we disable ppc builds of mir?
[01:59] <robert_ancell> Because u-s-c is waiting for libmirserver-dev to appear for PPC, and that's never going to happen
[02:00] <RAOF> robert_ancell: I think you need to modify the Architecture of u-s-c, right?
[02:01] <robert_ancell> RAOF, ah, true - thanks!
[02:02] <smspillaz> argh
[02:03] <smspillaz> australia tax
[02:03] <RAOF> ?
[02:03]  * RAOF needs to get his tax in order; there should be a juicy refund out of it.
[02:03] <smspillaz> RAOF: I need to buy new headlights for my car
[02:03] <smspillaz> there's like a 200% markup over shipping them from the UK
[02:03] <robert_ancell> 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] <smspillaz> RAOF: but the shipping cost kinda negates buying them from there
[02:05] <RAOF> Oh, australia tax. Right.
[02:05] <smspillaz> RAOF: its like 7 pounds vs $AUD35
[02:05]  * RAOF now gets it.
[02:05] <robert_ancell> smspillaz, yeah, we get that too
[02:05] <robert_ancell> though, does Australia allow parallel imports?
[02:06] <RAOF> Starting to more, yh.
[02:06] <smspillaz> RAOF: I think so. Its more just the RRP here is much higher
[02:06] <smspillaz> erm, robert_ancell
[02:06] <robert_ancell> yeah, we're in the same boat there
[02:09] <RAOF> robert_ancell: Do we build mir on arm64?
[02:10] <robert_ancell> RAOF, copy and paste says yes
[02:10] <robert_ancell> perhaps it's just ignored for now
[02:10] <RAOF> Ok then.
[02:22] <thomi> 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] <thomi> errr, not work related :-/
[02:23] <RAOF> thomi: Sure.
[02:51] <robert_ancell> RAOF, qa-testing2 is good for ati/nouveau testing?
[03:17] <RAOF> robert_ancell: qa-testing2 is good for ati/nouveau testing.
[03:33] <RAOF> Lunch time!
[03:57] <robert_ancell> RAOF, two of the radeon machines have completed on Jenkins, which is good
[03:57] <robert_ancell> RAOF, and confirmed that VT switching doesn't drop focus, :(
[04:32] <rsalveti> mir doesn't like my radeon :-(
[04:34] <rsalveti> [    34.161] (EE) Failed to map vb -2
[04:35] <rsalveti> that's the only error from xorg
[04:35] <robert_ancell> rsalveti, from ppa:mir-team/system-compositor-testing?
[04:35] <rsalveti> from dmesg: http://paste.ubuntu.com/6031250/
[04:35] <rsalveti> robert_ancell: yes
[04:35] <robert_ancell> rsalveti, yeah, ati and nouveau don't work in there yet
[04:36] <rsalveti> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV620/M82 [Mobility Radeon HD 3450/3470]
[04:36] <rsalveti> anything I can do for better debugging or a confirmed issue already?
[04:37] <robert_ancell> rsalveti, you could try the MM3 xserver-xorg-video-ati package from https://launchpad.net/~mir-team/+archive/qa-testing2
[04:38] <robert_ancell> that's the PPA we copied to ppa:mir-team/system-compositor-testing. It has updated ati and nouveau drivers
[04:38] <rsalveti> cool, let me give that a shot
[04:39] <robert_ancell> 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] <rsalveti> alright, let me try another reboot :-)
[04:42] <rsalveti> brb
[04:47] <tvoss__> duflu_, ping
[04:47] <tvoss__> olli_, ping
[04:51] <rsalveti> yeee, progress
[04:51] <rsalveti> robert_ancell: with mm3 I works better
[04:51] <rsalveti> I'm using xmir now, but while it works, had to use xfce
[04:51] <rsalveti> unity fails to load it seems
[04:51] <rsalveti> and it's quite a bit slower
[04:52] <duflu_> tvoss__: pong?
[04:54] <duflu> to the luncheon
[04:57] <robert_ancell> RAOF, looks like the new nouveau driver didn't work on Jenkins
[05:00] <rsalveti> cool, now with unity
[05:00] <rsalveti> just took a bit more to load, not sure why it failed when I tried it the first time
[05:01] <rsalveti> so it seems ati is working with mm3
[05:01] <rsalveti> at least single-monitor
[05:39] <RAOF> Why does no store in Hobart stock mDP → DP cables?
[05:39] <duflu> 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] <duflu> RAOF: apple.com.au ?
[05:39] <duflu> That's what I use
[05:49] <RAOF> duflu: Apparently apple.com.au don't have mDP → DP cables?!
[05:49] <duflu> RAOF: Yeah just noticed. Only mDP to DVI
[05:50] <duflu> RAOF: Shipping from Perth :)  http://ple.com.au/ViewItem.aspx?InventoryItemID=609956&CategoryID=427
[05:51] <RAOF> 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] <duflu> RAOF: Oh. Actually would have only been $30 delivered from PLE
[05:53] <RAOF> It's $26 direct from lenovo.com
[05:53] <duflu> Ah yes
[05:54] <duflu> Supports all your 4K monitors ;)
[05:56] <rsalveti> bug 1217195
[05:56] <rsalveti> bug 1217199
[05:57] <rsalveti> 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] <mlankhorst> RAOF: did you figure out the issue yet?
[06:25] <RAOF> mlankhorst: Yup, failure to call xmir_submit_rendering_for_window.
[06:25] <mlankhorst> https://www.youtube.com/watch?v=zTHhwvTJyMU
[06:28] <RAOF> mlankhorst: Please feel free to try the new new nouveau; I've not seen testing of it.
[06:28] <duflu> Hey, I think I can reproduce the glitches with egltriangle. I was just testing the wrong dual monitor combo
[06:30] <RAOF> Woot!
[06:30] <RAOF> 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] <duflu> 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] <duflu> Excellent. I've lost the ability to VT switch. That's an annoying Mir/X bug that's happened before
[06:39] <duflu> RAOF: Nope. Still happens. But at least I seem to have a test case now
[06:47] <RAOF> duflu: Wow. Have you tried MM XMir on your timerless branch?
[06:47] <duflu> RAOF: No... ?
[06:48] <RAOF> It generates the most awesome visual artefacts ever!
[06:48] <duflu> RAOF: It includes bypass. You're sure that's not it?
[06:48] <RAOF> I guess it might be bypass?
[06:48] <duflu> RAOF: You mean single (short) line artefacts?
[06:49] <RAOF> But rendering comes in over a couple of frames in horizontal stripes.
[06:49] <RAOF> Yeah, I might mean that.
[06:49] <duflu> RAOF: Yeah I noticed that with qa-testing. Something about bypass+XMir
[06:49] <RAOF> That is really odd; I don't have any intuition for what the problem might be there.
[06:50] <duflu> RAOF: Same. Can you verify bypass does the same, and also with no buffer_age?
[06:52] <RAOF> Sure.
[06:59] <duflu> 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] <RAOF> duflu:Huh!
[07:02] <RAOF> Turns out I *have* been testing without buffer_Age
[07:06] <duflu> 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] <RAOF> Beat frequency!
[07:07] <duflu> At least for egltriangle
[07:07] <duflu> It's a beat alright
[07:07] <duflu> Only happens on the slower monitor
[07:10] <duflu> Back in a tick
[07:10] <duflu> Or a few beats
[07:23] <duflu> RAOF: Suggestions for avoiding beats? Sync to the slowest output instead?
[07:25] <duflu> Though I'm not too sure how such an algorithm would go...
[07:29] <mlankhorst> RAOF: oh btw tiling fail on nouveau
[07:29] <mlankhorst> bigtime :P
[07:30] <mlankhorst> and the screen is now reduced to random noise
[07:32] <mlankhorst> looks like freed b uff
[07:32] <mlankhorst> buffers are being copied to the screen, or something
[07:33] <mlankhorst> .. which might not be different from the ati case I was hitting..
[07:34] <duflu> mlankhorst: Running what?
[07:35] <mlankhorst> qa-testing2 on a single monitor setup
[07:38] <duflu> Hmm
[07:38] <RAOF> mlankhorst: Hrm. Works fine for me on ati single
[07:39] <RAOF> -monitor.
[07:40] <mlankhorst> 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] <duflu> RAOF: Interestingly, each beat pops out to stdout from egltriangle as "61 FPS"
[07:43] <mlankhorst> I've poked upstream a bit about the vsync fixes I was working on
[07:43] <mlankhorst> they make glxgears a nice 65.4 fps :-)
[07:44] <duflu> mlankhorst: Sounds close to perfect. Seen any X/Compiz problem like I did?
[07:44] <mlankhorst> duflu: well considering my screen was overclocked to 65.4 it was perfect
[07:44] <duflu> mlankhorst, Sweet
[07:49] <mlankhorst> RAOF: hm radeon is correct now, I'll poke nouveau a bit more
[07:50] <RAOF> Ta.
[07:50] <RAOF> 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] <mlankhorst> single monitor resize worked, but I don't know if it resizes when lowering the resolution..
[07:55] <RAOF> Hm.
[07:56] <RAOF> Maybe only the dri2 code that we don't hit uses the front buffer reference...
[07:56] <mlankhorst> RAOF: did you push your nouveau changes?
[07:57] <RAOF> mlankhorst: I have now :)
[07:57] <mlankhorst> or the ati changes for that matter :P
[08:00] <duflu> That's new. My VT font is now only 8px high
[08:10] <alan_g> hikiko: good morning. How are things?
[08:12] <hikiko> hi alan_g
[08:12] <mlankhorst> RAOF: ..
[08:12] <hikiko> how are you?
[08:12] <mlankhorst> -+                                    damage_box->x1 - output_box->x1,
[08:12] <mlankhorst> -+                                    damage_box->y1 - output_box->y1,
[08:12] <hikiko> alan_g, did you see my MPs?
[08:12] <mlankhorst> why such a creative way of writing 0?
[08:13] <alan_g> hikiko: I see them. will review with all the others
[08:13] <hikiko> :)
[08:13] <alan_g> hikiko: we have an MP backlog - are you doing your reviews?
[08:13] <hikiko> what do you mean alan_g ?
[08:14] <alan_g> hikiko: All team members, including you, have a responsibility to review MPs
[08:14] <hikiko> you mean all the mps?
[08:15] <alan_g> hikiko: if no-one reviews them they don't land and we get a backlog
[08:16] <hikiko> where can I find this backlog?
[08:16] <hikiko> I wasn't aware to be honest
[08:16] <alan_g> hikiko: https://code.launchpad.net/mir/+activereviews
[08:17] <hikiko> ok, so I guess I have to start reviewing?
[08:18] <duflu> For reviews, just keep in mind this week the priorities are multi-monitor and bypass proposals
[08:19] <alan_g> hikiko: start with any easy ones (small & things you know) - it make the list smaller.
[08:21] <hikiko> ok
[08:21] <alan_g> duflu: what's the current rule about landing bypass?
[08:21] <duflu> alan_g: Top approval is deferred till more PPA testing I think
[08:23] <mlankhorst> 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] <alan_g> hikiko: If you're looking at mine, don't overlook the pre-requisites - if you top-approve they land too.
[08:41] <mlankhorst> RAOF: heh all that silly stuff about bo creation in nouveau.. there are easier ways to do so :P
[08:50] <RAOF> mlankhorst: I don't think it adds an extra copy for the single-monitor case?
[08:51] <RAOF> mlankhorst: damage_box->x1 - output_box->x1 is zero iff the damage occurs on a display with top-left at (0,0)
[08:51] <duflu> RAOF: OK, I've written a key repeat simulator native client. And no bugs. Still only happens in XMir ?!
[08:52] <RAOF> mlankhorst: On a display at (x, y), output_box->x1 will be x, but damage_box->x1 will be >= x
[08:53] <mlankhorst> RAOF: I mean that the current path requires always making a copy..
[08:54] <mlankhorst> oh hm this could explain why xorg didn't work..
[08:54] <mlankhorst> [   50.333352] nouveau E[  PGRAPH][0000:01:00.0] DATA_ERROR XY_OUT_OF_BOUNDS
[08:54] <mlankhorst> [   50.334335] nouveau E[  PGRAPH][0000:01:00.0]  DATA_ERROR
[08:54] <mlankhorst> [   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] <RAOF> Whoops.
[08:54] <RAOF> mlankhorst: The current path already requires always making a copy, though?
[08:55] <mlankhorst> RAOF: yeah but ideally it'd just be a flip
[08:56] <RAOF> Yeah, but we can't do that.
[08:56] <RAOF> Or, we could, but would require significant mir-side work to enable.
[08:56] <duflu> I think it's generally understood XMir will have copies, for now...
[08:57] <RAOF> Well, that's rather odd.
[08:57] <mlankhorst> RAOF: any idea where the XY_OUT_OF_BOUNDS is coming from at least?
[08:58] <RAOF> Ahem.
[08:59] <RAOF> 	pScreen->ModifyPixmapHeader(dst, dst_box->x2 - dst_box->x1,
[08:59] <RAOF> 								dst_box->y2 - dst_box->y1, pScrn->depth, pScrn->depth,
[08:59] <RAOF> 				    pScrn->virtualX, NULL);
[08:59] <RAOF> Spot the odd one out...
[08:59] <mlankhorst> RAOF: well I did get rid of it in my version
[08:59] <RAOF> Although for the single monitor case, pScrn->virtualX should be right.
[08:59] <mlankhorst> anbd it's unity-system-compositor failing, not xorg
[09:00] <mlankhorst> RAOF: http://paste.debian.net/30763/
[09:00] <RAOF> Woohoo!
[09:00] <duflu> ?
[09:01] <RAOF> Oh, it's just an implementation of copy_to_mir that doesn't go through EXA
[09:01] <mlankhorst> it's the default m2mf implementation for nouveau anyway, depends on hw which implementation it uses
[09:02] <mlankhorst> but unity-system-compositor is still complaining about XY_OUT_OF_BOUNDS.. Hmmz
[09:02] <RAOF> Yeah; that's odd.
[09:02] <RAOF> That couldn't be because xmir is submitting something strange?
[09:03] <mlankhorst> it's unity-system-compositor, not xorg complaining..
[09:03] <RAOF> duflu: Did you find that the crazy horizontal artefacts only occurred when you had two displays enabled?
[09:04] <RAOF> Yeah, but could unity-system-compositor be complaining because it's trying to access something that xorg screwed up?
[09:04] <RAOF> The other option is that usc is, in fact, doing something wrong.
[09:04] <duflu> RAOF: I think so. Because we all tested bypass XMir single monitor a while back and no one had any issues
[09:04] <RAOF> But I don't really know what that would be, particularly if other Mir clients work.
[09:05] <mlankhorst> 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] <duflu> RAOF: I should have realized, but yes the crazy horizontal artefacts are multimonitor only AFAIK
[09:05] <duflu> Multimonitor+bypass I mean
[09:06] <RAOF> mlankhorst: Hrm. When you run regular Mir clients against usc things work?
[09:07] <mlankhorst> hm it does
[09:09] <mlankhorst> "Your x/y coords exceed the size of your surface."
[09:09] <mlankhorst> o.O
[09:10] <mlankhorst> oh right, not on 9.2 yet..
[09:10] <mlankhorst> I'll try mesa 9.2 first before digging further
[09:16] <alan_g> tvoss: is anything happening with https://code.launchpad.net/~thomas-voss/mir/fix-fd-sharing/+merge/180801?
[09:16] <sil2100> kgunn: hi! Any news on https://bugs.launchpad.net/unity-system-compositor/+bug/1216979 ?
[09:16] <duflu> sil2100: Good luck. He's at 4am I think
[09:17] <sil2100> kgunn: since right now it's blocking unity-system-compositor from releasing
[09:17] <sil2100> duflu: lovely, thanks
[09:18] <mlankhorst> RAOF: lol, fail in nv50_m2mf_transfer_rect
[09:18] <RAOF> What's it doing?
[09:19] <mlankhorst> not setting X/Y at all
[09:19] <mlankhorst> ;D
[09:20] <RAOF> Ahem. Yeah, that doesn't seem particularly likely to work :)
[09:20] <RAOF> That's clearly not something that I did. Yay!
[09:24] <duflu> Might work at defaulting to 0,0 on some machines, if you're lucky
[09:26] <duflu> RAOF: Was there any technical reason (other than performance) why XMir couldn't be switched to being a dumb Mir software client?
[09:26] <RAOF> No
[09:26] <duflu> RAOF: Because I'm starting to think that would be nice to test
[09:26] <RAOF> But "other than performance" is a pretty big "other than"
[09:28] <RAOF> We could whip up a sw-rendering DDX reasonably quickly.
[09:28] <alan_g> 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] <duflu> RAOF: Yeah, I mean just for debugging. Smells like some issues still lurk in XMir trying to be super fast
[09:29] <duflu> RAOF: Yes please. Otherwise I may well end up trying to learn it and do it myself
[09:31] <hikiko> I did it already alan_g I am building before I push
[09:33] <duflu> 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] <mlankhorst> 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] <mlankhorst> oops, nouveau has betrayed me :P
[10:03] <mlankhorst> it was xserver after all
[10:04] <mlankhorst> yeah there we go, all working now.. mostly
[10:04] <asac> hi
[10:04] <asac> i am testing MM
[10:05] <asac> here on my x220 in a dock and the external monitor being the primary
[10:05] <asac> i get wrong resolution (that of the front screen) stretched
[10:10] <duflu> asac: Yes we have a bug logged for that. I get it too
[10:14] <asac> duflu: cool. once fixed can you ping me? happy to give it a try :)
[10:15] <duflu> asac: Probably best if you just subscribe: https://bugs.launchpad.net/xmir/+bug/1216224
[10:15] <duflu> asac: Though once logged in you can change the resolution
[10:17] <mlankhorst> RAOF: well that was easy to fix once I caught the kernel module lying about the source :P
[10:17] <asac> duflu: i can? how?
[10:17] <asac> wait ... cant copy/paste here anymore :((
[10:18] <mlankhorst> RAOF: http://paste.debian.net/30796/ --- enjoy!
[10:18] <duflu> 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:23] <asac> duflu: was asking how to change resolution, but found that it can be done with just the normal preferences dialog
[10:23] <asac> something is really tslow though
[10:24] <duflu> asac: Slow? Yes there's at least one bug for that too
[10:25] <asac> i think its better now
[10:25] <asac> after reboot
[10:25] <asac> still, movig windows is a bit laggy
[10:25] <asac> but so far i can survive... cool
[10:28] <asac> seems i also get some texture artifacts while moving windows
[10:28] <asac> as if the window is split up in multiple pieces and they move out of sync :)
[10:30] <duflu> asac: You may wish to comment on the issues: https://bugs.launchpad.net/xmir/+bugs?field.tag=multimonitor
[10:35]  * duflu goes to organise dinner
[10:36] <RAOF> mlankhorst: Heh. Stride Strikes Again!
[10:36] <RAOF> asac: That sounds pretty cool!
[10:39] <asac> yeah i am happy :)
[10:39] <mlankhorst> RAOF: yes :P
[10:39] <asac> bleeding edge :)
[10:39] <RAOF> mlankhorst: I don't suppose you tried copying just the region that's damaged?
[10:40] <mlankhorst> RAOF: hm is it clipped against the output? :P
[10:40] <mlankhorst> but I guess I could..
[10:40] <RAOF> Yeah.
[10:41] <RAOF> region is always fully contained within dst_box (we do the intersection in the xmir module)
[10:42] <RAOF> So it's not *wrong* to always copy dst_box, but it's a wasteful.
[10:42] <mlankhorst> hm sure
[10:43] <mlankhorst> RAOF: is it guaranteed to be non-zero?
[10:43] <mlankhorst> eg no 0x0,0x0 copy
[10:43] <RAOF> Yes
[10:43] <mlankhorst> kk
[10:44]  * RAOF has weeded out all of these cases by testing on Intel, which uses region :)
[10:44] <RAOF> Man, the NVAccelM2MF declaration is not exactly self-documenting code :)
[10:45] <mlankhorst> it is
[10:46] <mlankhorst> the ofs refers to offset from start of bo, in case of scratch bo usage
[10:46] <RAOF> Aaah.
[10:46] <RAOF> And the rest you can mostly guess.
[10:47] <mlankhorst> source domain, source pitch, source height, x/y
[10:47] <RAOF> source_depth, source_pitch, source_height, source_x, source_y
[10:47] <mlankhorst> domain not depth :p
[10:47] <RAOF> Hah, source *domain*.
[10:48] <RAOF> What does M2MF stand for? Something like Mem 2 Mem copy with Format?
[10:49] <mlankhorst> memory to memory function was my guess, but yours is just as good I suppose
[10:49] <mlankhorst> hm format is probably the right one
[10:49] <mlankhorst> it can convert some formats to others and do some swizzling
[10:51] <mlankhorst> RAOF: oh btw what coordinates is damage_box in then?
[10:51] <RAOF> Screen coordinates.
[10:51] <mlankhorst> so same coordinate system as damage_box ?
[10:52] <RAOF> dst_box? Yes.
[10:52] <RAOF> Hm. We may have been confusing there :)
[10:52] <mlankhorst> you don't say!
[10:52] <RAOF> _region_ is in the same coordinate space as dst_box :)
[10:52] <RAOF> And region is the damage region.
[10:53] <RAOF> Both are in the window coordinate space of the window.
[10:54] <mlankhorst> http://paste.debian.net/30803/
[10:55] <mlankhorst> just guessing.. I'll give it a shot
[10:56] <RAOF> That looks roughly right?
[10:57] <mlankhorst> even seems to draw correctly
[10:57] <RAOF> 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] <RAOF> Ah, well. If it works, it's clearly not that wrong :)
[10:57] <RAOF> The ideal test client is an xterm on a raw X session.
[10:59] <mlankhorst> hm let me find a mouse for that machine, it didn't put focus on the xterm :P
[10:59] <RAOF> Fire up metacity?
[11:02] <mlankhorst> hm xterm -e 'find /' works
[11:04] <mlankhorst> RAOF: first client for x works, but if I kill it and screen returns to black the next client does not..
[11:04] <RAOF> mlankhorst: Yeah, loss of the sole client triggers a server regeneration, and XMir doesn't handle that well at all.
[11:05] <RAOF> Fortunately that should only hit people like us, who test clients on raw X.
[11:05] <RAOF> And, obviously, KDE, should they feel like porting. :)
[11:05] <mlankhorst> RAOF: oh and a major derp was not using damage_box->x1 for src :P
[11:06] <mlankhorst> hm and then not removing dst_box from dst coordinates
[11:06] <RAOF> Ah, right.
[11:06] <RAOF> Yes, I did wonder a bit about that :)
[11:07] <mlankhorst> http://paste.debian.net/30811/ this version is more correct right?
[11:08] <RAOF> Yeah, that looks like what I'd expect.
[11:08] <RAOF> Particularly: it looks like the radeon code :)
[11:11] <tsdgeos> ricmm: tvoss: there?
[11:12] <tsdgeos> ricmm: tvoss: unping
[11:12] <tvoss__> tsdgeos, ;)
[11:15] <mlankhorst> RAOF: odd, does compiz always do full-screen repaints then?
[11:15] <RAOF> mlankhorst: I think compiz is mostly doing glXSwapBuffers now (although you can turn that off)
[11:16] <RAOF> And SwapBuffers implies full-screen repaints.
[11:16]  * RAOF wonders whether it'd be worth teaching Compiz about swap_buffers_with_damage
[11:16] <mlankhorst> it's also very nice for bypass though :P
[11:16] <RAOF> mlankhorst: Indeed.
[11:17] <RAOF> It means that, once we actually implement the sucker, our normal-case overhead is going to be just protocol overhead.
[11:18] <mlankhorst> RAOF: but I'm mostly worried about the vblanking timestamp stuff, I still want accurate vblank on video
[11:19] <RAOF> Yeah, we need to hook that up.
[11:19] <RAOF> 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] <RAOF> You don't get scanline accuracy out of it, but you can approximate vblank with buffer-received.
[11:21] <mlankhorst> that's not accurate vblank :p
[11:21] <RAOF> Yeah, that requires more involved compositor support :)
[11:21] <RAOF> Which I want to do, but is obviously a "not now" thing :/
[11:22] <mlankhorst> the drivers can get that information directly without going through the compositor..
[11:22] <RAOF> Only if the compositor isn't compositing, though?
[11:22] <mlankhorst> they just need to have the correct drm fd for the crtc, and the crtc id..
[11:23] <RAOF> And where on the crtc the window is, yes?
[11:23] <RAOF> 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] <mlankhorst> not really, they just need to know for scheduling decisions
[11:24] <RAOF> As in: what-client-should-get-GPU-time-next decisions?
[11:26] <mlankhorst> 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] <RAOF> mlankhorst: Right, but that really wants compositor support.
[11:27] <RAOF> Because the compositor might introduce a delay
[11:27] <mlankhorst> what about the case of fullscreen bypass?
[11:28] <RAOF> Then can do it, yes.
[11:28] <RAOF> Which is, I agree, a common case.
[11:31] <RAOF> But it's also the case that a client doesn't know if it's bypassed or not.
[11:32] <mlankhorst> RAOF: hm crash when I plugged in a second monitor to ati :P
[11:32] <RAOF> mlankhorst: Yeah. Need to implement a SetScreenPixmap hook for ATI to update info->front*
[11:32] <RAOF> As far as I can tell nouveau doesn't do anything annoying like that.
[11:32] <RAOF> Good job!
[11:33] <mlankhorst> lol
[11:33] <mlankhorst> nvidia does everything in hardware where it can..
[11:36] <alan_g> hikiko: what are you working on?
[11:51] <RAOF> mlankhorst, tvoss: Nouveau uploaded to qa-testing2 PPA. Happy multi-monitor testing!
[11:55] <hikiko> 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] <alan_g> hikiko: ack
[11:56] <hikiko> alan_g, is there any way to check the changes in the display?
[11:56] <alan_g> hikiko: I'm not sure what you're asking
[11:56] <hikiko> or we have to fully implement the native/nested platform first?
[11:59] <alan_g> hikiko: we should be writing tests for the functionality we are working on
[12:00] <hikiko> alan_g, ok but let's first add the functionality :)
[12:01] <hikiko> I have a question on your branch actually
[12:01] <hikiko> + make_current(); // This duplicates what Eleni's original code did - but is it needed?
[12:01] <hikiko> what do you mean?
[12:01] <hikiko> do we swap buffers elsewhere?
[12:04] <alan_g> hikiko: I'm not sure why we'd do this when constructing the object (as opposed to when we render to it)
[12:04] <hikiko> I guess that if we don't we ll see nothing
[12:04] <hikiko> because we render to the back surface
[12:04] <hikiko> and we have to make it current
[12:05] <hikiko> let me see
[12:05] <alan_g> hikiko: rendering calls "make_current()"
[12:06] <hikiko> let me see what make_current does 1 sec
[12:07] <hikiko> make_current binds the context to the current rendering thread
[12:07] <hikiko> and to the draw and read surfaces
[12:09] <mlankhorst> RAOF: erm you failed somewhere
[12:09] <mlankhorst> ;P
[12:10] <mlankhorst> that src pixmap is definitely not covering the entire screen on my multimonitor setup
[12:10] <mlankhorst> proof..
[12:10] <mlankhorst> #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] <mlankhorst>     src=0x7f1600895280, sd=sd@entry=1, sp=5120, sh=sh@entry=1024, sx=sx@entry=1440, sy=sy@entry=0, dst=dst@entry=0x7f1600baf510, dd=dd@entry=1,
[12:10] <mlankhorst>     dp=dp@entry=5120, dh=dh@entry=1024, dx=dx@entry=0, dy=dy@entry=0) at ../../src/nouveau_exa.c:49
[12:10] <mlankhorst> eg pitch = 5120, 1280 * 4
[12:10] <alan_g> hikiko: I have to go make lunch - back in an hour
[12:11] <mlankhorst> but the rects are this:
[12:11] <mlankhorst> [   829.877] (II) NOUVEAU(0): copying pixmap: (1440,0),(2720,1024) with damage (1440,0),(2720,1024)
[12:11] <hikiko> me too :) see you later alan_g|lunch
[12:11] <mlankhorst> and src is this:
[12:11] <mlankhorst> (gdb) print *src
[12:11] <mlankhorst> $1 = {drawable = {type = 1 '\001', class = 0 '\000', depth = 24 '\030', bitsPerPixel = 32 ' ', id = 0, x = 0, y = 0, width = 1280, height = 1024,
[12:11] <mlankhorst>     pScreen = 0x7f1600880700, serialNumber = 2234}, devPrivates = 0x7f16008efca8, refcnt = 1, devKind = 5120, devPrivate = {ptr = 0x0, val = 0,
[12:11] <mlankhorst>     uval = 0, fptr = 0x0}, screen_x = 0, screen_y = 0, usage_hint = 0, master_pixmap = 0x0}
[12:12] <mlankhorst> so I guess your assumption about 1 pixmap to cover everything is wrong ;P
[12:12] <mlankhorst> https://www.youtube.com/watch?v=zTHhwvTJyMU
[12:14] <mlankhorst> 2 screens, first one 1440x900 and the second one 1280x1024
[12:16] <tvoss__> olli_, ping
[12:22] <smspillaz> RAOF: It'd be quite trivial to get compiz working with swap_buffers_with_damage
[12:22] <smspillaz> RAOF: s_b_w_d would need to be implemented in GLX though
[12:22] <smspillaz> and I have no idea if it is
[12:33] <derEremit> hi, can i assume that any support for optimus via bumblebee will be severely broken once the switch to mir is complete
[12:34] <tvoss__> derEremit, well, you can always fallback to vanilla X plus prop drivers in 13.10
[12:36] <derEremit> and probably will have to do that.
[12:36] <derEremit> ;)
[12:41] <tvoss__> derEremit, if you rely on that functionality, yes. However, would be great if you could try the system-compositor, too :)
[12:51] <derEremit> yeah had no positive results this far
[12:53] <tvoss__> derEremit, did you try it from the archive, yet?
[12:53] <derEremit> ppa?
[12:54] <derEremit> well today had other problems
[12:54] <derEremit> started my laptop and couldn't login anymore
[12:54] <derEremit> purged X and mir completely, now it works again ;)
[12:54] <derEremit> i think bumblebee is kind of in the way
[13:12] <tvoss__> RAOF, mlankhorst ping
[13:13] <mlankhorst> pong
[13:13] <mlankhorst> and no, I don't think mir has any support for crtc's that do not belong to the rendering graphics card..
[13:21] <frothnicator> I saw the recent request for testers for the multi-monitor support.  Would a live CD/USB/NetBoot be an appropriate route to test?
[13:25] <balloons> frothnicator, would you be running on real hardware?
[13:31] <alan_g> tvoss__: bypass is top-approved
[13:31] <tvoss__> alan_g, why?
[13:32] <tvoss__> alan_g, please revert that
[13:32] <alan_g> tvoss: ack
[13:32] <alan_g> tvoss: I thought we'd discussed
[13:33] <alan_g> tvoss: I thought we'd discussed doing that
[13:33] <tvoss__> alan_g, nope
[13:34] <alan_g> tvoss__: Misunderstanding then. Sorry
[13:34] <tvoss__> alan_g, ack, no worries
[13:41] <frothnicator> balloons: sorry, stepped out for a minute: yes.
[13:41] <frothnicator> one without discrete graphics card, even.
[13:48] <frothnicator> balloons: So if I were to use a daily saucy (with real hardware), that would be a good for y'all?
[13:49] <tvoss__> frothnicator, that would already help us, yes :)
[13:50] <frothnicator> tvoss__: okay.  Smiley face implies "yes it would help", but I don't understand what you mean by "already"?
[13:50] <kgunn> alan_g: i need to review the numbers w olli first....sorry bout that
[13:50] <tvoss__> frothnicator, the call for testing was referring to ppa:mir-team/system-compositor-testing for multi-monitor
[13:52] <mlankhorst> I thought qa-testing2? :P
[13:53] <frothnicator> tvoss__: thank you.  That was a detail that I apparently missed in the email.
[13:53] <frothnicator> I will work do so this evening.
[13:54] <tvoss__> mlankhorst, no, we copied over to system-compositor-testing iirc, kgunn, can you please cross-check?
[13:55] <kgunn> tvoss: mlankhorst frothnicator ....system-compositor-testing
[13:55] <kgunn> qa-testing2 is still live action
[13:56] <mlankhorst> ah
[13:56]  * mlankhorst is behind then!
[13:57] <frothnicator> kgunn: apologies, I've been out development for a few years, while getting my degree.  I'm not up with what "still live action" means?
[13:58] <kgunn> frothnicator: sorry...i just meant that qa-testing2 was still being used by dev team last night, packages being updated
[13:58] <kgunn> which can sometimes mean "trouble"....package mismatch or some such...
[13:59] <kgunn> whereas system-compositor-testing is static....nothing going in
[13:59] <frothnicator> kgunn: gotcha.  So bottom line is that I should use ppa:mir-team/system-compositor-testing when I get home to test.
[13:59] <kgunn> frothnicator: yes sir
[14:00] <frothnicator> kgunn: quick worflow: Saucy Daily + add-apt-repository ppa... + restart lightdm?
[14:00] <frothnicator> or quantal livecd + add-apt-repository paa... + restart lightdm?
[14:01] <kgunn> frothnicator: instructions here https://wiki.ubuntu.com/Mir/MultiMonitorTesting
[14:01] <kgunn> frothnicator: quantal ?....we're all saucy...so, as long as you get to saucy recent....
[14:03] <frothnicator> kgunn: you know, I missed the first email in that thread, so I'll bet you spelled all this out. With that last link, I htink I'm good to go.  However, I note that one of the instructions is to reboot: that implies a hard install rather than a LiveCD, or is that step fungible?
[14:04] <kgunn> frothnicator: you can also "restart lightdm" rather than reboot
[14:05] <kgunn> frothnicator: someone else gave me a hard time about that too :)
[14:05] <kgunn> frothnicator: i just reboot
[14:05] <kgunn> frothnicator: so my instructions just ended up being what i do :)
[14:06] <frothnicator> kgunn: Heh, roger.  From my perspective, I'm not heavy in to distro development, so all I have to test with are machines that I actually use.  Ergo, a temporary measure (i.e., LiveBoot) is what I need.
[14:06] <frothnicator> kgunn: Okay.  I'll report to Launchpad anything I find tonight.  Thanks for the help.
[14:07] <kgunn> frothnicator: thanks!
[14:10] <frothnicator> kgunn: not knowing how many "people like me" who might drop in, you might consider updating that wiki page to say just "Restart LightDM".  I would think that most folks would know that rebooting restarts the display manager automatically, whereas the reverse is not true.  I tend to associate "necessary rebooting" with "new kernel only".  Just a thought.  Cheers.
[14:11] <kgunn> frothnicator: thanks...i'll have to poke someone...it was editable...then some jake-leg made it immutable...geeze
[14:11] <kgunn> balloons: ^
[14:11] <kgunn> balloons: can we update the instructions to include "restart lightdm" ?
[14:12] <frothnicator> kgunn: hah.  I know the feeling.  The vicissitudes of working with other people.  :-)
[14:12] <kgunn> :)
[14:12] <kgunn> well-intentioned i'm sure
[14:14] <frothnicator> absolutely.
[14:14] <frothnicator> alright, I'm out.  Thanks again.
[14:14] <balloons> kgunn, sure thing.. you mean restarting lightdm after install?
[14:14] <balloons> perhaps that didn't end up on the wiki
[14:15] <kgunn> balloons: right
[14:15] <kgunn> i know someone spoke to me about it...i thot i added it....
[14:15] <kgunn> but i think it got moved in some edits when olli was going for twd
[14:16] <balloons> I do see it in there.. I remember adding the command to it
[14:16] <balloons> and indeed, it's in there
[14:16] <balloons> look in setup
[14:32] <frothnicator> balloons: I was the one suggesting to be consistent if you didn't need to fully restart the machine.  The specific line in setup is "Reboot and re-verify you are running Xmir."  I think I described my thought process fairly well about 22 minutes ago.
[14:33] <frothnicator> (but if I didn't, or if doesn't matter, feel free to tell me to move along.)
[14:34] <balloons> frothnicator, no, I agree just lightdm should be noted.. but I don't see where the line of reboot and re-verify is at
[14:35] <frothnicator> balloons: can you not find (via search, perhaps?) in the page what I just quoted (which I copy/pasted)?
[14:35] <frothnicator> balloons: maybe we're talking about different pages?  https://wiki.ubuntu.com/Mir/MultiMonitorTesting
[14:36] <balloons> frothnicator, k, I'll search again :-)
[14:36] <balloons> ahh, ok
[14:36] <frothnicator> balloons: I know, I know.  Stupid lusers like "frothnicator".  :-)
[14:38] <balloons> frothnicator, not at all. I just missed the line before.. i'm quite human and do such things I assure you
[14:38] <balloons> take a look now
[14:39] <frothnicator> balloons: heh, sometimes helps to clear ones cache: three reloads and on Ctrl+Shift+R later, I see the update!  Cheers.
[14:40] <balloons> excellent, thanks for pointing it out!
[14:40] <frothnicator> np.
[15:03] <hikiko> alan_g, kgunn +anyone else available meeting?
[15:58] <kgunn> bschaefer: hey...i really need your help
[15:59] <bschaefer> kgunn, what up? (I forgot about vUDS...)
[16:02] <kgunn> bschaefer: i have a blocker for unity (you prob heard?)
[16:02] <kgunn> https://bugs.launchpad.net/unity-system-compositor/+bug/1216979
[16:03] <bschaefer> kgunn, yup, thats what im working on right now!
[16:03] <kgunn> bschaefer: could you take a look ?
[16:03] <kgunn> oh great
[16:03] <kgunn> thank you
[16:03] <bschaefer> kgunn, yupp!
[16:03] <bschaefer> kgunn, np! Its a strange failure, as I can get manually use it...soo no regression from what i see...
[16:03] <bschaefer> as I can manually*
[16:09] <tvoss> bschaefer, please check if keycodes are correct, according to pitti, something changed in that respect
[16:10] <bschaefer> tvoss, yeah, I was just reading that email... that would explain the x error
[16:12] <tvoss> bschaefer, yeah, please see if you can track it down
[16:12] <bschaefer> tvoss, will do, good think is I can at lease manually use it, so no regression, just a very strange problem
[16:13] <bschaefer> thing*
[16:13] <bschaefer> ...
[16:13] <tvoss> bschaefer, ack
[16:14] <tvoss> bschaefer, got a link to that mail?
[16:14] <bschaefer> tvoss, hmm a recent one? no
[16:15] <bschaefer> tvoss, also this happens outside of xmir as well
[16:15] <tvoss> bschaefer, ?
[16:15] <kgunn> bschaefer: i was thinking just that...
[16:16] <kgunn> input not in xmir...input is left to the traditional x path
[16:16] <bschaefer> tvoss, as I don't have xmir running right now, and I still have the failure
[16:16] <bschaefer> kgunn, ^
[16:16] <tvoss> bschaefer, ack, thx
[16:16] <bschaefer> sooo whats causing this is some sort of update somewhere...which could be the new ibus update, or the email pitti sent out
[16:16] <bschaefer> tvoss, np!
[16:17] <tvoss> bschaefer, can you please update the issue report/bug report accordingly?
[16:17] <bschaefer> tvoss, yup!
[16:17] <tvoss> bschaefer, thx
[16:17] <bschaefer> np
[16:22] <bschaefer> tvoss, moved the bug blame to unity, as im still not sure where the problem came from and marked invalid for u-s-c
[16:25] <kgunn> bschaefer: : thank you for taking care....is there someone we should manually poke on ?
[16:26] <kgunn> as i understand its a stopper
[16:26] <bschaefer> kgunn, me :), i did most of that implementation in unity/nux plus most of the AP tests....
[16:26] <tvoss> thomi, can you please help bschaefer tracking down the issue? we are blocking a lot of releases right now
[16:26] <kgunn> bschaefer: please allow yourself to ...poke....yourself
[16:26] <bschaefer> kgunn, will do!
[16:26] <kgunn> :)
[16:26] <bschaefer> bschaefer, get to work!
[16:27] <kgunn> :))
[16:35] <thomi> tvoss: sure, I can lend my sleep-deprived brain to the cause.
[16:35] <thomi> bschaefer: what do you need?
[16:35] <bschaefer> thomi, sooo Multi_Key doesn't match any keybod
[16:35] <bschaefer> keycode in autopilot?
[16:36] <bschaefer> possibly removed, or somehow worked before?
[16:36] <thomi> errr... we're using the X11 keyboard?
[16:37] <bschaefer> hmm now we are getting a 0 from the x11 keyboard?
[16:40] <bschaefer> thomi, this is where its failing:
[16:40] <bschaefer> get_display().keysym_to_keycode(keysym)
[16:41] <thomi> hmmm
[16:41] <bschaefer> the keysym seems about right: 65312, ill double check
[16:41] <bschaefer> sooo it can't find the key on the keyboard
[16:41] <bschaefer> which would explain  the error...
[16:41] <thomi> bschaefer: indeed
[16:41] <bschaefer> thomi, at the end of this, ill push a branch to give some sort of error if that returns 0
[16:41] <thomi> this is the issue with the X11 bindings
[16:42] <bschaefer> right, soo i wonder if its due to keyboard layouts? I swear this worked before though...
[16:42] <bschaefer> on a normal X keyboard
[16:42] <bschaefer> err
[16:43] <bschaefer> normal english US keyboard
[16:43] <thomi> bschaefer: presumably that's the keymap you're using as well though, right?
[16:44] <bschaefer> thomi, and yup getting the right keysym:
[16:44] <bschaefer> #define XK_Multi_key                     0xff20
[16:44] <bschaefer> thomi, yes, but when I wrote the tests I do remember it working :)
[16:44] <bschaefer> thomi, i've also tried french layout though
[16:44] <bschaefer> which does have the multi key, and it does work manually
[16:45] <thomi> hmmm
[16:45] <thomi> what happens if you manually set the keycode?
[16:45] <bschaefer> thomi, hmm isn't the keycode dependent on the hardware? ie. its not always the same for each key?
[16:46] <bschaefer> thomi, but ill try to get it from some x tool I forgot the name of
[16:46] <thomi> ahh, sorry, I misunderstood.. keysym vs keycode :-/
[16:47] <bschaefer> xev, but hmm I think I might be missing up multi key vs composite key?
[16:48]  * bschaefer now does not remember where the hell the multi key is...
[16:49] <thomi> bschaefer: the composite key can be bound to some other key on your KB. perhaps the multi key can as well
[16:49] <bschaefer> thomi, right, I think I've confirmed the composite key is working, not the multi key though (testing through xev)
[16:50] <bschaefer> as if I can find the mutlikey on the keyboard through xev, we should have a keycode but now im wondering if its missing?
[16:50] <thomi> yeah, I dunno
[16:51] <bschaefer> :), yeah I just have to refresh my self on how to type it, sine I don't use it regularly
[16:52] <bschaefer> thomi, hmm I wonder if the OSK would have a nice button that we could press...
[16:52] <bschaefer> if it doesn't exist it *might* cause it to crash... or spit some error out
[16:54] <thomi> bschaefer: I think it would be instructive to get someone with a french keyboard to try this
[16:54] <bschaefer> thomi, it would be helpful
[16:54] <bschaefer> seb128, ping
[16:54] <seb128> bschaefer, hey
[16:54] <bschaefer> seb128, can you confirm the multi is on your keyboard through xev?
[16:54] <bschaefer> multi key*
[16:55]  * bschaefer is unable to find it on any keyboard layouts
[16:55] <seb128> what is "the multi key"?
[16:55] <bschaefer> seb128, thats what im trying to figure out :), I remember it being like the dead key...but its been a while now...
[16:55] <seb128> I've no clue about those things...
[16:55] <bschaefer> seb128, no worries! Thanks :)
[16:57] <seb128> bschaefer, sorry for not being able to help, but feel free to ping if you have more specifics
[16:57] <bschaefer> thomi, hmm it seems the composite key is the multi key?
[16:57] <seb128> bschaefer, http://www.linuxhowtos.org/Tips%20and%20Tricks/compose.htm
[16:57] <seb128> seems to indicator it's the composite key indeed
[16:57] <bschaefer> seb128, no worries, right, but I can't get the multi key sym to come up
[16:57] <bschaefer> #define XK_Multi_key                     0xff20
[16:57] <bschaefer> seb128, which is what we are asking python to enter
[16:58] <thomi> hmmm
[16:58] <bschaefer> but it doesn't seem to exist on the keyboard...
[17:01] <bschaefer> thomi, haha, im seeing the "compose key" as disabled... in the new text entry chart?
[17:01] <thomi> what's that?
[17:01] <bschaefer> err
[17:02] <bschaefer> thomi, go to your keyboard indicator, Text Entry Settings
[17:02] <bschaefer> thomi, then select your layout (french possibly), then press keyboard settings
[17:02]  * bschaefer tests if this is the problem
[17:03] <thomi> I have "Compose Key" set to Caps lock
[17:03] <bschaefer> thomi, then the test should ... *should* pass for you
[17:03] <thomi> what's the test id?
[17:03] <bschaefer> thomi, autopilot run unity.tests.test_dash.DashMultiKeyTests.test_multi_key_copyright
[17:04] <seb128> bschaefer, thomi: that test works for me on saucy
[17:04] <seb128> (session is running since yesterday)
[17:05] <bschaefer> thomi, worked :)
[17:05] <bschaefer> seb128, soo it seems the composite key is disabled by default now in the keyboard layout?
[17:05] <thomi> bschaefer: so I'm doing the autopilot 1.4 development, which means my system is full of 1.4 packages, so I can't run those tests, but I think we found the issue anyway
[17:05] <bschaefer> seb128, but im not sure if it was ever enabled though...for US en keyboard I don't think it even exists...
[17:05] <thomi> bschaefer: I suggest making the unity AP test set the compose key at the start of the test
[17:06] <bschaefer> thomi, right, that'll be fun to figure out
[17:06] <thomi> bschaefer: shouldn't be too hard :)
[17:06] <seb128> bschaefer, yeah, I'm not sure, I can't see why that would have changed recently
[17:06] <bschaefer> thomi, hopefully :)
[17:07] <bschaefer> seb128, yeah...this is why im wondering why all of sudden things have changed...as I don't remember having to set this before...
[17:07] <seb128> bschaefer, or it might be a fallout of the new g-s-d/ibus/indicator-keyboard ... though that happened a week ago and test starting failing more recently
[17:08] <bschaefer> seb128, hmm possibly, but now to figure out to set that in python...
[17:08] <bschaefer> tvoss, kgunn found problem, now to just find the fix
[17:08] <bschaefer> tvoss, kgunn composite key is disabled, causing it to not exist on the keyboard, ie. x key code error
[17:09] <seb128> bschaefer, system("setxkbmap -option compose:rwin")? ;-)
[17:09] <thomi> bschaefer: there's support for gsettings in unity module I believe
[17:09] <thomi> seb128: s/system/subprocess/ at least :)
[17:09] <bschaefer> seb128, that would work, but Ill look for a gsettings fix first
[17:09] <bschaefer> seb128, unless we want to get a fix out
[17:09] <seb128> thomi, right, I was not suggesting code, just giving the idea
[17:09] <thomi> seb128: yep :)
[17:09] <bschaefer> then get a better fix in..
[17:10] <seb128> bschaefer, well, mir stack and unity-system-compositor are being stucked until we resolve that
[17:10] <seb128> bschaefer, I'm sure the mir team is going to get angry soon
[17:10] <bschaefer> right which makes me want to get this out ASAP
[17:10] <bschaefer> yeeah...
[17:11] <thomi> so maybe seb128's idea is the fastest
[17:11] <bschaefer> thomi, yeah, hmm umm
[17:11] <bschaefer> thomi, let me just add that to the ctor for multi key tests...
[17:11] <bschaefer> then get a real fix in later today
[17:11] <thomi> bschaefer: you mean in setUp?
[17:11] <bschaefer> thomi, well thats the ctor right?
[17:12]  * bschaefer does to much c++
[17:13] <thomi> heh. I thought you meant __init__
[17:13] <bschaefer> thomi, nope, the constructor for the multi key class :)
[17:13] <seb128> bschaefer, I can confirm the test failing in a guest session, I'm going to try to figure out what changed
[17:13] <thomi> seb128: I'm reasonably sure that the compose key used to be set to something by default
[17:14] <seb128> right, but where/by what
[17:14]  * bschaefer is unsure but shouldn't have relied on that...
[17:14] <thomi> that I don't
[17:14] <bschaefer> we should have set our own, then reset the default...but yes
[17:15] <bschaefer> thomi, soo subprocess for python, using popen?
[17:16] <bschaefer> as i can confirm this is fixing it when its turned off: setxkbmap -option compose:rwi
[17:16] <bschaefer> n
[17:16] <bschaefer> setxkbmap -option compose:rwin*
[17:16] <thomi> bschaefer: so you can run something like:
[17:16] <bschaefer> thomi, I just want to make sure I at lease get this quick fix working :)
[17:16] <thomi> subprocess.call(["setxkbmap", "-option", "compose:rwin*"])
[17:17] <bschaefer> thomi, thanks let me test that out!
[17:17] <bschaefer> thomi, also the * was for my spelling mistake :)
[17:17] <bschaefer> missing the n in win
[17:26] <bschaefer> thomi, confirmed working...
[17:26] <bschaefer> just pushed a branch
[17:28] <bschaefer> thomi, seb128 https://code.launchpad.net/~brandontschaefer/unity/enable-compose-key/+merge/182454
[17:28] <seb128> bschaefer, I'm not going to nitpick on the empty lines changes :p
[17:28] <bschaefer> seb128, yeeah I know thomi loves them being removed
[17:28] <bschaefer> soo I have it set up to remove python empty lines :)
[17:29] <seb128> bschaefer, approved
[17:29] <bschaefer> seb128, thanks, and sorry about not getting this fixed yesterday!
[17:29] <thomi> bschaefer: LGTM
[17:29]  * bschaefer wasn't aware it was blocking yesterday...
[17:29] <bschaefer> thomi, thanks
[17:29] <seb128> bschaefer, no worry, thanks for fixing it today ;-)
[17:29] <bschaefer> seb128, you welcome, now to find a correct fix :)
[17:30] <bschaefer> your*
[17:30] <bschaefer> my keyboard likes leaving off keys...
[17:30] <bschaefer> kgunn, tvoss MP to quickly fix here:
[17:30] <bschaefer> https://code.launchpad.net/~brandontschaefer/unity/enable-compose-key/+merge/182454
[17:30] <seb128> bschaefer, "you're*" you mean :p
[17:30] <seb128> bschaefer, I'm trying to diff build logs between the working and non working version, I would like to figure out what update created the issue
[17:30] <bschaefer> seb128, yup haha...
[17:31]  * bschaefer has to many things going on...
[17:32] <bschaefer> seb128, though you seem to have a much better handle on multiple conversations :)
[17:32] <seb128> lol, you get used to it (or not) ;-)
[17:32] <bschaefer> haha
[17:32] <bschaefer> hopefully soon!
[19:43] <om26er> is there a way to turn off the screen on mako while using Mir ?
[19:43] <cub> How long during tomorrow will the multi-monitor test run?
[19:48] <cub> as per https://wiki.ubuntu.com/Mir/MultiMonitorTesting .
[21:10] <kgunn_> robert_ancell mornin
[21:10] <robert_ancell> kgunn_, hey
[21:10] <robert_ancell> kgunn_, robotfuel do you want just bypass or bypass + MM?
[21:11] <kgunn_> robert_ancell bypass
[21:11] <robotfuel> robert_ancell: let me know when it's ready so I can start tests
[21:11] <robert_ancell> kgunn_, ok, we've never had just bypass before, but can spin that up - is there any need for bypass+MM anymore? I'll reuse qa-testing if that's OK
[21:11] <kgunn_> robert_ancell at least mm+bypass didn't seem to work on Ati
[21:12] <kgunn_> robert_ancell to be clear qa-testing not qa-testing2
[21:12] <robert_ancell> kgunn_, so qa-testing has always been bypass+mm, I'll convert it to just bypass
[21:13] <robert_ancell> and qa-testing2 stays unchanged at mm
[21:13] <kgunn_> robert_ancell ah might be true for mir part
[21:13] <kgunn_> robert_ancell just need a working bypass
[21:13] <robert_ancell> ok, will do
[21:14] <kgunn_> robert_ancell I didn't try qa-testing on intel - maybe it works
[21:14] <kgunn_> ?
[21:15] <kgunn_> robert_ancell thanks
[21:16] <kgunn_> robotfuel so is archive xmir working on that machine ?
[21:16] <kgunn_> might be good to verify that
[21:16] <robotfuel> kgunn_: on which machine?
[21:16] <robotfuel> kgunn_: the radeon webcam machine?
[21:19] <robotfuel> it worked this morning http://10.97.2.12:8080/view/openarena/job/openarena-benchmark-ps-radeon-hd5750-le-xmir/43/
[21:22] <robotfuel> robert_ancell: http://10.97.2.12:8080/job/qa-ppa-guitoolkits-ps-intel-3000/ intel worked with the qa-testing ppa
[21:22] <robotfuel> kgunn: ^
[21:26] <robert_ancell> robotfuel, kgunn, ppa:mir-team/qa-testing is being converted to bypass only. Will take ~40 mins
[21:33] <kgunn> robert_ancell: thanks....hmmm, just wondering....earlier there were xorg packages there with latest ati drivers...wonder if those were the issue ??
[21:34] <kgunn> robert_ancell: since no one has seen mm on ati yet...just thinking aloud
[21:38] <robert_ancell> kgunn, right, they were needed for mm support and they didn't work. There are updated drivers in qa-testing2 that do work
[21:39] <robert_ancell> kgunn, right, rsalveti was using the MM3 ati driver from qa-testing2 and it worked for single monitor, but I don't think he had any success with multi-monitor
[21:42] <rsalveti> just in mirrored mode, booting with both monitors connected
[21:42] <rsalveti> kgunn: I updated the qa tracker with the results
[21:44] <kgunn> rsalveti: thank you
[21:49] <rsalveti> no worries
[22:11] <kgunn> robotfuel: qa-testing any moment now
[22:12] <robert_ancell> LP, faster with the publishing already :)
[22:12] <robotfuel> heh
[22:12] <robert_ancell> Note, there's a u-s-c upload after Mir is done, but that doesn't take too long
[22:14] <kgunn> robert_ancell: right!
[22:32] <robotfuel> robert_ancell: is it ready?
[22:32] <robert_ancell> robotfuel, almost...
[22:39] <robert_ancell> kgunn, robotfuel, published! Note, I haven't run these packages yet, this is just lp:mir+lp:~vanvugt/mir/bypass and lp:unity-system-compositor
[22:41] <robotfuel> ok I'll run the tests
[22:41] <robert_ancell> Hmm, 1:20 to update - I'll revise my estimate for next time
[22:41] <robotfuel> robert_ancell: kgunn do you care which test runs first?
[22:45] <robert_ancell> I don't
[22:53] <kgunn> robert_ancell: i'm going to step out...but the main thing is to see radeon X vs Xmir vs Xmir+bypass....if xmir/xmir-bypass is better than X...why?
[22:53] <kgunn> please email share with tvoss any findings
[22:54] <robert_ancell> kgunn, what is this for?
[22:54] <robert_ancell> robotfuel, do we have the radeon X / XMir numbers at the moment?
[22:55] <robotfuel> robert_ancell: http://reports.qa.ubuntu.com/graphics/openarena/
[22:56] <robert_ancell> robotfuel, ta
[22:57] <robotfuel> robert_ancell: you can doubleclick on a bar to go to the jenkins build results for that benchmark.
[22:57] <robert_ancell> clever!
[22:57] <robotfuel> robert_ancell: the screen looks messed up on the radeon machine
[22:57] <robotfuel> kgunn: ^
[22:58] <robert_ancell> :(
[22:58] <robert_ancell> yeah, I can see it on the video
[22:59] <robert_ancell> robotfuel, can you confirm the versions of packages on that machine?
[22:59] <robotfuel> robert_ancell: I'll pastebin, one second
[22:59] <robert_ancell> ta
[23:03] <robotfuel> http://paste.ubuntu.com/6034625/ <- robert_ancell
[23:03] <robert_ancell> robotfuel, they look correct
[23:04] <robert_ancell> robotfuel, was the video corrupt at all times or just during parts of the test?
[23:04] <robotfuel> robert_ancell: after rebooting in to xmir
[23:04] <robotfuel> robert_ancell: I'll reboot again to double check
[23:04] <robert_ancell> robotfuel, right
[23:06] <robotfuel> robert_ancell: it's bad after reboot
[23:07] <robert_ancell> robotfuel, the previous XMir run is using reasonably old Mir packages - we should run that again and confirm if it's the main archive that's broken and not bypass that's making the difference
[23:07] <robotfuel> robert_ancell: xmir tests ran okay earlier today.
[23:07] <robert_ancell> the last run was mir 0.0.9+13.10.20130821.1-0ubuntu1, archive is 0.0.9+13.10.20130822-0ubuntu1 and  0.0.10+13.10.20130827.1-0ubuntu1 is in proposed
[23:08] <robotfuel> *xmir from archive
[23:08] <robert_ancell> actually, everything seems held up in proposed - anyone know why that is?
[23:08] <robert_ancell> olli, ^?
[23:09] <robotfuel> robert_ancell: I think it was because of xmir crashing on didrocks ati machine
[23:10] <robert_ancell> robotfuel, I thought we'd resolved that / weren't going to block on it
[23:11] <robotfuel> robert_ancell: I need to commute home, I have to restart the camera in a screen session, you'll have to refresh
[23:11] <robert_ancell> robotfuel, this is just qa-ppa right?
[23:12] <robotfuel> robert_ancell: yes
[23:12] <robert_ancell> robotfuel, and just cancel jobs by right clicking on the X beside them? i.e. the machine will restart automatically?
[23:12] <robotfuel> robert_ancell: yes
[23:13] <robert_ancell> ok, thanks!
[23:13] <robotfuel> robert_ancell: the machine will restart automatically on the next test run
[23:13] <robert_ancell> robotfuel, what are all the new jobs? Still doing a run all?
[23:14] <robert_ancell> and which machine is the camera pointed at?
[23:14] <robotfuel> robert_ancell: I didn't add all the new jobs to run all.
[23:14] <robert_ancell> ok
[23:14] <robotfuel> robert_ancell: the machine is pointed at ps-radeon-5750-le
[23:14] <robotfuel> *ps-radeon-hd5750-le
[23:15] <RAOF> Ok, so XMir really does not like the bypass branch.
[23:17] <robert_ancell> RAOF, you're seeing it too?
[23:18] <RAOF> robert_ancell: Oh, what in particular? Crazy horizontal missing rendering?
[23:19] <robert_ancell> RAOF, yep horizontal corrupt lines
[23:20] <RAOF> I wonder if that's not missing flushing.
[23:21] <RAOF> But it doesn't look like any corruption that I'm familiar with.
[23:21] <robert_ancell> RAOF, you have some ati hardware right?
[23:21] <RAOF> robert_ancell: I do, yes.
[23:21] <robert_ancell> RAOF, can you confirm the mir from -proposed works?
[23:22] <robert_ancell> we're somewhat behind because I think there's a block on mir
[23:22] <RAOF> Sure.
[23:23] <robert_ancell> robotfuel, still there?
[23:23] <robotfuel> robert_ancell: the run all test for qa-ppa will now run all openarena, guitoolkits and nexuiz tests for the qa-testing ppa
[23:24] <robert_ancell> robotfuel, the camera link doesn't seem to be working
[23:24] <robotfuel> robert_ancell: I just restarted it in screen
[23:24] <robert_ancell> ah, ok now
[23:24] <robert_ancell> hi!
[23:25] <robert_ancell> interestingly the video only seems to work in chromium, not firefox
[23:25] <robotfuel> I am using simplecv to stream video
[23:26] <robert_ancell> RAOF, is that the type of corruption you were thinking of?
[23:27]  * robotfuel commutes home
[23:27] <robert_ancell> robotfuel, bye, thanks for your help!
[23:28] <RAOF> robert_ancell: No; the corruption I was thinking of is more transient.
[23:28] <RAOF> And is on intel.
[23:28] <robert_ancell> ah
[23:35] <robert_ancell> thomi, would it be possible to make jenkins have a job that uses -proposed?
[23:36] <robert_ancell> I'd like to test the Mir -proposed packages
[23:36] <thomi> robert_ancell: sure, robotfuel has a fancy script.
[23:36] <RAOF> robert_ancell: Just to check, you want me to test just stuff in saucy-proposed on ati?
[23:36] <thomi> what kind of timeline would you like that by? is it OK if I ask Chris to do it tomorrow, or do you need it today?
[23:38] <robert_ancell> thomi, ideally now...
[23:38] <robert_ancell> RAOF, yes
[23:39] <robert_ancell> I'm a bit worried that RAOF wont reproduce the problem and we'll be unsure if it's a bypass issue on that QA machine or a Mir issue
[23:41] <ricmm> hey guys, where do we stand with stuff not going from proposed to main?
[23:41] <robert_ancell> ricmm, I don't know what it's blocked on now, I'm trying to find out
[23:42] <RAOF> robert_ancell: usc in -proposed seems to be built against the wrong version?
[23:42] <robert_ancell> RAOF, is it built against the main version of mir?
[23:43] <robert_ancell> ricmm, is there a particular feature you need to depend on?
[23:45] <RAOF> robert_ancell: Oh. There *is* no usc in proposed!
[23:45] <robert_ancell> RAOF, ah, that's going to mess shit up
[23:45] <RAOF> Yes indeed :)
[23:45] <robert_ancell> thomi, ok, -proposed wont work on Jenkins anyway, so no need to do that
[23:46] <ricmm> robert_ancell: yea, the lifecycle stuff that landed a couple of days ago
[23:46] <robert_ancell> RAOF, who do we ask / what channel to find out why a package has a block on it?
[23:47] <RAOF> #ubuntu-devel or #-release would work.
[23:48] <robert_ancell> RAOF, ah, -release was the name I couldn't remember
[23:48] <robert_ancell> thanks!