[00:05] <kgunn> RAOF: anything noteworthy about xserver mm 14 & intel mm7 ?
[00:06] <RAOF> I moved a little code from intel to the xserver so that ati & nouveau are less work, and intel mm7 might render correctly in situations where mm6 didn't?
[00:07] <kgunn> ah,....i see buffer stride via the interface
[00:09] <RAOF> Yeah.
[00:10] <RAOF> You know what would be awesome? If our acceptance tests weren't riddled with non-deterministic failures :(
[00:10] <robert_ancell> thomi, ah, xrandr is considered a bit unstable
[00:11] <thomi> ugh
[00:18] <RAOF> thomi: Also, that check will become incorrect as soon as I create outputs with correct names (like HDMI-1 and eDP-1, etc)
[00:19] <thomi> so, what should it be doind?
[00:19] <thomi> *doing
[00:21] <RAOF> ‘grep "LoadModule.*xmir" /var/log/Xorg.${DISPLAY#:}.log’ is reasonable.
[00:23] <thomi> RAOF: thanks
[00:23] <thomi> robert_ancell: that fix is now in place - should I run the tests again?
[00:23] <robert_ancell> thomi, please do
[00:24] <thomi> robert_ancell: it seems like some jobs are already running :-/
[00:24] <robert_ancell> thomi, I started it earlier, some might not have completed
[00:24] <thomi> should I kill them, or wait?
[00:25] <robert_ancell> thomi, kill them
[00:26] <thomi> ok, they're running again
[01:16]  * RAOF wonders whether he should set up an android test environment or just wait the 30minutes for Jenkins to run the tests...
[01:36] <RAOF> Now really isn't the time, but we should totally rewrite cross-compile-chroot to use debootstrap and not be a huge pile of hack.
[01:40] <duflu> I'd just like a script that I didn't have to Ctrl+C part way through to use effectively
[01:41] <duflu> Though, I also don't have an N4 right now :/
[01:44] <duflu> Are we waiting on anything to get the bypass patch back in the PPA for testing?
[01:45] <duflu> robert_ancell, RAOF ^
[01:52] <RAOF> We should probably reverse copy from qa-testing2 to qu-testing now that MM is pretty much good in qa-testing2
[02:01] <duflu> RAOF: Did you try ignoring buffer age yet?
[02:02] <RAOF> duflu: Yes. I was just about to say that it doesn't help.
[02:02] <RAOF> :)
[02:02] <duflu> Fark. Well at least we know it's not from bypass. Back to square one
[02:03] <RAOF> It's going to be the compositor displaying buffers out of order again.
[02:04] <duflu> RAOF: I am struggling to find any way to reproduce it with the tools in lp:mir alone. Being able to reproduce it would be a huge step
[02:05] <duflu> lp:mir is still /too flawless/. There's something our demos are not doing to trigger the bug
[02:06] <duflu> RAOF: Can you please triple check going age-less? I don't want to spent more days in that rabbit hole accidentally...
[02:07] <RAOF> Ok
[02:10] <RAOF> As I say, my bet is that we're going to want to annotate XMir with the buffer ID its submitting and then print out the buffer ID the compositor is drawing.
[02:13] <duflu> RAOF: That's feasible
[02:14] <duflu> Though we are almost certain already that it's the wrong order. The how and why is important
[02:14] <duflu> And how to reproduce it with lp:mir servers/clients only
[02:30] <robert_ancell> duflu, last I heard from kgunn and olli, yes
[02:31] <robert_ancell> duflu, sorry, "back into the PPA" - do you mean the multi-monitor PPA?
[02:35]  * RAOF just realises that this isn't a good test; it's going to update every frame regardless of damage, so I won't see any glitches easily
[02:36] <duflu> robert_ancell: Yes qa-testing*. If there are any bugs then someone needs to tell me
[02:38] <robert_ancell> duflu, at the moment we just want to be sure mm works before combining it with bypass
[02:40] <duflu> robert_ancell: No problem. I only feared that some miscommunication about it being hideously broken may have occurred
[02:41] <robert_ancell> duflu, does using bypass together amplify some bug still?
[02:41] <duflu> robert_ancell: For nouveau/radeon I think. Can only test nouveau myself. I have some ideas for how to improve nouveau, but also think XMir won't trigger the issue
[02:44] <RAOF> duflu: Absolutely positively super triple-dog-sure that buffer age isn't the problem. I can still reproduce when doing a fullscreen blit on all damage.
[02:45] <duflu> RAOF: Ok, ta
[02:46] <RAOF> Huh. It's actually *two* frames behind!
[02:47]  * RAOF types 123 into an xterm, and sees ‘1’
[02:49] <duflu> Hmm, I wonder what Mir clients look like when the bug is occurring
[02:50] <RAOF> Probably roughly normal, because they almost all buffer swap at vsync?
[02:50] <RAOF> Only fingerpaint is likely to show anything, right?
[02:51] <duflu> RAOF: Probably, but does it get input? I'll try
[02:51] <duflu> Oh no, I can't the output_id fix isn't in the PPA yet
[02:52] <duflu> RAOF: I'm not sure now. Is it only lag or wrong order too?
[02:53] <RAOF> On the second head it seems to be purely lag.
[02:53] <duflu> RAOF:  Hmm, hold a key down and sometimes you do see the future for a split second. That's wrong order
[02:53] <RAOF> Ah, yes.
[02:53] <RAOF> There we go.
[02:54] <duflu> Should we say seeing the future is a *feature*?
[02:54] <RAOF> Lag *and* out of order :)
[02:54] <duflu> Interestingly, one monitor is bug-free
[02:54] <RAOF> Yeah. We fixed the "only one surface buffer order presentation" problem :/
[02:55] <duflu> OK, I have some good hints to work with
[02:56] <duflu> RAOF: Have you seen any order problems with just one output?
[02:57] <RAOF> No
[02:59]  * RAOF luncheons
[03:05] <kgunn> duflu: robert_ancell ...yeah it was testing from the boston 8...which i think all turned out ok...altho, now, we need to "make it work" with multimon
[03:06] <kgunn> i'll defer to you guys what order things need to land...
[03:06] <robert_ancell> kgunn, duflu, I vote we land bypass now
[03:08] <duflu> robert_ancell: I know of no issues, assuming xmir doesn't trigger bug 1211700 for nouveau. Which I can't test due to XMir and nouveau not being on the same machines
[03:09] <kgunn> robert_ancell: so...wrt multimon ppa....we just make sure not to let mir get rebuilt once its in archive ?
[03:09] <robert_ancell> kgunn, we can make an inverse bypass branch if necessary for now
[03:10] <duflu> robert_ancell: Do we need an env var to control it in case?
[03:10] <robert_ancell> duflu, I wasn't aware it could be switched off - there may be a case for an option to disable it then
[03:10] <kgunn> duflu: i personally like that idea...we had one in android & used it often for debug
[03:11] <duflu> OK, will hack the option into the bypass branch first
[03:11] <kgunn> if its low investment of ur time
[03:11] <duflu> It's trivial
[03:13] <kgunn> cool
[03:14] <robert_ancell> kgunn, thomi, do you have the numbers for the bypass test?
[03:16] <kgunn> robert_ancell: thomi ...http://10.97.2.12:8080/view/qa-ppa/
[03:16] <kgunn> so you kinda have to dig a little
[03:16] <kgunn> nothing looks completely amiss
[03:17] <robert_ancell> kgunn, yeah, wondering if there's anything to copy and paste into the MP
[03:19] <robert_ancell> brb
[03:23] <duflu> kgunn, robert_ancell: OK you can disable it with MIR_BYPASS=0
[03:24] <robert_ancell> duflu, awesome
[03:24] <robert_ancell> duflu, did you consider a command line flag? Then it can be disabled by either a flag or an env variable
[03:25] <duflu> robert_ancell: No... would that set the environment internally? If not then there's a lot of wiring up that would require
[03:25] <robert_ancell> duflu, all command line flags can be set with MIR_SERVER_FOO for --foo
[03:26] <duflu> robert_ancell: That doesn't have to be redone for each server right?
[03:26] <robert_ancell> duflu, nope, they all get that
[03:28] <kgunn> robert_ancell: so...should we line up the canonical folks tonight we want to give multimon a shot their morning ??
[03:28] <robert_ancell> kgunn, RAOF, it only works for intel right?
[03:28] <kgunn> or should we wait a bit ?
[03:28] <duflu> Now it's a non-trivial exercise :/
[03:29] <kgunn> robert_ancell: i thot you were trying to run it on the boston 8 earlier ?...did ati/nouveau fail ?
[03:29] <duflu> robert_ancell: Too complex to rush in such logic right now. It's pretty hidden so we can change it later
[03:30] <duflu> ... because getting command line option values seems to create complex class dependencies
[03:30] <robert_ancell> kgunn, we don't have the drivers working for ati/nouveau yet afaik. And the Boston 8 is failing at the moment, seems to be a problem in the test script - thomi is looking at it
[03:34] <thomi> robert_ancell: re-running with some tweaks to the test script
[03:35] <RAOF> robert_ancell: ati & nouveau should work, but I haven't tested them.
[03:36] <kgunn> cool...so we could just line up the internal testers w reckless abandon
[03:38] <RAOF> Yup.
[03:38] <kgunn> thomi: think we could get a sanity (e.g. does it boot) on ati/nouveau within an hour ?
[03:39] <thomi> on the boston 8?
[03:39] <thomi> I can just run them without the test, if you like
[03:39] <kgunn> yes...or any for that mattter
[03:39] <RAOF> Yes, that would be nice.
[03:40] <thomi> ...do we expect it to not boot!?
[03:40] <kgunn> yeah...i just don't want to tell people to test w/o having some idea of what will happen
[03:40] <RAOF> Oh, I expect it to boot, but it *might* not bring up X
[03:40] <kgunn> :)
[03:40] <kgunn> just a little thing like that
[03:40] <RAOF> I don't *think* that there's anything wrong with the changes, but I haven't tested them :)
[03:40] <kgunn> so yeah..boot to usable ui is the litmus
[03:42] <thomi> heh, would be a lot easier if I was in the lab, but I can kick it off after the current test runs
[03:45] <duflu> Hmm, how come USC's XMir is frozen while I run native Mir apps on top? It should render both simultaneously, like mir_demo_server_shell does
[03:47] <RAOF> Output change?
[03:47] <RAOF> USC changes output layout when I fire up mir_demo_client_egltriangle.
[03:48] <RAOF> Which is expected behaviour; resolution is per-session.
[03:49] <duflu> RAOF: But XMir is still composited and visible. Just frozen when a Mir client is focussed.
[03:49] <duflu> If it's composited and visible, it should keep rendering
[04:04] <kgunn> bbiab
[04:10] <robert_ancell> RAOF, so do you have a multi-monitor desktop working at the moment?
[04:10] <RAOF> Yes.
[04:10] <robert_ancell> I can't get spanning working in Unity and while playing with it I just end up with a black screen
[04:10] <RAOF> qa-testing2 works fine for me.
[04:10] <RAOF> Do you have delicious logs?
[04:11] <robert_ancell> what would you like? I've just restarted into a fresh session
[04:12] <RAOF> Xorg log, unity-system-compositor log, & lightdm log?
[04:12] <robert_ancell> brb
[04:14] <thomi> bah, jobs still failing
[04:20] <RAOF> robert_ancell: Winning?
[04:21] <robert_ancell> RAOF, ok, lets start with what I see.
[04:21] <RAOF> robert_ancell: Winning! https://code.launchpad.net/~raof/mir/fix-multi-surface-buffer-tracking/+merge/181259
[04:21] <robert_ancell> RAOF, 1. Log into Unity without monitor connected, all good
[04:21] <robert_ancell> 2. Connect monitor
[04:22] <robert_ancell> 3. See a pile of flickering, then second monitor shows mirrored display
[04:22] <robert_ancell> 4. BUT, the second display is taller and thinner than my laptop one so the desktop is cropped and extended
[04:22] <robert_ancell> 5. Can't launch any new X apps
[04:23] <RAOF> Good so far. I'm not sure why it flickers so much - I think that Mir is doing more modesetting than necessary.
[04:23] <robert_ancell> the X log shows ~1.6 million lines of "_XSERVTransSocketUNIXAccept: accept() failed"
[04:23] <RAOF> What Mir do you have? That means it doesn't have https://code.launchpad.net/~raof/mir/fix-multi-surface-buffer-tracking/+merge/181259 merged into it.
[04:24] <robert_ancell> ah
[04:24] <RAOF> (Mir is flooding the server with fds until accept() can't open a new fd)
[04:24] <robert_ancell> I have qa-testing pinned, not qa-testing2
[04:24] <robert_ancell> ok, I'll rinse and repeat
[04:25] <thomi> kgunn: robert_ancell: I just updated the ppa2 job to not actually run the tests, so when the current jobs end, you can re-kick off the run_all job and you'll have your boot test
[04:25] <robert_ancell> thomi, ta
[04:25] <thomi> I gotta go lie down though, I'm sick :(
[04:25] <thomi> will be back later maybe
[04:29] <robert_ancell> thomi, get well!
[04:29] <robert_ancell> RAOF, Do you know if SwapIntervalSignalTest works with fix-multi-surface-buffer-tracking? i.e. is alan_g's problem resolved?
[04:29] <robert_ancell> duflu, can you review that too asap if you need to?
[04:29] <RAOF> robert_ancell: Yes, it's resolved.
[04:29] <RAOF> robert_ancell: (As you can see from the tests all passing ☺)
[04:29] <duflu> robert_ancell: Yeah. I also have a reasonable theory for bad buffer ordering now. But first, lunch, postoffice, coffee
[04:31] <RAOF> I'm going out for a couple of hours; I'll get back to testing once I'm back.
[04:32] <robert_ancell> duflu, do you want to delay landing this?
[04:37] <robert_ancell> RAOF, cool, aside from the known lagging issue it works for me!
[04:40] <duflu> robert_ancell, I don't want to delay anything... Just going to lunch
[04:41] <robert_ancell> duflu, I mean, should we wait for you or you don't plan on reviewing
[04:44] <robert_ancell> kgunn, do you have that list of internal testers for multi-monitor? I'm having trouble finding it in my email
[04:50] <kgunn> robert_ancell: i do ...i crafted a setup email just now
[04:51] <robert_ancell> ok, cool
[04:54] <kgunn> robert_ancell: i'm gonna send...please read, then just followup with expectations on ati/nouveau
[04:56] <robert_ancell> RAOF, ati/nouveau are expected to work, just no-one has tested them right?
[04:57] <kgunn> robert_ancell: yeah...that's what he was saying
[04:57] <robert_ancell> kgunn, the Boston 8 tests are all failing again
[04:57] <kgunn> :-|
[04:57] <robert_ancell> kgunn, can you see those jenkins logs?
[04:58] <kgunn> http://10.97.2.12:8080/view/qa-ppa2/
[04:58] <robert_ancell> yeah
[05:00] <kgunn> i don't get it tho...it says intel is failing but the results look good
[05:00] <kgunn> on both resolutions
[05:01] <robert_ancell> kgunn, where are you looking at results?
[05:01] <kgunn> robert_ancell: here...http://10.97.2.12:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-intel-2500-le/ws/results/test-results/
[05:01] <kgunn> then drill into each folder marked for resolution...
[05:02] <kgunn> then composite.xml
[05:02] <kgunn> i'm gonna head off to bed....see you tomorrow
[05:02] <robert_ancell> later
[05:02] <kgunn> tvoss: i'll see you in ~9 hrs w/ olli :)
[05:02] <tvoss> kgunn, ack, later
[05:18] <robert_ancell> RAOF, so you think ati works, but you haven't tested it? You have some ati hardware right?
[05:23] <robert_ancell> tvoss, duflu, RAOF etc, can I get a review on https://code.launchpad.net/~robert-ancell/unity-system-compositor/fix-usc-shell-wrapper/+merge/181942 please?
[05:27] <robert_ancell> I'm finishing up for the night, any last requests?
[05:28] <duflu> robert_ancell: Relax?
[05:28] <robert_ancell> that would be awesome
[05:36] <tvoss> duflu, ping
[05:36] <duflu> tvoss, pong
[07:01] <RAOF> Ok.
[07:01] <RAOF> Let's test that radeon boots, at least.
[07:04] <duflu> Argh. I _still_ can't find a theoretical reason for bad frame ordering. The algorithm's designed to make it (theoretically) impossible
[07:05] <dholbach> good morning
[07:07] <RAOF> Good morning.
[07:07] <RAOF> Ah. I seem to have managed to break radeon. Excellent.
[07:07] <dholbach> hey RAOF
[07:09] <mlankhorst> perfect
[07:09] <mlankhorst> duflu: maybe it's not the theory, it's the implementation? :P
[07:10] <duflu> mlankhorst: Yeah, which is why I'm trying to find bugs still
[07:10] <mlankhorst> RAOF: perfect, can I look at it? :P
[07:11] <RAOF> mlankhorst: You're welcome to. It's... oh, not hosted in any public git tree.
[07:11] <RAOF> Let me fix that :)
[07:11] <RAOF> I've probably set the stride of the thingy wrong.
[07:12] <mlankhorst> yeah those thingies can get picky
[07:18] <RAOF> mlankhorst: github.com/RAOF/xf86-video-ati, branch "foo"
[07:18] <mlankhorst> RAOF: what mir branch etc do I need for that? or ppa
[07:19] <RAOF> You need ppa:mir-team/qa-testing2
[07:19] <RAOF> Or github.com/RAOF/xserver , branch vladmir-upstreaming
[07:20] <mlankhorst> ah
[07:27] <RAOF> mlankhorst: I'll have set devKind incorrectly in the ModifyPixmapHeader call.
[07:27] <RAOF> Becasue I'm still not entirely sure what WTH that's meant to be :)
[07:28] <RAOF> mlankhorst: Oh, I may have done the same for nouveau...
[07:34] <RAOF> mlankhorst: Do you remember offhand what devKind is meant to be for radeon?
[07:35] <RAOF> Hm. It *is* meant to be stride.
[07:49] <mlankhorst> RAOF: it's stride for all ddx iirc
[07:49] <RAOF> Then I broke it somewhere else :/
[07:49] <mlankhorst> yeah I'll take a look
[07:49] <mlankhorst> power just cut out :/
[07:50] <mlankhorst> for like 5 minutes or so
[07:52] <tvoss__> mlankhorst, in your place?
[07:56] <mlankhorst> yeah
[08:12] <mlankhorst> RAOF: do you get something like this?
[08:12] <mlankhorst> [  403.880155] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x9
[08:12] <mlankhorst> [  403.880435] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2!
[08:12] <duflu> Sigh. We may yet need a universal frame counter to throttle clients accurately under multimonitor
[08:13] <duflu> Wait a minute... what is "accurate"?
[08:13] <duflu> Surely if your client doesn't do "accurate" timing and relies on vsync then 120Hz with two monitors is not necessarily wrong :/
[08:13] <duflu> Hmm
[08:15] <mlankhorst> duflu: that is assuming both monitors have the same scanrate
[08:15] <duflu> mlankhorst: I mean generally sum of all
[08:16] <duflu> I think we've been trying to meet a requirement that doesn't really exist...
[08:16] <mlankhorst> RAOF: lol
[08:16] <mlankhorst> [  595.892399] radeon 0000:01:00.0: evergreen_cs_track_validate_texture:850 texture bo too small (layer size 5299200, offset 0, max layer 1, depth 1, bo size 12288) (1472 900)
[08:19] <mlankhorst> combined with the previous errors it looks like your handles are corrupted :P
[08:22] <mlankhorst>  +      if (!pScreen->ModifyPixmapHeader(dst,
[08:22] <mlankhorst> -+                                       pScrn->virtualX, pScrn->virtualY,
[08:22] <mlankhorst> ++                                       output_box->x2 - output_box->x1,
[08:22] <mlankhorst> ++                     output_box->y2 - output_box->y1,
[08:22] <mlankhorst> looks wrong..
[08:29] <mlankhorst> hm and the last error might be from freeing a buffer
[08:33] <hikiko> hello :) could someone review this branch: https://code.launchpad.net/~hikiko/mir/mir.gbm-buffer-allocator-modifications/+merge/182049 if not busy?
[08:34] <mlankhorst> RAOF: with valgrind I seem to get more errors :P
[08:35] <mlankhorst> definitely looks like the bo's get unreffed before being used..
[08:37] <RAOF> mlankhorst: That seems... wat? The changes shouldn't change when the bos get unreffed!
[08:42] <mlankhorst> RAOF: well from the dmesg I'm guessing that somewhere something gets freed before it should
[08:44] <mlankhorst> if i run things with valgrind I end up with Xorg failing in random random crashes
[08:44] <mlankhorst> s/random.*/random places/
[08:48] <RAOF> mlankhorst: Oh, that reminds me. I should push the xf86-video-intel change to actually enable the valgrind support.
[08:49] <mlankhorst> wasn't --enable-valgrind already added, or did you redisable it?
[08:50] <RAOF> No, it's enabled, but only if DEB_HOST_ARCH == linux
[08:50] <RAOF> But DEB_HOST_ARCH is never linux; you misspelt DEB_HOST_ARCH_OS
[08:51] <mlankhorst> oops
[08:55] <mlankhorst> RAOF: anyway I'm getting some weirdness that indicates a flink leak, though. but no clue as to where it comes from yet..
[08:55] <RAOF> Colour me confused, then.
[08:55] <mlankhorst> erm I mean you're probably freeing something twice
[08:55] <mlankhorst> or before using it
[09:02] <mlankhorst> or a particularly nasty kernel corruption.. I'll try on my older card
[09:04] <mlankhorst> RAOF: were you getting the same kind of errors?
[09:07] <RAOF> mlankhorst: Hm, no.
[09:09] <RAOF> I don't get any valgrind errors that aren't either unrelated (hello, writev!) or a couple of the harmless "I don't understand your ioctls" errors.
[09:09] <mlankhorst> I'm getting tons of crap like this
[09:09] <mlankhorst> [   99.170371] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2!
[09:09] <mlankhorst> [   99.178895] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x9
[09:09] <mlankhorst> and
[09:09] <mlankhorst> [  101.124015] radeon 0000:01:00.0: evergreen_cs_track_validate_cb:476 cb[0] bo too small (layer size 6144, offset 0, max layer 1, bo size 4096, slice 23)
[09:10] <mlankhorst> [  101.124021] radeon 0000:01:00.0: evergreen_cs_track_validate_cb:480 problematic surf: (64 24) (0 4 1 0 0 4 3)
[09:10] <RAOF> Ah, yes. I see those.
[09:10] <mlankhorst> which makes me think that some stuff gets freed by the driver before submitting the commands
[09:11] <RAOF> Ah, fair enough.
[09:11]  * RAOF was confused about your valgrind comment.
[09:12] <mlankhorst> RAOF: well I get some memcpy crashes from valgrind
[09:12] <mlankhorst> but nothing pointing towards what is going on
[09:13] <RAOF> Huh, really?
[09:13] <RAOF> memcpy?
[09:14] <mlankhorst> RAOF: does the root window have damage tracking after a resize event?
[09:14] <RAOF> Yes.
[09:14] <RAOF> But we should be disabling everything that has damage associated with the screen pixmap before resizing.
[09:15] <RAOF> 'cause we throw away the screen pixmap on resize, but not the root window.
[09:15] <mlankhorst> .. do you? :p
[09:18] <RAOF> I'm reasonably sure?
[09:18] <mlankhorst> hm good enough
[09:18] <RAOF> Anyway, resize isn't called in xserver startup?
[09:19] <mlankhorst> I'm trying to figure out what is going on there though
[09:21] <RAOF> What's your memcpy crash, anyway?
[09:26] <duflu> Woo! Perfect multimonitor frame sync with no timers!
[09:29] <mlankhorst> RAOF: never the same twice :/
[09:29] <mlankhorst> but usually exa related
[09:30] <mlankhorst> actually always the same it seems, it's from fallback call. same thing that happens when acceleration in nouveau fails
[09:30] <mlankhorst> and preceded by failed to map pixmap: -2
[09:31] <mlankhorst> hm from procRenderCreateCursor..
[09:33] <mlankhorst> http://paste.debian.net/30292/ with memory summary removed
[09:35] <mlankhorst> RAOF: it worked on intel right?
[09:35] <RAOF> Yeah, works on intel.
[09:35] <mlankhorst> RAOF: implement shadowfb call :P
[09:35] <duflu> Well, actually, my sync is temporarily lost when VT switching, but it comes back eventually
[09:35] <RAOF> Also, I *don't* see that CreateCursor crash.
[09:36] <mlankhorst> hm actually it wouldn't help
[09:36] <mlankhorst> it's falling back to downloading to screen because the mapping was failing
[09:37] <duflu> You know, it's rather hard to create visual glitches when you're triple buffering. I never realized just how hard...
[09:44] <mlankhorst> it's easy if you relax the restriction and allow them to be fatal :P
[09:48] <RAOF> Heh
[09:58] <mlankhorst> RAOF: also curious it looks like xmir_copy_to_mir was wrong in another place
[09:59] <RAOF> Oh?
[09:59] <mlankhorst> you set dst x / y to 0 0, should probably be the same as src x y
[10:00] <RAOF> dst x/y is not location in the destination buffer?
[10:00] <mlankhorst> it is
[10:00] <RAOF> Then why wouldn't I want it to be 0 0?
[10:00] <mlankhorst> but I'm guessing the destination buffer is full sized?
[10:00] <RAOF> No, the destination buffer is output-sized.
[10:00] <RAOF> Welcome to the poor-man's Shatter.
[10:01] <mlankhorst> ah..
[10:01] <mlankhorst> RAOF: you allocate a single bo for the entire screen, but each output uses a chunk of it?
[10:02] <RAOF> There's a single bo for the ScreenPixmap.
[10:02] <RAOF> But we copy each region that corresponds to an output into a different xmir_window
[10:03] <mlankhorst> nasty
[10:03] <RAOF> Or, perhaps more understandably - each enabled xf86Crtc has an associated xmir_window, with a MirSurface, and we copy from the root window into that surface.
[10:04] <RAOF> Eh, I don't think it's particularly nastier than having a single framebuffer surface and copying the whole root window into it.
[10:09] <mlankhorst> I don't really see where this particular error is coming from, what is your failure mode?
[10:10] <RAOF> Of *course* I don't see this crash under gdb & mir_demo_server_shell!
[10:10] <RAOF> BAH.
[10:11] <mlankhorst> ..?
[10:13] <mlankhorst> and I'm killing off the dup syscall. I'll just set fd to negative, and use that internally to say 'do not close after opening' :P
[10:14] <RAOF> mlankhorst: I can, apparently, quite happily run radeon under mir_demo_server_shell in gdb.
[10:15] <RAOF> No crashes, no madness...
[10:15] <RAOF> To be fair I'm not *actually* looking at the display; it's upstairs, so it might be entirely wrong ☺
[10:15] <tvoss__> RAOF, rofl
[10:17] <mlankhorst> you're like those tv commercials where they put 'not showing the actual product' in small letters on the bottom
[10:22] <mlankhorst> RAOF: is it just the xserver, or a full session?
[10:22] <RAOF> Just the X server.
[10:22] <mlankhorst> well duh :P
[10:22] <RAOF> Why duh?
[10:22] <mlankhorst> see if it survives this: DISPLAY=:0 XDESKTOP_SESSION=ubuntu /etc/X11/Xsession
[10:23] <mlankhorst> erm
[10:23] <mlankhorst> DESKTOP_SESSION*
[10:23] <RAOF> Hm. dmesg does not survive DISPLAY=:33 glxgears :)
[10:23] <mlankhorst> hah
[10:23] <RAOF> [ 1806.614838] [drm:r600_cs_common_vline_parse] *ERROR* cannot find crtc 1436857232
[10:24] <RAOF> I'm not surprised it can't find it!
[10:24] <mlankhorst> or are you? DUN DUN DUUUN
[10:24] <mlankhorst> 55a4b390
[10:31] <mlankhorst> RAOF: ah right, it's calling evergreen_cp_wait_vline_sync
[10:31] <RAOF> That seems unlikely to work. I thought I disabled vsyncing?
[10:33] <mlankhorst> all the calls are hidden behind accel_state->vsync
[10:34] <tvoss__> okay, time to take care of my visum for china
[10:34] <RAOF> Oh, dear.
[10:35] <RAOF> No, I undisabled vsynching when I shoved a non-null driver private in xf86Crtc.
[10:36] <mlankhorst> RAOF: erm it looks like the calls are only emitted if the driver has accel_state->vsync set though
[10:36]  * tvoss__ thinks about undisabled
[10:39] <RAOF> mlankhorst: Try bailing early with NULL from radeon_pick_best_crtc (in radeon_video.c)?
[10:40] <RAOF> Ok, time for me to sleep
[10:53] <mlankhorst> that's xv stuff..
[10:54] <mlankhorst> RAOF: did you explicitly enable vsync or something?
[10:55] <mlankhorst> looks like vsync is disabled in radeon unless you explicitly enable it
[11:00] <mlankhorst> hm indeed, same issue here :p
[11:02] <mlankhorst> radeon_dri2.c:    info->accel_state->vsync = info->swapBuffersWait;
[11:02] <mlankhorst> - OPTION_SWAPBUFFERS_WAIT, TRUE);
[11:03] <mlankhorst> + OPTION_SWAPBUFFERS_WAIT, !xorgMir);
[11:04] <mlankhorst> well that gets rid of 1 source of errors..
[12:07] <mlankhorst> meh on the crashing call..
[12:07] <mlankhorst> (gdb) print *(struct radeon_bo_gem*)((struct radeon_exa_pixmap_priv*)exaGetPixmapDriverPrivate(src))->bo
[12:07] <mlankhorst> $2 = {base = {ptr = 0x0, flags = 0, handle = 1, size = 5652480, alignment = 16384, domains = 4, cref = 3, bom = 0x5555559d81b0, space_accounted = 0, referenced_in_cs = 0}, name = 0, map_count = 0, reloc_in_cs = {
[12:07] <mlankhorst>     atomic = 0}, priv_ptr = 0x0}
[12:07] <mlankhorst> (gdb) print *(struct radeon_bo_gem*)((struct radeon_exa_pixmap_priv*)exaGetPixmapDriverPrivate(dst))->bo
[12:07] <mlankhorst> $3 = {base = {ptr = 0x0, flags = 0, handle = 9, size = 5299200, alignment = 0, domains = 2, cref = 2, bom = 0x5555559d81b0, space_accounted = 0, referenced_in_cs = 0}, name = 9, map_count = 0, reloc_in_cs = {
[12:07] <mlankhorst>     atomic = 0}, priv_ptr = 0x0}
[12:07] <mlankhorst> [  491.685460] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x9
[12:08] <mlankhorst> it still has refcount set >:(
[12:17] <kgunn> duflu: so is that branch good to go ?....e.g. add it to qa-testing2? or just build local for more confidence?
[13:02] <kgunn> mlankhorst: i see chris went to bed, so does ati work with multimon ? (i'm guessing no...)
[13:03] <mlankhorst> kgunn: it sort of looks like I'm hitting a kernel bug
[13:04] <kgunn> mlankhorst: does it work on standard xmir (w.o multimon?)
[13:05] <mlankhorst> hm I ws trying to rollback kernel, I guess standard xmir would be easier to test
[13:05] <kgunn> mlankhorst: glad i asked :) save you some effort
[13:14] <mlankhorst> hm I guess that works, weird stuff..
[13:17] <kgunn> mlankhorst: so xmir in archive works...but xmir (multimon, qa-testing2 ppa) does not ?
[13:18] <mlankhorst> yeah
[13:18] <kgunn> meaning...can't boot to unity ? or cycles endlessly on greeter ?...curious the symptom/end user result
[13:18] <mlankhorst> right now I just forced it to crash, saves times
[13:18] <kgunn> :)
[13:19] <kgunn> ricmm: i know you're swamped....had a chance to try xmir-multimonitor?
[13:19] <kgunn> rsalveti: ^
[13:20] <rsalveti> kgunn: will try today, have an ati board here
[13:20] <rsalveti> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV620/M82 [Mobility Radeon HD 3450/3470]
[13:21] <kgunn> rsalveti: well... :)   ...i'm sure you can see mlankhorst 's posts above
[13:21] <rsalveti> but is that the same board?
[13:21] <rsalveti> mine is quite old
[13:22] <rsalveti> but guess I'd get the same crash
[13:22] <rsalveti> we'll see
[13:23] <ricmm> kgunn: negativo
[13:23] <ricmm> and I actually cant, I dont have a second monitor
[13:23] <ricmm> :(
[13:26] <mlankhorst> not required
[13:26] <mlankhorst> I was testing a single monitor setup
[13:27] <kgunn> ricmm: so it would still be useful to see if you can boot into a useable unity session even on 1 monitor
[13:53] <kgunn> RAOF: duflu ....just sharing, seems nvidia at least did get to run http://10.97.2.12:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-nvidia-gt440-le/ws/results/800x600.output
[13:53] <kgunn> altho...looks like it hung or bailed on the last test (unsure)
[13:54] <kgunn> ....looking from syslog...whoopsie might have gotten in the way ?
[13:54] <kgunn> mlankhorst: ^....just sharing...no action
[13:54] <mlankhorst> nouveau is easier to test though :P
[13:54] <kgunn> thomi: robotfuel ^
[13:55] <robotfuel> kgunn: I am watching some of the jobs now, I think some of the failures are because of the install phase package names had changed.
[13:56] <robotfuel> kgunn: I didn't setup the ppa2 jobs
[13:56] <kgunn> robotfuel: thanks....actually....i see a radeon run now too :)
[13:56] <kgunn> http://10.97.2.12:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-radeon-hd7450-le/ws/results/
[13:57] <robotfuel> kgunn: it looks like package name issue is fixed but hasn't been run, I can also disable whoopsie
[13:57] <kgunn> robotfuel: is that your subtle way of blaming the kiwi's :)
[13:57] <kgunn> mlankhorst: http://10.97.2.12:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-radeon-hd7450-le/ws/results/
[13:57] <kgunn> so that's interesting....that actually ran
[13:57] <mlankhorst> kgunn: yeah but I'm on drm-next
[13:58] <kgunn> mlankhorst: oh...
[13:58] <robotfuel> kgunn: this one also looked like openarena finished http://10.97.2.12:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-radeon-hd5750-le/4/artifact/results/
[13:58] <kgunn> mlankhorst: that was lost on me...so qa-testing2 on drm-now...is ok?
[13:58] <mlankhorst> no idea, stupid laptop won't cooperate :P
[13:58] <kgunn> olli_: ^
[13:58] <kgunn> olli_: so looks like nouveau & radeon are actually running
[13:59] <kgunn> not sure why the report says fail...but if you dig...you can see results
[14:00] <robotfuel> kgunn: unity-system-compositor wasn't running on that build I linked to before http://10.97.2.12:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-radeon-hd5750-le/4/artifact/results/ps-aux.log
[14:01] <kgunn> robotfuel: ah...got too excited
[14:05] <kgunn> robotfuel: so can you confirm the following...xmir-mm (aka qa-ppa2) on ati & nouveau specifically
[14:05] <kgunn> robotfuel: is actually running xmir & can boot to a usable unity ui (first)
[14:05] <robotfuel> kgunn: unity system compositor wasn't running on the intel jobs, I am rerunning everything now, it looks like the tests were fixed 6 hours ago, but they were run 10 hours ago
[14:06] <kgunn> robotfuel: second, can you actually plug/unplug a second monitor monitor
[14:06] <kgunn> robotfuel: like manually
[14:06] <kgunn> robotfuel: like...as soon as you're able
[14:06] <robotfuel> kgunn: sure, I will drive in during lunch
[14:06] <kgunn> robotfuel: is there anyone in the office who could try ?
[14:07] <kgunn> sorry racing clock
[14:07] <robotfuel> rfowler might be in.
[14:09] <robotfuel> kgunn: which machine do you want the monitor tried on first?
[14:09] <kgunn> robotfuel: either...
[14:09] <kgunn> robotfuel: we're just looking for a sanity test of multimonitor on xmir
[14:20] <kgunn> robotfuel: can't seem to find anyone else in lex...so i might just be needing you to head for lunch
[14:21] <robotfuel> kgunn: sounds good I can head in right after a meeting I have at 11am (40 minutes)
[14:22] <kgunn> robotfuel: much thanks
[14:38] <robotfuel> kgunn: I am getting no video on the kvm on intel with the qa-testing2 ppa
[14:39] <mlankhorst> hm guess it's not just me then :P
[14:39] <kgunn> robotfuel: meaning?...like you're in the unity ui but you can play youtube videos? or just nothing?
[14:39] <robotfuel> kgunn: black screen
[14:40] <robotfuel> kgunn: no ui
[14:40] <kgunn> robotfuel: are the other intels the same??
[14:40] <robotfuel> kgunn: yes same issue
[14:41] <kgunn> robotfuel: what does apt-cache policy for xserver-xorg-video-intel say ?
[14:41] <kgunn> robotfuel: what does apt-cache policy for unity-system-compositor say also ?
[14:43] <robotfuel> kgunn: the driver is the issue apt-get install unity-system-compositor didn't pull in the driver.
[14:43] <kgunn> robotfuel: sorry...i just have to ask...ppa pinned ?
[14:44] <robotfuel> kgunn: yes it's pinned
[14:44] <robotfuel> kgunn: unity-system-compositor is installed from the pinned ppa
[14:45] <robotfuel> kgunn: sudo apt-get install xserver-xorg-video-intel pulls in the driver from the pinned ppa
[14:46] <robotfuel> kgunn: seems like a packaging bug
[14:46] <kgunn> robotfuel: just curious....how so ?...i was wondering....how is it pinned ??
[14:46] <kgunn> take a look at this doc
[14:46] <kgunn> https://docs.google.com/a/canonical.com/document/d/1hmSrL_ZqnpMo0oDf-lee22J2cJr54jWmCeziMxR131s/edit
[14:47] <kgunn> ^ i am wondering if you need the extra bit at the top
[14:47] <robotfuel> cat /etc/apt/preferences.d/50-pin-mir.pref Package: *
[14:47] <robotfuel> Pin: origin "private-ppa.launchpad.net"
[14:47] <robotfuel> Pin-Priority: 1001
[14:47] <robotfuel> Package: *
[14:47] <robotfuel> Pin: release o=LP-PPA-mir-team-qa-testing2
[14:47] <robotfuel> Pin-Priority: 1002
[14:47] <kgunn> my pin is like the bottom
[14:47] <robotfuel> kgunn: my pin is like the bottom
[14:47] <kgunn> robotfuel: cool...
[14:48] <kgunn> so that's not it
[14:48] <kgunn> robotfuel: i guess you'll need to check the blasted ati/nouveaus as well...
[14:48] <robotfuel> kgunn: I can add the drivers to apt-get install line to get the correct driver.
[14:48] <mlankhorst> looks like I messed up nouveau vblank in my tree, time to retest :P
[14:48] <robotfuel> radeon is a black screen
[14:48] <kgunn> robotfuel: thanks
[14:49] <robotfuel> kgunn: wrong driver
[14:49] <mlankhorst> robotfuel: anything in dmesg?
[14:49] <robotfuel> kgunn: I need to update the test and re-run pulling in the driver.
[14:49] <robotfuel> oops mlankhorst^
[14:51] <kgunn> robotfuel: no problem...and as usual...thanks for the help
[14:51] <mlankhorst> fwiw, same blackness here
[14:52] <mlankhorst> on nouveau at least
[14:54] <kgunn> mlankhorst: you get matches on cross check of apt-cache policy & qa-testing2  packages ?
[14:56] <mlankhorst> yes
[14:59] <kgunn> mlankhorst: does it make it to greeter ?
[15:00] <mlankhorst> it's black, no idea, all I know is it doesn't crash
[15:01] <kgunn> freaky...what does Xorg.0.log say ?
[15:01] <mlankhorst> nothing interesting
[15:01] <mlankhorst> pretends everything is fine
[15:02] <kgunn> mmmm...can you vt switch....then $ sudo chmod 777 /tmp/mir_socket...$ sudo mir_demo_client_egltriangle...then switch back to vt7 ?
[15:03] <kgunn> robotfuel: are you actually in office  already ?
[15:03] <kgunn> must be driving
[15:04] <robotfuel> kgunn: no in a meeting
[15:04] <mlankhorst> kgunn: triangle works nicely
[15:04] <mlankhorst> but I like the plasma one more :p
[15:04] <kgunn> mlankhorst: do you see unity as a backdrop to the triangle ?
[15:04] <mlankhorst> no the same blackness
[15:05] <kgunn> huh
[15:05] <hikiko> mmm anyone for the meeting?
[15:05] <kgunn> so mir is up..u-s-c is up no problem
[15:05] <mlankhorst> I think RAOF needs to get back to the drawing board somehow, and review what is going on with lifetime :P
[15:05] <hikiko> I am alone there :)
[15:05] <kgunn> hikiko: uk is off today...
[15:05] <hikiko> oh :) i see
[15:05] <kgunn> hikiko: free day to focus on mir-on-mir :)
[15:06] <kgunn> mlankhorst: right...but this means mir is up, its like compiz failed
[15:06] <kgunn> mlankhorst: or...xmir failed to hook up compiz to u-s-c frontend
[15:06] <kgunn> mlankhorst: is there a way to verify is compiz loaded/rendered....but buffer just didnt make it to screen ?
[15:07] <kgunn> like there should be more than one gl client active
[15:07] <kgunn> 1 for mir....and 1 or more for unity/compiz
[15:08] <hikiko> mm then here's a quick status in case someone has time to review my branches: https://code.launchpad.net/~hikiko/mir/mir.native-gbm-platform-class https://code.launchpad.net/~hikiko/mir/mir.gbm-buffer-allocator-modifications
[15:08] <kgunn> mlankhorst: just trying to think how to help RAOF with some usable debug
[15:08] <hikiko> bye!
[15:12] <robotfuel> kgunn: I have a black screen on radeon using http://ppa.launchpad.net/mir-team/qa-testing2/ubuntu/ saucy/main xserver-xorg-video-radeon
[15:13] <kgunn> robotfuel: anything interesting at the end of /var/log/Xorg.0.log ?
[15:14] <robotfuel> kgunn: a lot of this [    28.871] reloc emit failure -22 (evergreen_set_render_target 318)
[15:14] <robotfuel> [    28.871] reloc emit failure -22 (evergreen_cp_set_surface_sync 371)
[15:14] <kgunn> mlankhorst: ^
[15:15] <kgunn> robotfuel: curious can you vt switch, then $ sudo chmod 777 /tmp/mir_socket
[15:16] <kgunn> then $sudo mir_demo_client_egltriangle...then vt switch back to vt7....and see what happens?
[15:16] <robotfuel> kgunn: ok
[15:19] <robotfuel> kgunn: vt change has a scrolling error gem object lookup failed 0xa
[15:19] <robotfuel> kgunn: this is on radeon
[15:19] <kgunn> robotfuel: got it....all good data
[15:20] <kgunn> robotfuel: did you do a cross-check match of packages installed vs qa-testing2 ?
[15:22] <robotfuel> kgunn: doing that now, it looks good so far
[15:22] <sil2100> kgunn: hi!
[15:23] <sil2100> kgunn: during the last mirslave run we noticed that one of the AP tests failed on both machines
[15:23] <sil2100> kgunn: https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/1276/
[15:24] <sil2100> kgunn: not sure if that's just a flacky test or is this a real failure, but I think I'll fill in a bug anyway
[15:26] <kgunn> sil2100: ack...
[15:26] <kgunn> thomi: ^
[15:26] <robotfuel> kgunn: my meeting is over I am going to drive in to lexington
[15:27] <kgunn> robotfuel: cool...it'll be easier for you there i'm sure...just ping me when you're ready
[15:31] <sil2100> kgunn: https://bugs.launchpad.net/unity-system-compositor/+bug/1216979
[16:31] <kgunn> bschaefer: hey...you got a spare set of cycles?
[16:32] <bschaefer> kgunn,  possibly, whats up?
[16:35] <kgunn> bschaefer: just lookin' for a second set of eyes/attempt on nouveau and/or ati
[16:35] <bschaefer> kgunn, yeah I can try, I've to finish up some reviews first
[16:35] <kgunn> using mir-team/qa-testing2 ppa
[16:35] <kgunn> sure
[16:35] <bschaefer> cool
[16:35] <bschaefer> ill let you know!
[16:36] <kgunn> low expectations...but if you try, let me know if you boot to a usable unity (single monitor :)
[16:37] <bschaefer> well hopefully I can :)
[16:44] <robotfuel> kgunn: I'll test nvidia first with multimonitor
[16:45] <robotfuel> kgunn: I am in the lab
[16:47] <kgunn> robotfuel: cool...
[16:48] <kgunn> robotfuel: will be good to know if you get the same black screen on boot
[16:49] <jono> kgunn, on the Mir multimonitor page I see I pin:
[16:49] <jono>     Package: * Pin: origin "private-ppa.launchpad.net" Pin-Priority: 1001 Package: * Pin: release o=LP-PPA-mir-team-qa-testing2 Pin-Priority: 1002
[16:50] <jono> but it says I use the     $> sudo add-apt-repository ppa:mir-team/system-compositor-testing PPA
[16:50] <jono> shouldn'
[16:50] <jono> shouldn't the pin represent that PPA?
[16:50] <jono> I just added the PPA and MM doesn'work for me
[16:50] <robotfuel> kgunn: it looks like one intel machine passed on the testing2 ppa (not a multi-monitor test)
[16:51] <kgunn> jono: dang it....(going to make a tshirt that says "i hate ppa's"
[16:51] <jono> kgunn, do I add a different PPA?
[16:51] <kgunn> jono: right...for now its all qa-testin2
[16:51] <jono> kgunn, so do I remove the system-compositor PPA?
[16:51] <kgunn> when we go live to test external...we'll use system-compositor-testing
[16:52] <kgunn> sorry for the confusion
[16:52] <jono> np
[16:53] <jono> kgunn, we go live today, right?
[16:53] <jono> according to balloons
[16:53] <kgunn> jono: yes
[16:53] <jono> cool
[16:53] <jono> will res changes and rotation be fixed this week?
[16:54] <jono> brb
[16:56] <kgunn> robotfuel: would you mind just hotplugging a monitor into the intel machine...so when olli asks i can say...yes, robotfuel saw multimon work on the anointed machine :)
[16:57] <robotfuel> kgunn: will do.
[16:57] <robotfuel> kgunn: the nvidia machine has a black screens
[16:57] <robotfuel> kgunn: I'll try the vt change thing and let you know how it goes
[16:58] <kgunn> robotfuel: sounds intimidating :)
[16:58] <kgunn> robotfuel: thanks
[16:58] <kgunn> and check xorg.0.log if you don't mind
[17:01] <robotfuel> kgunn:  x went to fallback mode after the vt switch
[17:02] <kgunn> robotfuel: ooo, well that's kinda nice
[17:02] <robotfuel> kgunn: fallback meaning low-graphics mode
[17:02] <kgunn> robotfuel: oh, nvmd that's awful
[17:03] <kgunn> robotfuel: Xorg.0.log ?
[17:04] <robotfuel> kgunn: I am grabbing that now, I'll pastebin it
[17:05] <kgunn> robotfuel: would be good to get one prior to vt switch (sorry to be so picky)
[17:06] <robotfuel> kgunn: http://pastebin.ubuntu.com/6029411/ (with vtswitch)
[17:08] <robotfuel> kgunn: without vtswitch http://pastebin.ubuntu.com/6029418/
[17:10] <kgunn> robotfuel: more than i could hope for...putting both in the bug
[17:11] <robotfuel> kgunn: do you want me to use apport on the u-s-c and xorg crashes?
[17:11] <kgunn> that'd be good robotfuel
[17:13] <kgunn> robotfuel: now just need to double check the ati's....i assume black screen...but need to check xorg & try vt switch as well...
[17:14] <robotfuel> kgunn: ack, after I do the apport thing I'll check ati, then intel last.
[17:14] <kgunn> great
[17:14] <kgunn> robotfuel: i'll brb...gonna eat a quick lunch
[17:35] <kgunn> robotfuel: i'm bacl
[17:35] <kgunn> back even
[17:47] <kgunn> and...quick reboot
[18:00] <bschaefer> kgunn, hey, I got a black screen,but I still heard the lightdm login sound...
[18:00] <bschaefer> i also was getting a strange error on my tty...but its not on any logs that I can find...
[18:00]  * bschaefer digs for it
[18:05] <robotfuel> bschaefer: something about gem object lookup failed?
[18:06] <bschaefer> robotfuel, yup!
[18:06] <bschaefer> i can't find it logged anywhere...
[18:06] <bschaefer> there it is:
[18:07] <bschaefer> kernel: [   67.625036] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xb
[18:07] <robotfuel> I have a 0xa on one with the kvm and 0x8 using 2 monitors
[18:07] <bschaefer> kernel: [   67.628417] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xb
[18:07] <bschaefer> kernel: [   67.629992] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2!
[18:08] <bschaefer> robotfuel, hmm interesting, let me try with 2 monitors, or one? I forgot if I had my other one turned on :)
[18:10] <bschaefer> though I don't think it matters much...
[18:11] <kgunn> bschaefer: thanks...adding your details to the bug
[18:11] <bschaefer> kgunn, my video card is: 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Redwood XT [Radeon HD 5670/5690/5730]
[18:11] <bschaefer> the 5670 one...
[18:17] <robotfuel> kgunn: 2 of the intel machines time out, it looks like the benchmark hung using the new driver xserver-xorg-video-intel (2:2.21.14-4ubuntu2+xmirMM7) one of them passed
[18:21] <kgunn> robotfuel: did woopsie interfere ?
[18:22] <robotfuel> kgunn: I am watching the test run now to see what happens
[18:25] <kgunn> robotfuel: iirc i ran...but might have been one driver before....lemme run here
[18:33] <kgunn> robotfuel: hmmm running openarea no prob here...2 runs, 2 diff resolutions
[18:33] <kgunn> robotfuel: going to try my second machine
[18:44] <kgunn> robotfuel: did i miss it...did you also alreday check the ati machine(s)....just looking to be conclusive on "it didn't work" :)
[18:49] <kgunn> robotfuel: really only need 2 questions re qa-testing2 answered now #1) result of ati machine there boot to unity (single screen) & #2) did intel support hotplug of monitor to show multimon
[18:52] <robotfuel> kgunn: single intel on the kvm is messed up. I am trouble shooting that now.
[18:53] <robotfuel> kgunn: single monitor boot to unity on ati was a black screen.
[18:53] <robotfuel> kgunn: I'll plug in a monitor now, they are hard to get to.
[18:54] <kgunn> robotfuel: you might have to "liberate" some :)
[19:01] <robotfuel> kgunn: the video looked tiled on the kvm, but looks ok with a monitor connected
[19:02] <kgunn> robotfuel: ack thanks
[19:26] <robotfuel> kgunn: the intel machines don't have a place for a second monitor, they only have one hdmi port, no vga or dvi
[19:27] <kgunn> robotfuel: haha
[19:27] <kgunn> you can't make this stuff up
[19:30] <robotfuel> kgunn: the ps-intel-3000 has a vga and display port, so I can test it on that machine. the other 2 only have hdmi
[19:30] <kgunn> robotfuel: that's ok...both DP and hdmi worked
[19:38] <robotfuel> kgunn: benchmarks are up http://reports.qa.ubuntu.com/graphics/openarena/
[19:39] <kgunn> robotfuel: awesome! thanks...thanks for all the hard work that has gone (and is going) into that
[19:40] <robotfuel> kgunn: you can double click the bar and it will take you to the jenkins build for that run, so you can look at the log files easily.
[19:40] <kgunn> robotfuel: you're going to spoil us
[20:14] <robotfuel> kgunn: on intel xrandr is reporting 2 monitors are connected, even though only one monitor is connected
[20:15] <robotfuel> kgunn: I turned off the second monitor and the screen is blank now. (there was XMIR-0 and XMIR-2, I did xrandr --output XMIR-2 --off)
[20:16] <kgunn> robotfuel: was that using displayport ?
[20:16] <robotfuel> kgunn: hdmi
[20:16] <kgunn> hmmm...hadn't seen weirdness from hdmi yet...that's a good bug tho
[20:16] <kgunn> or good you caught it
[20:18] <robotfuel> kgunn: I resized XMIR-0 to 800x600 and it showed the 2 displays, one 800x600 and one 1024x768 display on the same monitor
[20:18] <robotfuel> I'll write a bug
[20:18] <kgunn> robotfuel: ta
[21:25] <jono> kgunn, installed the PPA, a bit of screwing with different res settings but dual-screen MM working perfectly on Intel :-)
[21:25] <kgunn> jono: good to hear :)
[21:25] <jono> kgunn, my default setup before-hand had part of the image chopped off
[21:59] <robotfuel> kgunn: will you need me in lexington tomorrow?
[22:00] <kgunn> robotfuel: i don't think so...
[22:02] <robotfuel> kgunn: ok I won't plan on it then. I won't be there first thing in the morning, but I'll drive in if you need me there again :)
[22:03] <kgunn> robotfuel: hey thank you for doing it today...greatly appreciate that...i owe you  abeer in a couple of weeks
[22:05]  * robert_ancell things kgunn is going to have a keg party :)
[22:06] <kgunn> robert_ancell: shhhhh
[22:06] <kgunn> that or just hand out fifths of whiskey
[22:08] <robert_ancell> thomi, could you copy the qa-ppa2 config and make a system-compositor testing one? That way we can test any of the PPAs in Jenkins
[22:11] <thomi> robotfuel: can you do that with your fancy-pants script?
[22:12] <robotfuel> thomi: so we want new tests or we want to modify the existing tests?
[22:12] <thomi> robotfuel: I guess a new set
[22:12] <thomi> with a corresponding new kickoff job
[22:13] <thomi> the only difference being the ppa we add
[22:13] <robotfuel> thomi: ok, I'll just need to create a new branch to pull from and I'll upload that
[22:13] <robotfuel> thomi: I'll ping you when I am done
[22:17] <netlar> Do they developers of apps for Ubuntu have to port over apps to mir, and if they do not the app will run on xmir right?
[22:25] <robotfuel> thomi: http://10.97.2.12:8080/view/sct-ppa/
[22:26] <thomi> robert_ancell: ^
[22:26] <thomi> thanks robert_ancell
[22:26] <thomi> err robotfuel
[22:26] <robert_ancell> thanks robotfuel!
[22:27] <robotfuel> thomi: BTW, I had to add apt-get install the intel radeon and nouveau drivers to get the qa ppa2 to work today
[22:28] <thomi> does the image install the proprietary drivers by default?
[22:29] <robotfuel> no those are the opensource drivers, they were pinned in the ppa, but not installed with apt-get install unity-system-compositor
[22:29] <robotfuel> if I explicitly do apt-get install xserver-xorg-<driver> they did get installed from the ppa
[22:31] <robotfuel> thomi: robert_ancell: BTW benchmarks are live http://reports.qa.ubuntu.com/graphics/openarena/
[22:31] <robert_ancell> robotfuel, this is from the main archive?
[22:32] <thomi> robotfuel: cool, I see my graph suggestions were too contentous to apply at short notice ;)
[22:32] <robotfuel> robert_ancell: yes the main archive
[22:32] <robert_ancell> robotfuel, can we get a line graph or similar? It's hard to tell if they're changing over time
[22:32] <robotfuel> thomi: I had your suggestions done in my first revision of the benchmarks using google charts. with the line graph and one day of results.
[22:33] <robotfuel> thomi: they didn't like the line graph
[22:33] <robotfuel> :(
[22:33] <thomi> yeah well, there's no educating some people
[22:34] <robotfuel> thomi: I could make a http://reports.qa.ubuntu.com/graphics/openarena/line and display a line graph
[22:34] <thomi> I should send someone a high school textbook and highlight the sections about histograms and bar graphs
[22:34] <thomi> robotfuel: nah, it's cool, I don't care that much :)
[22:34] <robotfuel> ok :) I am EOD ttyl
[22:35] <RAOF> Alright. Let's see if I can track down what madness I unleashed on radeon...
[22:38] <bschaefer> RAOF, if you need something to test out you can send me a patch :)
[22:38] <jono> RAOF, is https://bugs.launchpad.net/xmir/+bug/1192843 fixed?
[22:38] <RAOF> jono: no
[22:38] <jono> Matthew Garrett raised a valid point about this
[22:38] <jono> and I don't a clear mention of a security issue on the call for testing
[22:39] <jono> kgunn, ^
[22:40] <RAOF> Yes, we should stick a big fat warning on that.
[22:40] <kgunn> RAOF: jono robert_ancell ....i thot this was fixed
[22:41] <kgunn> we landed and i thot robert_ancell rebased on
[22:41] <RAOF> kgunn: The mir infrastructure required to fix that in XMir has landed; the actual fix in XMir isn't implemented.
[22:41] <robert_ancell> kgunn, no, only the first part of the fix is done - the bug report mentions that
[22:41] <jono> kgunn, RAOF, robert_ancell this really should have been mentioned in the call for testing
[22:41] <jono> I am updating the wiki now
[22:41] <kgunn> robert_ancell: my bad...can you add that to the ppa preamble ?
[22:42] <robert_ancell> kgunn, yes
[22:42] <kgunn> jono: so sorry...i really can't believe i missed that
[22:42] <kgunn> i guess we'll know if Matthew tries to test
[22:42] <jono> kgunn, unfortunately I heard about it from Matthew Garrett on Twitter
[22:42] <kgunn> jono: sorry...
[22:43] <jono> kgunn, nm
[22:44] <robert_ancell> kgunn, updated
[22:44] <kgunn> ta
[22:44] <robert_ancell> RAOF, anything I can do to help get that fixed in XMir?
[22:45] <robert_ancell> kgunn, there's two bugs marked "sessions" at the bottom of the description of the PPA - did you add that?
[22:45] <kgunn> robert_ancell: nope those were there...
[22:46] <robert_ancell> it's the VT input bugs, I've just moved them to the top
[22:50] <RAOF> robert_ancell: You could check that USC marks every surface as unfocused on VT switch.
[22:50] <robert_ancell> RAOF, will do
[22:51] <RAOF> robert_ancell: And that USC marks (at least one, but preferably) each window of an active session as focused.
[23:06] <kgunn> robert_ancell: i'm actually going get off for a while....but i'll be back on late just to check in
[23:07] <robert_ancell> kgunn, bye
[23:56]  * robert_ancell -> lunch