| === bschaefer_ is now known as bschaefer | ||
| RAOF | What? xmir_submit_rendering_for_window is never called? | 00:32 |
|---|---|---|
| RAOF | Ahem. | 01:08 |
| RAOF | I don't *call* xmir_submit_rendering_for_window. | 01:08 |
| RAOF | Oops. | 01:08 |
| RAOF | Well, that's really annoyingly stupid. | 01:24 |
| robert_ancell | RAOF, whoops? | 01:46 |
| 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:47 |
| RAOF | Because I do call xmir_submit_rendering_for_window there. | 01:49 |
| 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:50 |
| 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 | 01:59 |
| RAOF | robert_ancell: I think you need to modify the Architecture of u-s-c, right? | 02:00 |
| robert_ancell | RAOF, ah, true - thanks! | 02:01 |
| smspillaz | argh | 02:02 |
| 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:03 |
| smspillaz | RAOF: but the shipping cost kinda negates buying them from there | 02:04 |
| 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:05 |
| 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:06 |
| RAOF | robert_ancell: Do we build mir on arm64? | 02:09 |
| 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:10 |
| 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:22 |
| thomi | errr, not work related :-/ | 02:23 |
| RAOF | thomi: Sure. | 02:23 |
| robert_ancell | RAOF, qa-testing2 is good for ati/nouveau testing? | 02:51 |
| RAOF | robert_ancell: qa-testing2 is good for ati/nouveau testing. | 03:17 |
| === chihchun_afk is now known as chihchun | ||
| RAOF | Lunch time! | 03:33 |
| 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, :( | 03:57 |
| rsalveti | mir doesn't like my radeon :-( | 04:32 |
| rsalveti | [ 34.161] (EE) Failed to map vb -2 | 04:34 |
| 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:35 |
| 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:36 |
| robert_ancell | rsalveti, you could try the MM3 xserver-xorg-video-ati package from https://launchpad.net/~mir-team/+archive/qa-testing2 | 04:37 |
| 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:38 |
| 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:39 |
| rsalveti | alright, let me try another reboot :-) | 04:42 |
| rsalveti | brb | 04:42 |
| tvoss__ | duflu_, ping | 04:47 |
| tvoss__ | olli_, ping | 04:47 |
| 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:51 |
| duflu_ | tvoss__: pong? | 04:52 |
| === duflu_ is now known as duflu | ||
| duflu | to the luncheon | 04:54 |
| robert_ancell | RAOF, looks like the new nouveau driver didn't work on Jenkins | 04:57 |
| 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:00 |
| rsalveti | so it seems ati is working with mm3 | 05:01 |
| rsalveti | at least single-monitor | 05:01 |
| 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:39 |
| RAOF | duflu: Apparently apple.com.au don't have mDP → DP cables?! | 05:49 |
| duflu | RAOF: Yeah just noticed. Only mDP to DVI | 05:49 |
| duflu | RAOF: Shipping from Perth :) http://ple.com.au/ViewItem.aspx?InventoryItemID=609956&CategoryID=427 | 05:50 |
| 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:51 |
| 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:53 |
| duflu | Supports all your 4K monitors ;) | 05:54 |
| rsalveti | bug 1217195 | 05:56 |
| ubot5 | 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 |
| rsalveti | bug 1217199 | 05:56 |
| ubot5 | 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:56 |
| rsalveti | multimonitor works here only in mirrored mode | 05:57 |
| * duflu also notes he's slightly closer to Lenovo factories (Shenzhen)... Seems the East is more isolated ;) | 05:59 | |
| * duflu ignores the fact that his Lenovos are second-hand and came from the eastern states | 06:10 | |
| mlankhorst | RAOF: did you figure out the issue yet? | 06:24 |
| RAOF | mlankhorst: Yup, failure to call xmir_submit_rendering_for_window. | 06:25 |
| mlankhorst | https://www.youtube.com/watch?v=zTHhwvTJyMU | 06:25 |
| 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:28 |
| 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:30 |
| 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:35 | |
| duflu | Excellent. I've lost the ability to VT switch. That's an annoying Mir/X bug that's happened before | 06:36 |
| duflu | RAOF: Nope. Still happens. But at least I seem to have a test case now | 06:39 |
| RAOF | duflu: Wow. Have you tried MM XMir on your timerless branch? | 06:47 |
| duflu | RAOF: No... ? | 06:47 |
| 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:48 |
| 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:49 |
| duflu | RAOF: Same. Can you verify bypass does the same, and also with no buffer_age? | 06:50 |
| RAOF | Sure. | 06:52 |
| 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 | 06:59 |
| RAOF | duflu:Huh! | 07:02 |
| RAOF | Turns out I *have* been testing without buffer_Age | 07:02 |
| 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:06 |
| 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:07 |
| duflu | Back in a tick | 07:10 |
| duflu | Or a few beats | 07:10 |
| duflu | RAOF: Suggestions for avoiding beats? Sync to the slowest output instead? | 07:23 |
| duflu | Though I'm not too sure how such an algorithm would go... | 07:25 |
| mlankhorst | RAOF: oh btw tiling fail on nouveau | 07:29 |
| mlankhorst | bigtime :P | 07:29 |
| mlankhorst | and the screen is now reduced to random noise | 07:30 |
| mlankhorst | looks like freed b uff | 07:32 |
| mlankhorst | buffers are being copied to the screen, or something | 07:32 |
| mlankhorst | .. which might not be different from the ati case I was hitting.. | 07:33 |
| duflu | mlankhorst: Running what? | 07:34 |
| mlankhorst | qa-testing2 on a single monitor setup | 07:35 |
| duflu | Hmm | 07:38 |
| RAOF | mlankhorst: Hrm. Works fine for me on ati single | 07:38 |
| RAOF | -monitor. | 07:39 |
| 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:40 |
| 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:43 |
| 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:44 |
| mlankhorst | RAOF: hm radeon is correct now, I'll poke nouveau a bit more | 07:49 |
| 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:50 |
| mlankhorst | single monitor resize worked, but I don't know if it resizes when lowering the resolution.. | 07:53 |
| RAOF | Hm. | 07:55 |
| 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:56 |
| RAOF | mlankhorst: I have now :) | 07:57 |
| mlankhorst | or the ati changes for that matter :P | 07:57 |
| duflu | That's new. My VT font is now only 8px high | 08:00 |
| alan_g | hikiko: good morning. How are things? | 08:10 |
| 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:12 |
| 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:13 |
| alan_g | hikiko: All team members, including you, have a responsibility to review MPs | 08:14 |
| hikiko | you mean all the mps? | 08:14 |
| alan_g | hikiko: if no-one reviews them they don't land and we get a backlog | 08:15 |
| 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:16 |
| hikiko | ok, so I guess I have to start reviewing? | 08:17 |
| duflu | For reviews, just keep in mind this week the priorities are multi-monitor and bypass proposals | 08:18 |
| alan_g | hikiko: start with any easy ones (small & things you know) - it make the list smaller. | 08:19 |
| 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:21 |
| 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:23 |
| mlankhorst | RAOF: heh all that silly stuff about bo creation in nouveau.. there are easier ways to do so :P | 08:41 |
| RAOF | mlankhorst: I don't think it adds an extra copy for the single-monitor case? | 08:50 |
| 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:51 |
| RAOF | mlankhorst: On a display at (x, y), output_box->x1 will be x, but damage_box->x1 will be >= x | 08:52 |
| mlankhorst | RAOF: I mean that the current path requires always making a copy.. | 08:53 |
| 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:54 |
| mlankhorst | RAOF: yeah but ideally it'd just be a flip | 08:55 |
| 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:56 |
| RAOF | Well, that's rather odd. | 08:57 |
| mlankhorst | RAOF: any idea where the XY_OUT_OF_BOUNDS is coming from at least? | 08:57 |
| RAOF | Ahem. | 08:58 |
| 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 | 08:59 |
| mlankhorst | RAOF: http://paste.debian.net/30763/ | 09:00 |
| RAOF | Woohoo! | 09:00 |
| duflu | ? | 09:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| RAOF | mlankhorst: Hrm. When you run regular Mir clients against usc things work? | 09:06 |
| mlankhorst | hm it does | 09:07 |
| mlankhorst | "Your x/y coords exceed the size of your surface." | 09:09 |
| mlankhorst | o.O | 09:09 |
| mlankhorst | oh right, not on 9.2 yet.. | 09:10 |
| mlankhorst | I'll try mesa 9.2 first before digging further | 09:10 |
| 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 |
| ubot5 | Launchpad bug 1216979 in Unity System Compositor "Failing unity.tests.test_dash.DashMultiKeyTests.test_multi_key_delete autopilot test" [Undecided,New] | 09:16 |
| duflu | sil2100: Good luck. He's at 4am I think | 09:16 |
| sil2100 | kgunn: since right now it's blocking unity-system-compositor from releasing | 09:17 |
| sil2100 | duflu: lovely, thanks | 09:17 |
| mlankhorst | RAOF: lol, fail in nv50_m2mf_transfer_rect | 09:18 |
| RAOF | What's it doing? | 09:18 |
| mlankhorst | not setting X/Y at all | 09:19 |
| mlankhorst | ;D | 09:19 |
| RAOF | Ahem. Yeah, that doesn't seem particularly likely to work :) | 09:20 |
| RAOF | That's clearly not something that I did. Yay! | 09:20 |
| duflu | Might work at defaulting to 0,0 on some machines, if you're lucky | 09:24 |
| 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:26 |
| 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:28 |
| duflu | RAOF: Yes please. Otherwise I may well end up trying to learn it and do it myself | 09:29 |
| hikiko | I did it already alan_g I am building before I push | 09:31 |
| 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 | 09:33 |
| mlankhorst | oops, nouveau has betrayed me :P | 10:03 |
| mlankhorst | it was xserver after all | 10:03 |
| mlankhorst | yeah there we go, all working now.. mostly | 10:04 |
| asac | hi | 10:04 |
| asac | i am testing MM | 10:04 |
| 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:05 |
| duflu | asac: Yes we have a bug logged for that. I get it too | 10:10 |
| asac | duflu: cool. once fixed can you ping me? happy to give it a try :) | 10:14 |
| duflu | asac: Probably best if you just subscribe: https://bugs.launchpad.net/xmir/+bug/1216224 | 10:15 |
| ubot5 | Launchpad bug 1216224 in XMir "[multimonitor] XMir defaults to wrong resolution 1152x864 instead of 1920x1200." [Undecided,Confirmed] | 10:15 |
| duflu | asac: Though once logged in you can change the resolution | 10:15 |
| 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:17 |
| 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:18 |
| ubot5 | Launchpad bug 1216224 in XMir "[multimonitor] XMir defaults to wrong resolution 1152x864 instead of 1920x1200." [Undecided,Confirmed] | 10:18 |
| 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:23 |
| duflu | asac: Slow? Yes there's at least one bug for that too | 10:24 |
| 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:25 |
| 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:28 |
| === alan_g is now known as alan_g|vt | ||
| duflu | asac: You may wish to comment on the issues: https://bugs.launchpad.net/xmir/+bugs?field.tag=multimonitor | 10:30 |
| === alan_g|vt is now known as alan_g | ||
| * duflu goes to organise dinner | 10:35 | |
| RAOF | mlankhorst: Heh. Stride Strikes Again! | 10:36 |
| RAOF | asac: That sounds pretty cool! | 10:36 |
| 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:39 |
| mlankhorst | RAOF: hm is it clipped against the output? :P | 10:40 |
| mlankhorst | but I guess I could.. | 10:40 |
| RAOF | Yeah. | 10:40 |
| RAOF | region is always fully contained within dst_box (we do the intersection in the xmir module) | 10:41 |
| RAOF | So it's not *wrong* to always copy dst_box, but it's a wasteful. | 10:42 |
| mlankhorst | hm sure | 10:42 |
| 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:43 |
| * 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:44 |
| mlankhorst | it is | 10:45 |
| 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:46 |
| 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:47 |
| RAOF | What does M2MF stand for? Something like Mem 2 Mem copy with Format? | 10:48 |
| 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:49 |
| 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:51 |
| 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:52 |
| RAOF | Both are in the window coordinate space of the window. | 10:53 |
| mlankhorst | http://paste.debian.net/30803/ | 10:54 |
| mlankhorst | just guessing.. I'll give it a shot | 10:55 |
| RAOF | That looks roughly right? | 10:56 |
| 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:57 |
| 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? | 10:59 |
| mlankhorst | hm xterm -e 'find /' works | 11:02 |
| 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:04 |
| 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:05 |
| 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:06 |
| mlankhorst | http://paste.debian.net/30811/ this version is more correct right? | 11:07 |
| RAOF | Yeah, that looks like what I'd expect. | 11:08 |
| RAOF | Particularly: it looks like the radeon code :) | 11:08 |
| tsdgeos | ricmm: tvoss: there? | 11:11 |
| tsdgeos | ricmm: tvoss: unping | 11:12 |
| tvoss__ | tsdgeos, ;) | 11:12 |
| === chihchun is now known as chihchun_afk | ||
| 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:15 |
| 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:16 |
| RAOF | It means that, once we actually implement the sucker, our normal-case overhead is going to be just protocol overhead. | 11:17 |
| mlankhorst | RAOF: but I'm mostly worried about the vblanking timestamp stuff, I still want accurate vblank on video | 11:18 |
| 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:19 |
| RAOF | You don't get scanline accuracy out of it, but you can approximate vblank with buffer-received. | 11:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| RAOF | As in: what-client-should-get-GPU-time-next decisions? | 11:24 |
| 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:26 |
| RAOF | Because the compositor might introduce a delay | 11:27 |
| mlankhorst | what about the case of fullscreen bypass? | 11:27 |
| RAOF | Then can do it, yes. | 11:28 |
| RAOF | Which is, I agree, a common case. | 11:28 |
| RAOF | But it's also the case that a client doesn't know if it's bypassed or not. | 11:31 |
| 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:32 |
| mlankhorst | lol | 11:33 |
| mlankhorst | nvidia does everything in hardware where it can.. | 11:33 |
| alan_g | hikiko: what are you working on? | 11:36 |
| RAOF | mlankhorst, tvoss: Nouveau uploaded to qa-testing2 PPA. Happy multi-monitor testing! | 11:51 |
| 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:55 |
| 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:56 |
| alan_g | hikiko: we should be writing tests for the functionality we are working on | 11:59 |
| hikiko | alan_g, ok but let's first add the functionality :) | 12:00 |
| 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:01 |
| 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:04 |
| hikiko | let me see | 12:05 |
| alan_g | hikiko: rendering calls "make_current()" | 12:05 |
| hikiko | let me see what make_current does 1 sec | 12:06 |
| hikiko | make_current binds the context to the current rendering thread | 12:07 |
| hikiko | and to the draw and read surfaces | 12:07 |
| mlankhorst | RAOF: erm you failed somewhere | 12:09 |
| mlankhorst | ;P | 12:09 |
| 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:10 |
| === alan_g is now known as alan_g|lunch | ||
| 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 |
| === hikiko is now known as hikiko|lunch | ||
| 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:11 |
| 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:12 |
| mlankhorst | 2 screens, first one 1440x900 and the second one 1280x1024 | 12:14 |
| tvoss__ | olli_, ping | 12:16 |
| 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:22 |
| derEremit | hi, can i assume that any support for optimus via bumblebee will be severely broken once the switch to mir is complete | 12:33 |
| tvoss__ | derEremit, well, you can always fallback to vanilla X plus prop drivers in 13.10 | 12:34 |
| derEremit | and probably will have to do that. | 12:36 |
| derEremit | ;) | 12:36 |
| tvoss__ | derEremit, if you rely on that functionality, yes. However, would be great if you could try the system-compositor, too :) | 12:41 |
| derEremit | yeah had no positive results this far | 12:51 |
| tvoss__ | derEremit, did you try it from the archive, yet? | 12:53 |
| derEremit | ppa? | 12:53 |
| 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 | 12:54 |
| === hikiko|lunch is now known as hikiko | ||
| tvoss__ | RAOF, mlankhorst ping | 13:12 |
| 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:13 |
| 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:21 |
| balloons | frothnicator, would you be running on real hardware? | 13:25 |
| === alan_g|lunch is now known as alan_g | ||
| alan_g | tvoss__: bypass is top-approved | 13:31 |
| tvoss__ | alan_g, why? | 13:31 |
| tvoss__ | alan_g, please revert that | 13:32 |
| alan_g | tvoss: ack | 13:32 |
| alan_g | tvoss: I thought we'd discussed | 13:32 |
| alan_g | tvoss: I thought we'd discussed doing that | 13:33 |
| tvoss__ | alan_g, nope | 13:33 |
| alan_g | tvoss__: Misunderstanding then. Sorry | 13:34 |
| tvoss__ | alan_g, ack, no worries | 13:34 |
| frothnicator | balloons: sorry, stepped out for a minute: yes. | 13:41 |
| frothnicator | one without discrete graphics card, even. | 13:41 |
| frothnicator | balloons: So if I were to use a daily saucy (with real hardware), that would be a good for y'all? | 13:48 |
| tvoss__ | frothnicator, that would already help us, yes :) | 13:49 |
| 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:50 |
| mlankhorst | I thought qa-testing2? :P | 13:52 |
| 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:53 |
| tvoss__ | mlankhorst, no, we copied over to system-compositor-testing iirc, kgunn, can you please cross-check? | 13:54 |
| kgunn | tvoss: mlankhorst frothnicator ....system-compositor-testing | 13:55 |
| kgunn | qa-testing2 is still live action | 13:55 |
| mlankhorst | ah | 13:56 |
| * mlankhorst is behind then! | 13:56 | |
| 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:57 |
| 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:58 |
| 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 | 13:59 |
| 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:00 |
| 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:01 |
| 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:03 |
| kgunn | frothnicator: you can also "restart lightdm" rather than reboot | 14:04 |
| 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:05 |
| 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:06 |
| kgunn | frothnicator: thanks! | 14:07 |
| 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:10 |
| === om26er is now known as om26er|away | ||
| 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:11 |
| 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:12 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:32 |
| frothnicator | (but if I didn't, or if doesn't matter, feel free to tell me to move along.) | 14:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:38 |
| frothnicator | balloons: heh, sometimes helps to clear ones cache: three reloads and on Ctrl+Shift+R later, I see the update! Cheers. | 14:39 |
| balloons | excellent, thanks for pointing it out! | 14:40 |
| frothnicator | np. | 14:40 |
| hikiko | alan_g, kgunn +anyone else available meeting? | 15:03 |
| === om26er|away is now known as om26er | ||
| kgunn | bschaefer: hey...i really need your help | 15:58 |
| bschaefer | kgunn, what up? (I forgot about vUDS...) | 15:59 |
| kgunn | bschaefer: i have a blocker for unity (you prob heard?) | 16:02 |
| kgunn | https://bugs.launchpad.net/unity-system-compositor/+bug/1216979 | 16:02 |
| ubot5 | Launchpad bug 1216979 in Unity System Compositor "Failing unity.tests.test_dash.DashMultiKeyTests.test_multi_key_delete autopilot test" [Critical,Triaged] | 16:02 |
| 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:03 |
| tvoss | bschaefer, please check if keycodes are correct, according to pitti, something changed in that respect | 16:09 |
| bschaefer | tvoss, yeah, I was just reading that email... that would explain the x error | 16:10 |
| 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:12 |
| bschaefer | thing* | 16:13 |
| bschaefer | ... | 16:13 |
| tvoss | bschaefer, ack | 16:13 |
| tvoss | bschaefer, got a link to that mail? | 16:14 |
| bschaefer | tvoss, hmm a recent one? no | 16:14 |
| bschaefer | tvoss, also this happens outside of xmir as well | 16:15 |
| tvoss | bschaefer, ? | 16:15 |
| kgunn | bschaefer: i was thinking just that... | 16:15 |
| 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:16 |
| 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:17 |
| 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:22 |
| kgunn | bschaefer: : thank you for taking care....is there someone we should manually poke on ? | 16:25 |
| 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:26 |
| kgunn | :)) | 16:27 |
| 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:35 |
| bschaefer | possibly removed, or somehow worked before? | 16:36 |
| thomi | errr... we're using the X11 keyboard? | 16:36 |
| bschaefer | hmm now we are getting a 0 from the x11 keyboard? | 16:37 |
| bschaefer | thomi, this is where its failing: | 16:40 |
| bschaefer | get_display().keysym_to_keycode(keysym) | 16:40 |
| 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:41 |
| 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:42 |
| bschaefer | normal english US keyboard | 16:43 |
| thomi | bschaefer: presumably that's the keymap you're using as well though, right? | 16:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| bschaefer | xev, but hmm I think I might be missing up multi key vs composite key? | 16:47 |
| * bschaefer now does not remember where the hell the multi key is... | 16:48 | |
| 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:49 |
| 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:50 |
| bschaefer | :), yeah I just have to refresh my self on how to type it, sine I don't use it regularly | 16:51 |
| 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:52 |
| 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:54 |
| * 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:55 |
| 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:57 |
| thomi | hmmm | 16:58 |
| bschaefer | but it doesn't seem to exist on the keyboard... | 16:58 |
| 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:01 |
| 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:02 | |
| 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:03 |
| seb128 | bschaefer, thomi: that test works for me on saucy | 17:04 |
| seb128 | (session is running since yesterday) | 17:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| * bschaefer does to much c++ | 17:12 | |
| 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:13 |
| 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:14 |
| bschaefer | thomi, soo subprocess for python, using popen? | 17:15 |
| 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:16 |
| 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:17 |
| bschaefer | thomi, confirmed working... | 17:26 |
| bschaefer | just pushed a branch | 17:26 |
| 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:28 |
| 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:29 |
| 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:30 |
| * bschaefer has to many things going on... | 17:31 | |
| 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! | 17:32 |
| === olli_ is now known as olli | ||
| === sam113101 is now known as sam113101_afk | ||
| === sam113101_afk is now known as sam113101 | ||
| 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:43 |
| cub | as per https://wiki.ubuntu.com/Mir/MultiMonitorTesting . | 19:48 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| kgunn_ | robert_ancell I didn't try qa-testing on intel - maybe it works | 21:14 |
| kgunn_ | ? | 21:14 |
| kgunn_ | robert_ancell thanks | 21:15 |
| 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:16 |
| robotfuel | it worked this morning http://10.97.2.12:8080/view/openarena/job/openarena-benchmark-ps-radeon-hd5750-le-xmir/43/ | 21:19 |
| 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:22 |
| === seb128_ is now known as seb128 | ||
| robert_ancell | robotfuel, kgunn, ppa:mir-team/qa-testing is being converted to bypass only. Will take ~40 mins | 21:26 |
| === bschaefer_ is now known as bschaefer | ||
| kgunn | robert_ancell: thanks....hmmm, just wondering....earlier there were xorg packages there with latest ati drivers...wonder if those were the issue ?? | 21:33 |
| kgunn | robert_ancell: since no one has seen mm on ati yet...just thinking aloud | 21:34 |
| 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:38 |
| 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:39 |
| rsalveti | just in mirrored mode, booting with both monitors connected | 21:42 |
| rsalveti | kgunn: I updated the qa tracker with the results | 21:42 |
| kgunn | rsalveti: thank you | 21:44 |
| rsalveti | no worries | 21:49 |
| kgunn | robotfuel: qa-testing any moment now | 22:11 |
| 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:12 |
| kgunn | robert_ancell: right! | 22:14 |
| robotfuel | robert_ancell: is it ready? | 22:32 |
| robert_ancell | robotfuel, almost... | 22:32 |
| 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:39 |
| 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:41 |
| robert_ancell | I don't | 22:45 |
| 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:53 |
| robert_ancell | kgunn, what is this for? | 22:54 |
| robert_ancell | robotfuel, do we have the radeon X / XMir numbers at the moment? | 22:54 |
| robotfuel | robert_ancell: http://reports.qa.ubuntu.com/graphics/openarena/ | 22:55 |
| robert_ancell | robotfuel, ta | 22:56 |
| 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:57 |
| robert_ancell | :( | 22:58 |
| robert_ancell | yeah, I can see it on the video | 22:58 |
| 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 | 22:59 |
| robotfuel | http://paste.ubuntu.com/6034625/ <- robert_ancell | 23:03 |
| robert_ancell | robotfuel, they look correct | 23:03 |
| 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:04 |
| robotfuel | robert_ancell: it's bad after reboot | 23:06 |
| 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:07 |
| 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:08 |
| robotfuel | robert_ancell: I think it was because of xmir crashing on didrocks ati machine | 23:09 |
| robert_ancell | robotfuel, I thought we'd resolved that / weren't going to block on it | 23:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| RAOF | Ok, so XMir really does not like the bypass branch. | 23:15 |
| robert_ancell | RAOF, you're seeing it too? | 23:17 |
| RAOF | robert_ancell: Oh, what in particular? Crazy horizontal missing rendering? | 23:18 |
| robert_ancell | RAOF, yep horizontal corrupt lines | 23:19 |
| RAOF | I wonder if that's not missing flushing. | 23:20 |
| 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:21 |
| robert_ancell | we're somewhat behind because I think there's a block on mir | 23:22 |
| RAOF | Sure. | 23:22 |
| 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:23 |
| 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:24 |
| robert_ancell | interestingly the video only seems to work in chromium, not firefox | 23:25 |
| robotfuel | I am using simplecv to stream video | 23:25 |
| robert_ancell | RAOF, is that the type of corruption you were thinking of? | 23:26 |
| * robotfuel commutes home | 23:27 | |
| robert_ancell | robotfuel, bye, thanks for your help! | 23:27 |
| 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:28 |
| robert_ancell | thomi, would it be possible to make jenkins have a job that uses -proposed? | 23:35 |
| 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:36 |
| robert_ancell | thomi, ideally now... | 23:38 |
| robert_ancell | RAOF, yes | 23:38 |
| 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:39 |
| 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:41 |
| 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:42 |
| robert_ancell | ricmm, is there a particular feature you need to depend on? | 23:43 |
| 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:45 |
| 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:46 |
| RAOF | #ubuntu-devel or #-release would work. | 23:47 |
| robert_ancell | RAOF, ah, -release was the name I couldn't remember | 23:48 |
| robert_ancell | thanks! | 23:48 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!