#ubuntu-mir 2013-08-26
<kgunn> RAOF: anything noteworthy about xserver mm 14 & intel mm7 ?
<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?
<kgunn> ah,....i see buffer stride via the interface
<RAOF> Yeah.
<RAOF> You know what would be awesome? If our acceptance tests weren't riddled with non-deterministic failures :(
<robert_ancell> thomi, ah, xrandr is considered a bit unstable
<thomi> ugh
<RAOF> thomi: Also, that check will become incorrect as soon as I create outputs with correct names (like HDMI-1 and eDP-1, etc)
<thomi> so, what should it be doind?
<thomi> *doing
<RAOF> âgrep "LoadModule.*xmir" /var/log/Xorg.${DISPLAY#:}.logâ is reasonable.
<thomi> RAOF: thanks
<thomi> robert_ancell: that fix is now in place - should I run the tests again?
<robert_ancell> thomi, please do
<thomi> robert_ancell: it seems like some jobs are already running :-/
<robert_ancell> thomi, I started it earlier, some might not have completed
<thomi> should I kill them, or wait?
<robert_ancell> thomi, kill them
<thomi> ok, they're running again
 * RAOF wonders whether he should set up an android test environment or just wait the 30minutes for Jenkins to run the tests...
<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.
<duflu> I'd just like a script that I didn't have to Ctrl+C part way through to use effectively
<duflu> Though, I also don't have an N4 right now :/
<duflu> Are we waiting on anything to get the bypass patch back in the PPA for testing?
<duflu> robert_ancell, RAOF ^
<RAOF> We should probably reverse copy from qa-testing2 to qu-testing now that MM is pretty much good in qa-testing2
<duflu> RAOF: Did you try ignoring buffer age yet?
<RAOF> duflu: Yes. I was just about to say that it doesn't help.
<RAOF> :)
<duflu> Fark. Well at least we know it's not from bypass. Back to square one
<RAOF> It's going to be the compositor displaying buffers out of order again.
<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
<duflu> lp:mir is still /too flawless/. There's something our demos are not doing to trigger the bug
<duflu> RAOF: Can you please triple check going age-less? I don't want to spent more days in that rabbit hole accidentally...
<RAOF> Ok
<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.
<duflu> RAOF: That's feasible
<duflu> Though we are almost certain already that it's the wrong order. The how and why is important
<duflu> And how to reproduce it with lp:mir servers/clients only
<robert_ancell> duflu, last I heard from kgunn and olli, yes
<robert_ancell> duflu, sorry, "back into the PPA" - do you mean the multi-monitor PPA?
 * 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
<duflu> robert_ancell: Yes qa-testing*. If there are any bugs then someone needs to tell me
<robert_ancell> duflu, at the moment we just want to be sure mm works before combining it with bypass
<duflu> robert_ancell: No problem. I only feared that some miscommunication about it being hideously broken may have occurred
<robert_ancell> duflu, does using bypass together amplify some bug still?
<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
<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.
<duflu> RAOF: Ok, ta
<RAOF> Huh. It's actually *two* frames behind!
 * RAOF types 123 into an xterm, and sees â1â
<duflu> Hmm, I wonder what Mir clients look like when the bug is occurring
<RAOF> Probably roughly normal, because they almost all buffer swap at vsync?
<RAOF> Only fingerpaint is likely to show anything, right?
<duflu> RAOF: Probably, but does it get input? I'll try
<duflu> Oh no, I can't the output_id fix isn't in the PPA yet
<duflu> RAOF: I'm not sure now. Is it only lag or wrong order too?
<RAOF> On the second head it seems to be purely lag.
<duflu> RAOF:  Hmm, hold a key down and sometimes you do see the future for a split second. That's wrong order
<RAOF> Ah, yes.
<RAOF> There we go.
<duflu> Should we say seeing the future is a *feature*?
<RAOF> Lag *and* out of order :)
<duflu> Interestingly, one monitor is bug-free
<RAOF> Yeah. We fixed the "only one surface buffer order presentation" problem :/
<duflu> OK, I have some good hints to work with
<duflu> RAOF: Have you seen any order problems with just one output?
<RAOF> No
 * RAOF luncheons
<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
<kgunn> i'll defer to you guys what order things need to land...
<robert_ancell> kgunn, duflu, I vote we land bypass now
<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
<ubot5> bug 1211700 in Mir "[radeon] [nouveau] Unthrottled EGL clients cause Mir to slow, sometimes to a halt" [Undecided,New] https://launchpad.net/bugs/1211700
<kgunn> robert_ancell: so...wrt multimon ppa....we just make sure not to let mir get rebuilt once its in archive ?
<robert_ancell> kgunn, we can make an inverse bypass branch if necessary for now
<duflu> robert_ancell: Do we need an env var to control it in case?
<robert_ancell> duflu, I wasn't aware it could be switched off - there may be a case for an option to disable it then
<kgunn> duflu: i personally like that idea...we had one in android & used it often for debug
<duflu> OK, will hack the option into the bypass branch first
<kgunn> if its low investment of ur time
<duflu> It's trivial
<kgunn> cool
<robert_ancell> kgunn, thomi, do you have the numbers for the bypass test?
<kgunn> robert_ancell: thomi ...http://10.97.2.12:8080/view/qa-ppa/
<kgunn> so you kinda have to dig a little
<kgunn> nothing looks completely amiss
<robert_ancell> kgunn, yeah, wondering if there's anything to copy and paste into the MP
<robert_ancell> brb
<duflu> kgunn, robert_ancell: OK you can disable it with MIR_BYPASS=0
<robert_ancell> duflu, awesome
<robert_ancell> duflu, did you consider a command line flag? Then it can be disabled by either a flag or an env variable
<duflu> robert_ancell: No... would that set the environment internally? If not then there's a lot of wiring up that would require
<robert_ancell> duflu, all command line flags can be set with MIR_SERVER_FOO for --foo
<duflu> robert_ancell: That doesn't have to be redone for each server right?
<robert_ancell> duflu, nope, they all get that
<kgunn> robert_ancell: so...should we line up the canonical folks tonight we want to give multimon a shot their morning ??
<robert_ancell> kgunn, RAOF, it only works for intel right?
<kgunn> or should we wait a bit ?
<duflu> Now it's a non-trivial exercise :/
<kgunn> robert_ancell: i thot you were trying to run it on the boston 8 earlier ?...did ati/nouveau fail ?
<duflu> robert_ancell: Too complex to rush in such logic right now. It's pretty hidden so we can change it later
<duflu> ... because getting command line option values seems to create complex class dependencies
<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
<thomi> robert_ancell: re-running with some tweaks to the test script
<RAOF> robert_ancell: ati & nouveau should work, but I haven't tested them.
<kgunn> cool...so we could just line up the internal testers w reckless abandon
<RAOF> Yup.
<kgunn> thomi: think we could get a sanity (e.g. does it boot) on ati/nouveau within an hour ?
<thomi> on the boston 8?
<thomi> I can just run them without the test, if you like
<kgunn> yes...or any for that mattter
<RAOF> Yes, that would be nice.
<thomi> ...do we expect it to not boot!?
<kgunn> yeah...i just don't want to tell people to test w/o having some idea of what will happen
<RAOF> Oh, I expect it to boot, but it *might* not bring up X
<kgunn> :)
<kgunn> just a little thing like that
<RAOF> I don't *think* that there's anything wrong with the changes, but I haven't tested them :)
<kgunn> so yeah..boot to usable ui is the litmus
<thomi> heh, would be a lot easier if I was in the lab, but I can kick it off after the current test runs
<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
<RAOF> Output change?
<RAOF> USC changes output layout when I fire up mir_demo_client_egltriangle.
<RAOF> Which is expected behaviour; resolution is per-session.
<duflu> RAOF: But XMir is still composited and visible. Just frozen when a Mir client is focussed.
<duflu> If it's composited and visible, it should keep rendering
<kgunn> bbiab
<robert_ancell> RAOF, so do you have a multi-monitor desktop working at the moment?
<RAOF> Yes.
<robert_ancell> I can't get spanning working in Unity and while playing with it I just end up with a black screen
<RAOF> qa-testing2 works fine for me.
<RAOF> Do you have delicious logs?
<robert_ancell> what would you like? I've just restarted into a fresh session
<RAOF> Xorg log, unity-system-compositor log, & lightdm log?
<robert_ancell> brb
<thomi> bah, jobs still failing
<RAOF> robert_ancell: Winning?
<robert_ancell> RAOF, ok, lets start with what I see.
<RAOF> robert_ancell: Winning! https://code.launchpad.net/~raof/mir/fix-multi-surface-buffer-tracking/+merge/181259
<robert_ancell> RAOF, 1. Log into Unity without monitor connected, all good
<robert_ancell> 2. Connect monitor
<robert_ancell> 3. See a pile of flickering, then second monitor shows mirrored display
<robert_ancell> 4. BUT, the second display is taller and thinner than my laptop one so the desktop is cropped and extended
<robert_ancell> 5. Can't launch any new X apps
<RAOF> Good so far. I'm not sure why it flickers so much - I think that Mir is doing more modesetting than necessary.
<robert_ancell> the X log shows ~1.6 million lines of "_XSERVTransSocketUNIXAccept: accept() failed"
<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.
<robert_ancell> ah
<RAOF> (Mir is flooding the server with fds until accept() can't open a new fd)
<robert_ancell> I have qa-testing pinned, not qa-testing2
<robert_ancell> ok, I'll rinse and repeat
<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
<robert_ancell> thomi, ta
<thomi> I gotta go lie down though, I'm sick :(
<thomi> will be back later maybe
<robert_ancell> thomi, get well!
<robert_ancell> RAOF, Do you know if SwapIntervalSignalTest works with fix-multi-surface-buffer-tracking? i.e. is alan_g's problem resolved?
<robert_ancell> duflu, can you review that too asap if you need to?
<RAOF> robert_ancell: Yes, it's resolved.
<RAOF> robert_ancell: (As you can see from the tests all passing âº)
<duflu> robert_ancell: Yeah. I also have a reasonable theory for bad buffer ordering now. But first, lunch, postoffice, coffee
<RAOF> I'm going out for a couple of hours; I'll get back to testing once I'm back.
<robert_ancell> duflu, do you want to delay landing this?
<robert_ancell> RAOF, cool, aside from the known lagging issue it works for me!
<duflu> robert_ancell, I don't want to delay anything... Just going to lunch
<robert_ancell> duflu, I mean, should we wait for you or you don't plan on reviewing
<robert_ancell> kgunn, do you have that list of internal testers for multi-monitor? I'm having trouble finding it in my email
<kgunn> robert_ancell: i do ...i crafted a setup email just now
<robert_ancell> ok, cool
<kgunn> robert_ancell: i'm gonna send...please read, then just followup with expectations on ati/nouveau
<robert_ancell> RAOF, ati/nouveau are expected to work, just no-one has tested them right?
<kgunn> robert_ancell: yeah...that's what he was saying
<robert_ancell> kgunn, the Boston 8 tests are all failing again
<kgunn> :-|
<robert_ancell> kgunn, can you see those jenkins logs?
<kgunn> http://10.97.2.12:8080/view/qa-ppa2/
<robert_ancell> yeah
<kgunn> i don't get it tho...it says intel is failing but the results look good
<kgunn> on both resolutions
<robert_ancell> kgunn, where are you looking at results?
<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/
<kgunn> then drill into each folder marked for resolution...
<kgunn> then composite.xml
<kgunn> i'm gonna head off to bed....see you tomorrow
<robert_ancell> later
<kgunn> tvoss: i'll see you in ~9 hrs w/ olli :)
<tvoss> kgunn, ack, later
<robert_ancell> RAOF, so you think ati works, but you haven't tested it? You have some ati hardware right?
<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?
<robert_ancell> I'm finishing up for the night, any last requests?
<duflu> robert_ancell: Relax?
<robert_ancell> that would be awesome
<tvoss> duflu, ping
<duflu> tvoss, pong
<RAOF> Ok.
<RAOF> Let's test that radeon boots, at least.
<duflu> Argh. I _still_ can't find a theoretical reason for bad frame ordering. The algorithm's designed to make it (theoretically) impossible
<dholbach> good morning
<RAOF> Good morning.
<RAOF> Ah. I seem to have managed to break radeon. Excellent.
<dholbach> hey RAOF
<mlankhorst> perfect
<mlankhorst> duflu: maybe it's not the theory, it's the implementation? :P
<duflu> mlankhorst: Yeah, which is why I'm trying to find bugs still
<mlankhorst> RAOF: perfect, can I look at it? :P
<RAOF> mlankhorst: You're welcome to. It's... oh, not hosted in any public git tree.
<RAOF> Let me fix that :)
<RAOF> I've probably set the stride of the thingy wrong.
<mlankhorst> yeah those thingies can get picky
<RAOF> mlankhorst: github.com/RAOF/xf86-video-ati, branch "foo"
<mlankhorst> RAOF: what mir branch etc do I need for that? or ppa
<RAOF> You need ppa:mir-team/qa-testing2
<RAOF> Or github.com/RAOF/xserver , branch vladmir-upstreaming
<mlankhorst> ah
<RAOF> mlankhorst: I'll have set devKind incorrectly in the ModifyPixmapHeader call.
<RAOF> Becasue I'm still not entirely sure what WTH that's meant to be :)
<RAOF> mlankhorst: Oh, I may have done the same for nouveau...
<RAOF> mlankhorst: Do you remember offhand what devKind is meant to be for radeon?
<RAOF> Hm. It *is* meant to be stride.
<mlankhorst> RAOF: it's stride for all ddx iirc
<RAOF> Then I broke it somewhere else :/
<mlankhorst> yeah I'll take a look
<mlankhorst> power just cut out :/
<mlankhorst> for like 5 minutes or so
<tvoss__> mlankhorst, in your place?
<mlankhorst> yeah
<mlankhorst> RAOF: do you get something like this?
<mlankhorst> [  403.880155] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x9
<mlankhorst> [  403.880435] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2!
<duflu> Sigh. We may yet need a universal frame counter to throttle clients accurately under multimonitor
<duflu> Wait a minute... what is "accurate"?
<duflu> Surely if your client doesn't do "accurate" timing and relies on vsync then 120Hz with two monitors is not necessarily wrong :/
<duflu> Hmm
<mlankhorst> duflu: that is assuming both monitors have the same scanrate
<duflu> mlankhorst: I mean generally sum of all
<duflu> I think we've been trying to meet a requirement that doesn't really exist...
<mlankhorst> RAOF: lol
<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)
<mlankhorst> combined with the previous errors it looks like your handles are corrupted :P
<mlankhorst>  +      if (!pScreen->ModifyPixmapHeader(dst,
<mlankhorst> -+                                       pScrn->virtualX, pScrn->virtualY,
<mlankhorst> ++                                       output_box->x2 - output_box->x1,
<mlankhorst> ++                     output_box->y2 - output_box->y1,
<mlankhorst> looks wrong..
<mlankhorst> hm and the last error might be from freeing a buffer
<hikiko> hello :) could someone review this branch: https://code.launchpad.net/~hikiko/mir/mir.gbm-buffer-allocator-modifications/+merge/182049 if not busy?
<mlankhorst> RAOF: with valgrind I seem to get more errors :P
<mlankhorst> definitely looks like the bo's get unreffed before being used..
<RAOF> mlankhorst: That seems... wat? The changes shouldn't change when the bos get unreffed!
<mlankhorst> RAOF: well from the dmesg I'm guessing that somewhere something gets freed before it should
<mlankhorst> if i run things with valgrind I end up with Xorg failing in random random crashes
<mlankhorst> s/random.*/random places/
<RAOF> mlankhorst: Oh, that reminds me. I should push the xf86-video-intel change to actually enable the valgrind support.
<mlankhorst> wasn't --enable-valgrind already added, or did you redisable it?
<RAOF> No, it's enabled, but only if DEB_HOST_ARCH == linux
<RAOF> But DEB_HOST_ARCH is never linux; you misspelt DEB_HOST_ARCH_OS
<mlankhorst> oops
<mlankhorst> RAOF: anyway I'm getting some weirdness that indicates a flink leak, though. but no clue as to where it comes from yet..
<RAOF> Colour me confused, then.
<mlankhorst> erm I mean you're probably freeing something twice
<mlankhorst> or before using it
<mlankhorst> or a particularly nasty kernel corruption.. I'll try on my older card
<mlankhorst> RAOF: were you getting the same kind of errors?
<RAOF> mlankhorst: Hm, no.
<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.
<mlankhorst> I'm getting tons of crap like this
<mlankhorst> [   99.170371] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2!
<mlankhorst> [   99.178895] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x9
<mlankhorst> and
<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)
<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)
<RAOF> Ah, yes. I see those.
<mlankhorst> which makes me think that some stuff gets freed by the driver before submitting the commands
<RAOF> Ah, fair enough.
 * RAOF was confused about your valgrind comment.
<mlankhorst> RAOF: well I get some memcpy crashes from valgrind
<mlankhorst> but nothing pointing towards what is going on
<RAOF> Huh, really?
<RAOF> memcpy?
<mlankhorst> RAOF: does the root window have damage tracking after a resize event?
<RAOF> Yes.
<RAOF> But we should be disabling everything that has damage associated with the screen pixmap before resizing.
<RAOF> 'cause we throw away the screen pixmap on resize, but not the root window.
<mlankhorst> .. do you? :p
<RAOF> I'm reasonably sure?
<mlankhorst> hm good enough
<RAOF> Anyway, resize isn't called in xserver startup?
<mlankhorst> I'm trying to figure out what is going on there though
<RAOF> What's your memcpy crash, anyway?
<duflu> Woo! Perfect multimonitor frame sync with no timers!
<mlankhorst> RAOF: never the same twice :/
<mlankhorst> but usually exa related
<mlankhorst> actually always the same it seems, it's from fallback call. same thing that happens when acceleration in nouveau fails
<mlankhorst> and preceded by failed to map pixmap: -2
<mlankhorst> hm from procRenderCreateCursor..
<mlankhorst> http://paste.debian.net/30292/ with memory summary removed
<mlankhorst> RAOF: it worked on intel right?
<RAOF> Yeah, works on intel.
<mlankhorst> RAOF: implement shadowfb call :P
<duflu> Well, actually, my sync is temporarily lost when VT switching, but it comes back eventually
<RAOF> Also, I *don't* see that CreateCursor crash.
<mlankhorst> hm actually it wouldn't help
<mlankhorst> it's falling back to downloading to screen because the mapping was failing
<duflu> You know, it's rather hard to create visual glitches when you're triple buffering. I never realized just how hard...
<mlankhorst> it's easy if you relax the restriction and allow them to be fatal :P
<RAOF> Heh
<mlankhorst> RAOF: also curious it looks like xmir_copy_to_mir was wrong in another place
<RAOF> Oh?
<mlankhorst> you set dst x / y to 0 0, should probably be the same as src x y
<RAOF> dst x/y is not location in the destination buffer?
<mlankhorst> it is
<RAOF> Then why wouldn't I want it to be 0 0?
<mlankhorst> but I'm guessing the destination buffer is full sized?
<RAOF> No, the destination buffer is output-sized.
<RAOF> Welcome to the poor-man's Shatter.
<mlankhorst> ah..
<mlankhorst> RAOF: you allocate a single bo for the entire screen, but each output uses a chunk of it?
<RAOF> There's a single bo for the ScreenPixmap.
<RAOF> But we copy each region that corresponds to an output into a different xmir_window
<mlankhorst> nasty
<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.
<RAOF> Eh, I don't think it's particularly nastier than having a single framebuffer surface and copying the whole root window into it.
<mlankhorst> I don't really see where this particular error is coming from, what is your failure mode?
<RAOF> Of *course* I don't see this crash under gdb & mir_demo_server_shell!
<RAOF> BAH.
<mlankhorst> ..?
<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
<RAOF> mlankhorst: I can, apparently, quite happily run radeon under mir_demo_server_shell in gdb.
<RAOF> No crashes, no madness...
<RAOF> To be fair I'm not *actually* looking at the display; it's upstairs, so it might be entirely wrong âº
<tvoss__> RAOF, rofl
<mlankhorst> you're like those tv commercials where they put 'not showing the actual product' in small letters on the bottom
<mlankhorst> RAOF: is it just the xserver, or a full session?
<RAOF> Just the X server.
<mlankhorst> well duh :P
<RAOF> Why duh?
<mlankhorst> see if it survives this: DISPLAY=:0 XDESKTOP_SESSION=ubuntu /etc/X11/Xsession
<mlankhorst> erm
<mlankhorst> DESKTOP_SESSION*
<RAOF> Hm. dmesg does not survive DISPLAY=:33 glxgears :)
<mlankhorst> hah
<RAOF> [ 1806.614838] [drm:r600_cs_common_vline_parse] *ERROR* cannot find crtc 1436857232
<RAOF> I'm not surprised it can't find it!
<mlankhorst> or are you? DUN DUN DUUUN
<mlankhorst> 55a4b390
<mlankhorst> RAOF: ah right, it's calling evergreen_cp_wait_vline_sync
<RAOF> That seems unlikely to work. I thought I disabled vsyncing?
<mlankhorst> all the calls are hidden behind accel_state->vsync
<tvoss__> okay, time to take care of my visum for china
<RAOF> Oh, dear.
<RAOF> No, I undisabled vsynching when I shoved a non-null driver private in xf86Crtc.
<mlankhorst> RAOF: erm it looks like the calls are only emitted if the driver has accel_state->vsync set though
 * tvoss__ thinks about undisabled
<RAOF> mlankhorst: Try bailing early with NULL from radeon_pick_best_crtc (in radeon_video.c)?
<RAOF> Ok, time for me to sleep
<mlankhorst> that's xv stuff..
<mlankhorst> RAOF: did you explicitly enable vsync or something?
<mlankhorst> looks like vsync is disabled in radeon unless you explicitly enable it
<mlankhorst> hm indeed, same issue here :p
<mlankhorst> radeon_dri2.c:    info->accel_state->vsync = info->swapBuffersWait;
<mlankhorst> - OPTION_SWAPBUFFERS_WAIT, TRUE);
<mlankhorst> + OPTION_SWAPBUFFERS_WAIT, !xorgMir);
<mlankhorst> well that gets rid of 1 source of errors..
<mlankhorst> meh on the crashing call..
<mlankhorst> (gdb) print *(struct radeon_bo_gem*)((struct radeon_exa_pixmap_priv*)exaGetPixmapDriverPrivate(src))->bo
<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 = {
<mlankhorst>     atomic = 0}, priv_ptr = 0x0}
<mlankhorst> (gdb) print *(struct radeon_bo_gem*)((struct radeon_exa_pixmap_priv*)exaGetPixmapDriverPrivate(dst))->bo
<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 = {
<mlankhorst>     atomic = 0}, priv_ptr = 0x0}
<mlankhorst> [  491.685460] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0x9
<mlankhorst> it still has refcount set >:(
<kgunn> duflu: so is that branch good to go ?....e.g. add it to qa-testing2? or just build local for more confidence?
<kgunn> mlankhorst: i see chris went to bed, so does ati work with multimon ? (i'm guessing no...)
<mlankhorst> kgunn: it sort of looks like I'm hitting a kernel bug
<kgunn> mlankhorst: does it work on standard xmir (w.o multimon?)
<mlankhorst> hm I ws trying to rollback kernel, I guess standard xmir would be easier to test
<kgunn> mlankhorst: glad i asked :) save you some effort
<mlankhorst> hm I guess that works, weird stuff..
<kgunn> mlankhorst: so xmir in archive works...but xmir (multimon, qa-testing2 ppa) does not ?
<mlankhorst> yeah
<kgunn> meaning...can't boot to unity ? or cycles endlessly on greeter ?...curious the symptom/end user result
<mlankhorst> right now I just forced it to crash, saves times
<kgunn> :)
<kgunn> ricmm: i know you're swamped....had a chance to try xmir-multimonitor?
<kgunn> rsalveti: ^
<rsalveti> kgunn: will try today, have an ati board here
<rsalveti> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV620/M82 [Mobility Radeon HD 3450/3470]
<kgunn> rsalveti: well... :)   ...i'm sure you can see mlankhorst 's posts above
<rsalveti> but is that the same board?
<rsalveti> mine is quite old
<rsalveti> but guess I'd get the same crash
<rsalveti> we'll see
<ricmm> kgunn: negativo
<ricmm> and I actually cant, I dont have a second monitor
<ricmm> :(
<mlankhorst> not required
<mlankhorst> I was testing a single monitor setup
<kgunn> ricmm: so it would still be useful to see if you can boot into a useable unity session even on 1 monitor
<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
<kgunn> altho...looks like it hung or bailed on the last test (unsure)
<kgunn> ....looking from syslog...whoopsie might have gotten in the way ?
<kgunn> mlankhorst: ^....just sharing...no action
<mlankhorst> nouveau is easier to test though :P
<kgunn> thomi: robotfuel ^
<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.
<robotfuel> kgunn: I didn't setup the ppa2 jobs
<kgunn> robotfuel: thanks....actually....i see a radeon run now too :)
<kgunn> http://10.97.2.12:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-radeon-hd7450-le/ws/results/
<robotfuel> kgunn: it looks like package name issue is fixed but hasn't been run, I can also disable whoopsie
<kgunn> robotfuel: is that your subtle way of blaming the kiwi's :)
<kgunn> mlankhorst: http://10.97.2.12:8080/view/qa-ppa2/job/qa-ppa2-openarena-ps-radeon-hd7450-le/ws/results/
<kgunn> so that's interesting....that actually ran
<mlankhorst> kgunn: yeah but I'm on drm-next
<kgunn> mlankhorst: oh...
<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/
<kgunn> mlankhorst: that was lost on me...so qa-testing2 on drm-now...is ok?
<mlankhorst> no idea, stupid laptop won't cooperate :P
<kgunn> olli_: ^
<kgunn> olli_: so looks like nouveau & radeon are actually running
<kgunn> not sure why the report says fail...but if you dig...you can see results
<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
<kgunn> robotfuel: ah...got too excited
<kgunn> robotfuel: so can you confirm the following...xmir-mm (aka qa-ppa2) on ati & nouveau specifically
<kgunn> robotfuel: is actually running xmir & can boot to a usable unity ui (first)
<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
<kgunn> robotfuel: second, can you actually plug/unplug a second monitor monitor
<kgunn> robotfuel: like manually
<kgunn> robotfuel: like...as soon as you're able
<robotfuel> kgunn: sure, I will drive in during lunch
<kgunn> robotfuel: is there anyone in the office who could try ?
<kgunn> sorry racing clock
<robotfuel> rfowler might be in.
<robotfuel> kgunn: which machine do you want the monitor tried on first?
<kgunn> robotfuel: either...
<kgunn> robotfuel: we're just looking for a sanity test of multimonitor on xmir
<kgunn> robotfuel: can't seem to find anyone else in lex...so i might just be needing you to head for lunch
<robotfuel> kgunn: sounds good I can head in right after a meeting I have at 11am (40 minutes)
<kgunn> robotfuel: much thanks
<robotfuel> kgunn: I am getting no video on the kvm on intel with the qa-testing2 ppa
<mlankhorst> hm guess it's not just me then :P
<kgunn> robotfuel: meaning?...like you're in the unity ui but you can play youtube videos? or just nothing?
<robotfuel> kgunn: black screen
<robotfuel> kgunn: no ui
<kgunn> robotfuel: are the other intels the same??
<robotfuel> kgunn: yes same issue
<kgunn> robotfuel: what does apt-cache policy for xserver-xorg-video-intel say ?
<kgunn> robotfuel: what does apt-cache policy for unity-system-compositor say also ?
<robotfuel> kgunn: the driver is the issue apt-get install unity-system-compositor didn't pull in the driver.
<kgunn> robotfuel: sorry...i just have to ask...ppa pinned ?
<robotfuel> kgunn: yes it's pinned
<robotfuel> kgunn: unity-system-compositor is installed from the pinned ppa
<robotfuel> kgunn: sudo apt-get install xserver-xorg-video-intel pulls in the driver from the pinned ppa
<robotfuel> kgunn: seems like a packaging bug
<kgunn> robotfuel: just curious....how so ?...i was wondering....how is it pinned ??
<kgunn> take a look at this doc
<kgunn> https://docs.google.com/a/canonical.com/document/d/1hmSrL_ZqnpMo0oDf-lee22J2cJr54jWmCeziMxR131s/edit
<kgunn> ^ i am wondering if you need the extra bit at the top
<robotfuel> cat /etc/apt/preferences.d/50-pin-mir.pref Package: *
<robotfuel> Pin: origin "private-ppa.launchpad.net"
<robotfuel> Pin-Priority: 1001
<robotfuel> Package: *
<robotfuel> Pin: release o=LP-PPA-mir-team-qa-testing2
<robotfuel> Pin-Priority: 1002
<kgunn> my pin is like the bottom
<robotfuel> kgunn: my pin is like the bottom
<kgunn> robotfuel: cool...
<kgunn> so that's not it
<kgunn> robotfuel: i guess you'll need to check the blasted ati/nouveaus as well...
<robotfuel> kgunn: I can add the drivers to apt-get install line to get the correct driver.
<mlankhorst> looks like I messed up nouveau vblank in my tree, time to retest :P
<robotfuel> radeon is a black screen
<kgunn> robotfuel: thanks
<robotfuel> kgunn: wrong driver
<mlankhorst> robotfuel: anything in dmesg?
<robotfuel> kgunn: I need to update the test and re-run pulling in the driver.
<robotfuel> oops mlankhorst^
<kgunn> robotfuel: no problem...and as usual...thanks for the help
<mlankhorst> fwiw, same blackness here
<mlankhorst> on nouveau at least
<kgunn> mlankhorst: you get matches on cross check of apt-cache policy & qa-testing2  packages ?
<mlankhorst> yes
<kgunn> mlankhorst: does it make it to greeter ?
<mlankhorst> it's black, no idea, all I know is it doesn't crash
<kgunn> freaky...what does Xorg.0.log say ?
<mlankhorst> nothing interesting
<mlankhorst> pretends everything is fine
<kgunn> mmmm...can you vt switch....then $ sudo chmod 777 /tmp/mir_socket...$ sudo mir_demo_client_egltriangle...then switch back to vt7 ?
<kgunn> robotfuel: are you actually in office  already ?
<kgunn> must be driving
<robotfuel> kgunn: no in a meeting
<mlankhorst> kgunn: triangle works nicely
<mlankhorst> but I like the plasma one more :p
<kgunn> mlankhorst: do you see unity as a backdrop to the triangle ?
<mlankhorst> no the same blackness
<kgunn> huh
<hikiko> mmm anyone for the meeting?
<kgunn> so mir is up..u-s-c is up no problem
<mlankhorst> I think RAOF needs to get back to the drawing board somehow, and review what is going on with lifetime :P
<hikiko> I am alone there :)
<kgunn> hikiko: uk is off today...
<hikiko> oh :) i see
<kgunn> hikiko: free day to focus on mir-on-mir :)
<kgunn> mlankhorst: right...but this means mir is up, its like compiz failed
<kgunn> mlankhorst: or...xmir failed to hook up compiz to u-s-c frontend
<kgunn> mlankhorst: is there a way to verify is compiz loaded/rendered....but buffer just didnt make it to screen ?
<kgunn> like there should be more than one gl client active
<kgunn> 1 for mir....and 1 or more for unity/compiz
<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
<kgunn> mlankhorst: just trying to think how to help RAOF with some usable debug
<hikiko> bye!
<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
<kgunn> robotfuel: anything interesting at the end of /var/log/Xorg.0.log ?
<robotfuel> kgunn: a lot of this [    28.871] reloc emit failure -22 (evergreen_set_render_target 318)
<robotfuel> [    28.871] reloc emit failure -22 (evergreen_cp_set_surface_sync 371)
<kgunn> mlankhorst: ^
<kgunn> robotfuel: curious can you vt switch, then $ sudo chmod 777 /tmp/mir_socket
<kgunn> then $sudo mir_demo_client_egltriangle...then vt switch back to vt7....and see what happens?
<robotfuel> kgunn: ok
<robotfuel> kgunn: vt change has a scrolling error gem object lookup failed 0xa
<robotfuel> kgunn: this is on radeon
<kgunn> robotfuel: got it....all good data
<kgunn> robotfuel: did you do a cross-check match of packages installed vs qa-testing2 ?
<robotfuel> kgunn: doing that now, it looks good so far
<sil2100> kgunn: hi!
<sil2100> kgunn: during the last mirslave run we noticed that one of the AP tests failed on both machines
<sil2100> kgunn: https://jenkins.qa.ubuntu.com/job/autopilot-saucy-daily_release/1276/
<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
<kgunn> sil2100: ack...
<kgunn> thomi: ^
<robotfuel> kgunn: my meeting is over I am going to drive in to lexington
<kgunn> robotfuel: cool...it'll be easier for you there i'm sure...just ping me when you're ready
<sil2100> kgunn: https://bugs.launchpad.net/unity-system-compositor/+bug/1216979
<ubot5> Launchpad bug 1216979 in Unity System Compositor "Failing unity.tests.test_dash.DashMultiKeyTests.test_multi_key_delete autopilot test" [Undecided,New]
<kgunn> bschaefer: hey...you got a spare set of cycles?
<bschaefer> kgunn,  possibly, whats up?
<kgunn> bschaefer: just lookin' for a second set of eyes/attempt on nouveau and/or ati
<bschaefer> kgunn, yeah I can try, I've to finish up some reviews first
<kgunn> using mir-team/qa-testing2 ppa
<kgunn> sure
<bschaefer> cool
<bschaefer> ill let you know!
<kgunn> low expectations...but if you try, let me know if you boot to a usable unity (single monitor :)
<bschaefer> well hopefully I can :)
<robotfuel> kgunn: I'll test nvidia first with multimonitor
<robotfuel> kgunn: I am in the lab
<kgunn> robotfuel: cool...
<kgunn> robotfuel: will be good to know if you get the same black screen on boot
<jono> kgunn, on the Mir multimonitor page I see I pin:
<jono>     Package: * Pin: origin "private-ppa.launchpad.net" Pin-Priority: 1001 Package: * Pin: release o=LP-PPA-mir-team-qa-testing2 Pin-Priority: 1002
<jono> but it says I use the     $> sudo add-apt-repository ppa:mir-team/system-compositor-testing PPA
<jono> shouldn'
<jono> shouldn't the pin represent that PPA?
<jono> I just added the PPA and MM doesn'work for me
<robotfuel> kgunn: it looks like one intel machine passed on the testing2 ppa (not a multi-monitor test)
<kgunn> jono: dang it....(going to make a tshirt that says "i hate ppa's"
<jono> kgunn, do I add a different PPA?
<kgunn> jono: right...for now its all qa-testin2
<jono> kgunn, so do I remove the system-compositor PPA?
<kgunn> when we go live to test external...we'll use system-compositor-testing
<kgunn> sorry for the confusion
<jono> np
<jono> kgunn, we go live today, right?
<jono> according to balloons
<kgunn> jono: yes
<jono> cool
<jono> will res changes and rotation be fixed this week?
<jono> brb
<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 :)
<robotfuel> kgunn: will do.
<robotfuel> kgunn: the nvidia machine has a black screens
<robotfuel> kgunn: I'll try the vt change thing and let you know how it goes
<kgunn> robotfuel: sounds intimidating :)
<kgunn> robotfuel: thanks
<kgunn> and check xorg.0.log if you don't mind
<robotfuel> kgunn:  x went to fallback mode after the vt switch
<kgunn> robotfuel: ooo, well that's kinda nice
<robotfuel> kgunn: fallback meaning low-graphics mode
<kgunn> robotfuel: oh, nvmd that's awful
<kgunn> robotfuel: Xorg.0.log ?
<robotfuel> kgunn: I am grabbing that now, I'll pastebin it
<kgunn> robotfuel: would be good to get one prior to vt switch (sorry to be so picky)
<robotfuel> kgunn: http://pastebin.ubuntu.com/6029411/ (with vtswitch)
<robotfuel> kgunn: without vtswitch http://pastebin.ubuntu.com/6029418/
<kgunn> robotfuel: more than i could hope for...putting both in the bug
<robotfuel> kgunn: do you want me to use apport on the u-s-c and xorg crashes?
<kgunn> that'd be good robotfuel
<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...
<robotfuel> kgunn: ack, after I do the apport thing I'll check ati, then intel last.
<kgunn> great
<kgunn> robotfuel: i'll brb...gonna eat a quick lunch
<kgunn> robotfuel: i'm bacl
<kgunn> back even
<kgunn> and...quick reboot
<bschaefer> kgunn, hey, I got a black screen,but I still heard the lightdm login sound...
<bschaefer> i also was getting a strange error on my tty...but its not on any logs that I can find...
 * bschaefer digs for it
<robotfuel> bschaefer: something about gem object lookup failed?
<bschaefer> robotfuel, yup!
<bschaefer> i can't find it logged anywhere...
<bschaefer> there it is:
<bschaefer> kernel: [   67.625036] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xb
<robotfuel> I have a 0xa on one with the kvm and 0x8 using 2 monitors
<bschaefer> kernel: [   67.628417] [drm:radeon_cs_parser_relocs] *ERROR* gem object lookup failed 0xb
<bschaefer> kernel: [   67.629992] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -2!
<bschaefer> robotfuel, hmm interesting, let me try with 2 monitors, or one? I forgot if I had my other one turned on :)
<bschaefer> though I don't think it matters much...
<kgunn> bschaefer: thanks...adding your details to the bug
<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]
<bschaefer> the 5670 one...
<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
<kgunn> robotfuel: did woopsie interfere ?
<robotfuel> kgunn: I am watching the test run now to see what happens
<kgunn> robotfuel: iirc i ran...but might have been one driver before....lemme run here
<kgunn> robotfuel: hmmm running openarea no prob here...2 runs, 2 diff resolutions
<kgunn> robotfuel: going to try my second machine
<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" :)
<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
<robotfuel> kgunn: single intel on the kvm is messed up. I am trouble shooting that now.
<robotfuel> kgunn: single monitor boot to unity on ati was a black screen.
<robotfuel> kgunn: I'll plug in a monitor now, they are hard to get to.
<kgunn> robotfuel: you might have to "liberate" some :)
<robotfuel> kgunn: the video looked tiled on the kvm, but looks ok with a monitor connected
<kgunn> robotfuel: ack thanks
<robotfuel> kgunn: the intel machines don't have a place for a second monitor, they only have one hdmi port, no vga or dvi
<kgunn> robotfuel: haha
<kgunn> you can't make this stuff up
<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
<kgunn> robotfuel: that's ok...both DP and hdmi worked
<robotfuel> kgunn: benchmarks are up http://reports.qa.ubuntu.com/graphics/openarena/
<kgunn> robotfuel: awesome! thanks...thanks for all the hard work that has gone (and is going) into that
<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.
<kgunn> robotfuel: you're going to spoil us
<robotfuel> kgunn: on intel xrandr is reporting 2 monitors are connected, even though only one monitor is connected
<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)
<kgunn> robotfuel: was that using displayport ?
<robotfuel> kgunn: hdmi
<kgunn> hmmm...hadn't seen weirdness from hdmi yet...that's a good bug tho
<kgunn> or good you caught it
<robotfuel> kgunn: I resized XMIR-0 to 800x600 and it showed the 2 displays, one 800x600 and one 1024x768 display on the same monitor
<robotfuel> I'll write a bug
<kgunn> robotfuel: ta
<jono> kgunn, installed the PPA, a bit of screwing with different res settings but dual-screen MM working perfectly on Intel :-)
<kgunn> jono: good to hear :)
<jono> kgunn, my default setup before-hand had part of the image chopped off
<robotfuel> kgunn: will you need me in lexington tomorrow?
<kgunn> robotfuel: i don't think so...
<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 :)
<kgunn> robotfuel: hey thank you for doing it today...greatly appreciate that...i owe you  abeer in a couple of weeks
 * robert_ancell things kgunn is going to have a keg party :)
<kgunn> robert_ancell: shhhhh
<kgunn> that or just hand out fifths of whiskey
<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
<thomi> robotfuel: can you do that with your fancy-pants script?
<robotfuel> thomi: so we want new tests or we want to modify the existing tests?
<thomi> robotfuel: I guess a new set
<thomi> with a corresponding new kickoff job
<thomi> the only difference being the ppa we add
<robotfuel> thomi: ok, I'll just need to create a new branch to pull from and I'll upload that
<robotfuel> thomi: I'll ping you when I am done
<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?
<robotfuel> thomi: http://10.97.2.12:8080/view/sct-ppa/
<thomi> robert_ancell: ^
<thomi> thanks robert_ancell
<thomi> err robotfuel
<robert_ancell> thanks robotfuel!
<robotfuel> thomi: BTW, I had to add apt-get install the intel radeon and nouveau drivers to get the qa ppa2 to work today
<thomi> does the image install the proprietary drivers by default?
<robotfuel> no those are the opensource drivers, they were pinned in the ppa, but not installed with apt-get install unity-system-compositor
<robotfuel> if I explicitly do apt-get install xserver-xorg-<driver> they did get installed from the ppa
<robotfuel> thomi: robert_ancell: BTW benchmarks are live http://reports.qa.ubuntu.com/graphics/openarena/
<robert_ancell> robotfuel, this is from the main archive?
<thomi> robotfuel: cool, I see my graph suggestions were too contentous to apply at short notice ;)
<robotfuel> robert_ancell: yes the main archive
<robert_ancell> robotfuel, can we get a line graph or similar? It's hard to tell if they're changing over time
<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.
<robotfuel> thomi: they didn't like the line graph
<robotfuel> :(
<thomi> yeah well, there's no educating some people
<robotfuel> thomi: I could make a http://reports.qa.ubuntu.com/graphics/openarena/line and display a line graph
<thomi> I should send someone a high school textbook and highlight the sections about histograms and bar graphs
<thomi> robotfuel: nah, it's cool, I don't care that much :)
<robotfuel> ok :) I am EOD ttyl
<RAOF> Alright. Let's see if I can track down what madness I unleashed on radeon...
<bschaefer> RAOF, if you need something to test out you can send me a patch :)
<jono> RAOF, is https://bugs.launchpad.net/xmir/+bug/1192843 fixed?
<ubot5> Launchpad bug 1192843 in XMir "XMir receives input from other VTs" [Critical,In progress]
<RAOF> jono: no
<jono> Matthew Garrett raised a valid point about this
<jono> and I don't a clear mention of a security issue on the call for testing
<jono> kgunn, ^
<RAOF> Yes, we should stick a big fat warning on that.
<kgunn> RAOF: jono robert_ancell ....i thot this was fixed
<kgunn> we landed and i thot robert_ancell rebased on
<RAOF> kgunn: The mir infrastructure required to fix that in XMir has landed; the actual fix in XMir isn't implemented.
<robert_ancell> kgunn, no, only the first part of the fix is done - the bug report mentions that
<jono> kgunn, RAOF, robert_ancell this really should have been mentioned in the call for testing
<jono> I am updating the wiki now
<kgunn> robert_ancell: my bad...can you add that to the ppa preamble ?
<robert_ancell> kgunn, yes
<kgunn> jono: so sorry...i really can't believe i missed that
<kgunn> i guess we'll know if Matthew tries to test
<jono> kgunn, unfortunately I heard about it from Matthew Garrett on Twitter
<kgunn> jono: sorry...
<jono> kgunn, nm
<robert_ancell> kgunn, updated
<kgunn> ta
<robert_ancell> RAOF, anything I can do to help get that fixed in XMir?
<robert_ancell> kgunn, there's two bugs marked "sessions" at the bottom of the description of the PPA - did you add that?
<kgunn> robert_ancell: nope those were there...
<robert_ancell> it's the VT input bugs, I've just moved them to the top
<RAOF> robert_ancell: You could check that USC marks every surface as unfocused on VT switch.
<robert_ancell> RAOF, will do
<RAOF> robert_ancell: And that USC marks (at least one, but preferably) each window of an active session as focused.
<kgunn> robert_ancell: i'm actually going get off for a while....but i'll be back on late just to check in
<robert_ancell> kgunn, bye
 * robert_ancell -> lunch
#ubuntu-mir 2013-08-27
<RAOF> What? xmir_submit_rendering_for_window is never called?
<RAOF> Ahem.
<RAOF> I don't *call* xmir_submit_rendering_for_window.
<RAOF> Oops.
<RAOF> Well, that's really annoyingly stupid.
<robert_ancell> RAOF, whoops?
<RAOF> I've found out why radeon and nouveau don't work.
<RAOF> It's because I don't call xmir_submit_rendering_for_window.
<duflu_> That sounds important. How did intel work?
<RAOF> Because I do call xmir_submit_rendering_for_window there.
<RAOF> robert_ancell: So, there'll be radeon -MM3 and nouveau -MM3 that are more likely to actually work in the PPA soon :)
<robert_ancell> RAOF, cool, I'll give Jenkins a kick when they're ready
<robert_ancell> does anyone know how we disable ppc builds of mir?
<robert_ancell> Because u-s-c is waiting for libmirserver-dev to appear for PPC, and that's never going to happen
<RAOF> robert_ancell: I think you need to modify the Architecture of u-s-c, right?
<robert_ancell> RAOF, ah, true - thanks!
<smspillaz> argh
<smspillaz> australia tax
<RAOF> ?
 * RAOF needs to get his tax in order; there should be a juicy refund out of it.
<smspillaz> RAOF: I need to buy new headlights for my car
<smspillaz> there's like a 200% markup over shipping them from the UK
<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
<smspillaz> RAOF: but the shipping cost kinda negates buying them from there
<RAOF> Oh, australia tax. Right.
<smspillaz> RAOF: its like 7 pounds vs $AUD35
 * RAOF now gets it.
<robert_ancell> smspillaz, yeah, we get that too
<robert_ancell> though, does Australia allow parallel imports?
<RAOF> Starting to more, yh.
<smspillaz> RAOF: I think so. Its more just the RRP here is much higher
<smspillaz> erm, robert_ancell
<robert_ancell> yeah, we're in the same boat there
<RAOF> robert_ancell: Do we build mir on arm64?
<robert_ancell> RAOF, copy and paste says yes
<robert_ancell> perhaps it's just ignored for now
<RAOF> Ok then.
<thomi> hey RAOF, when you get a moment, I wonder if I could ask for your help with an X11 issue I'm having?
<thomi> errr, not work related :-/
<RAOF> thomi: Sure.
<robert_ancell> RAOF, qa-testing2 is good for ati/nouveau testing?
<RAOF> robert_ancell: qa-testing2 is good for ati/nouveau testing.
<RAOF> Lunch time!
<robert_ancell> RAOF, two of the radeon machines have completed on Jenkins, which is good
<robert_ancell> RAOF, and confirmed that VT switching doesn't drop focus, :(
<rsalveti> mir doesn't like my radeon :-(
<rsalveti> [    34.161] (EE) Failed to map vb -2
<rsalveti> that's the only error from xorg
<robert_ancell> rsalveti, from ppa:mir-team/system-compositor-testing?
<rsalveti> from dmesg: http://paste.ubuntu.com/6031250/
<rsalveti> robert_ancell: yes
<robert_ancell> rsalveti, yeah, ati and nouveau don't work in there yet
<rsalveti> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV620/M82 [Mobility Radeon HD 3450/3470]
<rsalveti> anything I can do for better debugging or a confirmed issue already?
<robert_ancell> rsalveti, you could try the MM3 xserver-xorg-video-ati package from https://launchpad.net/~mir-team/+archive/qa-testing2
<robert_ancell> that's the PPA we copied to ppa:mir-team/system-compositor-testing. It has updated ati and nouveau drivers
<rsalveti> cool, let me give that a shot
<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?
<rsalveti> alright, let me try another reboot :-)
<rsalveti> brb
<tvoss__> duflu_, ping
<tvoss__> olli_, ping
<rsalveti> yeee, progress
<rsalveti> robert_ancell: with mm3 I works better
<rsalveti> I'm using xmir now, but while it works, had to use xfce
<rsalveti> unity fails to load it seems
<rsalveti> and it's quite a bit slower
<duflu_> tvoss__: pong?
<duflu> to the luncheon
<robert_ancell> RAOF, looks like the new nouveau driver didn't work on Jenkins
<rsalveti> cool, now with unity
<rsalveti> just took a bit more to load, not sure why it failed when I tried it the first time
<rsalveti> so it seems ati is working with mm3
<rsalveti> at least single-monitor
<RAOF> Why does no store in Hobart stock mDP â DP cables?
<duflu> rsalveti: If you get the failure again, please take a copy of ~/.xsession-errors before logging out/in again and log a bug
<duflu> RAOF: apple.com.au ?
<duflu> That's what I use
<RAOF> duflu: Apparently apple.com.au don't have mDP â DP cables?!
<duflu> RAOF: Yeah just noticed. Only mDP to DVI
<duflu> RAOF: Shipping from Perth :)  http://ple.com.au/ViewItem.aspx?InventoryItemID=609956&CategoryID=427
<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
<duflu> RAOF: Oh. Actually would have only been $30 delivered from PLE
<RAOF> It's $26 direct from lenovo.com
<duflu> Ah yes
<duflu> Supports all your 4K monitors ;)
<rsalveti> bug 1217195
<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
<rsalveti> bug 1217199
<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
<rsalveti> multimonitor works here only in mirrored mode
 * duflu also notes he's slightly closer to Lenovo factories (Shenzhen)... Seems the East is more isolated ;)
 * duflu ignores the fact that his Lenovos are second-hand and came from the eastern states
<mlankhorst> RAOF: did you figure out the issue yet?
<RAOF> mlankhorst: Yup, failure to call xmir_submit_rendering_for_window.
<mlankhorst> https://www.youtube.com/watch?v=zTHhwvTJyMU
<RAOF> mlankhorst: Please feel free to try the new new nouveau; I've not seen testing of it.
<duflu> Hey, I think I can reproduce the glitches with egltriangle. I was just testing the wrong dual monitor combo
<RAOF> Woot!
<RAOF> I was about to try a build of your timerless MM to see if that fixed it; shall I not do that now?
<duflu> RAOF: It's worthwhile for MM even if it doesn't fix that bug.
 * duflu builds on the *correct* machine this time
<duflu> Excellent. I've lost the ability to VT switch. That's an annoying Mir/X bug that's happened before
<duflu> RAOF: Nope. Still happens. But at least I seem to have a test case now
<RAOF> duflu: Wow. Have you tried MM XMir on your timerless branch?
<duflu> RAOF: No... ?
<RAOF> It generates the most awesome visual artefacts ever!
<duflu> RAOF: It includes bypass. You're sure that's not it?
<RAOF> I guess it might be bypass?
<duflu> RAOF: You mean single (short) line artefacts?
<RAOF> But rendering comes in over a couple of frames in horizontal stripes.
<RAOF> Yeah, I might mean that.
<duflu> RAOF: Yeah I noticed that with qa-testing. Something about bypass+XMir
<RAOF> That is really odd; I don't have any intuition for what the problem might be there.
<duflu> RAOF: Same. Can you verify bypass does the same, and also with no buffer_age?
<RAOF> Sure.
<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
<RAOF> duflu:Huh!
<RAOF> Turns out I *have* been testing without buffer_Age
<duflu> RAOF: Great. Still no leads on lag. Though the glitches seem to match up perfectly with (1.0 / (refresh_rate1 - refresh_rate2)) seconds
<RAOF> Beat frequency!
<duflu> At least for egltriangle
<duflu> It's a beat alright
<duflu> Only happens on the slower monitor
<duflu> Back in a tick
<duflu> Or a few beats
<duflu> RAOF: Suggestions for avoiding beats? Sync to the slowest output instead?
<duflu> Though I'm not too sure how such an algorithm would go...
<mlankhorst> RAOF: oh btw tiling fail on nouveau
<mlankhorst> bigtime :P
<mlankhorst> and the screen is now reduced to random noise
<mlankhorst> looks like freed b uff
<mlankhorst> buffers are being copied to the screen, or something
<mlankhorst> .. which might not be different from the ati case I was hitting..
<duflu> mlankhorst: Running what?
<mlankhorst> qa-testing2 on a single monitor setup
<duflu> Hmm
<RAOF> mlankhorst: Hrm. Works fine for me on ati single
<RAOF> -monitor.
<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
<duflu> RAOF: Interestingly, each beat pops out to stdout from egltriangle as "61 FPS"
<mlankhorst> I've poked upstream a bit about the vsync fixes I was working on
<mlankhorst> they make glxgears a nice 65.4 fps :-)
<duflu> mlankhorst: Sounds close to perfect. Seen any X/Compiz problem like I did?
<mlankhorst> duflu: well considering my screen was overclocked to 65.4 it was perfect
<duflu> mlankhorst, Sweet
<mlankhorst> RAOF: hm radeon is correct now, I'll poke nouveau a bit more
<RAOF> Ta.
<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 :(
<mlankhorst> single monitor resize worked, but I don't know if it resizes when lowering the resolution..
<RAOF> Hm.
<RAOF> Maybe only the dri2 code that we don't hit uses the front buffer reference...
<mlankhorst> RAOF: did you push your nouveau changes?
<RAOF> mlankhorst: I have now :)
<mlankhorst> or the ati changes for that matter :P
<duflu> That's new. My VT font is now only 8px high
<alan_g> hikiko: good morning. How are things?
<hikiko> hi alan_g
<mlankhorst> RAOF: ..
<hikiko> how are you?
<mlankhorst> -+                                    damage_box->x1 - output_box->x1,
<mlankhorst> -+                                    damage_box->y1 - output_box->y1,
<hikiko> alan_g, did you see my MPs?
<mlankhorst> why such a creative way of writing 0?
<alan_g> hikiko: I see them. will review with all the others
<hikiko> :)
<alan_g> hikiko: we have an MP backlog - are you doing your reviews?
<hikiko> what do you mean alan_g ?
<alan_g> hikiko: All team members, including you, have a responsibility to review MPs
<hikiko> you mean all the mps?
<alan_g> hikiko: if no-one reviews them they don't land and we get a backlog
<hikiko> where can I find this backlog?
<hikiko> I wasn't aware to be honest
<alan_g> hikiko: https://code.launchpad.net/mir/+activereviews
<hikiko> ok, so I guess I have to start reviewing?
<duflu> For reviews, just keep in mind this week the priorities are multi-monitor and bypass proposals
<alan_g> hikiko: start with any easy ones (small & things you know) - it make the list smaller.
<hikiko> ok
<alan_g> duflu: what's the current rule about landing bypass?
<duflu> alan_g: Top approval is deferred till more PPA testing I think
<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..
<alan_g> hikiko: If you're looking at mine, don't overlook the pre-requisites - if you top-approve they land too.
<mlankhorst> RAOF: heh all that silly stuff about bo creation in nouveau.. there are easier ways to do so :P
<RAOF> mlankhorst: I don't think it adds an extra copy for the single-monitor case?
<RAOF> mlankhorst: damage_box->x1 - output_box->x1 is zero iff the damage occurs on a display with top-left at (0,0)
<duflu> RAOF: OK, I've written a key repeat simulator native client. And no bugs. Still only happens in XMir ?!
<RAOF> mlankhorst: On a display at (x, y), output_box->x1 will be x, but damage_box->x1 will be >= x
<mlankhorst> RAOF: I mean that the current path requires always making a copy..
<mlankhorst> oh hm this could explain why xorg didn't work..
<mlankhorst> [   50.333352] nouveau E[  PGRAPH][0000:01:00.0] DATA_ERROR XY_OUT_OF_BOUNDS
<mlankhorst> [   50.334335] nouveau E[  PGRAPH][0000:01:00.0]  DATA_ERROR
<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
<RAOF> Whoops.
<RAOF> mlankhorst: The current path already requires always making a copy, though?
<mlankhorst> RAOF: yeah but ideally it'd just be a flip
<RAOF> Yeah, but we can't do that.
<RAOF> Or, we could, but would require significant mir-side work to enable.
<duflu> I think it's generally understood XMir will have copies, for now...
<RAOF> Well, that's rather odd.
<mlankhorst> RAOF: any idea where the XY_OUT_OF_BOUNDS is coming from at least?
<RAOF> Ahem.
<RAOF> 	pScreen->ModifyPixmapHeader(dst, dst_box->x2 - dst_box->x1,
<RAOF> 								dst_box->y2 - dst_box->y1, pScrn->depth, pScrn->depth,
<RAOF> 				    pScrn->virtualX, NULL);
<RAOF> Spot the odd one out...
<mlankhorst> RAOF: well I did get rid of it in my version
<RAOF> Although for the single monitor case, pScrn->virtualX should be right.
<mlankhorst> anbd it's unity-system-compositor failing, not xorg
<mlankhorst> RAOF: http://paste.debian.net/30763/
<RAOF> Woohoo!
<duflu> ?
<RAOF> Oh, it's just an implementation of copy_to_mir that doesn't go through EXA
<mlankhorst> it's the default m2mf implementation for nouveau anyway, depends on hw which implementation it uses
<mlankhorst> but unity-system-compositor is still complaining about XY_OUT_OF_BOUNDS.. Hmmz
<RAOF> Yeah; that's odd.
<RAOF> That couldn't be because xmir is submitting something strange?
<mlankhorst> it's unity-system-compositor, not xorg complaining..
<RAOF> duflu: Did you find that the crazy horizontal artefacts only occurred when you had two displays enabled?
<RAOF> Yeah, but could unity-system-compositor be complaining because it's trying to access something that xorg screwed up?
<RAOF> The other option is that usc is, in fact, doing something wrong.
<duflu> RAOF: I think so. Because we all tested bypass XMir single monitor a while back and no one had any issues
<RAOF> But I don't really know what that would be, particularly if other Mir clients work.
<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
<duflu> RAOF: I should have realized, but yes the crazy horizontal artefacts are multimonitor only AFAIK
<duflu> Multimonitor+bypass I mean
<RAOF> mlankhorst: Hrm. When you run regular Mir clients against usc things work?
<mlankhorst> hm it does
<mlankhorst> "Your x/y coords exceed the size of your surface."
<mlankhorst> o.O
<mlankhorst> oh right, not on 9.2 yet..
<mlankhorst> I'll try mesa 9.2 first before digging further
<alan_g> tvoss: is anything happening with https://code.launchpad.net/~thomas-voss/mir/fix-fd-sharing/+merge/180801?
<sil2100> kgunn: hi! Any news on https://bugs.launchpad.net/unity-system-compositor/+bug/1216979 ?
<ubot5> Launchpad bug 1216979 in Unity System Compositor "Failing unity.tests.test_dash.DashMultiKeyTests.test_multi_key_delete autopilot test" [Undecided,New]
<duflu> sil2100: Good luck. He's at 4am I think
<sil2100> kgunn: since right now it's blocking unity-system-compositor from releasing
<sil2100> duflu: lovely, thanks
<mlankhorst> RAOF: lol, fail in nv50_m2mf_transfer_rect
<RAOF> What's it doing?
<mlankhorst> not setting X/Y at all
<mlankhorst> ;D
<RAOF> Ahem. Yeah, that doesn't seem particularly likely to work :)
<RAOF> That's clearly not something that I did. Yay!
<duflu> Might work at defaulting to 0,0 on some machines, if you're lucky
<duflu> RAOF: Was there any technical reason (other than performance) why XMir couldn't be switched to being a dumb Mir software client?
<RAOF> No
<duflu> RAOF: Because I'm starting to think that would be nice to test
<RAOF> But "other than performance" is a pretty big "other than"
<RAOF> We could whip up a sw-rendering DDX reasonably quickly.
<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?
<duflu> RAOF: Yeah, I mean just for debugging. Smells like some issues still lurk in XMir trying to be super fast
<duflu> RAOF: Yes please. Otherwise I may well end up trying to learn it and do it myself
<hikiko> I did it already alan_g I am building before I push
<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 :(
<mlankhorst> RAOF: it's probably not a usc bug anyway, even if feeding invalid date the state tracker is supposed to deal with it
<mlankhorst> oops, nouveau has betrayed me :P
<mlankhorst> it was xserver after all
<mlankhorst> yeah there we go, all working now.. mostly
<asac> hi
<asac> i am testing MM
<asac> here on my x220 in a dock and the external monitor being the primary
<asac> i get wrong resolution (that of the front screen) stretched
<duflu> asac: Yes we have a bug logged for that. I get it too
<asac> duflu: cool. once fixed can you ping me? happy to give it a try :)
<duflu> asac: Probably best if you just subscribe: https://bugs.launchpad.net/xmir/+bug/1216224
<ubot5> Launchpad bug 1216224 in XMir "[multimonitor] XMir defaults to wrong resolution 1152x864 instead of 1920x1200." [Undecided,Confirmed]
<duflu> asac: Though once logged in you can change the resolution
<mlankhorst> RAOF: well that was easy to fix once I caught the kernel module lying about the source :P
<asac> duflu: i can? how?
<asac> wait ... cant copy/paste here anymore :((
<mlankhorst> RAOF: http://paste.debian.net/30796/ --- enjoy!
<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
<ubot5> Launchpad bug 1216224 in XMir "[multimonitor] XMir defaults to wrong resolution 1152x864 instead of 1920x1200." [Undecided,Confirmed]
<asac> duflu: was asking how to change resolution, but found that it can be done with just the normal preferences dialog
<asac> something is really tslow though
<duflu> asac: Slow? Yes there's at least one bug for that too
<asac> i think its better now
<asac> after reboot
<asac> still, movig windows is a bit laggy
<asac> but so far i can survive... cool
<asac> seems i also get some texture artifacts while moving windows
<asac> as if the window is split up in multiple pieces and they move out of sync :)
<duflu> asac: You may wish to comment on the issues: https://bugs.launchpad.net/xmir/+bugs?field.tag=multimonitor
 * duflu goes to organise dinner
<RAOF> mlankhorst: Heh. Stride Strikes Again!
<RAOF> asac: That sounds pretty cool!
<asac> yeah i am happy :)
<mlankhorst> RAOF: yes :P
<asac> bleeding edge :)
<RAOF> mlankhorst: I don't suppose you tried copying just the region that's damaged?
<mlankhorst> RAOF: hm is it clipped against the output? :P
<mlankhorst> but I guess I could..
<RAOF> Yeah.
<RAOF> region is always fully contained within dst_box (we do the intersection in the xmir module)
<RAOF> So it's not *wrong* to always copy dst_box, but it's a wasteful.
<mlankhorst> hm sure
<mlankhorst> RAOF: is it guaranteed to be non-zero?
<mlankhorst> eg no 0x0,0x0 copy
<RAOF> Yes
<mlankhorst> kk
 * RAOF has weeded out all of these cases by testing on Intel, which uses region :)
<RAOF> Man, the NVAccelM2MF declaration is not exactly self-documenting code :)
<mlankhorst> it is
<mlankhorst> the ofs refers to offset from start of bo, in case of scratch bo usage
<RAOF> Aaah.
<RAOF> And the rest you can mostly guess.
<mlankhorst> source domain, source pitch, source height, x/y
<RAOF> source_depth, source_pitch, source_height, source_x, source_y
<mlankhorst> domain not depth :p
<RAOF> Hah, source *domain*.
<RAOF> What does M2MF stand for? Something like Mem 2 Mem copy with Format?
<mlankhorst> memory to memory function was my guess, but yours is just as good I suppose
<mlankhorst> hm format is probably the right one
<mlankhorst> it can convert some formats to others and do some swizzling
<mlankhorst> RAOF: oh btw what coordinates is damage_box in then?
<RAOF> Screen coordinates.
<mlankhorst> so same coordinate system as damage_box ?
<RAOF> dst_box? Yes.
<RAOF> Hm. We may have been confusing there :)
<mlankhorst> you don't say!
<RAOF> _region_ is in the same coordinate space as dst_box :)
<RAOF> And region is the damage region.
<RAOF> Both are in the window coordinate space of the window.
<mlankhorst> http://paste.debian.net/30803/
<mlankhorst> just guessing.. I'll give it a shot
<RAOF> That looks roughly right?
<mlankhorst> even seems to draw correctly
<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.
<RAOF> Ah, well. If it works, it's clearly not that wrong :)
<RAOF> The ideal test client is an xterm on a raw X session.
<mlankhorst> hm let me find a mouse for that machine, it didn't put focus on the xterm :P
<RAOF> Fire up metacity?
<mlankhorst> hm xterm -e 'find /' works
<mlankhorst> RAOF: first client for x works, but if I kill it and screen returns to black the next client does not..
<RAOF> mlankhorst: Yeah, loss of the sole client triggers a server regeneration, and XMir doesn't handle that well at all.
<RAOF> Fortunately that should only hit people like us, who test clients on raw X.
<RAOF> And, obviously, KDE, should they feel like porting. :)
<mlankhorst> RAOF: oh and a major derp was not using damage_box->x1 for src :P
<mlankhorst> hm and then not removing dst_box from dst coordinates
<RAOF> Ah, right.
<RAOF> Yes, I did wonder a bit about that :)
<mlankhorst> http://paste.debian.net/30811/ this version is more correct right?
<RAOF> Yeah, that looks like what I'd expect.
<RAOF> Particularly: it looks like the radeon code :)
<tsdgeos> ricmm: tvoss: there?
<tsdgeos> ricmm: tvoss: unping
<tvoss__> tsdgeos, ;)
<mlankhorst> RAOF: odd, does compiz always do full-screen repaints then?
<RAOF> mlankhorst: I think compiz is mostly doing glXSwapBuffers now (although you can turn that off)
<RAOF> And SwapBuffers implies full-screen repaints.
 * RAOF wonders whether it'd be worth teaching Compiz about swap_buffers_with_damage
<mlankhorst> it's also very nice for bypass though :P
<RAOF> mlankhorst: Indeed.
<RAOF> It means that, once we actually implement the sucker, our normal-case overhead is going to be just protocol overhead.
<mlankhorst> RAOF: but I'm mostly worried about the vblanking timestamp stuff, I still want accurate vblank on video
<RAOF> Yeah, we need to hook that up.
<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.
<RAOF> You don't get scanline accuracy out of it, but you can approximate vblank with buffer-received.
<mlankhorst> that's not accurate vblank :p
<RAOF> Yeah, that requires more involved compositor support :)
<RAOF> Which I want to do, but is obviously a "not now" thing :/
<mlankhorst> the drivers can get that information directly without going through the compositor..
<RAOF> Only if the compositor isn't compositing, though?
<mlankhorst> they just need to have the correct drm fd for the crtc, and the crtc id..
<RAOF> And where on the crtc the window is, yes?
<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?
<mlankhorst> not really, they just need to know for scheduling decisions
<RAOF> As in: what-client-should-get-GPU-time-next decisions?
<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
<RAOF> mlankhorst: Right, but that really wants compositor support.
<RAOF> Because the compositor might introduce a delay
<mlankhorst> what about the case of fullscreen bypass?
<RAOF> Then can do it, yes.
<RAOF> Which is, I agree, a common case.
<RAOF> But it's also the case that a client doesn't know if it's bypassed or not.
<mlankhorst> RAOF: hm crash when I plugged in a second monitor to ati :P
<RAOF> mlankhorst: Yeah. Need to implement a SetScreenPixmap hook for ATI to update info->front*
<RAOF> As far as I can tell nouveau doesn't do anything annoying like that.
<RAOF> Good job!
<mlankhorst> lol
<mlankhorst> nvidia does everything in hardware where it can..
<alan_g> hikiko: what are you working on?
<RAOF> mlankhorst, tvoss: Nouveau uploaded to qa-testing2 PPA. Happy multi-monitor testing!
<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
<alan_g> hikiko: ack
<hikiko> alan_g, is there any way to check the changes in the display?
<alan_g> hikiko: I'm not sure what you're asking
<hikiko> or we have to fully implement the native/nested platform first?
<alan_g> hikiko: we should be writing tests for the functionality we are working on
<hikiko> alan_g, ok but let's first add the functionality :)
<hikiko> I have a question on your branch actually
<hikiko> + make_current(); // This duplicates what Eleni's original code did - but is it needed?
<hikiko> what do you mean?
<hikiko> do we swap buffers elsewhere?
<alan_g> hikiko: I'm not sure why we'd do this when constructing the object (as opposed to when we render to it)
<hikiko> I guess that if we don't we ll see nothing
<hikiko> because we render to the back surface
<hikiko> and we have to make it current
<hikiko> let me see
<alan_g> hikiko: rendering calls "make_current()"
<hikiko> let me see what make_current does 1 sec
<hikiko> make_current binds the context to the current rendering thread
<hikiko> and to the draw and read surfaces
<mlankhorst> RAOF: erm you failed somewhere
<mlankhorst> ;P
<mlankhorst> that src pixmap is definitely not covering the entire screen on my multimonitor setup
<mlankhorst> proof..
<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,
<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,
<mlankhorst>     dp=dp@entry=5120, dh=dh@entry=1024, dx=dx@entry=0, dy=dy@entry=0) at ../../src/nouveau_exa.c:49
<mlankhorst> eg pitch = 5120, 1280 * 4
<alan_g> hikiko: I have to go make lunch - back in an hour
<mlankhorst> but the rects are this:
<mlankhorst> [   829.877] (II) NOUVEAU(0): copying pixmap: (1440,0),(2720,1024) with damage (1440,0),(2720,1024)
<hikiko> me too :) see you later alan_g|lunch
<mlankhorst> and src is this:
<mlankhorst> (gdb) print *src
<mlankhorst> $1 = {drawable = {type = 1 '\001', class = 0 '\000', depth = 24 '\030', bitsPerPixel = 32 ' ', id = 0, x = 0, y = 0, width = 1280, height = 1024,
<mlankhorst>     pScreen = 0x7f1600880700, serialNumber = 2234}, devPrivates = 0x7f16008efca8, refcnt = 1, devKind = 5120, devPrivate = {ptr = 0x0, val = 0,
<mlankhorst>     uval = 0, fptr = 0x0}, screen_x = 0, screen_y = 0, usage_hint = 0, master_pixmap = 0x0}
<mlankhorst> so I guess your assumption about 1 pixmap to cover everything is wrong ;P
<mlankhorst> https://www.youtube.com/watch?v=zTHhwvTJyMU
<mlankhorst> 2 screens, first one 1440x900 and the second one 1280x1024
<tvoss__> olli_, ping
<smspillaz> RAOF: It'd be quite trivial to get compiz working with swap_buffers_with_damage
<smspillaz> RAOF: s_b_w_d would need to be implemented in GLX though
<smspillaz> and I have no idea if it is
<derEremit> hi, can i assume that any support for optimus via bumblebee will be severely broken once the switch to mir is complete
<tvoss__> derEremit, well, you can always fallback to vanilla X plus prop drivers in 13.10
<derEremit> and probably will have to do that.
<derEremit> ;)
<tvoss__> derEremit, if you rely on that functionality, yes. However, would be great if you could try the system-compositor, too :)
<derEremit> yeah had no positive results this far
<tvoss__> derEremit, did you try it from the archive, yet?
<derEremit> ppa?
<derEremit> well today had other problems
<derEremit> started my laptop and couldn't login anymore
<derEremit> purged X and mir completely, now it works again ;)
<derEremit> i think bumblebee is kind of in the way
<tvoss__> RAOF, mlankhorst ping
<mlankhorst> pong
<mlankhorst> and no, I don't think mir has any support for crtc's that do not belong to the rendering graphics card..
<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?
<balloons> frothnicator, would you be running on real hardware?
<alan_g> tvoss__: bypass is top-approved
<tvoss__> alan_g, why?
<tvoss__> alan_g, please revert that
<alan_g> tvoss: ack
<alan_g> tvoss: I thought we'd discussed
<alan_g> tvoss: I thought we'd discussed doing that
<tvoss__> alan_g, nope
<alan_g> tvoss__: Misunderstanding then. Sorry
<tvoss__> alan_g, ack, no worries
<frothnicator> balloons: sorry, stepped out for a minute: yes.
<frothnicator> one without discrete graphics card, even.
<frothnicator> balloons: So if I were to use a daily saucy (with real hardware), that would be a good for y'all?
<tvoss__> frothnicator, that would already help us, yes :)
<frothnicator> tvoss__: okay.  Smiley face implies "yes it would help", but I don't understand what you mean by "already"?
<kgunn> alan_g: i need to review the numbers w olli first....sorry bout that
<tvoss__> frothnicator, the call for testing was referring to ppa:mir-team/system-compositor-testing for multi-monitor
<mlankhorst> I thought qa-testing2? :P
<frothnicator> tvoss__: thank you.  That was a detail that I apparently missed in the email.
<frothnicator> I will work do so this evening.
<tvoss__> mlankhorst, no, we copied over to system-compositor-testing iirc, kgunn, can you please cross-check?
<kgunn> tvoss: mlankhorst frothnicator ....system-compositor-testing
<kgunn> qa-testing2 is still live action
<mlankhorst> ah
 * mlankhorst is behind then!
<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?
<kgunn> frothnicator: sorry...i just meant that qa-testing2 was still being used by dev team last night, packages being updated
<kgunn> which can sometimes mean "trouble"....package mismatch or some such...
<kgunn> whereas system-compositor-testing is static....nothing going in
<frothnicator> kgunn: gotcha.  So bottom line is that I should use ppa:mir-team/system-compositor-testing when I get home to test.
<kgunn> frothnicator: yes sir
<frothnicator> kgunn: quick worflow: Saucy Daily + add-apt-repository ppa... + restart lightdm?
<frothnicator> or quantal livecd + add-apt-repository paa... + restart lightdm?
<kgunn> frothnicator: instructions here https://wiki.ubuntu.com/Mir/MultiMonitorTesting
<kgunn> frothnicator: quantal ?....we're all saucy...so, as long as you get to saucy recent....
<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?
<kgunn> frothnicator: you can also "restart lightdm" rather than reboot
<kgunn> frothnicator: someone else gave me a hard time about that too :)
<kgunn> frothnicator: i just reboot
<kgunn> frothnicator: so my instructions just ended up being what i do :)
<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.
<frothnicator> kgunn: Okay.  I'll report to Launchpad anything I find tonight.  Thanks for the help.
<kgunn> frothnicator: thanks!
<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.
<kgunn> frothnicator: thanks...i'll have to poke someone...it was editable...then some jake-leg made it immutable...geeze
<kgunn> balloons: ^
<kgunn> balloons: can we update the instructions to include "restart lightdm" ?
<frothnicator> kgunn: hah.  I know the feeling.  The vicissitudes of working with other people.  :-)
<kgunn> :)
<kgunn> well-intentioned i'm sure
<frothnicator> absolutely.
<frothnicator> alright, I'm out.  Thanks again.
<balloons> kgunn, sure thing.. you mean restarting lightdm after install?
<balloons> perhaps that didn't end up on the wiki
<kgunn> balloons: right
<kgunn> i know someone spoke to me about it...i thot i added it....
<kgunn> but i think it got moved in some edits when olli was going for twd
<balloons> I do see it in there.. I remember adding the command to it
<balloons> and indeed, it's in there
<balloons> look in setup
<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.
<frothnicator> (but if I didn't, or if doesn't matter, feel free to tell me to move along.)
<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
<frothnicator> balloons: can you not find (via search, perhaps?) in the page what I just quoted (which I copy/pasted)?
<frothnicator> balloons: maybe we're talking about different pages?  https://wiki.ubuntu.com/Mir/MultiMonitorTesting
<balloons> frothnicator, k, I'll search again :-)
<balloons> ahh, ok
<frothnicator> balloons: I know, I know.  Stupid lusers like "frothnicator".  :-)
<balloons> frothnicator, not at all. I just missed the line before.. i'm quite human and do such things I assure you
<balloons> take a look now
<frothnicator> balloons: heh, sometimes helps to clear ones cache: three reloads and on Ctrl+Shift+R later, I see the update!  Cheers.
<balloons> excellent, thanks for pointing it out!
<frothnicator> np.
<hikiko> alan_g, kgunn +anyone else available meeting?
<kgunn> bschaefer: hey...i really need your help
<bschaefer> kgunn, what up? (I forgot about vUDS...)
<kgunn> bschaefer: i have a blocker for unity (you prob heard?)
<kgunn> https://bugs.launchpad.net/unity-system-compositor/+bug/1216979
<ubot5> Launchpad bug 1216979 in Unity System Compositor "Failing unity.tests.test_dash.DashMultiKeyTests.test_multi_key_delete autopilot test" [Critical,Triaged]
<bschaefer> kgunn, yup, thats what im working on right now!
<kgunn> bschaefer: could you take a look ?
<kgunn> oh great
<kgunn> thank you
<bschaefer> kgunn, yupp!
<bschaefer> kgunn, np! Its a strange failure, as I can get manually use it...soo no regression from what i see...
<bschaefer> as I can manually*
<tvoss> bschaefer, please check if keycodes are correct, according to pitti, something changed in that respect
<bschaefer> tvoss, yeah, I was just reading that email... that would explain the x error
<tvoss> bschaefer, yeah, please see if you can track it down
<bschaefer> tvoss, will do, good think is I can at lease manually use it, so no regression, just a very strange problem
<bschaefer> thing*
<bschaefer> ...
<tvoss> bschaefer, ack
<tvoss> bschaefer, got a link to that mail?
<bschaefer> tvoss, hmm a recent one? no
<bschaefer> tvoss, also this happens outside of xmir as well
<tvoss> bschaefer, ?
<kgunn> bschaefer: i was thinking just that...
<kgunn> input not in xmir...input is left to the traditional x path
<bschaefer> tvoss, as I don't have xmir running right now, and I still have the failure
<bschaefer> kgunn, ^
<tvoss> bschaefer, ack, thx
<bschaefer> sooo whats causing this is some sort of update somewhere...which could be the new ibus update, or the email pitti sent out
<bschaefer> tvoss, np!
<tvoss> bschaefer, can you please update the issue report/bug report accordingly?
<bschaefer> tvoss, yup!
<tvoss> bschaefer, thx
<bschaefer> np
<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
<kgunn> bschaefer: : thank you for taking care....is there someone we should manually poke on ?
<kgunn> as i understand its a stopper
<bschaefer> kgunn, me :), i did most of that implementation in unity/nux plus most of the AP tests....
<tvoss> thomi, can you please help bschaefer tracking down the issue? we are blocking a lot of releases right now
<kgunn> bschaefer: please allow yourself to ...poke....yourself
<bschaefer> kgunn, will do!
<kgunn> :)
<bschaefer> bschaefer, get to work!
<kgunn> :))
<thomi> tvoss: sure, I can lend my sleep-deprived brain to the cause.
<thomi> bschaefer: what do you need?
<bschaefer> thomi, sooo Multi_Key doesn't match any keybod
<bschaefer> keycode in autopilot?
<bschaefer> possibly removed, or somehow worked before?
<thomi> errr... we're using the X11 keyboard?
<bschaefer> hmm now we are getting a 0 from the x11 keyboard?
<bschaefer> thomi, this is where its failing:
<bschaefer> get_display().keysym_to_keycode(keysym)
<thomi> hmmm
<bschaefer> the keysym seems about right: 65312, ill double check
<bschaefer> sooo it can't find the key on the keyboard
<bschaefer> which would explain  the error...
<thomi> bschaefer: indeed
<bschaefer> thomi, at the end of this, ill push a branch to give some sort of error if that returns 0
<thomi> this is the issue with the X11 bindings
<bschaefer> right, soo i wonder if its due to keyboard layouts? I swear this worked before though...
<bschaefer> on a normal X keyboard
<bschaefer> err
<bschaefer> normal english US keyboard
<thomi> bschaefer: presumably that's the keymap you're using as well though, right?
<bschaefer> thomi, and yup getting the right keysym:
<bschaefer> #define XK_Multi_key                     0xff20
<bschaefer> thomi, yes, but when I wrote the tests I do remember it working :)
<bschaefer> thomi, i've also tried french layout though
<bschaefer> which does have the multi key, and it does work manually
<thomi> hmmm
<thomi> what happens if you manually set the keycode?
<bschaefer> thomi, hmm isn't the keycode dependent on the hardware? ie. its not always the same for each key?
<bschaefer> thomi, but ill try to get it from some x tool I forgot the name of
<thomi> ahh, sorry, I misunderstood.. keysym vs keycode :-/
<bschaefer> xev, but hmm I think I might be missing up multi key vs composite key?
 * bschaefer now does not remember where the hell the multi key is...
<thomi> bschaefer: the composite key can be bound to some other key on your KB. perhaps the multi key can as well
<bschaefer> thomi, right, I think I've confirmed the composite key is working, not the multi key though (testing through xev)
<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?
<thomi> yeah, I dunno
<bschaefer> :), yeah I just have to refresh my self on how to type it, sine I don't use it regularly
<bschaefer> thomi, hmm I wonder if the OSK would have a nice button that we could press...
<bschaefer> if it doesn't exist it *might* cause it to crash... or spit some error out
<thomi> bschaefer: I think it would be instructive to get someone with a french keyboard to try this
<bschaefer> thomi, it would be helpful
<bschaefer> seb128, ping
<seb128> bschaefer, hey
<bschaefer> seb128, can you confirm the multi is on your keyboard through xev?
<bschaefer> multi key*
 * bschaefer is unable to find it on any keyboard layouts
<seb128> what is "the multi key"?
<bschaefer> seb128, thats what im trying to figure out :), I remember it being like the dead key...but its been a while now...
<seb128> I've no clue about those things...
<bschaefer> seb128, no worries! Thanks :)
<seb128> bschaefer, sorry for not being able to help, but feel free to ping if you have more specifics
<bschaefer> thomi, hmm it seems the composite key is the multi key?
<seb128> bschaefer, http://www.linuxhowtos.org/Tips%20and%20Tricks/compose.htm
<seb128> seems to indicator it's the composite key indeed
<bschaefer> seb128, no worries, right, but I can't get the multi key sym to come up
<bschaefer> #define XK_Multi_key                     0xff20
<bschaefer> seb128, which is what we are asking python to enter
<thomi> hmmm
<bschaefer> but it doesn't seem to exist on the keyboard...
<bschaefer> thomi, haha, im seeing the "compose key" as disabled... in the new text entry chart?
<thomi> what's that?
<bschaefer> err
<bschaefer> thomi, go to your keyboard indicator, Text Entry Settings
<bschaefer> thomi, then select your layout (french possibly), then press keyboard settings
 * bschaefer tests if this is the problem
<thomi> I have "Compose Key" set to Caps lock
<bschaefer> thomi, then the test should ... *should* pass for you
<thomi> what's the test id?
<bschaefer> thomi, autopilot run unity.tests.test_dash.DashMultiKeyTests.test_multi_key_copyright
<seb128> bschaefer, thomi: that test works for me on saucy
<seb128> (session is running since yesterday)
<bschaefer> thomi, worked :)
<bschaefer> seb128, soo it seems the composite key is disabled by default now in the keyboard layout?
<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
<bschaefer> seb128, but im not sure if it was ever enabled though...for US en keyboard I don't think it even exists...
<thomi> bschaefer: I suggest making the unity AP test set the compose key at the start of the test
<bschaefer> thomi, right, that'll be fun to figure out
<thomi> bschaefer: shouldn't be too hard :)
<seb128> bschaefer, yeah, I'm not sure, I can't see why that would have changed recently
<bschaefer> thomi, hopefully :)
<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...
<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
<bschaefer> seb128, hmm possibly, but now to figure out to set that in python...
<bschaefer> tvoss, kgunn found problem, now to just find the fix
<bschaefer> tvoss, kgunn composite key is disabled, causing it to not exist on the keyboard, ie. x key code error
<seb128> bschaefer, system("setxkbmap -option compose:rwin")? ;-)
<thomi> bschaefer: there's support for gsettings in unity module I believe
<thomi> seb128: s/system/subprocess/ at least :)
<bschaefer> seb128, that would work, but Ill look for a gsettings fix first
<bschaefer> seb128, unless we want to get a fix out
<seb128> thomi, right, I was not suggesting code, just giving the idea
<thomi> seb128: yep :)
<bschaefer> then get a better fix in..
<seb128> bschaefer, well, mir stack and unity-system-compositor are being stucked until we resolve that
<seb128> bschaefer, I'm sure the mir team is going to get angry soon
<bschaefer> right which makes me want to get this out ASAP
<bschaefer> yeeah...
<thomi> so maybe seb128's idea is the fastest
<bschaefer> thomi, yeah, hmm umm
<bschaefer> thomi, let me just add that to the ctor for multi key tests...
<bschaefer> then get a real fix in later today
<thomi> bschaefer: you mean in setUp?
<bschaefer> thomi, well thats the ctor right?
 * bschaefer does to much c++
<thomi> heh. I thought you meant __init__
<bschaefer> thomi, nope, the constructor for the multi key class :)
<seb128> bschaefer, I can confirm the test failing in a guest session, I'm going to try to figure out what changed
<thomi> seb128: I'm reasonably sure that the compose key used to be set to something by default
<seb128> right, but where/by what
 * bschaefer is unsure but shouldn't have relied on that...
<thomi> that I don't
<bschaefer> we should have set our own, then reset the default...but yes
<bschaefer> thomi, soo subprocess for python, using popen?
<bschaefer> as i can confirm this is fixing it when its turned off: setxkbmap -option compose:rwi
<bschaefer> n
<bschaefer> setxkbmap -option compose:rwin*
<thomi> bschaefer: so you can run something like:
<bschaefer> thomi, I just want to make sure I at lease get this quick fix working :)
<thomi> subprocess.call(["setxkbmap", "-option", "compose:rwin*"])
<bschaefer> thomi, thanks let me test that out!
<bschaefer> thomi, also the * was for my spelling mistake :)
<bschaefer> missing the n in win
<bschaefer> thomi, confirmed working...
<bschaefer> just pushed a branch
<bschaefer> thomi, seb128 https://code.launchpad.net/~brandontschaefer/unity/enable-compose-key/+merge/182454
<seb128> bschaefer, I'm not going to nitpick on the empty lines changes :p
<bschaefer> seb128, yeeah I know thomi loves them being removed
<bschaefer> soo I have it set up to remove python empty lines :)
<seb128> bschaefer, approved
<bschaefer> seb128, thanks, and sorry about not getting this fixed yesterday!
<thomi> bschaefer: LGTM
 * bschaefer wasn't aware it was blocking yesterday...
<bschaefer> thomi, thanks
<seb128> bschaefer, no worry, thanks for fixing it today ;-)
<bschaefer> seb128, you welcome, now to find a correct fix :)
<bschaefer> your*
<bschaefer> my keyboard likes leaving off keys...
<bschaefer> kgunn, tvoss MP to quickly fix here:
<bschaefer> https://code.launchpad.net/~brandontschaefer/unity/enable-compose-key/+merge/182454
<seb128> bschaefer, "you're*" you mean :p
<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
<bschaefer> seb128, yup haha...
 * bschaefer has to many things going on...
<bschaefer> seb128, though you seem to have a much better handle on multiple conversations :)
<seb128> lol, you get used to it (or not) ;-)
<bschaefer> haha
<bschaefer> hopefully soon!
<om26er> is there a way to turn off the screen on mako while using Mir ?
<cub> How long during tomorrow will the multi-monitor test run?
<cub> as per https://wiki.ubuntu.com/Mir/MultiMonitorTesting .
<kgunn_> robert_ancell mornin
<robert_ancell> kgunn_, hey
<robert_ancell> kgunn_, robotfuel do you want just bypass or bypass + MM?
<kgunn_> robert_ancell bypass
<robotfuel> robert_ancell: let me know when it's ready so I can start tests
<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
<kgunn_> robert_ancell at least mm+bypass didn't seem to work on Ati
<kgunn_> robert_ancell to be clear qa-testing not qa-testing2
<robert_ancell> kgunn_, so qa-testing has always been bypass+mm, I'll convert it to just bypass
<robert_ancell> and qa-testing2 stays unchanged at mm
<kgunn_> robert_ancell ah might be true for mir part
<kgunn_> robert_ancell just need a working bypass
<robert_ancell> ok, will do
<kgunn_> robert_ancell I didn't try qa-testing on intel - maybe it works
<kgunn_> ?
<kgunn_> robert_ancell thanks
<kgunn_> robotfuel so is archive xmir working on that machine ?
<kgunn_> might be good to verify that
<robotfuel> kgunn_: on which machine?
<robotfuel> kgunn_: the radeon webcam machine?
<robotfuel> it worked this morning http://10.97.2.12:8080/view/openarena/job/openarena-benchmark-ps-radeon-hd5750-le-xmir/43/
<robotfuel> robert_ancell: http://10.97.2.12:8080/job/qa-ppa-guitoolkits-ps-intel-3000/ intel worked with the qa-testing ppa
<robotfuel> kgunn: ^
<robert_ancell> robotfuel, kgunn, ppa:mir-team/qa-testing is being converted to bypass only. Will take ~40 mins
<kgunn> robert_ancell: thanks....hmmm, just wondering....earlier there were xorg packages there with latest ati drivers...wonder if those were the issue ??
<kgunn> robert_ancell: since no one has seen mm on ati yet...just thinking aloud
<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
<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
<rsalveti> just in mirrored mode, booting with both monitors connected
<rsalveti> kgunn: I updated the qa tracker with the results
<kgunn> rsalveti: thank you
<rsalveti> no worries
<kgunn> robotfuel: qa-testing any moment now
<robert_ancell> LP, faster with the publishing already :)
<robotfuel> heh
<robert_ancell> Note, there's a u-s-c upload after Mir is done, but that doesn't take too long
<kgunn> robert_ancell: right!
<robotfuel> robert_ancell: is it ready?
<robert_ancell> robotfuel, almost...
<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
<robotfuel> ok I'll run the tests
<robert_ancell> Hmm, 1:20 to update - I'll revise my estimate for next time
<robotfuel> robert_ancell: kgunn do you care which test runs first?
<robert_ancell> I don't
<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?
<kgunn> please email share with tvoss any findings
<robert_ancell> kgunn, what is this for?
<robert_ancell> robotfuel, do we have the radeon X / XMir numbers at the moment?
<robotfuel> robert_ancell: http://reports.qa.ubuntu.com/graphics/openarena/
<robert_ancell> robotfuel, ta
<robotfuel> robert_ancell: you can doubleclick on a bar to go to the jenkins build results for that benchmark.
<robert_ancell> clever!
<robotfuel> robert_ancell: the screen looks messed up on the radeon machine
<robotfuel> kgunn: ^
<robert_ancell> :(
<robert_ancell> yeah, I can see it on the video
<robert_ancell> robotfuel, can you confirm the versions of packages on that machine?
<robotfuel> robert_ancell: I'll pastebin, one second
<robert_ancell> ta
<robotfuel> http://paste.ubuntu.com/6034625/ <- robert_ancell
<robert_ancell> robotfuel, they look correct
<robert_ancell> robotfuel, was the video corrupt at all times or just during parts of the test?
<robotfuel> robert_ancell: after rebooting in to xmir
<robotfuel> robert_ancell: I'll reboot again to double check
<robert_ancell> robotfuel, right
<robotfuel> robert_ancell: it's bad after reboot
<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
<robotfuel> robert_ancell: xmir tests ran okay earlier today.
<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
<robotfuel> *xmir from archive
<robert_ancell> actually, everything seems held up in proposed - anyone know why that is?
<robert_ancell> olli, ^?
<robotfuel> robert_ancell: I think it was because of xmir crashing on didrocks ati machine
<robert_ancell> robotfuel, I thought we'd resolved that / weren't going to block on it
<robotfuel> robert_ancell: I need to commute home, I have to restart the camera in a screen session, you'll have to refresh
<robert_ancell> robotfuel, this is just qa-ppa right?
<robotfuel> robert_ancell: yes
<robert_ancell> robotfuel, and just cancel jobs by right clicking on the X beside them? i.e. the machine will restart automatically?
<robotfuel> robert_ancell: yes
<robert_ancell> ok, thanks!
<robotfuel> robert_ancell: the machine will restart automatically on the next test run
<robert_ancell> robotfuel, what are all the new jobs? Still doing a run all?
<robert_ancell> and which machine is the camera pointed at?
<robotfuel> robert_ancell: I didn't add all the new jobs to run all.
<robert_ancell> ok
<robotfuel> robert_ancell: the machine is pointed at ps-radeon-5750-le
<robotfuel> *ps-radeon-hd5750-le
<RAOF> Ok, so XMir really does not like the bypass branch.
<robert_ancell> RAOF, you're seeing it too?
<RAOF> robert_ancell: Oh, what in particular? Crazy horizontal missing rendering?
<robert_ancell> RAOF, yep horizontal corrupt lines
<RAOF> I wonder if that's not missing flushing.
<RAOF> But it doesn't look like any corruption that I'm familiar with.
<robert_ancell> RAOF, you have some ati hardware right?
<RAOF> robert_ancell: I do, yes.
<robert_ancell> RAOF, can you confirm the mir from -proposed works?
<robert_ancell> we're somewhat behind because I think there's a block on mir
<RAOF> Sure.
<robert_ancell> robotfuel, still there?
<robotfuel> robert_ancell: the run all test for qa-ppa will now run all openarena, guitoolkits and nexuiz tests for the qa-testing ppa
<robert_ancell> robotfuel, the camera link doesn't seem to be working
<robotfuel> robert_ancell: I just restarted it in screen
<robert_ancell> ah, ok now
<robert_ancell> hi!
<robert_ancell> interestingly the video only seems to work in chromium, not firefox
<robotfuel> I am using simplecv to stream video
<robert_ancell> RAOF, is that the type of corruption you were thinking of?
 * robotfuel commutes home
<robert_ancell> robotfuel, bye, thanks for your help!
<RAOF> robert_ancell: No; the corruption I was thinking of is more transient.
<RAOF> And is on intel.
<robert_ancell> ah
<robert_ancell> thomi, would it be possible to make jenkins have a job that uses -proposed?
<robert_ancell> I'd like to test the Mir -proposed packages
<thomi> robert_ancell: sure, robotfuel has a fancy script.
<RAOF> robert_ancell: Just to check, you want me to test just stuff in saucy-proposed on ati?
<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?
<robert_ancell> thomi, ideally now...
<robert_ancell> RAOF, yes
<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
<ricmm> hey guys, where do we stand with stuff not going from proposed to main?
<robert_ancell> ricmm, I don't know what it's blocked on now, I'm trying to find out
<RAOF> robert_ancell: usc in -proposed seems to be built against the wrong version?
<robert_ancell> RAOF, is it built against the main version of mir?
<robert_ancell> ricmm, is there a particular feature you need to depend on?
<RAOF> robert_ancell: Oh. There *is* no usc in proposed!
<robert_ancell> RAOF, ah, that's going to mess shit up
<RAOF> Yes indeed :)
<robert_ancell> thomi, ok, -proposed wont work on Jenkins anyway, so no need to do that
<ricmm> robert_ancell: yea, the lifecycle stuff that landed a couple of days ago
<robert_ancell> RAOF, who do we ask / what channel to find out why a package has a block on it?
<RAOF> #ubuntu-devel or #-release would work.
<robert_ancell> RAOF, ah, -release was the name I couldn't remember
<robert_ancell> thanks!
#ubuntu-mir 2013-08-28
<thomi> robert_ancell: OK, cool. I'm kind of here, kind of not, depending on how long this coffee keeps me awake
<robert_ancell> thomi, :)
<robert_ancell> ricmm, I'm trying to manually get mir out of proposed - it seems to be in a deadlock due to some build ordering issues
<RAOF> robert_ancell: I don't see that corruption on ati with mir from -proposed (and usc built against that mir)
<ricmm> robert_ancell: awesome, thaks
<ricmm> lemme know how that goes
<robert_ancell> ricmm, packages are built, just waiting for the job that migrates them from -proposed to universe
<ricmm> \o/
<robert_ancell> ricmm, seems to have worked, I'm upgrading now and pulling in the new versions
<ricmm> great!
<robert_ancell> duflu, have you tested bypass on an ati machine?
<duflu> robert_ancell: No, it proved impossible. Multiple kernel bugs prevent me from being able to. Alf tested it for me
<robert_ancell> duflu, it's failing in the lab
<robert_ancell> we've set up ppa:mir-team/qa-testing to just contain bypass, then you can run it in the lab and watch the screen there
<robert_ancell> has lots of corruption
<duflu> robert_ancell: Hmm. OK. I was relying on Alexandros' testing. Got kernel 3.11.0+?
<robert_ancell> the main archive version works
<robert_ancell> duflu, I don't think I can check until the test completes
<robert_ancell> thomi, (if still awake) is that true?
<duflu> robert_ancell: Because corruption is expected. You need the "DMA-buf" fix wherever that was... in kernel 3.11
<thomi> robert_ancell: Im still awake
<thomi> robert_ancell: you should be able to ssh in to the machine while the test is running
<duflu> robert_ancell: To clarify... I have radeon hardware, but can't test saucy due to saucy being unbootable on my desktop (regardless of graphics)
<thomi> robert_ancell: obviously you run the risk of affecting the result, but if all you need to do is check package versions it should be OK
<robert_ancell> duflu, it's running saucy right now and seems to work
<thomi> robert_ancell: oh, also, the machine may reboot under you :)
<thomi> IP addresses are all on the wiki, in case you need them
<robert_ancell> thomi, ta
<robert_ancell> duflu, so the dma-buf fix is required only for bypass?
<duflu> robert_ancell: Seems so. Because I can test raring and it fails there. alf said it worked for him on saucy+radeon.
<robert_ancell> duflu, do you have a bug number?
<duflu> robert_ancell: We're not also testing XMir at the same time are we? XMir adds new bugs which we would have to exclude
<robert_ancell> duflu, yes, with xmir
<duflu> robert_ancell: I wish I had a bug number, or a commit to point to. All anyone has been able to tell me is "you need kernel 3.11". Which seems true for nouveau too
<robert_ancell> duflu, but saucy is kernel 3.11
<duflu> I've also tried kernel 3.11 on raring but ran into other graphics bugs before I could test Mir
<duflu> robert_ancell: It would be unproductive to debug XMir+radeon+bypass right now. I need someone to test just radeon+bypass
<duflu> I'm already in the boat of having too many variables at once with another bug
<robert_ancell> duflu, ok, to be clear. On one of the QA ATI boxes running standard saucy + xmir enabled it works fine, but standard saucy + lp:~vanvugt/mir/bypass + xmir does not
<robert_ancell> so this is only one variable...
<duflu> robert_ancell: Not true. We've spent the past few days finding and fixing XMir bugs only revealed by new Mir features (which themselves are bug free)
<duflu> Maybe we have working saucy images I can boot now. Will retry today
<robert_ancell> thomi, what is the wiki link
<thomi> robert_ancell: https://wiki.canonical.com/UbuntuEngineering/QA/Lab
<kgunn> robert_ancell: is the failure in the mode of the funky stripes? or black screen ?
<robert_ancell> kgunn, looks like just the funky stripes - the test completed otherwise
<kgunn> robert_ancell: that is strange as it keeps changing
<robert_ancell> kgunn, I'm just running saucy without XMir for completeness so we are sure we're comparing apples with apples
<robert_ancell> yeah
<robert_ancell> this remote camera is awesome :)
<kgunn> robert_ancell: so what i'm looking at right now is saucy X
<kgunn> ?
<kgunn> well...then...
<robert_ancell> kgunn, you were looking at saucy + XMir+bypass
<kgunn> oh
<kgunn> it is awesome
<robert_ancell> our mir packages were all out of date - there was some deadlock in the autolanding system
<robert_ancell> They're up to date now, so running the three cases with these packages
<kgunn> robert_ancell: i stepped away...did it run yet?
<robert_ancell> kgunn, yes, just collecting the results
<robert_ancell> kgunn, emailed you the results
<robert_ancell> kgunn, what were you looking for?
<duflu> robert_ancell: The radeon issue, looks like vertical stripes right?
<robert_ancell> duflu, there's a link to an image in the MP
<duflu> If that means incorrect pixel format then I have a reasonable theory as to the cause. But haven't been able to reproduce any such issue yet
<robert_ancell> duflu, that QA machine is at your disposal :)
<duflu> robert_ancell, OK. I was hoping to not have to invest the time setting up VPNs etc :/
<robert_ancell> duflu, I recommend getting the QA VPN set up - it makes life easier
<robert_ancell> thomi, asleep yet?
<duflu> I used to... before reinstalling
<duflu> robert_ancell: Shall I remove the prereq of bypass for timerless?
<duflu> Just means bypass will conflict for a while
<robert_ancell> duflu, sounds like a good idea
<RAOF> Bypass breaks intel XMir too, even single head.
<thomi> robert_ancell: asleep at my desk, does that count?
<robert_ancell> RAOF, is it the mir side or the xmir side?
<robert_ancell> duflu, do you have all the info for the VPN?
<duflu> robert_ancell: No idea. And now I'm a couple of hours from trying :/
<robert_ancell> thomi, can you send any links info to duflu about setting up the QA VPN
<thomi> sure, let me see where I can find it
<thomi> duflu: robert_ancell: https://wiki.canonical.com/InformationInfrastructure/IS/VPN
<thomi> worth noting that it's not so much a 'QA VPN' as a 'Canonical VPN'
<RAOF> robert_ancell: Possibly a combination of the two
<thomi> my understanding is that almost everyone who was in the old PS dept. should have an email in their inbox with their private key
<thomi> otherwise, IS can send you new keys, or help you get it set up
<duflu> I may get more value sooner by trying to find a way to boot saucy on my desktop (where I have radeon). Haven't succeeded yet but it's worth another try
<thomi> duflu: otherwise, I may be able to give you SSH access to my radeon laptop, although it will be slow
<duflu> thomi: If that blurry screenshot is to be trusted then it looks like vertical lines? That one I might have a clue about already
<thomi> duflu: uhh, I'm not sure what screenshot you refer to
<duflu> http://imgur.com/1k7tQE5
<thomi> oh
<thomi> ok, well, let me know if you need annything
<thomi> although for VPN-related things, IS is probably a better bet :)
<kgunn> robert_ancell: i don't understand how those results can be like that...
<kgunn> the thing that's supposed to be the crappiest is the best ?
<robert_ancell> kgunn, yeah...
<robert_ancell> kgunn, please double check the results but I *think* it was run correctly
<robert_ancell> bob
<robert_ancell> beLUmaya
<robert_ancell> DISPLAY=:0 xev
<tvoss> duflu, ping
<tvoss> RAOF, ping
<RAOF> tvoss: Pong.
<duflu> tvoss, pong
<RAOF> mlankhorst: Oooh, you're awake?
<robert_ancell> RAOF, I notice X doesn't drop focus when you VT switch away - do you think this should be a system compositor special option?
<RAOF> Hm, I don't know.
<RAOF> I don't think it makes a huge amount of difference either way.
<RAOF> But a client really isn't focused if it doesn't display or get input.
<tvoss> robert_ancell, RAOF the benchmarking results for radeon seem to suggest that X touching the framebuffer makes things slower?
<tvoss> duflu, kgunn ^
<robert_ancell> I've forwarded them to duflu and RAOF
<RAOF> Does it render correctly?
<tvoss> robert_ancell, ?
<robert_ancell> RAOF, not with bypass
<RAOF> I'm not sure that we should trust the benchmark numbers then.
<tvoss> RAOF, true
<duflu> I know that software rendering + bypass is often slower. Which is why bypass is disabled for software surfaces
<duflu> RAOF: If XMir does any "copies" it's really a software renderer then... ?
<duflu> And it's lying to Mir in saying this is a hardware surface?
<duflu> I remember a while back I said we should distinguish between "hardware" buffer residency and hardware blitting, but my suggestion was rejected :/
 * duflu *shrugs* and goes to lunch
<RAOF> duflu: It's does hardware blitting, from hardware-rendered other buffers.
<RAOF> duflu: It's as much a hardware surface as any EGL app.
<tvoss> RAOF, duflu back
<duflu> RAOF: OK. Though this "copy" I keep hearing about, is that on the CPU? What stage is it?
<RAOF> duflu: It's on the GPU; X is basically acting as a compositor.
<RAOF> Except rather than going through GL, it's speaking raw GPU command streams.
<duflu> RAOF: Sounds fast. I guess if it actually was software copying I would not see the nice reduction in mouse lag with qa-testing(bypass)
<RAOF> As far as Mir is concerned, though, it's not different than an EGL client. The difference between X and and EGL client is an EGL client has the mesa library to produce the command streams.
<duflu> RAOF: Oh, BTW, any idea why single-buffering desktop environments would *not* exhibit the frame ordering bug?
<RAOF> No, and are you certain that they don't? Last time I checked I could get the frame-ordering problem on raw X + xterm.
<RAOF> But I guess that was a while ago.
<duflu> RAOF: Almost certain. I could not get it to happen with Compiz doing single buffering, or plain Xfce
<tvoss> RAOF, can we disable buffer age in X?
<RAOF> tvoss: Yes, but it doesn't help.
<tvoss> RAOF, ah
<duflu> But that could be timing too... single buffer damage-only updates are faster
<duflu> I have tried making intentionally slow clients, but didn't reproduce it that way
<tvoss> RAOF, duflu so trying to understand: somewhere the buffer order inside X gets fucked up, and n+1 is submitted before n
<duflu> It looks like it. I still can't reproduce it with any demo client, no matter how I try to change variables
<RAOF> I don't believe that is the case - smspillaz was seeing the same problem with his GTK implementation, and he dumped the frames to disc before submitting them and they were correct.
<RAOF> tvoss: ^^^
<duflu> RAOF: No, Sam reported lag only, not buffer misordering. Hence it's still a separate bug. Also that was fixed by ignoring buffer age
<RAOF> Huh, I thought he'd tried that and it didn't work.
<RAOF> I'm clearly not up on that bug.
<tvoss> smspillaz, ping
<duflu> I have other theories as to where bad ordering could come from. But I will have to learn new Mir code I've never really looked at
<tvoss> duflu, which one? how can I help?
<smspillaz> tvoss: pong, but I gotta go soon
<tvoss> smspillaz, quick x-check: ignoring buffer age in your gtk port fixed the lag?
<smspillaz> duflu: I'm not so sure if that was "fixed" by ignoring buffer age
<smspillaz> at least - I didn't see it when I did full repaints but it appears to be a race condition
<smspillaz> and furthermore, the symptoms I'm seeing are not consistent with incorrect buffer ages being sent
<smspillaz> I'd suggest running the gtk demo to see if you can reproduce it on your end
<tvoss> duflu, sounds like a simpler client than X
<duflu> smspillaz: Yes, sorry, bad choice of words. But at least "worked around" by not using the buffer age
<duflu> tvoss: Different bug
<duflu> Hence not a valid test case
<tvoss> duflu, ack
<duflu> We have at least three lag/ordering bugs and they are all most definitely separate. It takes careful analysis to know they're different tho
<smspillaz> duflu: like I said, I'm not sure that not using buffer age would actually fix it
<smspillaz> it just seems that here it does not trigger that race
<tvoss> duflu, so for the ordering bug: do we have a frame counter per surface?
<duflu> tvoss: No, we have a unique ID you can track tho
<tvoss> duflu, how do we know it's an ordering bug then and not an unfinished rendering?
<duflu> tvoss: mir_debug_surface_current_buffer_id should be sufficient
<duflu> tvoss: Unfinished rendering *usually* appears as tearing
<duflu> But it could also be related to a missing flush/finish or equivalent
<tvoss> duflu, true, but we are making an assumption here, and at such high frame rates, I would actually want to make sure that it is really ordering :)
<duflu> tvoss: Well, we have tests for it already in lp:mir. You could also ask the client to check the order it's getting, with mir_debug_surface_current_buffer_id
<duflu> Of course, tests are never foolproof
<RAOF> That's how I tracked down the ordering problem last time; by dumping the surface ID all over the place.
<duflu> RAOF: That was a while ago... we fixed that one right?
<RAOF> Yeah.
<RAOF> At least for single outputs and clients with single surfaces :)
<RAOF> But I don't think that code cared where the buffer came from.
<duflu> I have had more theories as to how order might be violated. However can't yet find any theoretical reason why it would be in the buffer swapper. That part is now designed to make ordering theoretically guaranteed
<duflu> We might be racing/messing up in the protocol/threading somewhere though
<duflu> ... but if it was that easy then you'd think some mir_demo_client could show a similar bug.
<RAOF> Maybe?
<RAOF> I think we might want to write a one-surface-per-output version of progressbar that uses GL rather than CPU mapping.
<duflu> RAOF: egltriangle should be sufficient. Just need to add a parameter to populate output_id methinks
<duflu> RAOF: I also keep thinking if your surfaces usually only map to one monitor each, then only one compositor thread should be getting each surface. It should behave like single monitor... unless we've messed up the region calculation
<robert_ancell> RAOF, duflu, kgunn, racarr|desert, hikiko, tvoss, thomi, meeting time...
<thomi> omw
<tvoss> robert_ancell, not on broadband, will try to join, though
<thomi> ugh, RAGE!
<thomi> stupid technology
<tvoss> duflu, do we see the ordering issue only on multi-monitor or also on single output?
<thomi> robert_ancell: can someone link me the hangout url please? It's now showing up in my calendar
<duflu> tvoss: Multimonitor only
<tvoss> duflu, my understanding: it's trunk + bypass exposing it when used with XMir?
<duflu> tvoss: No, multimonitor only. And even without bypass
<tvoss> duflu, ah, that helps a lot
<duflu> tvoss: It happens on qa-testing2 (no bypass)
<tvoss> duflu, ack. So to land bypass, we need to check the weird ati numbers
<duflu> tvoss: And corruption
<duflu> tvoss: I will be in a better state to test and fix when I can boot saucy on my desktop. Which I cannot yet :(
<tvoss> duflu, ack, what is blocking you from booting saucy on your desktop?
<duflu> tvoss: Kernel/BIOS issues new in saucy. Cannot even start to boot it
<tvoss> robert_ancell, which ppa did you use to run the openarena benchmarks? qa-testing?
<tvoss> duflu, got a bug report?
<robert_ancell> tvoss, ye
<robert_ancell> s
<duflu> tvoss: https://bugs.launchpad.net/bugs/1212977
<ubot5> Launchpad bug 1212977 in linux (Ubuntu) "saucy daily-live images are unbootable on Dell Optiplex 990; stuck in BusyBox shell" [High,Incomplete]
<tvoss> duflu, thx
<mlankhorst> RAOF: yeah
<mlankhorst> RAOF: did you get my message and video? :P
<RAOF> mlankhorst: Yes
<mlankhorst> ah good
<RAOF> mlankhorst: I had a couple of questions. Mainly - is that pixmap the screen pixmap?
<mlankhorst> no idea, considering the code it was from i would assume so :P
<mlankhorst> tvoss: xorg-server is unmodified for bypass right?
<olli> robert_ancell, mir/archive should be unblcoked
<tvoss> mlankhorst, ack
<robert_ancell> olli, yeah, it was another issue, fixed now
<olli> ok
<RAOF> mlankhorst: gdb and print out (screen->GetScreenPixmap)(screen)?
<mlankhorst> RAOF: oh right it might be very much possible that it switches the front  buffer in fullscreen gl case
<mlankhorst> tvoss: hm interesting noise pattern :P
<hikiko> could anyone review this branch: https://code.launchpad.net/~hikiko/mir/mir.native-gbm-platform-class/+merge/182074 ?
<mlankhorst> I can vaguely make out the details
<mlankhorst> tiling or pixel format is messed up
<RAOF> mlankhorst: And I've just noticed that nouveau *does* keep a track of what it thinks is the front buffer that is wrong as soon as xmir_resize hits...
<mlankhorst> RAOF: hah!
<robert_ancell> later all
<RAOF> SetScreenPixmap hooks for everybody!
<RAOF> robert_ancell: 'night!
<hikiko> bye robert_ancell
<RAOF> Also, I really really really really hate the way xf86-video-ati has an open coded "set up this radeon_surface" struct in like 2032232332342342 different places.
<RAOF> That's right. There are more copies of that code than there are lines of code.
<mlankhorst> tvoss: actually on closer look it looks like there are vertical lines that look correct, 4 pixels? then another vertical line with garbage
<RAOF> It's very quantum.
<mlankhorst> so dno
 * RAOF goes and get groceries for dinner.
<mlankhorst> RAOF: welcome to radeon ;)
<mlankhorst> RAOF: don't look at the kernel!
<mlankhorst> it has  5 copies of 'is this command ring working'
<mlankhorst> one for each ring
<tvoss> duflu, did you see mlankhorst's findings?
<duflu> afk
<tvoss> duflu, ack
<mlankhorst> nothing in dmesg this time
<tvoss> mlankhorst, can you check with a mir demo client if the corruption shows up with that?
<tvoss> mlankhorst, you can use lp:~thomas-voss/glmark2/mir-no-deprecated-functions and run it in fullscreen
<mlankhorst> hm crash on eglplasma :P
<tvoss> hah
<mlankhorst> http://paste.debian.net/31210/
<mlankhorst> that's the eglplasma thing crashing, i think usc went too
<tvoss> mlankhorst, thx
<tvoss> mlankhorst, can you verify that usc did really crash?
<mlankhorst> Program received signal SIGABRT, Aborted.
<mlankhorst> [Switching to Thread 0x7f165cafe700 (LWP 2149)]
<mlankhorst> 0x00007f1669126f77 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
<mlankhorst> 56      ../nptl/sysdeps/unix/sysv/linux/raise.c: Bestand of map bestaat niet.
<mlankhorst> http://paste.debian.net/31211/
<mlankhorst> lol, crashes on closing egltriangle too
<mlankhorst> but the triangle looks fine, fwiw
<tvoss> mlankhorst, okay, thanks for the hints
<mlankhorst> back to the drawing board for you? :P I'm going to test for raof a bit
<tvoss> mlankhorst, ack, calling some people to get an amd machine now
<tvoss> mlankhorst, okay, I'm mostly interested in the corruption right now
<mlankhorst> tvoss: oh I'm still on mesa 9.2 fwiw
<tvoss> mlankhorst, mind switching to default saucy?
<duflu> Sorry... had to get a quick fix for my leaky roof. Done I think
<duflu> tvoss: What am I looking at?
<mlankhorst> tvoss: actually I do, need to finish testing on that first :P
<mlankhorst> but fine
<duflu> mlankhorst: Yes I suspect the vertical lines might just be the drm fb using the wrong pixel format to the attached bo
<duflu> Since we don't actually set it yet...
<duflu> mlankhorst: Also, compiz _will_ switch front buffers, when it decides a fullscreen window can be "unredirected"
<mlankhorst> that probably sounds about right :P
<duflu> tvoss: "did you see mlankhorst's findings?" .... where?
<mlankhorst> actually it looks like even worse garbage on 9.1.6 :P
<mlankhorst> might just be freed memory being displayed
<mlankhorst> hm then again it looks too much like what should be displayed, so i dont know
<mlankhorst> but there's definitely some garbage on top of it
<duflu> mlankhorst, sounds like what I saw with radeon doing bypass on raring. Still could never test saucy
<tvoss> duflu, where would we need to set the pixel format?
<duflu> tvoss: DRM calls. I will put together an attempt momentarily... which I have done before but never found a need to modify that code till now
<duflu> I mean, it's something I've tried before but never found a system where it was necessary, yet
<mlankhorst> $6 = {drawable = {type = 1 '\001', class = 0 '\000', depth = 24 '\030', bitsPerPixel = 32 ' ', id = 0, x = 0, y = 0, width = 2720, height = 1024, pScreen = 0x7f92f1e1b700, serialNumber = 2589},
<mlankhorst>   devPrivates = 0x7f92f264ef38, refcnt = 1, devKind = 10880, devPrivate = {ptr = 0x0, val = 0, uval = 0, fptr = 0x0}, screen_x = 0, screen_y = 0, usage_hint = 2, master_pixmap = 0x0}
<mlankhorst> RAOF: screen pixmap^
<mlankhorst> but the pixmap the function is called with is this
<mlankhorst> $7 = {drawable = {type = 1 '\001', class = 0 '\000', depth = 24 '\030', bitsPerPixel = 32 ' ', id = 0, x = 0, y = 0, width = 1280, height = 1024, pScreen = 0x7f92f1e1b700, serialNumber = 2124},
<tvoss> duflu, ack
<mlankhorst>   devPrivates = 0x7f92f1e8aca8, refcnt = 1, devKind = 5120, devPrivate = {ptr = 0x0, val = 0, uval = 0, fptr = 0x0}, screen_x = 0, screen_y = 0, usage_hint = 0, master_pixmap = 0x0}
<RAOF> mlankhorst: Thanks.
<duflu> Silly question... "DMAbuf" I've never seen explicitly mentioned. Is it part of how we use drmModeAddFB ?
<RAOF> No.
<RAOF> dma-buf is our buffer IPC mechanism.
<RAOF> We go from a gem name (for use in drmModeAddFB et al) to a dma-buf fd and back.
<duflu> RAOF: Umm, kay. So it is correct to pass in  gbm_bo_get_handle(bo).u32 (the "gem" handle?) to  AddFB?
<duflu> Obviously it works for intel+nouveau...
<RAOF> Yup, that would be the right thing.
<duflu> It's really confusing when people talk about "gem" this and that, even in naming variables, but "gem" isn't mentioned in the API at all. It's just uint32_t
<tvoss> duflu, sounds like we should have a wrapper for that then :)
 * tvoss restarts
<duflu> tvoss: Not Mir's fault. Just DRM... undocumented
<tvoss> duflu, ack
<Mirv> someone could check my two MP:s to get trunks in sync with the archive rebuilds https://code.launchpad.net/~timo-jyrinki/unity-mir/sync_to_archive/+merge/182553 + https://code.launchpad.net/~timo-jyrinki/unity-system-compositor/sync_to_archive/+merge/182554
<mlankhorst> duflu: yeah gem predates dma-buf, fd's were too expensive at the time :P
<Mirv> not sure why robert changed that architecture line in a 'no change' rebuild, but it seems fine
<tvoss> duflu, is the bypass branch in sync with trunk?
<RAOF> mlankhorst: Fun story: randr resizes don't fix up the root window pixmap.
<duflu> tvoss: Not sure about the LP one, but there have been no conflicts or logic changes since 14 Aug
<duflu> tvoss: I'm working on it locally
<mlankhorst> RAOF: you don't say ;)
<tvoss> duflu, ack
<RAOF> mlankhorst: Would you kindly check the new xserver & nouveau? They're in qa-testing2 and also in git.
<mlankhorst> sure
<duflu> RAOF, mlankhorst: Is it standard to use fourcc's for pixel formats now? I can't tell when pixel_format is just uint32_t
<mlankhorst> I guess so, just look at the source I guess
<duflu> Ah, in place of documentation, interpret the source :)
<duflu> mlankhorst: Is it generally considered valid to keep an alpha channel on scanout buffers? Or expected to fail?
<RAOF> duflu: Pixel format is always just a uint32_t. Sometimes it's just a uint32_t generated by concatenating 4 bytes...
<RAOF> dma-buf brought drm in to the magical world of fourccs, because it implies interop with v4l stuff.
<RAOF> To the ZoÃ«!
<tvoss> RAOF, :)
<tvoss> mlankhorst, what's the status of https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1214066
<tvoss> ?
<ubot5> Launchpad bug 1214066 in xorg (Ubuntu) "phoronix benchmarks on nouveau is 4 times slower today than it was last thursday" [Undecided,Incomplete]
<mlankhorst> as it says in the status, undecided, incomplete
<mlankhorst> :P
<tvoss> mlankhorst, have you seen similar behavior on your machine?
<mlankhorst> not really, but I'm planning on releasing 9.2 soon
<tvoss> mlankhorst, okay, eta?
<tvoss> mlankhorst, is there a ppa with 9.2 such that I can test with Mir and XMir?
<mlankhorst> ppa:canonical-x/x-staging
<tvoss> mlankhorst, ack
<tvoss> mlankhorst, so that has got all our mesa patches for Mir, too? just x-checking
<duflu> mlankhorst: The bypass corruption issue... could that be because nothing is marked as dirty?
<duflu> I just noticed the "dirty" feature
<mlankhorst> no idea
<mlankhorst> i think xorg only sends stuff when marked as dirty
<duflu> The more I read, the more it sounds like bypass might /require/ it for some hardware
<mlankhorst> I guess mir needs to be at least told a buffer is dirty :P
<duflu> mlankhorst: I find some platforms fail to page flip with pixel_format's containing alpha. Can I tell if it's going to work before attempting the flip? Seems like I can't
<mlankhorst> duflu: dno, I think if you can create a fb with the format flip should work
<duflu> mlankhorst: FB creation always succeeds. But the drivers only check if the pixel_format is compatible later when the flip is attempted :(
<hikiko> duflu, do you have some time to review a branch? (sorry I need to merge it and alf is on holidays so it's approved only by alan and jenkins) could you get a quick look? it's a very small change...
<duflu> hikiko: Maybe. Not sure. I'm already way overloaded for the next day or two
<mlankhorst> duflu: well strictly speaking ARGB would be compatible for flipping..
<mlankhorst> but as XRGB
<duflu> mlankhorst: Apparently not. intel rejects AR24, only flips XR24.
<hikiko> duflu, only if you have some free time (here it is: https://code.launchpad.net/~hikiko/mir/mir.native-gbm-platform-class/+merge/182074) +thank you :)
<mlankhorst> duflu: kernel or userspace?
<duflu> mlankhorst: Userspace
<mlankhorst> then fix userspace..
<hikiko> hi alan_g :)
<alan_g> hikiko: hi
<hikiko> alan_g, I was waiting for you! :) can I merge this one: https://code.launchpad.net/~hikiko/mir/mir.native-gbm-platform-class/+merge/182074
<hikiko> ?
<alan_g> hikiko: Yeah, autolanding failed for "unrelated reasons". I'll top-approve again
<hikiko> thank you alan_g :)
<alan_g> hikiko: can you do the same for https://code.launchpad.net/~alan-griffiths/mir/spike-NestedOutput/+merge/182405?
<hikiko> yes
<hikiko> I thought it was merged.. done alan_g :)
<alan_g> hikiko: there are some intermittent test failures that we see in CI. No-one has got to the bottom of them yet
<hikiko> what is the Cl?
<alan_g> CI == Continuous Integration
<hikiko> I see
<tvoss> duflu, RAOF back
<tvoss> duflu, any more insights?
<duflu> tvoss: I have an experimental change that might fix radeon. But lots of mocks are now broken :(
<tvoss> duflu, okay, can you get packages over to mlankhorst? disable tests in the package build if need be
<tvoss> just to verify that the change fixes radeon
<duflu> tvoss: I will test it with everything I have first. Make sure nothing regressed
<tvoss> duflu, ack
<tvoss> duflu, I have got an amd machine now
<tvoss> duflu, need to set it up with 13.04
<RAOF> mlankhorst: How'd testing go?
<mlankhorst> RAOF: oops was waiting for the build
<RAOF> Slacker :)
<tvoss> mlankhorst, xmir from archive working fine with mesa 9.2 on intel
<mlankhorst> tvoss: yeah noticed the same with nouveau + radeon
<duflu> Wow, I hate gmock more than ever now
<duflu> Its sharing of details you shouldn't know and should be free to modify is absurd
<tvoss> duflu, could you verify locally that things work fine on intel?
<duflu> tvoss: Yes, about to start hardware testing. Given up trying to fix all the DRM mocks
<duflu> brb
<RAOF> mlankhorst: Still waiting for the build? :)
<mlankhorst> nah was setting up my site
<mlankhorst> with ssl.. https://mblankhorst.nl/
<Mirv> the mir+mirslave on't publish next cu2d run if https://code.launchpad.net/~timo-jyrinki/unity-system-compositor/sync_to_archive/+merge/182554 + https://code.launchpad.net/~timo-jyrinki/unity-mir/sync_to_archive/+merge/182553 don't get merged
<mlankhorst> RAOF: hm your build is a fail :P
<mlankhorst> it built against the wrong mir?
<RAOF> Both build locally!!!!!
<mlankhorst> of course but there's a newer mir in the distro archive
<mlankhorst> which it built against
<RAOF> Arse
<RAOF> Just force dependencies; mirclient ABI hasn't changed.
<mlankhorst> boom, dead
<mlankhorst> #0  NVSetScreenPixmap (ppix=0x7f84f7000490) at ../../src/nv_driver.c:613
<mlankhorst> no bo attached yet, har har
<mlankhorst> (gdb) print (struct nouveau_pixmap *)exaGetPixmapDriverPrivate(ppix)
<mlankhorst> $6 = (struct nouveau_pixmap *) 0x0
<mlankhorst> did you mean: nouveau_pixmap_bo ? :P
<mlankhorst> I think you're worrying too much about scanout, tbh..
<mlankhorst> RAOF: where do you see nouveau actually _using_ scanout?
<mlankhorst> if you moved pScrn->displayWidth out from NVMapMem, I bet you could get rid of pNv->scanout entirely for xorgMir..
<RAOF> A bit in nv_accel, but mostly in drmmode_display. It probably can be just wrong.
<mlankhorst> I would think so :p
<mlankhorst> bet it's the same for ati though
<katie> tvoss, ping
<tvoss> katie, pong
<RAOF> mlankhorst: Probably, yeah.
<RAOF> mlankhorst: Do you want to patch that out locally, or do you need me to push a patch for it?
<mlankhorst> sec
<mlankhorst> testing if nvmapmem can be skipped entirely
<RAOF> Looks like it can, although fbScreenInit is probably going to want *something* moderately sane as displayWidth.
<mlankhorst> yeah but it should
<mlankhorst> probably unconditionally set it from earlier
<mlankhorst> RAOF: you still failed :P
<RAOF> Booo
<mlankhorst> hm GetScreenPixmap is null
<RAOF> Wat now?
<RAOF> How is getscreenpixmap null?
<duflu> tvoss: I have tested all the hardware I can test, and can't see any change in behaviour... but this might fix the test lab radeon issue: lp:~vanvugt/mir/bypass-drmModeAddFB2
<RAOF> That's not my fault :)
<mlankhorst> ok it might want some more sanity for displayWidth then.
<tvoss> mlankhorst, can you test lp:~vanvugt/mir/bypass-drmModeAddFB2
<tvoss> ?
<tvoss> mlankhorst, I'm mostly done setting up my amd machine, too
<duflu> tvoss: Still can't boot saucy with today's images either
<duflu> Maybe I will have to try a BIOS. Somehow
<mlankhorst> RAOF: hm the pixmap you create has no bo, and now nouveau_xmir_copy_to_mir crashes on that ;P
<RAOF> mlankhorst: Huh. I don't immediately see why that would be the case.
<mlankhorst> are you using createpixmap instead of createpixmap2? :p
<tvoss> duflu, I can totally reproduce the garbled screen issue on ati with qa-testing \o/
<tvoss> duflu, there is hope ;)
<mlankhorst> hm seems so..
<duflu> tvoss: Woo
<RAOF> mlankhorst: Neither; I'm using Screen->CreatePixmap
<duflu> tvoss: How garbled? Any lines?
<tvoss> duflu, completely garbled, I couldn't see a thing
<duflu> tvoss: Sounds like what I see with radeon on raring. I only assumed saucy would fix it cos alf said it worked for him
<tvoss> duflu, not working here
<tvoss> duflu, anyway, I can at least reproduce, compiling packages from your branch right now
<RAOF> mlankhorst: Ah, maybe nouveau needs to migrate the pixmap in nouveau_xmir_copy_to_mir
<RAOF> ?
<duflu> tvoss: Excellent, thanks
<tvoss> duflu, ack
<mlankhorst> RAOF: probably..
<mlankhorst> RAOF: actually nouveau shouldn't, xmir should :P
<RAOF> mlankhorst: Why?
<RAOF> There's no driver-independent way of doing that, at least that I know of.
<RAOF> It's a DDX-internal (or, really, EXA internal) implementation detail.
<mlankhorst> exa is doing it :P
<mlankhorst> RAOF: in that case is there any way to force it to be migrated into the driver?
<RAOF> You just need to throw an exaMoveInPixmap(src) at the top of nouveoau_xmir_copy_to_mir
<mlankhorst> any idea why I didn't hit this before, though?
<RAOF> mlankhorst: Because we weren't changing the screen resolution, so you got the fully-accelerated thing that nouveau creates on startup.
<mlankhorst> also no luck..
<RAOF> No fixy?
<RAOF> Still no bo after exaMoveInPixmap()?
<mlankhorst> hm seems there is simply no bo, driverprivate exists
<mlankhorst> so width = 0 or height = 0 at time of creation, breaking on nouveau_exa_create_pixmap shows both were 0 at time of CreateScreenResources..
<RAOF> Oh! You're not hitting this after resize, but on startup?
<mlankhorst> yeah
<RAOF> Oh. You're no longer creating pNv->scanout, are you?
<mlankhorst> indeed
<RAOF> So when NVCreateScreenResources refs pNv->scanout into GetScreenPixmap()->boâ¦
<mlankhorst> well I fixed that one
<mlankhorst> and that only happens later, it dies in createscreenresources before that point
<mlankhorst> hm or not, let me rebuild just to be sure
<RAOF> Yeah, but you map anything into GetScreenPixmap()->bo?
<mlankhorst> hm no, should it?
<RAOF> Probably; as you say, the screen pixmap is created in miCreateScreenResources with width = height = 0 and then ModifyPixmapHeader'd.
<mlankhorst> how nasty..
<RAOF> Yeah, I'm not entirely sure why it does that.
<mlankhorst> setscreenpixmap is not even called though :P
<mlankhorst> miSetScreenPixmap isn't, at least
<mlankhorst> RAOF: does xserver always use ModifyPixmapHeader to change resolution?
<RAOF> Hahahahahahha!
<RAOF> Modify resolution! Surely you jest!
<mlankhorst> ugh w/e
<mlankhorst> s/change/during/
<RAOF> No; xserver doesn't modify resolution. It delegates that entirely to the driver.
<mlankhorst> ok so how does xmir handle it :P
<RAOF> c/o randr.
<RAOF> I use Screen->CreatePixmap(new_width, new_height, ...)
<RAOF> Then set the screen pixmap & root window pixmap.
<RAOF> But that code doesn't get called on startup.
<RAOF> On startup it's just miCreateScreenResources shoving stuff directly into pScreen->devPrivate.
<mlankhorst> hm adding exaMoveInPixmap(src) to createscreenresources probably worked
<duflu> RAOF: tvoss showed me webcam of what looks like bypass working on radeon. But the stride is all messed up. Have you fixed any radeon stride-ness?
<mlankhorst> something crashed though :P
<mlankhorst> but might just be the gpu *checks*
<RAOF> duflu: What version of radeon/xmir?
<tvoss> RAOF, archive
<tvoss> RAOF, or better qa-testing, which is archive
 * RAOF tries to page that version of the driver back into my brain.
<tvoss> RAOF, sorry for the context switch
<RAOF> duflu: There have certainly been stride-related *changes* between there and qa-testing2
<duflu> So... get the DDX from qa-testing2?
<RAOF> You'd need both the DDX and xserver from qa-testing2
<duflu> OK, same bug or not, I'm reinstalling radeon. BRB
<tvoss> duflu, qa-testing shows the same pattern
<tvoss> duflu, slightly more noisy though
<duflu> tvoss: So the new branch made no difference. I recommend the old one (in qa-testing)
<duflu> Going to put radeon back in
<duflu> 5 min
<tvoss> hah, egl-triangle works perfectly fine :)
<tvoss> RAOF, would it work if I take X and radeon from qa-testing2?
<RAOF> tvoss: Should, yes.
<tvoss> RAOF, ack
<RAOF> Well, obviously modulo the Mir bugs you're trying to track down :)
<tvoss> RAOF, ;)
<tvoss> duflu, \o/ egltriangle is working perfectly fine on qa-testing
<tvoss> with the noise in the background ;)
<duflu> tvoss: Umm, what?!
<tvoss> duflu, wanna see?
<duflu> Sure
<tvoss> duflu, calling you on g+
<tvoss> duflu, can you invite me to a hangout again?
<mlankhorst> RAOF: but I think adding exaMoveInPixmap is enough..
<mlankhorst> to NVSetScreenPixmap
<RAOF> Oooh, yeah. That's even better!
<tvoss> RAOF, ?
<mlankhorst> RAOF: oh and add this to your .quiltrc
<mlankhorst> QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index"
<RAOF> tvoss: mlankhorst's suggestion of moving the screen pixmap into VRAM in SetScreenPixmap. Rather than in nouveau_xmir_copy_to_mir.
<RAOF> mlankhorst: OOOOH AWESOME.
<mlankhorst> QUILT_NO_DIFF_INDEX=1
<mlankhorst> QUILT_NO_DIFF_TIMESTAMPS=1
<mlankhorst> and that :P
<hikiko> alan_g|afk, I have an idea of something that might be wrong in the mir-on-mir design but I am not sure...
<mlankhorst> hm I guess that one is more thorough
<tvoss> RAOF, I need xserver-xorg-common, xserver-xorg-core, xserver-xorg-xmir. Correct?
<alan_g> hikiko: tell me
<RAOF> tvoss: Correct.
<RAOF> Technically you don't need xserver-xorg-common, but dpkg will complain if you don't have matching versions :)
<tvoss> RAOF, exactly
<duflu> Argh. Nested display stuff has broken bypass builds
<tvoss> duflu, why is that?
<alan_g> duflu: how?
<duflu> Class changes...
<duflu> Or has my system switched to gcc-4.7 by accident too?
<tvoss> duflu, RAOF a lot better, but still not there
<tvoss> duflu, can you invite me to a hangout?
<duflu> What's a lot?
<tvoss> duflu, I can log in to my session, and run glmark2
<hikiko> alan_g, I am not sure but as we have designed it we call the create_nested_display with a parameter that is the native display constructor which means that the native display constructor is called before the nested one and we initialize the gbm/drm etc before we have a nested platform and a connection etc but I am not sure if this is bad and if this has anything to do with the bug I have
<hikiko> still investigating
<duflu> tvoss: Lost you... ?
<alan_g> hikiko: *if* we need to initialize gbm after connecting to the host then that just means we shouldn't do it in the NativeDisplay constructor.
<hikiko> yes, that's what I am checking now
<hikiko> if moving this part
<hikiko> will solve the issues
<RAOF> mlankhorst: Are you able to upload to qa-testing2 / push a merge request to github?
<tvoss__> duflu, can you call me again please?
<tvoss__> duflu, internet connection dropped
<RAOF> mlankhorst: 9:30 says âyou're too tired to do any real work, go to sleepâ
<hikiko> alan_g, the thing is if I add the gbm code to the nested platform then it won
<hikiko> mmm nothing :)
<alan_g> duflu: I see - you're changing the DisplayBuffer interface and that is implemented in nested.
 * alan_g wishes folks would let code land instead of keeping it on branches for days on end
<alan_g> duflu: want me to MP a fix?
<duflu> alan_g, please
<mlankhorst> RAOF: well dno about the merge request stuff
<alan_g> hikiko: ?
<hikiko> nothing I fixed it :)
<hikiko> I changed the drm.setup call and now I get an exception that mir tries to get a drm device it shouldnt but that's easier to fix :)
<alan_g> hikiko: cool
<alan_g> duflu: https://code.launchpad.net/~alan-griffiths/mir/prepare-nested-for-bypass/+merge/182610
<tvoss__> mlankhorst, can you check if XMir on nouveau with qa-testing is working?
 * duflu -> dinner
<tvoss__> greyback, got a machine with an nvidia card?
<greyback> tvoss__: I do, but at home (am in my office)
<tvoss__> greyback, ack
<tvoss__> anyone with an nvidia card around?
<mlankhorst> tvoss__: oh seems to work btw
<tvoss__> mlankhorst, can you try x vs. xmir vs. xmir bypass with glmark2 please?
<mlankhorst> how? :P
<mlankhorst> not sure if it's going to be accurate either
<tvoss__> mlankhorst, well, it's a bit tedious, and involves installing and uninstalling
<tvoss__> mlankhorst, got time for that right now? or are you busy with other stuff?
<mlankhorst> not that busy, waiting for some compiles
<tvoss__> mlankhorst, do you know your way around the xmir radeon driver?
<mlankhorst> sort of
<mlankhorst> raof knows the pure X stuff a lot better than me, so for any deep architectural questions ask him, small things I can probably do :P
<tvoss__> mlankhorst, can I show you something on a hangout? I think you know how to fix it
<kgunn> tvoss__: can i join for a status/data dump ?
<tvoss__> kgunn, sure
<mlankhorst> word description would be easier I think, if it's small :P
<tvoss__> mlankhorst, well, with bypass, I'm pretty sure we have one stall frame coming from the X side
<tvoss__> mlankhorst, easier if I can just show you what I'm seeing
<mlankhorst> hm raof would know this kind of thing a lot more than me, I probably don't know about that ;P
<tvoss__> mlankhorst, can you point me to the branch we are building from?
<tvoss__> mlankhorst, will look myself then
<mlankhorst> raof's github, xf86-video-ati
<mlankhorst> the ones in the archive are on debian
<mlankhorst> http://anonscm.debian.org/gitweb/?p=pkg-xorg/driver/xserver-xorg-video-ati.git;a=shortlog;h=refs/heads/ubuntu
<kgunn> tvoss__: appears to be branch foo
<mlankhorst> the foo branch is for mm support
<tvoss__> mlankhorst, ack and thx
<tvoss__> olli, kgunn wanna jump on a hangout real quick?
<kgunn> tvoss__: good for me
<olli> wfm, give me 2min
<tvoss__> kgunn, sent you an invite
<tvoss__> kgunn, can you open a hangout and invite me?
<kgunn> tvoss__: :)) sure
<duflu> Oh, hello USA. I must be in the wrong place
<duflu> tvoss__, I'm finding new ways to make radeon do the same thing (noise without errors) but getting nowhere. Do you need me online?
<duflu> kgunn^ ?
<tvoss__> duflu, not right now
<tvoss__> mlankhorst, do you have any idea what radeonShadowWindow is supposed to do?
<mlankhorst> hold on let me check
<mlankhorst> return a pointer to the window in shadowfb
<mlankhorst> shadowfb is just a b ig slab of memory encompassing all screens :)
 * kgunn notes... kgunn^ didn't alert me...huh
<tvoss__> mlankhorst, in radeon_kms.c
<tvoss__> mlankhorst, line 205: mind explaining to me the stride calculation?
<tvoss__> mlankhorst, that should be the stride in pixels, under the assumption that every pixel has got 8 byte, correct?
<alan_g> hikiko: any progress towards nested GBM?
<mlankhorst> tvoss__: no, *BITS*perpixel :P
<mlankhorst> eg / 8
<hikiko> yes alan_g
<hikiko> I found a bug
<hikiko> https://code.launchpad.net/~hikiko/mir/mir.fix-drm-version/+merge/182653
<alan_g> hikiko: \o/ I'll take a look
<hikiko> alan_g, I don't know if it's relevant to RAOF-duflu task but since it includes drm code I added them as reviewers
<hikiko> (alf is on holidays :/)
<mlankhorst> hikiko: considering freeing NULL is allowed, maybe you can come up with a more compat version?
<hikiko> true :) I'll fix it
<mlankhorst> eg if (!(drm_version = drmGetVersion(tmp_fd)) || !(drm_version->version_major < 1) || (drm_version->version_major == 1 && drm_version->version_minor < 4)) { drmFreeVersion(drm_version); } ; etc :P
<hikiko> oh
<mlankhorst> but I think that would fail, did you actually test it with drm as the only user?
<hikiko> I thought you mean I free something that is null
<hikiko> what do you mean by drm as the only user?
<hikiko> I tested with mir_server_basic mir_server_shell and nested mir mlankhorst
<hikiko> I just ran it and print the version numbers with and without the change
<hikiko> without the change nested mir couldnt allocate any device with drm 1.6
<hikiko> do you think I have to test something more?
<mlankhorst> I don't think they're identical, let me check..
<hikiko> ok
<mlankhorst> drmGetVersion gets the driver version, which is dd_major/minor
<hikiko> so I should get the di
<hikiko> you are right
<mlankhorst> and is different for each driver
<hikiko> if we want the interface version
<hikiko> why do we do it in a loop?
<mlankhorst> a misguided attempt..
<mlankhorst> at fixing a race condition, but it does not work
<hikiko> ok I'll delete the MP then and check more tomorrow because it's almost the end of my day :)
<mlankhorst> hikiko: who passes the fd, or do you open it yourself?
<mlankhorst> if the fd is passed to you, you could kill the check and assume the version is correct
<mlankhorst> fixing nesting
<hikiko> yes that's what I did but then I thought that for some reason we need that check
<hikiko> so I tried to "fix" it
<mlankhorst> it's only required if opening the fd yourself the first time
<hikiko> that's what I think we do
<hikiko>         tmp_fd = open(dev_path, O_RDWR, O_CLOEXEC);
<hikiko> but the thing is
<hikiko> we run this code *after* we open the device
<hikiko> and if the version is not the desired
<hikiko> we close the device
<hikiko> is this correct?
<mlankhorst> drmSetInterfaceVersion is not really required for mir, just assume it's correct or other things would have broken down sooner..
<hikiko> ok then I ll do an MP without any check at all
<mlankhorst> sec, I had a nice check in nouveau for it
<mlankhorst> drmModeGetResources(fd), if it returns NULL kms is not supported :P
<mlankhorst> freed with drmModeFreeResources
<hikiko> mlankhorst, I think we do that check elsewhere let me see
<mlankhorst> probably but if you do that check first it should be good enough
<hikiko> yes we do it at the beginning
<hikiko> so I guess there's no need to do it again
<mlankhorst> well I think it's required for getting bus name, but meh
<tvoss__> mlankhorst, how am I supposed to test mm from qa-testing2? Seems like xserver-xorg-xmir in there is built against trunk
<mlankhorst> tvoss__: dpkg -i --force :P
<mlankhorst> it's what I did anyway
<hikiko> http://manpages.ubuntu.com/manpages/raring/man3/drmModeGetResources.3.html mlankhorst it doesnt seem to give any information on the version
<mlankhorst> hikiko: not really, but it only works if kms is available
<mlankhorst> if (!drm_core_check_feature(dev, DRIVER_MODESET))
<mlankhorst> 		return -EINVAL;
<hikiko> ok that check is done at mir initialization
<hikiko> so we don't need to do it one more time
<mlankhorst> yeah but I fear it might break things, so try testing at least once without plymouth
<hikiko> I am not using plymouth as far as I know mlankhorst
<hikiko> :s
<hikiko> how can I check if I use plymouth?
<mlankhorst> hikiko: it's part of the boot sequence
<hikiko> if you run unity I guess?
<mlankhorst> removing splash from linux cmdline options might be enough
<mlankhorst> no, plymouth is the boot splash thing
<hikiko> ah ok I have disabled the splash and everything the first day I installed ubuntu :D
<hikiko> so I don't have plymouth
<kgunn> mlankhorst: you still on ?
<tvoss__> jibel, ping
<jibel> tvoss__, pong
<hoodoowoo> balloons: are you handy?  I had a conversation with you yesterday, but I don't know if you're the one I should ping now (so please redirect as appropriate).  I'm eager to respond to a question, but I need a follow up to this question: https://bugs.launchpad.net/unity-system-compositor/+bug/1217262/comments/3
<ubot5> Launchpad bug 1217262 in Unity System Compositor ""sudo restart lightdm" always hangs/fails when using unity-system-compositor" [Undecided,Confirmed]
<balloons> hoodoowoo, perhaps you had a different nick yesterday? :-p
<hoodoowoo> balloons: heh, yes, different computer
<hoodoowoo>  /account/work rules, etc.
<hoodoowoo> frothnicator
<balloons> hoodoowoo, ok, I saw your thread
<hoodoowoo> the joys of being a friendly tester but without the development background to have no questions ...
<balloons> the ppa is frozen during testing, so you would have to build from trunk i'd guess.. or use the unstable ppa, if the team is building it and they think that is sane
<balloons> http://unity.ubuntu.com/mir/building_source_for_pc.html
<balloons> I'd defer to others in here on that
<tvoss__> mlankhorst, around?
<hoodoowoo> balloons: noted.  I'm now on the idea of automated testing.  Have y'all thought about have a script as part of the PPA that testers can execute?  I ask because though I tried to go through the test scenarios, I don't know exactly what the developers need to see.  A script could extract these automatically.
<balloons> hoodoowoo, there was an idea for a script that olli had, but time constraints led us here ;-)
<hoodoowoo> roger.
<hoodoowoo> balloons: from the outside, it seems like that script could be rather useful going forward.  Otherwise, you get stupid testers like me who don't know what their doing.  ;-)
<balloons> hoodoowoo, :-) Just testing it and giving a thumbs up or thumbs down is important
<balloons> automated tests are useful but they don't replace your experience, your machine, etc
<hoodoowoo> well, then, thumbs up for the work in general (was impressed by the KMS integration, and auto-detection of the VGA cable).
<balloons> and they aren't as smart as someone look at it
<balloons> thanks for testing :-)
<hoodoowoo> balloons: ah, I was looking at the fact that the devs (I assume y'all?) don't have access to every machine, but do know exactly what you need to see.  On the other hand, various testers (like me), have machines and configurations that you don't have.  Hence the idea for the test script that you write, but I run.  But gotcha.  Hope I was helpful.
<hoodoowoo> ... thumbs up for work in general ... thumbs down for ability to complete some of the test scenarios, etc.
<kgunn> hoodoowoo: thanks for testing....yeah, would've loved to get a bit more automated....but...clock killed us :)
<balloons> I'm not a dev, so I won't take any credit.. but I'm sure they are very happy to receive your praise.
<hoodoowoo> kgunn: roger.  I don't know Canonical's internal time table, other than the stage freezes.  But again, I stress "going forward".  On that note, I'm out.  Time for a tester to stop wasting your time.  Thanks very much for the hard work.
<tvoss__> okay, it becomes interesting
<bschaefer> kgunn, hey, got around to testing the u-s-c ppa and I get a black screen on boot :(, on ati 5670
<bschaefer> just with 1 monitor
 * bschaefer didn't find anything to crazy about the logs
<kgunn> bschaefer: ok...so purge that....get to a saucy only...then download & force install the xserver & x-driver from ppa:/mir-team/qa-testing2(not apt-get)
<kgunn> it should boot to single monitor fine
<bschaefer> kgunn, alright Ill give that a try!
<bschaefer> yeah, thats what i was wondering about...
<bschaefer> kgunn, but mir doesn't seem to like my ati card atm anyway
<bschaefer> when I try to run it natively
<kgunn> yeah...the guys updated the drivers on the problem platforms
<bschaefer> cool, but I think my problem is a bit different, its this gbm buffer failed to create (failing on a mmap)
<bschaefer> which I need to sill dig into the radeon.ko stuff in the kernel...
<bschaefer> kgunn, ill give it a try any way though, possibly something fixes it :)
<bschaefer> kgunn, well single monitor works fine on saucy with xmir soo thats good, ill attempt MM now...
<kgunn> drum roll (don't expect much)
<bschaefer> haha, well we shall see :)
<RAOF> Woo!
<RAOF> What fixed it for youL
<RAOF> ?
<bschaefer> RAOF, hmm well im not sure why xmir is working ... but not native mir?
<bschaefer> RAOF, as i've only ever had a problem with native mir
<RAOF> usc doesn't try to allocate a cursor :)
<bschaefer> RAOF, which is just a work around then :), cause I could get around that with native mir as well, but couldn't draw to a mir region...
<bschaefer> ill have to find sometime to do some digging into that problem
<bschaefer> got a fun error in x-0.log: X: ../../../../include/privates.h:123: dixGetPrivateAddr: Assertion `key->initialized' failed.
<bschaefer> and screen was black
<bschaefer> using xserver video ati, xserver from qa-testing2
<bschaefer> kgunn, ^
<RAOF> bschaefer: Oooh, urgh.
<RAOF> Why is your machine so odd :)
<bschaefer> idk...I usually use my laptop haha
<bschaefer> but its fired atm...
<bschaefer> RAOF, good for testing I suppose :)
<RAOF> kgunn: Do you happen to know the status of nouveau MM?
<bschaefer> or bad...depending on how you look at it
<bschaefer> grabbing these *.debs from qa-testing2... possibly I should have installed something else?
<bschaefer> xserver-common xserver-xorg-core xserver-xorg-video-ati xserver-xorg-xmir
<RAOF> bschaefer: Oh, you need xserver-xorg-video-radeon
<RAOF> bschaefer: xserver-xorg-video-ati is a wrapper that just calls -radeon.
<bschaefer> RAOF, let me try that!
 * bschaefer should have seen that based on the size of the ati one.. 25kb
 * bschaefer reboots
<bschaefer> awesome! Things seem to be working
<bschaefer> have a nice 640x480 resolution on both
<bschaefer> but no overdraw/underdraw on my hdmi monitor which is very nice
<RAOF> I suspect that trying to change the resolution at this point will cause sorrow.
<bschaefer> it wont even let me :), well I could force it...but
<bschaefer> sorrow sounds bad
 * bschaefer tires it anyway
#ubuntu-mir 2013-08-29
<bschaefer> RAOF, though whats strange is:
<bschaefer> http://paste.ubuntu.com/6038461/
<bschaefer> it has a XMIR-1 display added in?
<bschaefer> but not connected...
<bschaefer> annd yeah changing the res sends me back to lightdm
<bschaefer> RAOF, if you're interested in the stacktrace in my Xorg.0.log:
<bschaefer> http://paste.ubuntu.com/6038469/
<RAOF> Ta.
<RAOF> bschaefer: And, as usual, you can't get a proper trace out of that, can you?
<RAOF> bschaefer: OH! Did you get an apport crash report out of that?
<bschaefer> hmm
<bschaefer> RAOF, im not sure, I usually don't use apport :)
 * bschaefer checks
<RAOF> Because you can post-process that locally to get a symbolic backtrace, using apport-retrace.
<bschaefer> let me see if I can get a real backtrace...
<bschaefer> as that one is pretty useless :)
<bschaefer> RAOF, hmm I don't seem to have a *.crash file from today ... besides the hud service...
<RAOF> Delete any existing Xorg crash file, and then crash it again :)
<bschaefer> alright!
<bschaefer> RAOF, cool got a *.crash file, now to run it through apport...
<bschaefer> it doesn't crash very often though
<RAOF> Oh, it doesn't dependably crash when you change resolution?
<bschaefer> most the time it was changing the res, but lots of graphic problems
<bschaefer> nope!
<bschaefer> ill upload an image of what it looks like...but it looks baaad
<bschaefer> finally got a crash though
<bschaefer> RAOF, http://i.imgur.com/dKiZNKY.jpg
<bschaefer> when it does work
<RAOF> 404'd!
<bschaefer> :(
 * bschaefer tries a different site?
<bschaefer> RAOF, or possibly this: http://imgur.com/dKiZNKY
<RAOF> Whee!
<bschaefer> strange, o well but yeah, I think I saw similar rendering issue with other testers?
<bschaefer> but things are rendering fine when I don't force the res
<bschaefer> :(
<bschaefer> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
<RAOF> :(
<RAOF> bschaefer: There'll be a shiny new -ati to test in qa-testing2 shortly.
<bschaefer> sweet, I can give that run
 * bschaefer attempts the apport-retrace again...for the hell of it
<bschaefer> RAOF, i've also just realized I pulled the packages directly from qa-testing2, instead of adding that ppa...
<bschaefer> which im guessing means it can't find the correct packages for the sandbox...
 * bschaefer adds pps
<bschaefer> ppa*
<RAOF> bschaefer: That would be correct, yes.
<RAOF> bschaefer: You're looking for xserver-xorg-video-radeon 7.2.0-0ubuntu3+xmirMM4
<bschaefer> RAOF, the new one?
 * bschaefer just added the ppa, and is redoing the apport-retrace
<RAOF> Yeah. That's the one to test next.
<bschaefer> cool, ill test it out after this (hopefully) new retrace attempt
<bschaefer> hopefully successful*
<bschaefer> RAOF, stracktrace: http://paste.ubuntu.com/6038660/
<bschaefer>         pid = -1222160384
<bschaefer> doesn't like good :)
<RAOF> src_obj = {pitch = 1280, width = 3093165488, height = 3086817120, bpp = -1237450752, domain = 3093165488, bo = 0xb8560c28, tiling_flags = 3086729320, surface = 0xb63a06d6 <RADEONEXASetSharedPixmapBacking+70>}
<bschaefer> yeah I just saw that as well
<bschaefer> same with dest_obj
<bschaefer> dst_obj*
<RAOF> I believe that's fixed in MM4
<bschaefer> sweet, let me give that a run
 * bschaefer reboots
<bschaefer> RAOF, just to double check, just asserting that that crash ins't happening?
<bschaefer> after ~3 attempts no crash, but still have to reboot after the screen goes crazy :)
<RAOF> Hm.
<RAOF> Screen going crazy is not expected. :
<RAOF> :/
<bschaefer> RAOF, I could also be forcing the res in an odd way
 * bschaefer paste bin commands
<bschaefer> RAOF, http://paste.ubuntu.com/6038680/
<RAOF> Ok.
<RAOF> Huh.
<bschaefer> used: cvt 1280 720 to get the modeline
<RAOF> Why do you need --newmode?
<RAOF> That won't work :)
<bschaefer> RAOF, excellent, I just quickly looked up how to change the res using xrandr...
<bschaefer> RAOF, I should just have to do:
<RAOF> âxrandr -qâ should list the valid modes, then you can just xrandr --output XMIR-0 --mode $EXISTING_MODE
<bschaefer> xrandr --output XMIR-0 --mode 1024x768?
<bschaefer> alright, ill give that a try then
<bschaefer> RAOF, :( screen still went crazy....
<RAOF> Hm.
 * bschaefer checks logs for anything
<bschaefer> nothingis crashing though
<RAOF> Got dmesg / Xorg log?
<bschaefer> RAOF, hmm let me past the xorg log/dmesg but Its hard to read them with such a small screen :)
<RAOF> You should be able to just use pastebinit, right?
<bschaefer> yeah I can: http://paste.ubuntu.com/6038693/
 * bschaefer likes to be able to attempt to read them
<bschaefer> dmesg: http://paste.ubuntu.com/6038696/
 * bschaefer looks at the kern log
<RAOF> Ah. You haven't tried to change the mode yet?
<bschaefer> RAOF, ?
<RAOF> bschaefer: The xorg log doesn't seem to contain an attempt to change the mode from the default.
<bschaefer> RAOF, hmm I wonder if I grabed the wrong one?
<RAOF> Mayhap.
<bschaefer> i used Xorg.0.log.old...assuming it was the last one
 * bschaefer attempts the mode change again looking at the current time...
<bschaefer> RAOF, hmm my Xorg has the correct time, but I don
<bschaefer> dont see it trying to set it...
<RAOF> That is odd.
<bschaefer> i have a bunch of extra bytes at the end of the file though...
<duflu> RAOF: Those little horizontal lines with intel+XMir+bypass, they seem to be on damage rect boundaries... ?
<RAOF> duflu: Not really, no?
<bschaefer> RAOF, which when I try to open it in gedit says there an encoding error...I wonder if it was failing to get logged to...
<bschaefer> lots of: \00
<RAOF> bschaefer: Hm, maybe?
 * bschaefer has no clue how that would happen
<bschaefer> RAOF, should I try turning all the debugging messages back on?
<bschaefer> and try to get some logs from the kern.log?
<RAOF> Hm, maye?
<bschaefer> wouldn't hurt at this point at lease...
<bschaefer> RAOF, would setting the drm.debug thing even work for this?
 * bschaefer also forgot the path to it...and does't have the log saved
 * bschaefer found it..
<bschaefer> well wouldnt hurt
<bschaefer> RAOF, yay the Xorg log is showing it now...
<RAOF> Woot!
<bschaefer> http://paste.ubuntu.com/6038776/
<bschaefer> but no errors in it...
<bschaefer> at lease that I see :)
 * bschaefer wonders if its having a problem cause one monitor is still the 640x480 res
<bschaefer> as things are mirrored atm
<RAOF> Hrm. Stupid qa-testing2 ppa building against the archive...
<RAOF> Hm. Ok, that looks pretty standard.
 * RAOF wonders if he can trigger this on his radeon.
<bschaefer> I wonder if its cause im setting a mirror monitor to a res that is not supported by the other
<bschaefer> the only one that overlaps is 640x480
<bschaefer> RAOF, well im going to head off for the night and eat some dinner, hopefully its reproducible else where :)
<RAOF> Yeah.
<RAOF> Have nice dinner!
<bschaefer> thanks! If I find any other info Ill poke you tomorrow
<bschaefer> or if you want me to test anything else out
<RAOF> Yay! Reproducible locally!
<kgunn> RAOF: did anyone tell you?....nouvea w/ latest drivers from qa-testing2 will boot to usable unity single screen
<RAOF> kgunn: But not more than one screen?
<kgunn> RAOF: nope....but gagnon tried with standalone X and it wasn't happy
<kgunn> i'm convinced nouveau is just a mess
<kgunn> before we stirred the pot
<duflu> robert_ancell: I only heard underwater mumbles half the time :/
<robert_ancell> duflu, awesome
<robert_ancell> :)
<duflu> robert_ancell: So which should I expect to be landing first? bypass or timerless?
<robert_ancell> duflu, probably bypass
<duflu> OK, removing one of the timerless branches then
<robert_ancell> duflu, does that make it easier to land timerless?
<duflu> Yes
<tvoss__> good morning
<tvoss__> RAOF, ping
<RAOF> tvoss__: Pong.
<robert_ancell> bbiab
<tvoss__> kgunn, ping
<kgunn> tvoss__: pong
<mlankhorst> morning
<RAOF> mlankhorst: Speak of the devil!
 * robert_ancell -> dinner etc, will be back later
<duflu> Oh multi-monitor is so much less annoying when none of them are analog VGA
<RAOF> Yeah, I'm trying to rid the world of VGA interfaces.
<duflu> Especially when my oldest monitor misdetects the VGA signal most of the time
<RAOF> You know, it'd be much easier to debug bypass if my radeon card didn't work perfectly with it.
<duflu> RAOF: Good to hear, kinda. I'm working on a setup to try radeon+saucy here too
<duflu> Oh, new saucy wallpapers?!
<duflu> Ahem, wallpapers for saucy
<RAOF> To the multi-monitor-bypass-testotron!
<RAOF> Heh.
<duflu> RAOF: Do you have a solid indication it is bypassing on radeon? Like performance?
<duflu> ... lack or mouse lag?
<RAOF> Ok. As long as you don't mind waiting a couple of frames for all your rendering to appear, multimonitor+bypass on Intel wors.
<RAOF> *works.\
<duflu> RAOF: Yeah that was true without bypass too, but I think the out-of-order-ness is worse with bypass
<RAOF> Oh, no.
<RAOF> This isn't out of orderness.
<RAOF> And I'm *not* seeing the same out-of-order problems. At least at the moment.
<RAOF> I'm talking about the rendering "teleporting in" in horizontal lines.
<duflu> RAOF: Yeah saw that (less so) with intel bypass single monitor too
<RAOF> Right.
<duflu> Annoyingly, only on the XMir surface
<mlankhorst> RAOF: did you fix ati? :P
<RAOF> mlankhorst: By setting the window pixmap of all the children of the root window that share the root window's pixmap.
<RAOF> I presume by "fix ati" you're talking about mode changing here?
<mlankhorst> ytes
<RAOF> Yeah.
<RAOF> Did nouveau work with modechanges? I'd expect it to suffer the same problem.
<duflu> brb
<mlankhorst> RAOF: did you upload a version bump to mir so it's easier to test? :p
<RAOF> No; I'll do so now.
 * mlankhorst slowly wakes up
<RAOF> mlankhorst: Got any idea what might cause this: http://ubuntuone.com/08RzJfgwUfZd1LigIS16Mh particularly fun brand of misrendering?
<mlankhorst> RAOF: forgetting to flush maybe?
<RAOF> That thought occurred
<mlankhorst> try damaging the whole screen and see what happens..
<mlankhorst> hm compiz already should, though
<duflu> mlankhorst: I tried that. No change
<mlankhorst> duflu: might be a driver bug or something :P
<RAOF> I suspect it might be a cache-coherency problem that ickle warned me about.
<duflu> Does intel need/use the "dirty/clips" feature of DRM? I thought it was only vmware that did
<RAOF> fbc might interact with that?
<mlankhorst> oh is it intel?
<RAOF> Yad
<duflu> Yes
<RAOF> Yah
<mlankhorst> yeah probably something like that
<duflu> RAOF: What was the cache coherency warning?
<duflu> brb
<RAOF> mlankhorst: xserver MM16 awaits your attention
<mlankhorst> what do you want me to test?
<RAOF> nouveau MM
<RAOF> If that didn't work before.
<RAOF> duflu: I forget the details, but I half-remember that there was special cache invalidation magic needed when doing things to the framebuffer that mesa doesn't do?
<duflu> RAOF: AFAICT, we're not doing anything Mesa doesn't do. I keep searching the Mesa sorce
<duflu> But I'm probably wrong
<RAOF> We'll, we're calling drmModeAddFB and drmModePageFlip, which mesa doesn't do :)
<duflu> RAOF: Oh just SetCrtc?
<RAOF> Mesa doesn't do that, either.
<duflu> RAOF: ??
<RAOF> Mesa doesn't do any of the modesettingy stuff; it leaves that for X to do.
<RAOF> And X leaves that for the DDX to do.
<RAOF> Except we don't let the DDX do what it was doing, and we do our own thing.
<duflu> RAOF: So we need to copy some magic from DDX into Mir?
<RAOF> Maybe
<duflu> The old DDX
 * duflu now has new source to examine
<duflu> BTW, my experiment to get saucy on radeon has now failed
<duflu> The machine fails to boot for new unknown reasons
<mlankhorst> RAOF: hm could you MIR libjsoncpp? :P
<mlankhorst> build-dep for llvm-toolchain
<RAOF> mlankhorst: I can't promote it myself; is there a MIR already filed?
<mlankhorst> it hm don't know if there is, but it was always a build-dep for llvm, but llvm-toolchain-3.3 had some package modifications to use an external copy
<RAOF> How did llvm build before if it always build-depended on a package not in main?
<mlankhorst> it had an internal copy :P
<RAOF> Heh
<mlankhorst> I suppose I could make a MIR for it, but I feel it's a bit of overkill
<mlankhorst> bah it moved llvm-toolchain-3.3 back to universe
<tvoss> duflu, one thing I noticed yesterday: we never "release" the BufferObject for the scanout bo
<duflu> tvoss: I thought  there was a devious and non-obvious path where it was released. Will check again. It's certainly different to the default front_buffer as far as GBM is concerned
<tvoss> duflu, as I understand it, the buffer object is never released until destruction
<duflu> tvoss: Oh. Yes we do delete it correctly. And the "release" call would be erroneous (and crash from memory) on the bypass buf. Because that applies to gbm surface-specific bo's
<tvoss> duflu, might be good to have a different type to wrap the buffer object, then. But that's for later
<duflu> tvoss: You're only meant to gbm_surface_release_buffer on things which come from gbm_surface_lock_front_buffer
<tvoss> duflu, one other thing: if a bypass buffer is provided, we never eglswap
<duflu> tvoss: Correct! Bypass means no GL-anything!
<tvoss> duflu, ack
<tvoss> duflu, if only that was documented somewhere ;)
<duflu> tvoss: Fair point. But it's interesting when you realise you can composite without any GL
<RAOF> Well, we're not actually compositing anything.
<duflu> True
<duflu> Kinda
<RAOF> If we used overlays then we *could* be compositing and bypass at the same time.
<duflu> ... it opens up doors like Mir supporting non-GL platforms in a limited fashion
 * tvoss points out that we have a weird cache invalidation thingy to fix first
<duflu> RAOF: Already with the hardware cursor (works over bypass)
<duflu> BTW, I think I observed a noticeable improvement with timerless on radeon with dual monitors. I think...
<sil2100> Hi everyone
<duflu> sil2100, morning
<sil2100> Did all the branches needed for bypass and multimonitor get merged into trunks already?
<sil2100> Of mir and unity-system-compositor?
<duflu> sil2100: Not yet. Happening now
<tvoss> sil2100, I will keep you posted as merges are happening
<tvoss> sil2100, makes sense?
<sil2100> duflu: can you poke me when that's done? And which components have changes that need releasing? Since I'd like to get it out today
<sil2100> tvoss: thanks!
<duflu> sil2100: Yep
<hikiko> hi, question: what's the drm interface version? is it the library version or something else?
<duflu> hikiko: I was wondering that myself. Seems unrelated to anything. And I was told that it doesn't get updated at all
<hikiko> and it causes a bug in nested mir
<mlankhorst> hikiko: no it's checking if dri2 is supported or not
<mlankhorst> that's all
<hikiko> so, if I want to fix the bug on nested mir (which is: I don't have permission to set the drmInterfaceVersion to the device I want to use - which is usable) I have to find another way to check if dri2 is supported?
<mlankhorst> just assume it's supported tbh
<mlankhorst> did you try killing that check entirely?
<hikiko> yes and it works fine
<hikiko> if there's no other part of mir that uses it
<hikiko> then I ll just do an mp
<hikiko> mlankhorst, duflu could you review it? https://code.launchpad.net/~hikiko/mir/mir.fix-drm-version/+merge/182830
<hikiko> (i just removed the check)
<duflu> Will do
<hikiko> thanks!
<duflu> hikiko: Could that explain the strange DRM open failures some nvidia users get?
<mlankhorst> duflu: that's.. more complicated
<mlankhorst> but link a bug?
<duflu> mlankhorst: bug 1206633
<ubot5> bug 1206633 in Mir "mir doesn't start "Error opening DRM device" on nVidia" [Medium,Triaged] https://launchpad.net/bugs/1206633
<hikiko> that's the error I was getting too
<hikiko> but I don't know if that change solves it (I have an intel)
<mlankhorst> some calls require DRM_MASTER, but meh
<duflu> Which we have, maybe not soon enough?
<mlankhorst> probably not then
<alan_g> \o/ bypass has landed
<hikiko> :D
<mlankhorst> and there can only be 1 master
<mlankhorst> this is legacy from dri1 :/
<mlankhorst> duflu: it's complicated, there used to be a race between xorg-server, lightdm and plymouth, where lightdm could not detect plymouth..
 * duflu ducks
<mlankhorst> I think if you start xorg-server before opening the drm fd in mir, you get the same kind of symptoms for a race..
<duflu> alan_g: I'm fixing timerless now. I don't care what the variables are called. *count/no/num ... pick one and I'll change them all
<duflu> hikiko: You got the same exception with errno==0 ?
<alan_g> duflu: I'm not blocking on the names - and *_sequence_number is a mouthful
<hikiko> no, with errno = 13 or so let me see
<duflu> hikiko: Different bug. But it exists :)
<hikiko> a yes the Success
<hikiko> let me run it one more time
<hikiko> :P
<duflu> hikiko, Success or errno 13?
<alan_g> duflu: *seq_no?
<hikiko> I got the 13
<hikiko> Permission denied
<hikiko> but I think that at some point I got the success as well :S while debugging
<hikiko> if I leave the check I get the 13
<duflu> alan_g: That's the one option I disliked. It is actually a count or frame number without gaps (on at least one or more monitors). So I think count/no/num is better
<mlankhorst> hikiko: can you do lsof /dev/dri/*
<hikiko> it doesnt return anything
<hikiko> plymouthd  189 root   12u   CHR  226,0      0t0 8971 /dev/dri/card0
<hikiko> Xorg      1988 root  mem    CHR  226,0          8971 /dev/dri/card0
<hikiko> Xorg      1988 root   10u   CHR  226,0      0t0 8971 /dev/dri/card0
<hikiko> Xorg      1988 root   42u   CHR  226,0      0t0 8971 /dev/dri/card0
<hikiko> mir_demo_ 8375 root  mem    CHR  226,0          8971 /dev/dri/card0
<hikiko> mir_demo_ 8375 root    9u   CHR  226,0      0t0 8971 /dev/dri/card0
<hikiko> mir_demo_ 8375 root   10u   CHR  226,0      0t0 8971 /dev/dri/card0
<hikiko> ouch
<hikiko> sorry
<hikiko> ://
<hikiko> it was huge
<alan_g> duflu: sync_counter?
<mlankhorst> hikiko: yeah you still had some stuff open, can only run 1 at the same time
<duflu> alan_g: I think frame number is more self explanatory
<hikiko> mlankhorst, it seems that I have plymouth running after all :)
<mlankhorst> indeed!
<alan_g> duflu: ok [current|local|global]_frame_number
<duflu> tvoss: Do you want timerless done before we declare MM feature complete?
<duflu> It's not really critical
<tvoss> duflu, let's get it in if it does not break us
<duflu> tvoss: Still working on fixing it tho
<hikiko> mlankhorst, what do you mean I can only run one at time? only one can use the drm device at a specific time? (which means that I can't set the version to a device that is used although I can use the device?)
<tvoss> duflu, don't block on it
<hikiko> I dont know if what I wrote makes sense :p
<mlankhorst> hikiko: there can only be 1 master
<hikiko> and when you set the version you have to be the master?
<mlankhorst> yes
<mlankhorst> and if nobody has the device opened, you automatically become master
<duflu> In that case, sil2100, bypass and MM are fully landed in lp:mir. There is no new version/tag yet. Usually robert_ancell does that
<hikiko> then ok it's normal that only nested mir has the error
<robert_ancell> yeah, I tag on mondays
<hikiko> because in my case I am not and I don't want to become the master
<robert_ancell> duflu, you haven't landed MM right?
<duflu> robert_ancell: I said lp:mir where it landed weeks ago
<robert_ancell> oh, right
<mlankhorst> hikiko: yeah if you get the fd from someone else, presumably you're already authenticated. it's a silly concept :P
<duflu> sil2100: But ask RAOF when the XMir parts are landing...
<alan_g> hikiko: ( mlankhorst ) the fd should come from the hosting Mir session
<duflu> alan_g: Actually I just noticed freezing the count doesn't always freeze rendering. It probably should. So fixing...
<sil2100> duflu: ok, anything else needs landing? Anything in u-s-c?
<duflu> robert_ancell, ^
<hikiko> alan_g, the host uses the drm device and then I create a drm device to create the gbm device and allocate a gbm buffer (because gbm depends on drm) but it's the host that renders on the screen and is the master
<robert_ancell> sil2100, lp:unity-system-compositor and lp:lightdm are all up to date
<hikiko> so while my device can be used I dont have the permission (since I am not a master) to set the version
<alan_g> hikiko: you can get a pre-authorised from mir_connection_drm_auth_magic()
<hikiko> yes
<hikiko> but I don't want to do this
<hikiko> because I need to see on the screen
<hikiko> (host mir does the rendering/vt etc)
<hikiko> what does mir_connection_drm_auth_magic() do exactly?
<mlankhorst> hikiko: authenticate
<mlankhorst> which involves guessing a 32-bit integer iirc
<hikiko> yes, in nested mir I only authenticate when I need to use the display
<hikiko> and I guess that's correct, because if nested mir is the master then the host mir won't render anymore
<hikiko> and I will see a freeze
<hikiko> isnt it?
<mlankhorst> authenticate != master
<hikiko> then authentication doesn't solve the problem with the interface version
<RAOF> mlankhorst: Did you get to test MM+nouveau?
<hikiko> the initial problem was that I couldnt call the drmSetInterfaceVersion without being the master
<alan_g> the host remains master, but gives the nested the fd it needs. The host sets the interface version nested
<alan_g> nested doesn't need to
<mlankhorst> RAOF: i was busy with llvm and tjaalton's stuff :P
<RAOF> mlankhorst: Yeah, thought so.
<hikiko> alan_g, the problem is that in drm helpers we call the setInterface when we open the drm device
<hikiko> which is before authentication anyway
<hikiko> and we use that code to check if the device we already opened
<hikiko> is "usable"
<hikiko> sorruy meeting brb
<mlankhorst> hikiko: even authentication is not enough, requires master
<mlankhorst> an authed client is something like glxgears, it can't touch the output mode or anything, but it can render and allocate buffers
<hikiko> currently I do: open_drm_device
<hikiko> amd then authentication
<alan_g> mlankhorst: that's what I understand hikiko needs for nested. It is "just" an auth client
<mlankhorst> indeed
<mlankhorst> but drmSetVersion requires master :P
<mlankhorst> so just kill it
<alan_g> hikiko: don't do that - just get the fd from the master
<hikiko> yes :)
<hikiko> that's what I did
<mlankhorst> ok so erm nouveau mm testing..
<hikiko> alan_g, I cant get the fd from the master
<hikiko> the master must use it's own gbm device
<hikiko> because it might have other clients instead of mir on mir
<RAOF> hikiko: Aren't you getting the drm fd from the PlatformPackage?
<hikiko> PlatformIPCPackage?
<RAOF> MirPlatformPackage, from mir_connection_get_platform
<hikiko> no because I don't get the platform
<hikiko> I create a native platform
<hikiko> that has it's own buffers
<hikiko> I don't use mir buffers
<RAOF> And you can't get the platform first?
<RAOF> Because mir_connection_get_platform will give you a fully armed and operation drm fd that you can create a gbm_device from.
<RAOF> And then allocate buffers to your heart's content.
<alan_g> RAOF: that's exactly what we want
<hikiko> yes but the design we did was to have a native platform etc alan_g
<alan_g> hikiko: What has that to do with this?
<alan_g> The native platform needs an FD. mir_connection_get_platform (I had the wrong function before) gets that FD
<mlankhorst> RAOF: single monitor works :P
<tvoss> RAOF, what changes in Mir do you need landed for mm?
<RAOF> tvoss: NOne
<hikiko> yes just checking the MirPlatformPackage struct alan_g
<mlankhorst> hm didn't crash on hotplug
<RAOF> mlankhorst: And is displaying roughly correctly?
<hikiko> RAOF, will this platform package give me the drm device of the host mir?
<mlankhorst> RAOF: it would seem so
<RAOF> mlankhorst: SHIP IT!
<hikiko> because this is not what I want
<RAOF> hikiko: No, it won't give you the same drm fd that the host mir has open.
<mlankhorst> RAOF: overlapping screen works correctly too
<RAOF> hikiko: It will give you a drm fd that you can use for your own rendering/buffer allocation/etc.
<mlankhorst> as does a hole between the screens :P
<RAOF> OOoh, thorough!
<hikiko> RAOF, also will it be the master?
<RAOF> hikiko: No, but it will be authenticated.
<mlankhorst> RAOF: well those would be the main usecases anyway..
<hikiko> cool then :)
<RAOF> mlankhorst: And then it doesn't notice hotunplug? :)
<mlankhorst> RAOF: no idea, I tried disabling both screens for fun, didn't work as intended :P
<mlankhorst> main screen turn on
<RAOF> :)
<hikiko> +question how is this fd allocated? if we call the open_drm_device in gbm_display_helpers we have the same problem :)
<hikiko> I think that just removing the check is the best
<mlankhorst> RAOF: so it seems the case of 0 monitors doesn't work correctly :p
<mlankhorst> when doing xrandr --output XMIR-* --off for all outputs
<alan_g> hikiko: if gbm_display_helpers doesn't do what you need don't use it
<RAOF> mlankhorst: I'm a bit surprised that doesn't work, but that's an edge case I'm happy to fix in post :
<RAOF> :)
<alan_g> hikiko: or give it the function you do need
<duflu> I'm sure someone logged a bug for that yesterday
<mlankhorst> looks like xorg didn't crash either :O
<hikiko> alan_g, I ll just write a second open_drm_device that doesnt have the check of this branch: https://code.launchpad.net/~hikiko/mir/mir.fix-drm-version/+merge/182830 then and use it
<mlankhorst> oh right didn't test normal shutdown yet
<mlankhorst> gasp, no crash
<alan_g> hikiko: ack
<mlankhorst> now the same, but with valgrind >:O
<RAOF> mlankhorst: My code laughs at your petty memory-correctness tools!
<mlankhorst> or does it? DUN DUN DUUN
<RAOF> hikiko: It's still not clear to me why you need to open_drm_device at all?
<mlankhorst> RAOF: haha i broke things, lets see if the panda has some debug output on serial console :P
<hikiko> RAOF, I wont use mir buffers
<hikiko> I will use native buffers
<hikiko> gbm and android
<mlankhorst> RAOF: bahaha
<mlankhorst> [  292.862839] nouveau E[  PGRAPH][0000:01:00.0] DATA_ERROR [XY_OUT_OF_BOUNDS] ch 3 [0x003fb4e000 unity-system-co[1120]] subc 2 class 0x9039 mthd 0x0300 data 0x00100000
<hikiko> so in order to allocate a gbm buffer I need a gbm device which needs a drm device
<mlankhorst> RAOF: seems to happen a few times during resizing
<RAOF> hikiko: Yeah, but you *get* a drm device for free from the hosting Mir.
<hikiko> RAOF, the problem is this check here:
<hikiko> https://code.launchpad.net/~hikiko/mir/mir.fix-drm-version/+merge/182830
<mlankhorst> RAOF: so har har har har har, I win :D
<hikiko> which is inside open_drm_device
<hikiko> so before you authenticate
<hikiko> you have to drmSet..
<RAOF> hikiko: Yeah, but you don't need to call open_drm_device at all.
 * duflu doesn't understand what mlankhorst wins
<hikiko> that's what I asked you, if I call the mir_connection..
<hikiko> it wont call the open_drm_device at some point?
<RAOF> All that open_drm_device does is get a drm fd; and you get the correct, pre-authenticated drm fd from mir_connection_get_platform
<RAOF> hikiko: No, not on the nested server side.
<hikiko> in any server's side
<hikiko> the 2nd drm device allocated
<RAOF> It *will* call get_authenticated_fd on the host's side.
<hikiko> will have the problem
<hikiko> yes
<mlankhorst> duflu: RAOF may have won on memory validation, but he definitely LOST on gpu validation ;)
<hikiko> then ok you ll get the bug in the host racarr|desert
<RAOF> But you can get as many authenticated fds as you want.
<hikiko> sorry
<hikiko> RAOF,
<hikiko> RAOF, I know the prob is that you cant run drmSetInterfaceVersion
<hikiko> without being the drm_master
<RAOF> Right. But the host Mir *is* drm master.
<hikiko> since that is called before the drm authentication
<hikiko> question:
<RAOF> And the host Mir opens the fd for you, and then gives the fd over IPC.
<hikiko> drm master is mir or a device?
<RAOF> drm master is a state that a drm fd can be in. It basically means you get to modeset.
<RAOF> (Among other things)
<hikiko> when you call SetDrmMaster you pass an fd?
<hikiko> let me check
<RAOF> I'm not sure why you're caring about drm master?
<RAOF> The nested compositor is not going to have access to a drm master fd, nor does it need one.
<hikiko> RAOF,
<hikiko> host mir starts
<hikiko> it opens fd0
<hikiko> it automatically becomes the master because it s the first device isnt it?
<hikiko> and then you call setInterfaceVersion
<hikiko> then opens fd1
<hikiko> it's not the master
<hikiko> you have to call setDrmMaster if you want it to be the master
<hikiko> but before that
<hikiko> in open_drm_device
<hikiko> you call setInterfaceVersion
<hikiko> for which you have no permission
<hikiko> because you are not the master
<hikiko> thats the problem
<alan_g> hikiko: didn't we already solve that?
<alan_g> <hikiko> alan_g, I ll just write a second open_drm_device that doesnt have the check of this branch: https://code.launchpad.net/~hikiko/mir/mir.fix-drm-version/+merge/182830 then and use it
<hikiko> alan_g, yes but RAOF asked which is the problem
<tvoss> hikiko, I don't think we should call setInterfaceVersion in the nested compositor then
<mlankhorst> which is what I said :P
<hikiko> tvoss, that's what mlankhorst said and initially I did this MP because I thought that for the reason I wrote we dont wont it on mir as well
<hikiko> https://code.launchpad.net/~hikiko/mir/mir.fix-drm-version/+merge/182830
<tvoss> hikiko, we want it on the outer-most mir
<hikiko> but ok I ll just remove it from the nested mur
<RAOF> alan_g, hikiko: The second open_drm_device should be: { MirPlatformPackage *pkg; mir_connection_get_platform(conn, &pkg); return pkg->fds[0]; }
<hikiko> ok then I ll just use another function in my branch
<alan_g> hikiko: go for it!
<hikiko> no RAOF because this way we ll get the device that the  host uses for rendering and we ll see nothing ... anyway :) I am going to do the change as alan_g says and then we improve it if there's something better :)
<duflu> sil2100: Got what you need? AFAIK the LP-based projects are fully landed at least
<RAOF> hikiko: That is how *all* (non-software) Mir clients work!
<RAOF> hikiko: That *will* allow you to render and allocate buffers correctly.
<alan_g> hikiko: we get an fd that allows us to allocate and use buffers - which is what we need
<sil2100> duflu: I think all is in now, had a talk with RAOF and I think it should all go smoothly
<hikiko> alan_g, RAOF then maybe better to give it a try
<duflu> Hah. Don't google saucy wallpapers
<RAOF> duflu: bypass is busted on intel; xmir is just exposing the bustedness by drawing enough to fill caches.
<duflu> RAOF: I don't understand that statement entirely
<RAOF> I'm talking with ickle in #intel-gfx; the horizontal bar corruption we see is stale cachelines.
<RAOF> This is why you see it more on multihead than single-head; you're less likely to overfill the cache there.
<duflu> RAOF: OK. What is "overfilling" and how is it avoided?
<RAOF> Intel-specific stuff.
<duflu> RAOF: Anything I can do for it in DRM userland?
<RAOF> We need to disable caching for scanout buffers, and then periodically call kgem_busy
<duflu> Sounds hackish
<RAOF> Yeah.
<duflu> That reminds me, I must improve the examples/ to help with that
<tvoss> RAOF, is there an example where that is done?
<RAOF> tvoss: grep xf86-video-intel for is_scanout; it's fairly widely distributed.
<tvoss> RAOF, ack
<tvoss> RAOF, where do we need to call kgem_busy? on the client or server-side?
<RAOF> Really, server side.
<RAOF> Since xmir is the only thing that reliably exposes this at the moment we could get away with doing it in xmir, but Unity8 will hit the same problems later.
<tvoss> RAOF, indeed
<tvoss> RAOF, is there a trigger that tells us when we should call kgem_busy?
<RAOF> Don't know
<tvoss> RAOF, ack
<RAOF> Although probably when submitting a batch buffer
<tvoss> duflu, do you file a bug?
<tvoss> RAOF, reading through the numerous commits mentioning kgem_busy right now
<duflu> tvoss: I don't think we have one yet. Because it never affected any PPA most people were testing, let alone trunk
<tvoss> duflu, ack
<tvoss> duflu, might make sense to note it down in a bug, though
<RAOF> Actually, we might not have to fix it in the server; fixing it in XMir *and* ensuring that Mesa does the right thing (which it should do) should fix it for both.
<RAOF> Which is significantly more tractable.
<tvoss> RAOF, indeed, we keep it driver specific with that, don't we?
<RAOF> Yes.
<tvoss> RAOF, otherwise the server would make _interesting_ assumptions
 * duflu votes for driver-specific hacks in driver-specific packages
<RAOF> Eh, we'd just need to have a DDX layer for Mir ;)
<duflu> :)
<RAOF> We'd have a intel-gbm platform, and a nouveau-gbm platform, andâ¦
<duflu> Eek
<duflu> tvoss, RAOF: Any objections to me logging off? I may yet cook dinner
<RAOF> duflu: None from my end?
<duflu> RAOF: On my desktop forcing two hardware surfaces to be placed on corresponding outputs (1920x1200) isn't enough to hit corruption/cache issues... !? But that's raring
<RAOF> duflu: What card?
<tvoss> duflu, feel free. Will call you in case of emergencies
<tvoss> ;)
<duflu> RAOF: HD2000 (i7-2600)
<duflu> RAOF: Also lp:~vanvugt/mir/eglapp-place-output
<RAOF> mlankhorst: Oh, where is your current xf86-video-nouveauL?
<hikiko> alan_g, if you have a moment could you review this: https://code.launchpad.net/~hikiko/mir/mir.init-native-gbm/+merge/182864 ?
<alan_g> hikiko: sure
<alan_g> hikiko: there are some MPs you can review too. ;)
<hikiko> I am going to pull them alan_g :)
<mlankhorst> RAOF: ..?
<RAOF> mlankhorst: Yours is the last upload to qa-testing2; I want to prepare that for the archive.
<mlankhorst> RAOF: oh didn't upload to github
<mlankhorst> just apt-get source it
<RAOF> Yeah, that's what I decided to do ;)
<mlankhorst> RAOF: can you include xserver-xorg-video-nouveau 1.0.9 too?
<RAOF> Sure.
<hikiko> alan_g, how can I run the mir tests?
<alan_g> hikiko: how long have you been on the project?!
<alan_g> hikiko: https://code.launchpad.net/~hikiko/mir/mir.init-native-gbm/+merge/182864/comments/414597
<tvoss_> RAOF, mlankhorst sent you some packages for testing purposes
<mlankhorst> yeah he should have them
<tvoss_> mlankhorst, on nouveau with usc running, could you try to run sudo glmark2-es2-mir?
<mlankhorst> sec, let me plug in a more.. stable card
<tvoss_> mlankhorst, ack :)
 * alan_g suddenly realises that we don't run the test suite for clang or android/armhf targets in CI
<mlankhorst> mir should really have -dbg packages
<mlankhorst> and usc too
<RAOF> No, not really.
<RAOF> Use the dbgsym packages.
<RAOF> *Debian* should have -dbgsym packages
<RAOF> Rather than manually constructing -dbg packages, like _animals_!
<mlankhorst> RAOF: in the ppa?
<RAOF> IIRC we've turned dbgsym packages on for the PPA.
<RAOF> Dear Xserver: your intermittently failing test suite is adorable.
<mlankhorst> RAOF: tell me where to find them, then :P
<kgunn> RAOF: remember i told you there would be new ways for X to annoy you
<RAOF> mlankhorst: I think you need to add the main/debug component to sources.
<RAOF> mlankhorst: Enjoy your shiny new nouveau 1.0.9
<mlankhorst> ah
<mlankhorst> do all ppa's have that?
<RAOF> Only those that have dbgsym packages enabled, sadly.
<RAOF> Probably for space reasons?
<RAOF> I don't know.
<mlankhorst> probably
<RAOF> But PPAs are space-limited *anyway*
<RAOF> We should totally build dbgsym packages *everywhere*
<mlankhorst> except we don't
<RAOF> should implies don't :)
<RAOF> Anyway, sleepy time!
<mlankhorst> nn
<tvoss_> RAOF, good night and get well soon
<mlankhorst> interesting, I'm hitting a bug in vblanking somewhere
<mlankhorst> probably
<tvoss_> mlankhorst, with my testing packages
<mlankhorst> I'm not sure what's causing it yet, but it seems some event is not being sent, ever ;P
<tvoss_> mlankhorst, interesting
<mlankhorst> hm might be a hang, bah
<mlankhorst> ok other card
<tvoss_> mlankhorst, ;)
<mlankhorst> >:(
<mlankhorst> there seems to be a memory corruption affecting all cards, but I don't know how
<kgunn> hikiko: ping
<hikiko> kgunn, hi
<mlankhorst> wow..
<tvoss_> mlankhorst, ?
<mlankhorst> I may have found my nouveau issue, lets find out..
<mlankhorst> hm no, still no closer :/
<mlankhorst> tvoss_: do you have a normal glmark too? :P
<tvoss_> mlankhorst, normal as in? :)
<mlankhorst> x11
<tvoss_> mlankhorst, it installs the usual x glmark2 as well
<tvoss_> mlankhorst, should be part of the package
<mlankhorst> tvoss_: not really, only contains glmark2-mir
<mlankhorst> and glmark-es2-mir
<tvoss_> mlankhorst, okay, recompiling packages
<tvoss_> mlankhorst, thanks for testing :) found the issue btw
<mlankhorst> hehe np :P
<mlankhorst> btw does it matter if xorg runs in usc or not?
<mlankhorst> as opposed to not running at all
<sil2100> tvoss_, kgunn: hi guys, can you confirm if everything landed as needed (in -proposed at least)?
<tvoss_> sil2100, ack
<sil2100> tvoss_, kgunn: related to mir and the two features
<mlankhorst> oh btw mesa 9.2 landed now
<tvoss_> mlankhorst, wow, you love living on the edge, don't you? :)
<tvoss_> mlankhorst, in archive or in proposed?
<mlankhorst> tvoss_: proposed
<mlankhorst> and now main it seems :P
<tvoss_> mlankhorst, ack
<mlankhorst> so right in time for feature freeze this time
<kgunn> sil2100: yes
<mlankhorst> tvoss_: hey last release we landed 9.1 right before final freeze
<kgunn> hikiko: i just realized i'm on the hook for a uds session
<hikiko> :)
<hikiko> no problem kgunn
<mlankhorst> unfortunately I cna't make any session this week, g2g :/
<kgunn> hikiko: oh...wait...i was wrong...top of the hour....we're still on
<jono> tvoss_, hey
<jono> so the composite bypass lands today?
<tvoss_> jono, yup
<smartboyhw> tvoss_, is Mir now already in ubuntu-desktop meta packaage?
<tvoss_> smartboyhw, not sure, need to check :)
<tvoss_> jono, http://samohtv.wordpress.com/2013/08/29/mir-xmir-performance-in-13-10/
<smartboyhw> :)
<jono> tvoss_, does that include MM?
<tvoss_> jono, the post? no: that's only addressing bypass
<tvoss_> jono, I think we need some fixes for mm before we want to blog about it
<jono> tvoss_, no I mean is MM in the archive?
<jono> as part of FF?
<tvoss_> jono, yeah
<jono> ahhh awesome
<olli> smartboyhw, no, it will need to be in main first before being pulled in as default
<ricmm> tvoss_: ping
<tvoss_> ricmm, pong
<ricmm> tvoss_: where does Mir stand re: resizing/moving surfaces?
<tvoss_> ricmm, we don't have it right now
<ricmm> is there a plan for this? short-term I mean
<tvoss_> ricmm, not really, would be great if we can live a week without it
<ricmm> not sure how possible that is going to be with the OSK
<ricmm> we will try today, but not sure
<arsson> latest updates makes my cursor freeze in lightdm with nouveau?
<RAOF> arsson: Updates from where?
<arsson> RAOF: basic no ppa
<RAOF> arsson: :(
<RAOF> arsson: And you're presumably using unity-system-compositor+XMir? Does VT switching away and then back unfreeze the cursor?
<robert_ancell> RAOF, lp:~robert-ancell/mir/drop-focus-on-vt-switch seems to work with test clients and drops focus when you VT switch away from them. It has a graphics lock-up as described in the MP, but you can work around it
<robert_ancell> It should be good enough to start the XMir side of things
<RAOF> robert_ancell: Sweet!
<arsson> i went VT and removed u-s-c and now everything is workin
#ubuntu-mir 2013-08-30
<robert_ancell> brb
<RAOF> arsson: Did you restart lightdm?
<RAOF> If not, you'll still be running unity-system-compositor+XMir, and you'll have hit the bug where usc stops rendering for no obvious reason.
<arsson_> Sorry i use huawei stick and it constantly disconnect
<bschaefer> RAOF, hey, what were the functions I should be looking at in radeon.ko? (if you know off the top of your head)
<bschaefer> as im just getting to digging through them, and ill have the weekend to poke around as well :)
<RAOF> bschaefer: You'd be looking at create_dumb and map_dump
<RAOF> bschaefer: You'd be looking at create_dumb and map_dumb
<bschaefer> RAOF, awesome, thanks!
 * bschaefer didn
<RAOF> They might not be called that, but they'll be something like that.
 * bschaefer didn't have the logs being saved...
<bschaefer> RAOF, and they are getting called through mmap, from mesa?
<RAOF> You can also chase them through drm_drv.c; work out what radeon hooks up to those ioctls.
<bschaefer> to see where its getting the offset from?
 * RAOF forgets where it's getting the offset from.
 * bschaefer should also dig through how each of these things are connected
<bschaefer> well  more about digging through the ioctls to figure out where a possible incorrect argument could be generated
<bschaefer> so the 2 functions i should dig through from the top would be drmIoctl, and mmap
<RAOF> Ah, yeah.
<bschaefer> cool, thanks! (i have logging set on now so I can revisit this conversation :)
<RAOF> create_dumb and map_dumb are what you're fater.
<bschaefer> cool, yup those are in mesa, but ill have to dig to where my card is setting things up as well...cause it has to be with the evergreen family, or possibly just the redwood ones
<bschaefer> (where my card == where the driver)
<bschaefer> RAOF, also, any luck reproducing the monitor issue on your ATI machine?
<RAOF> bschaefer: The resolution change thing? Yeah, it's fixed.
<bschaefer> RAOF, sweeet! what was the issue?
<bschaefer> if its not tooo complicated haha
<RAOF> bschaefer: More than just the root window uses the screen pixmap as its backing; so there was a valid new screen pixmap and root window that XMir was copying out of, but we hadn't fixed up other pixmaps, such as the one that Compiz renders into.
<bschaefer> so one was trying to render to the wrong size? but cool!
 * bschaefer goes to read the branch more or less
<RAOF> They were totally disconnected.
<RAOF> Compiz was rendering into one pixmap, XMir was copying out of another.
<bschaefer> oo, so it was just copying garbage pixels/data, while compiz was rendering into a pixmap that wasn't being drawn
<RAOF> Yeah.
<bschaefer> well know I know what that looks like haha
<RAOF> Hm. Do we have any guarantee about ordering of messages at all?
<RAOF> Specifically - if I'm a client with more than one surface (like, say XMir), and focus switches from one of my surfaces to another, what are the states that I can see?
<RAOF> Can I see âboth of my surfaces are focusedâ? Can I see âneither of my surfaces are focusedâ?
<RAOF> On the server side we guarantee that the two states are âsurface A is focused, surface B is unfocusedâ and âsurface B is focused, surface A is unfocusedâ; are there any similar guarantees on the client side?
<duflu> RAOF: That's why I rejected the focus notification design (which landed)
<RAOF> duflu: Ah. That wasn't obvious to me from your comments.
<duflu> RAOF: Yeah, but it's a natural side effect from the concerns I was raising
<duflu> It landed, but I think still needs rewriting
<RAOF> True. Just not a side effect I actually thought of.
<duflu> RAOF: You can heuristically make a good guess of which surface has focus. But I suggest logging it as a bug. We need a definitive "one focus message" relative to the connection/session. Or a get_focused_surface
<duflu> You could just ignore all the unfocus messages and take the focus messages in order...
<RAOF> Unless you want to know when *none* of your surfaces are focused.
<duflu> RAOF: if (focused_surface_id in (any of mine)) ?
<RAOF> I'll get two events.
<RAOF> One is "surface A lost focus"
<RAOF> Another is "surface B gained focus"
<duflu> RAOF: Just ignore the lost focus messages I guess. Take the gained focus messages in order and assume it's impossible to have nothing focused
<RAOF> But it's explicitly possible to have nothing focused.
<duflu> Yes, I just realized :(
<RAOF> This is not something that should actually cause a problem for me, just interesting.
<RAOF> Is there a standard C atomic ops library in main?
<duflu> RAOF: sigatomic_t for an int. Otherwise pthread.h :)
<RAOF> Or libatomic-ops
<duflu> Yeah. Sorry, I'm in the habit of finding portable solutions... which work on all platforms. Not just Linux
<duflu> RAOF: Any more thoughts on intel cache issues?
<tvoss_> good morning
<tvoss_> duflu, RAOF o/
<RAOF> Morn.
<duflu> tvoss_, Morning-ish
<tvoss_> RAOF, duflu how is it going?
<duflu> tvoss_: OK. Back to just figuring out bugs now  :)
<tvoss_> duflu, :)
<RAOF> Doing the XMir work to fix input-after-VT-switch.
 * duflu goes to find lunch and /professional/ coffee :)
<tvoss_> duflu, professional coffee ... a very nice term
<duflu> RAOF: Still around?
<RAOF> duflu: Yeah
<RAOF> duflu: What's up?
<duflu> RAOF: I just noticed... with the damaged/stripey cursor...
<duflu> RAOF: The artefacts last _many_ frames. Much longer than 3. So that suggests it's indeed not related to buffer ordering.
<RAOF> Which damaged/stripy cursor is this?
<duflu> RAOF: intel "caching" artefacts ickle mentions
<duflu> mentioned
<RAOF> Oh, yeah.
<duflu> I'm sanity checking to try and find related bugs in the Mir server still
<RAOF> You probably won't see them with two full-screen egltriangles, either; you want to be doing *lots* of drawing.
<RAOF> Like X window â compiz â root window â Mir. âº
<duflu> RAOF: How different to filling the screen? Stressing the GPU?
<RAOF> Lots of memory access, I think.
<duflu> RAOF: Oh, texturing?
<RAOF> That'd be an easy way to generate lots of memory access, yes.
<RAOF> It's *possible* that EGL Mir clients won't trigger this; there's apparently some effort taken in mesa to make this work.
<RAOF> Although totally untested, because X does it.
<duflu> I'm also trying to find a way to separate those artefacts from frame ordering issues
<duflu> It would be nice to see only one bug at a time
<RAOF> Yes.
<duflu> Woo, easily separated
<tvoss> woot :)
<tvoss> sdl1.2 with Mir support & nexuiz -> win
<RAOF> libatomic-oops
<tvoss> RAOF, :)
<Mirv> is there a way to get the same mirror mode that was before the multimonitor support? xrandr --output XMIR-2 --same-as XMIR-0 gives me something that is clipped on the lower resolution screen, but still has the same artifacts/slowness as with dual screen. before multimonitor support I had artifact free mirror mode where the lower resolution screen was displayed with grey borders on the higher resolution screen
<duflu> Mirv: Not sure. I agree the mirroring was perfect before XMir became MM-aware :/
<Mirv> duflu: heh, true
<Mirv> the new mirroring is actually near unusable, while the dual screen is about usable still, with some slowness and artifacts. I think I'll use that for now.
<Mirv> it's nice to have the fullhd back, to counter the minus sides
<duflu> Mirv: If you want to vote... please do so on bug 1216472 and bug 1218735
<duflu> :)
<ubot5> bug 1216472 in mir (Ubuntu) "[xmir] [multimonitor] Frames eventually get slightly out of order, look like glitches or typing will feel slow" [Critical,Confirmed] https://launchpad.net/bugs/1216472
<ubot5> bug 1218735 in XMir "[intel] Bypass mode makes the cursor break up into horizontal line artefacts" [High,New] https://launchpad.net/bugs/1218735
<Mirv> yeah :)
<Mirv> yay for workarounds
<duflu> Mirv: Also vote: bug 1217917
<ubot5> bug 1217917 in XMir "XMir Multimonitor Not possible to select "Mirror Displays" in setting." [Undecided,Confirmed] https://launchpad.net/bugs/1217917
<Mirv> mm. I'm an experimental person so I tried killall unity-system-compositor. no it did not gracefully restart, but now I've missing input methods in VT7 (lightdm) even after multiple reboots. any idea what could be wrong?
<Mirv> it types in lightdm though everything that I type here
<Mirv> but I can't type or move mouse if I move to VT7
<duflu> Also no idea.
<duflu> RAOF: Did you observe Mir giving XMir 2 or 3 unique buffers?
<dholbach> good morning
<tvoss_> duflu, RAOF you guys still around?
<duflu> tvoss_: Yes. And finally got XMir running in my own development Mir server so I can examine it :)
<tvoss_> duflu, \o/
<duflu> XMir in mir_demo_server_shell is kind of funky
<tvoss_> duflu, I can imagine :) I had nexuiz running mir_demo_server_shell an hour ago, quite funky, too
<duflu> I can drag my X outputs on top of each other... it's not natural
<tvoss_> duflu,  :)
<tvoss_> mind taking a crappy video with your mobile?
<duflu> tvoss_: That would appear to require 4 hangs right now :(
<duflu> *4 hands
<tvoss_> duflu, indeed :)
<tvoss_> duflu, cancel that then
<tvoss_> duflu, what is the status for the artifacts with bypass? can that be attributed to the cursor?
<duflu> tvoss_, RAOF said that ickle said it was a quirk of the intel driver. Requires some workarounds
<tvoss_> duflu, ack. Do we have a bug open?
 * duflu shrugs
<duflu> tvoss_: bug 1218735
<ubot5> bug 1218735 in XMir "[intel] Bypass mode makes the cursor break up into horizontal line artefacts" [High,New] https://launchpad.net/bugs/1218735
<tvoss_> duflu, thx
<tvoss_> duflu, do we have a bug open for fullscreen games running at non-native resolution not benefitting from composite bypass?
<duflu> tvoss_: No. I also haven't thought about it for a while. It's really all XMir I think
<tvoss_> duflu, ack
<dholbach> hey hey
<dholbach> does anyone else have a bit of flickering with the cursor?
<tvoss_> dholbach, yeah, known issue: bug 1218735
<ubot5> bug 1218735 in XMir "[intel] Bypass mode makes the cursor break up into horizontal line artefacts" [High,New] https://launchpad.net/bugs/1218735
<dholbach> thanks!
<tvoss_> dholbach, please upvote it, will take some dancing with the Intel driver. RAOF has checked in intel-x
<dholbach> upboat!
<duflu> RAOF: OK, I'm logging all the XMir buffer actions. The compositor is acquiring/releasing in exactly the same order as the client. Even though I *see* incorrect ordering :(
<alan_g> duflu: you're assuming a consistent sequential ordering. Einstein disproved that a century ago.
<tvoss_> duflu, if that is the case, then XMir is jumbling up the frame order somewhere, isn't it?
<duflu> tvoss_: That would be the conclusion. Assuming I'm right. Still trying to prove myself wrong
<tvoss_> duflu, ack
<tvoss_> duflu, mind summarizing how you report acquisition/release and how you assert that it is in the correct order?
<duflu> tvoss: fprintf() says for each Switching bundle, the order of client/compositor acquire/releases is always 0,1,2,0,1,2
<duflu> Maybe it's rarer than I think. I need to search for glitches programatically
<tvoss_> duflu, yeah, just assert if the order is violated and run phoronix or glmark in xmir
<tvoss_> duflu, putting load on x is usually a good way to trigger the issue
<duflu> tvoss_: I can trigger it. I can see it.
<duflu> tvoss_: I'm talking about the frame ordering bug, not the cursor bug
<tvoss_> duflu, likewise, I thought you couldn't see it
<duflu> tvoss_: I can't see it without XMir. Now I have XMir running in my dev server
<tvoss_> duflu, yeah
<duflu> I can see the compositor spinning through frames much faster than XMir provides them. But still the same order. The compositor just reuses the last one
<tvoss_> duflu, shouldn't we only composite if there is a new frame?
<duflu> tvoss_: Yes, but there's something funny with XMir multimonitor triggering redraws on all outputs even when only one screen is changing. I think that used to be a unityshell bug.
<tvoss_> duflu, okay
<duflu> Hmm
 * duflu tries without Unity
<tvoss_> duflu, I was just about to propose that
<tvoss_> xfce without comp ftw :)
<tvoss_> then with comp
<tvoss_> \o/
<duflu> tvoss_, ?
<tvoss_> duflu, completed the first set of nexuiz/openarena benchmarks against native mir with bschaefer's sdl1.2 adjustments
<duflu> Oh cool
<duflu> Should be blazing fast
<duflu> Hopefully
<duflu> tvoss_: And yes, no ordering problems with Xfce in XMir
<tvoss_> duflu, it is
<tvoss_> duflu, verifying the numbers now
<tvoss_> duflu, in the multi-monitor case, right?
<tvoss_> duflu, did you enable composition in xfce?
<duflu> tvoss_: Although I'm seeing very strange X damage artefacts. Yes, all multimonitor
<duflu> tvoss_, composition?
<duflu> I need to run in a minute
<tvoss_> duflu, xfce has got a compositor, too
<tvoss_> duflu, by default, it is switched off iirc
<duflu> And out of time. I have real life to catch up on...
<RAOF> Hey, what? Why does mir_surface_set_event_handler not take a void *ctx?
<RAOF> What does the event handler get called with?
<mlankhorst> tvoss_: could you send a new build for glmark? :P
<tvoss_> mlankhorst, yeah, on it :)
<RAOF> And with that, it's EOW
<tvoss_> RAOF, enjoy your weekend :)
<mlankhorst> sort of same for me, but I left early yesterday so I want to make up by engaging some phoronix mode :P
<mlankhorst> write an email about glmark2 nouveau xmir vs mir, bahah
<tvoss_> mlankhorst, compiling
<discopig> hi
<tvoss_> discopig, hey
<hikiko> hi, I performed a dist-upgrade a while ago (i386) and since then the vt switch doesn't work in any mir branch (even when I use a fresh clone of trunk) does anyone have the same problem?
<alan_g> hikiko: are you running the server without root?
<hikiko> no
<hikiko> I reboot and fixed
<tvoss_> mlankhorst, ping
<smspillaz> RAOF: it takes a void * I'm pretty sure
<smspillaz> RAOF: ah wait, it doesn't, but MirEventDelegate is defined as struct { event_handler_func func; void *ctx }
<tvoss_> smspillaz, ping
<tvoss_> smspillaz, you around for a bit?
<smspillaz> tvoss_: a little bit
<smspillaz> tvoss_: .. still here
<tvoss_> smspillaz, yup, otp right now :) would like to talk about cursors and touches and motion events
<smspillaz> ah okay. I can only talk over IRC at the moment - I've got a bad cold
<tvoss_> smspillaz, sure, irc is fine with me
<smspillaz> tvoss_: ... although I'll be going to bed soon. It might be better to send me an email or send an email to the list?
<tvoss_> smspillaz, list is fine, too
<mlankhorst> tvoss_: pong
#ubuntu-mir 2013-09-01
<oiaohm> http://dvdhrm.wordpress.com/2013/09/01/splitting-drm-and-kms-device-nodes/  I really do wonder badly this is going to effect mir idea of server side control.
<RAOF> oiaohm: Not at all.
<oiaohm> RAOF using device nodes could nicely under mine buffer controls.  Client side allocation in GPU memory spaces.
<RAOF> They can't allocate the front or back buffers, which is all Mir controls anyway.
<RAOF> We weren't planning to, and don't, allocate *all* client buffers. That would entail much annoyance - we'd need to have server-side changes any time a GPU driver wanted a differently laid out buffer for internal purposes.
<RAOF> Clients allocate all their textures themselves.
<oiaohm> RAOF: the back buffer one is something I do wonder about.  dma-buf  that is used to pass from device nodes back to servers can have a back buffer applied.
<oiaohm> basically the change might effect you a little.  RAOF
<RAOF> You're using "back buffer" in a way I don't recognise.
<RAOF> dma-bufs are a buffer passing mechanism, yes.
<RAOF> There's no way for a client to *display* anything except through Mir; only what they render to the buffers sent out from the server (as dma-bufs) will ever make it to the screen.
<RAOF> (Barring hilarious client bugs)
#ubuntu-mir 2014-08-26
<RAOF> Urgh. Have I broken CI again?
<RAOF> The test-build worked, damnit!
<RAOF> ON CI!
<RAOF> OOOOooooooooh!
<RAOF> I have become the destroyer of CI!
 * RAOF should not work in branches where the default push is to the default CI runner.
<RAOF> Alright!
<RAOF> CI should really, really work now you guys.
<RAOF> FOR REALZ!
 * RAOF goes to pick up his car.
<RAOF> Ok. Now CI's just messing with me.
<anpok> yay renaming functions with the c-preprocessor is great
<alan_g> It is a powerful technique - and should be used responsibly (i.e. rarely)
<anpok> here it was used to link to archives together that use a lot of copied code
<anpok> *two
<anpok> hence one is built with a header full of #definef func old_func ..
<alf_> alan_g: Hi! Could you please elaborate on "Indeed wouldn't placing a cache implementation directly in the configuration object be sufficient?". Do you mean that the configuration object should have something like: std::shared_ptr<SharedLibrary> the_platform_library() ?
<alan_g> alf_: I was thinking of a data member SharedLibraryCache with a load_library member.
<alan_g> But I guess we only ever load the one, so a std::shared_ptr<SharedLibrary> platform_library member would do.
<alf_> alan_g: The SharedLibraryCache needs to be shared/survive across configurations and MirConnections, so I am not sure how a SharedLibraryCache as data member would work.
<alan_g> alf_: OK, that answers my "needs info".
<eanyx> hi
<eanyx> Does someone has metrics for 2D/3D throuput of mir?
<eanyx> throughput
<kdub> there's a glmark built for mir
<eanyx> Does the performance are good compared to legacy X?
<kdub> sure
<eanyx> In what proportion?
<kdub> too vague questions
<eanyx> I'm wanting to write a 2D game, and wanting to know what is the blitter speed ?
<kdub> with the in-game stuff, thats up to you... for mir at least
<kdub> we bypass fullscreen on mesa
<kdub> and use the overlay path on android
<kdub> could everyone take a look at  https://code.launchpad.net/~kdub/mir/frontend-tracking/+merge/232123
<kdub> and indicate which of the two exchange_buffer messages are preferable?
<eanyx> is there some vsync for smooth animation?
<alan_g> kdub: I've looked and don't have a preference
<kdub> thanks alan_g
<eanyx> have to leave you, have a nive day/evening.
<alf_> kdub: fine with both, although I wonder if allowing the client to indicate surf_id could be used maliciously. Of course we already trust the client library to give us correct info in general, so perhaps this is a non-issue.
<kdub> alf_, yeah, agree
<kdub> at any rate, i'll be on later than normal tonight, so I'll just chat it over with RAOF then
<dandrader> a gmock question: is using MOCK_METHODX(....) any good when I want to check a complex parameter of a method?
<dandrader> I have a parameter like this "const QList<struct QWindowSystemInterface::TouchPoint> &points"
<dandrader> so I wanna iterate the list and check the values of the TouchPoint structure, etc
<dandrader> I wonder if using the gmock magic stuff (like declaring the method with MOCK_METHOD() and using things like EXPECT_CALL()... in the test) will be of any use in this case
<dandrader> or if I'm better of doing the mock implementation manually
 * dandrader was told mir developers were the local gmock experts
<tvoss> dandrader, you might want to look into MATCHER_P
<tvoss> dandrader, so yes, gmock is quite useful in your scenario, and you can just describe your matching logic in MATCHER_P
 * dandrader googles for MATCHER_P
<kdub> there are also some container matchers
<kdub> https://code.google.com/p/googlemock/wiki/CheatSheet#Container_Matchers
<kdub> that might be helpful
<dandrader> tvoss, kdub, ok, thanks for the tips. will look into those
<josharenson> greyback__ when I build qtmir, it keeps failing on a mir header file, even though the file exists...
<greyback__> josharenson: can I see the build output please? How are you building?
<greyback__> josharenson: if you're building manually on the phone, you need this: qmake "QMAKE_CXX=arm-linux-gnueabihf-g++-4.9" "QMAKE_LINK=arm-linux-gnueabihf-g++-4.9" "QMAKE_LINK_SHLIB=arm-linux-gnueabihf-g++-4.9"
<josharenson> as per the readme.. mk-build-deps, qmake, make (getting a pastebin of the output)
<greyback__> ah, I better update the readme - the 4.9 thing is annoying
<josharenson> i was going to update it when I got it working :-p
<josharenson> http://pastebin.ubuntu.com/8151394/
<greyback__> josharenson: so libmirserver-dev is installed? In that case, I'd clean all & try again (qmake not good at seeing dependencies changing): bzr clean-tree && bzr clean-tree --ignore
<greyback__> then try the qmake command again
<josharenson> greyback__ I had libmirserver-dev installed, but cleaning the tree seems to have fixed whatever was wrong...
<greyback__> josharenson: glad to hear it. Usually that happens to me if I run qmake before having all the dependencies installed. Running qmake again after often does not pick up the new header/lib directories
<josharenson> greyback__ good to know, thanks
<greyback__> full clean and retry is my usual fix
<greyback__> np
<rsalveti> AlbertA2: hey, while I agree that it's good to hold a lock during a voicecall, this same issue will happen next time we have an app using the proximity sensor
<rsalveti> checking https://code.launchpad.net/~albaguirre/powerd/avoid-suspend-during-call/+merge/232290
<Saviq> camako, is there an actual reason why we need the bump of qtmir dep to > 0.7.0? if not, we should just go for a no-change rebuild?
<Saviq> camako, although the -gles dep should definitely be bumped to actually be in sync with the non-gles one, but in general unless there's API breaks we don't bump the -dev dependency, it will still build with the latest available
<camako> Saviq we broke the ABI.. So I just updated the dependency
<Saviq> camako, right, so we only need a no-change rebuild against the new -dev, debian/control deps should generally reflect the truth (as in what's the minimal mir version with which qtmir will build)
<camako> Saviq, do you mean, for instance, if there is no client API break then leave the client dependency alone?
<Saviq> camako, basically if there's no code changes required
<Saviq> camako, there's no need to touch the deps
<camako> Saviq, but we definitely broke the ABI on the server side... client side perhaps I should leave it alone
<Saviq> camako, sure, but that will sort itself out through a no-change rebuild
<Saviq> camako, the build system will select the highest -dev version during the build anyway, and then encode the real versioned dependency in the runtime dependencies
<Saviq> camako, basically, qtmir can build with 0.6.0 still, can it not?
<camako> Saviq, Oh I see what you mean... I dunno if it can actually..
<Saviq> camako, if you only bumped the debian/control version and it still builds, sounds like it can :)
<camako> Saviq, you're right... If mir hasn't changed actual code qtmir (or others) depend on then no need to do what I did
<Saviq> camako, dependencies (especially versioned ones) in debian/control should be "the least required"
 * Saviq comments on the MP then
<camako> Saviq, I see... so how do we do a no change rebuild in the silo?
<Saviq> camako, you just need an empty (--unchanged) commit in the MP
<Saviq> camako, for the -gles counterpart you still need to sync the version number (and silo)
<camako> Saviq, yes Iit's just prelim at this moment
<Saviq> camako, yup
<camako> Saviq, thanks man... every time I talked to you I'm illuminated :-)
<Saviq> camako, always
<Saviq> camako, for fast development like we do now it isn't as important, but once Mir becomes part of the default distro, LTS and such, it pays off to not bump deps unnecessarily so that you're not forced to unnecessarily build a chain of dependencies
<Saviq> when someone wants to build on an older distro, that is
<camako> Saviq, makes total sense...
<Saviq> camako, one thing to note (when not bumping -dev deps), when you build things in silo, you need to make sure of the order things build in the right order
<Saviq> camako, because if you just build mir and qtmir in parallel, qtmir will actually build against the distro version
<camako> Saviq, ok.. and putting mir MP in the front doesn't help with that right?
<Saviq> camako, no, they all get pushed to the PPA at the same time
<Saviq> camako, you just need to run the build job with just "mir" first
<Saviq> or whatever comes first for real
<camako> Saviq, ok got it
<Saviq> camako, I think there's a circular dependency between papi and mir still, which means you might actually need to build papi, mir, then papi again or something similar
<RAOF> kdub_: Yo!
<camako> Saviq, yeah I've encountered that before and I look out for it
<Saviq> camako, ideally this should be resolved if at all possible
<Saviq> camako, that would require splitting papi, though
<camako> Saviq, yeah it's a nuisance
<Saviq> camako, the circular dep might lead into a difficult situation if in a single landing you'll have papi depending on new mir api and mir on new papi, neither will build without the other
<Saviq> oh and there's even one with mesa too bug #1239037
<ubot5> bug 1239037 in mir (Ubuntu) "circular build-dependency between mesa, mir" [Medium,Triaged] https://launchpad.net/bugs/1239037
<Saviq> I thought I filed one for papi, mir, will do so now
<camako> Saviq, yeah I guess we change only one first, build the other then we change the other and build the first.. if that makes sense)
<Saviq> camako, sure, that makes sense, but might mean you have to do the changes in stages unnecessarily
<camako> Saviq, right can't do in one silo... would have to split the landing
<camako> which would be an even bigger PITA than it already is
<camako> Saviq, so it'll look like this right? https://code.launchpad.net/~mir-team/qtmir/devel-mir-next/+merge/232329
<Saviq> camako, yes, approved
<Saviq> camako, btw, looks like the papi/mir loop was resolved in the end, it's only the mesa one that remains
<Saviq> camako, i.e. mir does not build-depend on anything produced out of platform-api AFAICT
<camako> Saviq, I see
<Saviq> camako, btw, in theory it should be possible to pull lp:qtmir into lp:qtmir/devel-mir-next instead of merging (is what we do with the gles-sync branch)
<Saviq> well, not any more, because there were merges and such, but maybe we could make it happen again by overwriting devel-mir-next with trunk at the next landing
<Saviq> this way trunk and devel-mir-next actually maintain the same history
<camako> Saviq, I see what you mean
<camako> Saviq, good idea
 * Saviq tries to verify
<camako> Saviq, this actually occured to me but I was a chicken to try
<Saviq> camako, so yeah, as long as there's no commit *more* on devel than on trunk, you can pull
 * camako will do it next time
<camako> Saviq another nice thing with the empty commit option is now the MPs will be approved by Jenkins (before they always failed because Jenkins didn't know anything abt the new release before it happened)
<Saviq> camako, sure, assuming they will actually build ;)
<Saviq> camako, and well. sure, jenkins approved, but with old mir, so not really something you wanted
<camako> Saviq, yea I'm hungry so who knows what I did
<Saviq> camako, so yeah, even now, if you uncommit your last commit to devel-mir-next, you can just pull from trunk, so yeah, just after the next qtmir landing, pull into devel-mir-next and you'll have history nice & clean
<camako> Saviq, yeah but at least we won't see a failure
<camako> Saviq, yeah.. same thing with USC and papi
<Saviq> camako, yup
<Saviq> camako, so yeah, until devel-mir-next has actual source changes, jenkins should be happy - if it stops being happy is when you should actually bump the build dependencies appropriately
<camako> Saviq, yea.. it's sort of one extra checkpoint
<Saviq> camako, yup
<Saviq> o/
 * Saviq sleepy time
<camako> Hey Saviq, really thanks man.. good night
<Saviq> camako, right back at you
#ubuntu-mir 2014-08-27
<kdub_> RAOF, ping
<RAOF> kdub_: Pong!
<kdub_> RAOF, so I guess I still feel pretty neutrally about that exchange_buffer message signature
<kdub_> other than the fact there are a few other branches I have waiting in the wings based around the no-surface-id variant
<RAOF> Eh, ok.
<RAOF> It just seemed like you were doing a fair bit of work to match the Buffer to the Surface when the client already has that mapping (and the only interface for submitting the buffer goes through the surface anyway)
<RAOF> So, I guess I'm saying that I think the (SurfaceId, buffer) signature is lower total complexity, and should therefore be favoured :)
<kdub_> yeah, I guess what tipped my hand in thinking about it is that the other signature seem like a cleaner addition to the protocol
<RAOF> Eh. The protocol's there to make the code's life easier :)
<kdub_> hah, yeah :) well, I'm convinced enough to trim that MP down to just being a BufferId->Buffer* lookup
<kdub_> instead of BufferId->Buffer* lookup and a BufferId->SurfaceId lookup as well
<kdub_> and change the using the surfaceid/bufferid request
<RAOF> Sounds planworthy.
<kdub_> still somewhat on the fence on the whole as to which one is better, but may as well have less mappings
<kdub_> cool, thanks
<Wellark> when can I have screencapture recording of AP tests running on mako?
<Wellark> is there support for screen recording in Mir?
<Wellark> if there is then I will go bugging the QA team
<Wellark> + I might finish my unity8 input visualizer which will show graphically what input is applied by the AP tests and put the QML Particle system in good use
<RAOF> There's screen recording right now.
<Wellark> RAOF: sweet
<Wellark> so now it's only a tooling issue
<RAOF> https://code.launchpad.net/~mir-team/mir/touchspot-renderable/+merge/230555 for input visualisation (on the Mir side)
<Wellark> RAOF: ok. will that also show wipes ?
<Wellark> it's super easy to implement in Unity9
<Wellark> *8
<RAOF> It'll show where Mir thinks the touchpoints are.
<Wellark> just throwing a couple of Mouse, Touch and KeyboardAreas
<Wellark> to the root of unity8 shell
<Wellark> I was bored last weekend so I prototyped it
<Wellark> would make a nice addition to the developer mode
<Wellark> RAOF: sure, but no "higher level" information like "swipe start, swipe end"
<RAOF> Indeed.
<Wellark> or which keys are pressed
<Wellark> implementing a full featured input visualizer is better to be implemented inside unity8 shell with QML
<Wellark> as it would be like couple of hundreds of lines on QML code
<Wellark> including the shiny particles :)
<RAOF> You get different information out of the Mir visualiser; they're probably both useful.
<Wellark> sure.
<Wellark> Mir visualizer is probably very usefull for device bringups and touch calibration
<Wellark> like the low level stuff
<Wellark> but I want something shiny for the (end user) app developers :)
<Wellark> RAOF: thanks for the info
<Wellark> I go now to harrash the QA team
<RAOF> Ah. So StubConnectionConfiguration is actually a lie.
<RAOF> Oops.
<anpok_> RAOF: regarding cmake and rpath - so the issue was that there was a libmirclient.so.8 linking against mircommon.1 and another one linking against mircommon.2...
<anpok_> hm where is that build dependency coming that makes ci install mir
<anpok_> through egl -> mesa -> mir?
<RAOF> At least that, yes.
<RAOF> anpok_: Note that this is only the case for the uninstalled tests - once we install them the rpath gets stripped.
<anpok_> yes
<anpok_> i was just curious if we are fixing the right problem
<anpok_> i.e. shouldnt we bump mirclient if mircommon changes .. but I guesswe shouldnt since users will only rely on mirclients ABI...
<anpok_> or then instead fix the dependency cycle..
<RAOF> It's not really a dependency cycle.
<anpok_> only a build dependency
<anpok_> yes.. b
<anpok_> -b
<RAOF> Right.
<RAOF> And it's only a problem when uninstalled because of the rpath issue..
<anpok_> RAOF: did you find the time to have a look at the updated mir platform patch?
<RAOF> I haven't yet sorry.
<anpok_> that and a one liner in i915 fixes the issues we have on netbooks and those intels that come withan integrated 945 gpu.
<anpok_> ok
<RAOF> Sweet..
<RAOF> Want to send me the updated thing and I'll look at it after making dinner.
<RAOF> BAH!
<RAOF> StubConnectionConfiguration is a dirty, dirty lie, and making it not a lie is nontrivial.
<anpok_> RAOF: I know have another one for 10.2..
<anpok_> -k
<anpok_> and I think I can actually remove the changes to brw_context.c
<RAOF> If we use the image loader, yes.
<anpok_> but I havent tested yet... but yes due to the partially copy-paste-designed drivers it would then work like 915
<alan_g> alf__: I've just noticed that libmirclientlttng.so and libmirserverlttng.so are packaged in mir-test-tools. Does that mean the lttng reports are not available without installing the tests?
<alf__> alan_g: yes
<alan_g> I hadn't been aware of that. I hope there's a sensible error message.
<ahayzen> AlbertA, ping
<AlbertA> ahayzen: pong
<ahayzen> Hi, I have been advised to talk to about bug 1337239, jhodapp and rsalveti have both looked at the bug but believe it is mir/compositor's responsibility. Would you mind having a look at the bug and adding and comments that you have?
<ubot5> bug 1337239 in unity-system-compositor (Ubuntu) "Digitiser still works when phone locked" [Undecided,Confirmed] https://launchpad.net/bugs/1337239
<AlbertA> ahayzen: yep, I just dup it to https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1359264
<ubot5> Ubuntu bug 1359264 in mir (Ubuntu) "Surfaces receive input even while the screen is off" [High,Triaged]
<AlbertA> ahayzen: the next mir release should have a fix for it
<ahayzen> AlbertA, hah awesome :) is that in a silo that i can test now?
<AlbertA> ahayzen: camako is getting one ready
<ahayzen> AlbertA, ok thanks rsalveti ^^
#ubuntu-mir 2014-08-28
<RAOF> Wooo!
<RAOF> An MP that's less than 1000 lines!
<RAOF> I CAN DO IT!
<duflu> anpok! Fixed Mesa yet? :)
<anpok> yes
<anpok> patches have not yet been integrated..
<anpok> there is still a failure during unity8-dash context creation -- which is suspicious since unity8 and indicators start properly
<anpok> duflu: i guess the right answer is 'never'
<duflu> anpok: Aww. You should branch it then. Branching solves everything
<anpok> i thought rewriting does that?
<anpok> or was it adding another layer?
<RAOF> Indirection is what you're thinking of, yeah. :)
<anpok> possibly, as long as you make sure that those indirections are redundant.. it is always odd if similarities are indicated by sharing implementatioons
<anpok> we have to get to a point where think of software components as a genetic algorithm that test runs multiple specimen at the same time
<anpok> .. ok something different
<anpok> RAOF: i guess i was to late yesterday sending the patch - just couldnt send it without anothe test run on my laptop
<RAOF> anpok: Yeah, I think it came in overnight.
<RAOF> And I got distracted with duflu and his ridiculous âneeds to be reviewableâ criteria for branches :)
<duflu> Hmm, why is Mir so much slower to build than it was a few months ago?
<duflu> What did we change?
<duflu> Might need to script up some builds next weekend
<alan_g> alf__: libmiromnibus has "all" the mir code (and no test code). Are you sure that "libmirtesting" is a better name? Or do we need to think of a third?
<alf__> alan_g: Well, I had to look up what "omnibus" is, and that is not a good sign. Perhaps, though, "omnibus" is a well known term for native speakers. I think it would be good to consider a few more alternatives.
<alf__> alan_g: of course, this is an internal library, so getting a perfect name is not critical (but it would be nice if we could find one)
<alan_g> alf__: I don't consider it obscure, but I don't use it everyday either.
<alan_g> It might not stay internal. Downstream have expressed interest in having our test doubles available for their tests - and many of these rely on internal interfaces. Depending on how that progresses it may have a wider consumption.
<alf__> alan_g: just brainstorming (not necessarily good names) -> libmirall, libmirinternals, libmirfull
<alan_g> alf__: ack
<alan_g> libmir-all-naked
<alan_g> (That should get a phoronix article)
<alf__> :)
<alan_g> kdub: is "omnibus" an obscure word?
<kdub> alan_g|lunch, eh, I know what it means, but dont use it often
<alan_g> kdub: alf__ and I were discussing whether "libmiromnibus" is a good name and what else we might call it.
<kdub> its sort of an obscurely-used library, so I'm okay with the name
#ubuntu-mir 2014-08-29
<anpok_> haaa
<anpok_> first time I see dash on i915
<anpok_> maybe even more than one frame per second
<camako> Hey everyone! Wanna test Mir 0.7.0? Here are the instructions : http://pastebin.ubuntu.com/8168822/
<camako> kgunn, AlbertA, kdub ^^
<kdub> camako, ack
<Nothing_Much> camako: is that for phones or desktop?
<camako> Nothing_Much, both
<Nothing_Much> camako: oh cool, does it include xmir?
<anpok_> Nothing_Much: that is a mir release - so no changes to xmir
<Nothing_Much> ah darn
<Nothing_Much> so that would only involve the Touch and Unity 8 iso's
<anpok_> on the desktop unity8 with the tablet interface so far - yes
#ubuntu-mir 2015-08-24
<anpok> RAOF: oh hm kernel 3.12
<RAOF> anpok: Oh, yeah. Forgot about that. It'd be easy enough to provide a less-efficient work-around, though. (uinput via libevdev)
<RAOF> Or maybe, just maybe, the phone platforms we need this on will use a kernel less than two years old!
<anpok> seems simple to backport
<RAOF> Also true.
<RAOF> Now with bonus Xorg crash!
<RAOF> Heh. I love the juxtaposition of https://code.launchpad.net/~alan-griffiths/mir/simplify-connect-code/+merge/268740/comments/675948 with https://code.launchpad.net/~vanvugt/mir/fix-1476201/+merge/268693/comments/675947 :)
<guest42315> uu mir 0.15 in wily
<guest42315> too bad wily is broken X-(
<RAOF> Shouldn't be (anymore)
<duflu> RAOF: Do as I say, not as I do
<duflu> Generally I don't mean to me contradictory. It just sounds that way if I fail to communicate adequately
<duflu> Woo, Mir 0.15.0 is done. Unfortunately even with that large bug count subtracted the backlog remains over 300 now
<RAOF> duflu: Yeah; writing code that's readable for other people is hard (which is one reason why we have reviews âº)
<duflu> RAOF: I still wish we could get more reviewers. mir-team feels statistically not quite significant and we sway with confirmation bias (and mood) a lot
<duflu> Or even better: testers(!)
<RAOF> Eh, testers solve a different problem
<duflu> RAOF: They would solve one problem, of reviewers approving things that actually don't work :)
<RAOF> Well, reduce it :)
<duflu> An interesting observation I made years ago (and continues to be true throughout the world) is that some projects without code review actually yield higher quality. It's a matter of being able to achieve a sufficiently high throughput that your average number of fixes significantly outweighs the regressions.
<duflu> There is risk of course, but that can be mitigated with long release cycles and branching (which Ubuntu doesn't quite accommodate)
<duflu> Although I only remember that working when there actually was a dedicated test team. And more full-time testers of the code than developers
<duflu> Umm, Jenkins is over-eager now: https://code.launchpad.net/~vanvugt/mir/merge-distro-changelog-0.15.0/+merge/268884
<alan_g> alf_: you're on wily - could you check which libmirclient .so is used by glmark2-es2-mir? (I'm at the pocketdesktop sprint with only vivid to hand)
<alf_> alan_g: sure
<attente> http://paste.ubuntu.com/12183271/ <- does anyone know what this error means? i can't seem to launch a u8 session
<alf_> alan_g: libmirclient.so.9
<zzarr> Hello!
<zzarr> are there any nVidia Mir drivers yet?
<alan_g> alf_: that's good, thanks. (Now I just have to double check overlay)
<guest42315> zzarr, mir runs on nouveau
<zzarr> okey, so they are not finished yet I guess
<anpok> zzarr: yes.. time will tell if they will settle gbm ..
<anpok> or they might continue with their own path.. and expose something along the lines of the egl streams extension
<alf_> attente: what versions of mir packages do you have? (e.g. dpkg -l '*mir*' | grep '^ii' )
<zzarr> anpok, thanks
<kdub> vogons, reviews of https://code.launchpad.net/~kdub/mir/fix-1487967/+merge/268908 ?
<alan_g> kdub: I'm trying to track down a CI problem on mako and am seeing "<ERROR> MirBufferStream: Error processing incoming buffer error registering graphics buffer for client use" in src/platforms/android/client/gralloc_registrar.cpp. (This is running glmark - which hangs.) Is this error likely to be significant?
<alan_g> kdub: will look
<kdub> alan_g, sounds like https://bugs.launchpad.net/mir/+bug/1441553
<ubot5> Ubuntu bug 1441553 in Mir "[regression] Screen flickering and error messages on Android overlay surfaces: <ERROR> MirBufferStream: Error processing incoming buffer error registering graphics buffer for client use" [High,In progress]
<kdub> which happens when overallocation occurs, there's a quick fix in there to try out (increase mf::client_buffer_cache_size)
<kdub> basically, the client and server don't agree on how many buffers are around, which android has a hard time with
<alan_g> kdub: would that be causing a hang? https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/6354/console
<kdub> I guess its not unfathomable that it could
<alan_g> OK, what's a good size to try?
<kdub> probably 4 (nbuffers + 1)
<attente> alf_: thanks, i had two different versions installed
<alf_> attente: np
<alan_g> kdub: the "quick fix" seems to fix my problem locally. (I assume it isn't a good thing to add to my MP though.)
<kdub> the bad side effect with the cache size being 4 is that we can potentially have 2 old buffers lingering on the client client side
<kdub> and, its in progress because with nbs, the client and server agree on the buffer count
<kdub> but, I guess the side effect is better than the symptoms
<kdub> its not a regression, but a problem with the overallocation feature of BufferQueue... so reverting that is another solution
<alan_g> OK, I'll add to the MP with a dirty great TODO and see if it also works in CI
<kdub> alan_g, ack, sounds good
<alan_g> kdub: Like this? LL90-93 https://code.launchpad.net/~alan-griffiths/mir/fix-1486496/+merge/268747
<bschaefer> anpok, im not at the sprint :)
<bschaefer> anpok, and yeah revoking the fds could be an issue ... as well as adding the changes in relative mouse... possibly RAOF has ideas on that?
<anpok> bschaefer: RAOF pointed me to a ioctl in evdev to do that.. just read about it last night.. since kernel 3.12
<anpok> so atm not available in touch kernels..
<anpok> but it was made for us :) in an embarssing way
<anpok> i am off for a moment
<bschaefer> thats nice :)
<bschaefer> anpok, are we still focusing on dbus as well?
<bschaefer> then trying to implement the fd?
<bschaefer> passing
<anpok> yes usc-dbus interface .. and later a input configuration / introspection .. through mirclient
<anpok> the chances for fd passing to happen have declined..
<bschaefer> sweet
 * bschaefer goes to figure out how dbus works
<bschaefer> never actually used it for the most part :)
#ubuntu-mir 2015-08-25
<RAOF> duflu: Hm. Looking at https://code.launchpad.net/~vanvugt/mir/better-scaling-test/+merge/268894 it seems the sort of thing that kdub's test scheduler would be perfect for?
<duflu> RAOF: Yeah it should have an equivalent test if not already. The immediate goal however is to fix that one unit test that kept breaking in CI
<duflu> RAOF: Actually it might not need a test after kdub's work is done. May not be a feature. Dunno
<duflu> That one test is holding up all my other work :P
<RAOF> Yeah; what I was thinking was that you could *remove* the test in its current location and use the scheduling infrastructure.
<RAOF> Which would make it much less verbose.
<RAOF> (Possibly)
<duflu> RAOF: The feature is possibly BufferQueue specific and may not live beyond that. I'd rather not move things around right now. Just fix the issue that's blocking all my other work
<RAOF> Fair enough; I just thought that since you're re-writing the test anyway...
<shengchieh> Hi, does any one know how to cross compile platform-api package(https://launchpad.net/ubuntu/+source/platform-api) ?
<anpok> shengchieh: I havent tried for a while..
<kdub> vogons, any more reviews? :) https://code.launchpad.net/~kdub/mir/client-resize-logic/+merge/268269
<attente> AlbertA: hi, for mir menu surfaces i think we're going to need some extra functionality
<attente> for example, gtk has combo boxes which when clicked need to be pop over the attachment rectangle at a position determined by the current selection
<attente> it's further complicated because gtk prefers the combo box menu to be flush with the edge in this case
<attente> instead of flipping vertically relative to the attachment rectangle
<attente> in this case we need to know how far the menu surface is offset from its requested location
<AlbertA> attente: hi, but how would knowing the offset help?
<AlbertA> attente: so if I understand right, the selection would be shown as if it is within the combo box? and therefore the menu for that combo box would shift position accordingly?
<attente> AlbertA: exactly, the combo box shifts position to align the current selection on top of the combo box widget
<attente> AlbertA: you can see this behaviour in the open file chooser dialog in gedit for example
<attente> when you can select between All Files and All Text Files
<attente> or the character encoding filter
#ubuntu-mir 2015-08-26
<duflu> kdub: Interesting thought - nested bypass in its ability to use much less GPU might actually make phones less smooth (because they will clock lower). We need to get that under control too: https://bugs.launchpad.net/mir/+bug/1488386
<ubot5> Ubuntu bug 1488386 in qtmir (Ubuntu) "Double buffering is only smooth while you're touching it" [Undecided,New]
<RAOF> Wow. Touching mg::DisplayConfigurationOutput touches *all the things*.
<duflu> RAOF: All the server things? Yeah probably
<duflu> RAOF: Here's a thought: Is the system's "scale" setting a feature of the server rather than the display/displayconfig?
<RAOF> No, because it's per-output.
<duflu> Fair enough. More fields for everyone
<RAOF> Yeah :/
<duflu> RAOF: Hmm, do the toolkits report scale per display?
<duflu> Because if it's systemwide in the toolkit designs, that would be a problem
<RAOF> I'm pretty sure they do, yeah.
<duflu> If they report it at all
<RAOF> gdk tracks scale per-output, but gdk_window_get_scale will report the largest scale factor in the current configuration.
<RAOF> But it'd be an easy optimisation to make it report the scale that the surface is on.
<RAOF> (Because gdk notifies apps when the scale changes, and even with its current âmaximum scale of everything on the systemâ approach the scale *does* change at runtime, so apps need to handle it)
<dandrader> duflu, ping
<duflu> dandrader: Hello
<dandrader> duflu, hi
<dandrader> so, I got a problem um qtubuntu regarding resize events
<duflu> Yay
<dandrader> resize events are processed in a thread and buffer swapping in a different one
<dandrader> currently, when i get a resize event all I do is schedule the rendering of a new frame
<dandrader> and it has been working well until a couple of weeks ago
<dandrader> it used to be that after I get a resize event, on my next buffer swap I would get already a frame with the new size
<duflu> dandrader: Yeah, schedule a new frame on resize, but ignore the resize event contents. Instead use the dimensions of the buffer you get back from swap
<dandrader> but now it happens so that sometimes it takes two buffer swaps until I get a buffer with the new surface size
<dandrader> duflu, that's what I do
<duflu> dandrader: That's always been an issue. There are TODOs and comments in the Mir demos about it
<duflu> dandrader: Let me find the details
<dandrader> duflu, previously I would swap buffers until I get a buffer with the new size
<dandrader> duflu, but that proved problematic in some situations
<duflu> dandrader: Just remember every swap buffers will appear on screen, so it should have rendering in it :)
<duflu> dandrader: https://bugs.launchpad.net/mir/+bug/1288021
<ubot5> Ubuntu bug 1288021 in Mir "MirResizeEvent's width/height fields are not useful, even dangerous" [Medium,Triaged]
<dandrader> duflu, sure, when I say buffer swapping I mean rendering a new frame
<dandrader> duflu, so now I'm thinking about doing the following
<dandrader> duflu, when I get a resize event
<dandrader> duflu, I render up to 3 new frames trying to get a buffer with a new size
<dandrader> duflu, as opposed to rendering just once, as it's done now
<duflu> dandrader: There's a simple solution we've been using for a long time. Just see: https://bugs.launchpad.net/mir/+bug/1288021
<ubot5> Ubuntu bug 1288021 in Mir "MirResizeEvent's width/height fields are not useful, even dangerous" [Medium,Triaged]
<dandrader> duflu, yes, I do this
<dandrader> duflu, this is not the problem I'm explaining
<duflu> OK
<dandrader> duflu, problem is the following: unity8 rotates from landscape to portrait, thus resizing the focused app, which gets a resize event from mir
<dandrader> duflu, so qtubuntu, in the client app process, schedules the rendering of a new frame in response to that resize event
<dandrader> duflu, but the next buffer still has a landscape size
<duflu> dandrader: I know. I've been looking after that bug. I have posted a partial solution and suggested how to handle the rest in comments: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1466510
<ubot5> Ubuntu bug 1466510 in unity8 (Ubuntu) "Stretched screen (briefly) after rotating" [Undecided,Confirmed]
<dandrader> duflu, so it will look streched (as unity8 is already in portrait) until the user flicks the app, causing a new redraw
<dandrader> duflu, s/a new redraw/yet another redraw
<duflu> dandrader: I've fixed the stretching in my branch, but there's still a brief delay while it fixes up the bottom/right edges. Comment #4 should solve that.
<dandrader> suggestion #4 sounds wasteful
<duflu> dandrader: It would look beautiful, more like iOS rotation
<duflu> Oh, except Unity8 itself would have to support partial rotation
<duflu> dandrader: I tested it on a phone last Friday. The unstretch branch really solves most of the problem. The rest is just minor polish
<duflu> "minor polish" = you finding ways to tell the app to resize sooner
<dandrader> duflu, so https://code.launchpad.net/~vanvugt/qtmir/unstretch/+merge/268724 does clipping/cropping instead of streching
<seb128> hey there, does anyone know if there is documentation somewhere about mir-on-x?
<duflu> dandrader: Yes, so most of your pixels appear in the right place, even before the resize
<duflu> seb128: Not sure. It's very new. I heard that even intel gfx support isn't ready yet
<dandrader> duflu, I will try out the "redraw up to 3 times after getting a resize event" solution
<seb128> duflu, if it's not working on intel on what is it working? ;-)
<duflu> dandrader: Hmm, if you really need that then there must be another bug not revealed by mir-demos yet
<duflu> seb128: Other drivers. Ask camako / RAOF
<duflu> dandrader: I think you might have a new and unique bug there. Particularly for resizing input-driven apps. Not sure if we've covered that correctly. Yeah it seems like you do need to keep redrawing till the buffer dimensions == resize event dimensions
<duflu> dandrader: 3 times will work, but better to put it in a while loop
<seb128> camako, RAOF, should mir-on-X work on intel? do you have documentation on how to test it?
<duflu> seb128: Although "Mir on VT1" works right now ;)
<seb128> less handy for testing :-)
<dandrader> duflu, it's "*up* to 3 times". I give up ealier if I get a buffer with a new size already on the first or second redraw
<duflu> seb128: Meh, Ctrl+Alt+Fn is easy. And you get much better performance too
<duflu> dandrader: Yeah you're right. Our mir demos failed to reveal that bug
<duflu> dandrader: Seems like Mir itself should keep sending you the same resize event till it matches
<dandrader> duflu, thing is there's no synchronicity whatsoever between the mir event thread and the rendering thread
<dandrader> duflu, if we could tie a frame number to the resize event it would be perfect
<dandrader> duflu, so the client would know that it will get a buffer with the new size of frame number X
<duflu> dandrader: You can get the "age" of the buffer (number up to 3)
<duflu> which might help
<duflu> Not sure
<duflu> Also, I know... https://bugs.launchpad.net/mir/+bug/1194384
<ubot5> Ubuntu bug 1194384 in Mir "Mir client callbacks are not thread-safe" [High,Triaged]
<dandrader> duflu, the client would internally count the number of buffer swaps it has done on a surface. if mir provided the frame number of the buffer which will have the new size on the resize event, the client would know exacly how many buffer swaps would be needed to reach it. do you think that this could work?
<duflu> dandrader: I say use a while loop. It will cover the case of desktop resizing with a mouse much better (where the resize operation could go on indefinitely)
<anpok> seb128: not sure about hte current status, I know that there was something missing in the intel driver shipped in wily
<anpok> not sure if you have to go to drm-next or a newer mesa..
<alan_g> duflu: are you still set up to test https://code.launchpad.net/~alan-griffiths/mir/fix-1488500/+merge/269171?
<duflu> alan_g: No, but it's likely we can find the offending debs in /var/cache/apt/archives/
<duflu> If not just download them again
<alan_g> duflu: yeah, but making them appear in the directory in the right order isn't so easy
<alan_g> I had to hack the loading code to make it happen on my machine
<duflu> alan_g: Is it raw (unpredictable) directory order?
<alan_g> yep
<duflu> Excellent
<duflu> Definitely not then
<alan_g> nm thanks
<duflu> alan_g: Try a --reinstall on the latest package
<alan_g> I will, when I get home to a wily m/c
<duflu> Motorcycle?
<duflu> You may not want a wily motorcycle
<alan_g> haha
<alan_g> anpok: as you're looking at USC... https://code.launchpad.net/~alan-griffiths/unity-system-compositor/add-display-config-option/+merge/262110
<alan_g> greyback_: I think your NF is addressed? https://code.launchpad.net/~alan-griffiths/unity-system-compositor/add-display-config-option/+merge/262110
<greyback_> alan_g: approved
<alan_g> greyback_: thanks. :)
<alan_g> kdub: thoughts? https://code.launchpad.net/~alan-griffiths/mir/workaround-1441553/+merge/269008/comments/676875
<kdub> alan_g, left a comment, i think a clearer comment is along the lines of "this number should be however many buffers the system has"
<kdub> although, that number is part of what will be deprecated with NBS, so, its hopefully a short lived comment anyways
<alan_g> kdub: thanks
<alan_g> kdub: does this phrasing work?
<kdub> alan_g, seems more accurate and clearer to me at least
<alan_g> Good enough for me.
<camako> seb128, intel has a bug, so GL apps render black under mir-on-x.. Sw apps render ok. A new Mesa driver is being released, which according to RAOF, should fix the issue.
<camako> seb128, this is how I run it : bin/mir_demo_server --platform-input-lib lib/server-modules/server-mesa-x11.so.4
<camako> from a terminal
<alan_g> camako: it was working on my wily system end of last week. Still broken on vivid this week, I assumed the drivers got updated.
<camako> alan_g, what happens on vivid?
<alan_g> the client hangs without painting
<alan_g> But there's also the VT switching bug.
<alan_g> Which I didn't have last week
<robert_ancell> Why is it that GLES can do images in format GL_UNSIGNED_INT_2_10_10_10_REV in glTexSubImage2D but not GL_UNSIGNED_INT_8_8_8_8_REV?
<anpok> o_O
<josharenson> mterry: maybe I'm thinking about this wrong.. I'm running configure_file on qmldir and installing it in the binary directory. This is great. However, the plugin.h and plugin.cpp files need configuring too, but they are source files. Should there be 2 different files in the source dir (plugin_full.h && plugin_integrated.h) OR should I run configure_file on a "master" plugin.h file, and "copy" them to the source directory (seems wei
<josharenson> mterry: that probably isn't very clear, so let me know if you need clarification
<mterry> josharenson, naw you can just say add_definition(-DLIGHTDM_MODE=1) or -DGREETER_MODE=lightdm or something and check that with preprocessor logic
<josharenson> mterry: ack
<mterry> josharenson, I guess you'd use a target-specific version of add_definition.  I think it's like set_target_properties or something
<josharenson> mterry: I'll check that out too
#ubuntu-mir 2015-08-27
<duflu> RAOF: Remind me what part of hotplugging (if any) should or should not work?
<RAOF> Everything except for GPUs, I think.
<duflu> RAOF: Is it a udev event thing?
<RAOF> For the kms platform, yes.
<duflu> Hmm, do we monitor those?
<duflu> I don't remember
<RAOF> We do.
<RAOF> Now, it's entirely possible that mir_proving_server won't *do* anything with the configuration events it receives...
<duflu> RAOF: Yeah I know that bit's missing
<duflu> Sadly I did start implementing the automatic WM stuff for display layout changes. It all got shot down and never landed
<duflu> Hmm, is greyback travelling today?
<seb128> duflu, he's at the sprint in London, he just went to get something to drink, I guess he should be online in a few minutes
<dandrader> duflu, hey
<duflu> dandrader: Good morning
<duflu> I think
<dandrader> duflu, me, anpok and greyback were talking about that streched windows bug
<duflu> dandrader: Yeah seems like one of those bugs where you need fixes in multiple components
<dandrader> duflu, yeah, it's "good morning" :)
<dandrader> duflu, so I got the fix for qtubuntu and qtmir.
<duflu> dandrader: I saw. Can you answer the questions I put in those MPs (if not already)?
<dandrader> duflu, but the approach of swapping more buffers to finally get the one with the new size is seem as a waste of resources and a workaround
<dandrader> duflu, with the proper fix being that mir should ensure that the next buffer the client gets after the resize event would have the new size already. always
<dandrader> duflu, that do you think?
<dandrader> duflu, no, i didn't see your comments on those MPs yet
<dandrader> duflu, didn't get any e-mails from launchpad about then.... strange. let me open their pages
<duflu> dandrader: I think for desktop at least you will eventually need my texture coordinates fix. It's the only way resizing a window with a mouse will look right. But if you don't need it today that's OK
<dandrader> ah, you mean the lp:~vanvugt/qtmir/unstretch  branch. let me see
<duflu> Essentially you need to explain in what use case do you not want square pixels? Because that's what unstretch ensures
 * duflu does multi-monitor testing and might be unavailable for a bit
<kgunn> robert_ancell: willcooke anpok bregma wanna get together in like 10 min to discuss display stack assumptions/reqs for xmir?
<robert_ancell> kgunn, sure
<willcooke> kgunn, yes indeed
<anpok> ok
<willcooke> kgunn, I've reserved Richie meeting room, whereever that is
<kdub> any more reviews? :) https://code.launchpad.net/~kdub/mir/buffer-stream-use-vault/+merge/268633
<mdeslaur> could someone update the documentation here to remove the patched xorg driver requirement? http://unity.ubuntu.com/mir/building_source_for_pc.html
<mdeslaur> (I gather that's no longer necessary with glamor XMir?)
<anpok> and also RAOFs git repository might not be the right one..
<alan_g> kdub: still happy with the changes? https://code.launchpad.net/~alan-griffiths/mir/fix-1486496/+merge/269087
<kdub> looking
<kdub> yep, still lgtm
<kdub> alan_g,
<alan_g> thanks
<alan_g> That didn't work
<RAOF> greyback: Good morning!
<RAOF> Or even evening.
<RAOF> Ba baw!
<RAOF> greyback: In return for you not understanding my copy/paste proposal, I clearly don't quite understand your âscale associated with bufferâ idea âº
<greyback> RAOF: so it appears :D Just hitting the hay, let's chat later on
<RAOF> greyback: Sure. You'll be on the C&P call?
<RAOF> ie: You're still in London?
<greyback> yep
<RAOF> Or, at least, in London's timezone :)
<RAOF> I'll be leaving just after the call, so you might need to get up early if we want to talk.
<greyback> can wait for next week so
<greyback> nighty night!
#ubuntu-mir 2015-08-28
<alan_g> alf: I've got lost in our kms code (it all looks unfamiliar). Any chance you could take a quick look at lp:1489806 in case there's something obvious to you about what happens?
<alf> alan_g: let me see if I can reproduce
<alf> alan_g: OK, I can reproduce. Removing the fatal error, doesn't help, since we don't crash but don't render either, which indicates that this is not a soft failure.
<alan_g> alf: I got something: KMSPageFlipper::schedule_flip() is failing with "Permission denied"
<alf> alan_g: let me check something ...
<alan_g> alf: thanks
<alf> alan_g: Found a workaround, trying to figure out the core cause. Do you want me to take over?
<alan_g> alf: if you've got the time
<alan_g> You've seen the link to lp:1489689?
<alf> alan_g: Yes, can't try it out that moment though. From what I have seen, it doesn't seem related.
<alan_g> np just thought there might be a clue in there
<anpok> alan_g, alf: o_O it happens for me too
<anpok> but --launch-client works btw..
<anpok> whats the difference in behavior
<alan_g> --launch-client uses system()
<alan_g> anpok: what driver is that?
<anpok> i915 kernel and i965 user space
<alan_g> :(  - I was hoping for a new data point.
<alan_g> alf anpok could someone confirm lp:1489806?
<alf> alan_g: done
#ubuntu-mir 2016-08-29
<dandrader> alf_, is there an equivalent of "powerd-cli active" for repowerd?
<dandrader> alf_, I want to ensure the device never does to sleep or anything like that without having to resort to keeping the display on. is there a way?
<ogra_> so i was trying out unity8 on my laptop on the weekend ... and since i want to run my existing X apps (instead of installing duplicates in libertine wasting diskspace) i started them in Xmir windows ...
<ogra_> for most of them this works just fine ...
<ogra_> but some dont ever accept touchpad input at all (keyboard works fine)
<ogra_> i.e.
<ogra_>  Xmir :2 -rootless -flatten -terminate --desktop_file_hint=evolution.desktop & DISPLAY=:2 evolution &
<ogra_> that gets me a properly working evolution ... but only usable via kbd navigation
<ogra_> while:
<ogra_>  Xmir :2 -rootless -flatten -terminate --desktop_file_hint=hexchat.desktop & DISPLAY=:3 hexchat &
<ogra_> err
<ogra_>  Xmir :3 -rootless -flatten -terminate --desktop_file_hint=hexchat.desktop & DISPLAY=:3 hexchat &
<ogra_> gets me fully working input for everything
<ogra_> i couldnt find a bug for this ...
<alf_> dandrader: Îot at the moment, but it would be straightforward to add. Do you need it for local experiments, or does it have to be part of the official package?
<dandrader> alf_, official package. I believe it's a common usecase during development: You have a device on with multiple ssh connections to it. Unless you keep the display on the connections will become slow or stop responding overtime
<dandrader> alf_, keeping the display on just to get the device responsive, beside the extra battery drain, won't do any good for the display itself (will burn in)
<alf_> dandrader: do you want the interface to be same as "display on" (active until you ctrl-c)?
<dandrader> alf_, yep. that how "powerd-cli active" used to work
<alf_> dandrader: ok, I think I can have it upstream soon, but publishing a new package may take some time due to the freeze
<dandrader> alf_, should I report a bug or something to keep track of this request?
<alf_> dandrader: sure, that would be great
<dandrader> alf_, https://bugs.launchpad.net/repowerd/+bug/1618072
<ubot5> Launchpad bug 1618072 in repowerd "Missing "powerd-cli active"" [Undecided,New]
<alf_> dandrader: thanks
<alf_> dandrader: in the meantime you can talk directly to dbus to achieve the same effect
<dandrader> alf_, cool, so what would be the command line?
<alf_> dandrader: actually, now that I try it, you can't with the existing dbus tools, because they exit after making the call, and the request is cancelled
#ubuntu-mir 2016-08-30
<Mirv> RAOF: lpotter is wondering whether the mir code for inputconfig queries would work under Unity 7 or needs active Mir session?
<lpotter> or specifically, does that get compiled with CONFIG+=mirclient ?
<lpotter> looks like it should run only on mir. so would need different builds for unity7 and unity8
<duflu> lpotter: Everything Mir needs a Mir server (MirConnection). Although you could skip that and defer to libinput which we now use for everything
<duflu> Oh, no you can't under Unity7. You'd end up with duplicate and sync issues with the X input
<duflu> As we have done before
<duflu> lpotter, Mirv: Put another way: No there are no significant public bits of Mir that work without being connected to a Mir server
<Mirv> right, that's what I was guessing
<lpotter> hmm. it was contains(QT_CONFIG,mirclient)
<duflu> I'm guessing that refers to mirclient.pc
<duflu> lpotter: what is "it"?
<duflu> Unity7?
 * duflu looks
<Mirv> lpotter: on yakkety Unity 8 desktop I'm btw still getting '0' with ./inputinfo but 1 keyboard (no touchpad or touchscreen) when running the qml-inputinfo.qml
<Mirv> "AT Translated Set 2 keyboard QVariant(::QInputDevice::InputTypeFlags) 2", "number of mouse and keyboard devices: 1", "row count 1", "Button, Keyboard,"
<Mirv> duflu: oh btw my Chromebook is now almost completely usable, with 4.8rc1 kernel. booting from internal ssd works, touch works, keyboard works.. only the sound doesn't work which I'm workarounding with a bluetooth headset
<duflu> Mirv: Well digital output has better sound anyway
<duflu> Mirv: Don't you get the prompt at start-up?
<duflu> Or did you change the default in firmware?
<Mirv> duflu: oh yes I do get that since I haven't unlocked r/w, it's just RW_LEGACY flashed still. so that's another minus.
<duflu> Mirv: Ok, be careful... If you forget Ctrl+L then the firmware will clobber Ubuntu and render it unbootable
<Mirv> lpotter: and since now I'm able to reproduce the cli version's crash on desktop, it's easier to get a backtrace too: http://pastebin.ubuntu.com/23110601/ -  0x00007ffff6f55be4 in mir_connection_create_input_config () from /usr/lib/x86_64-linux-gnu/libmirclient.so.9
<Mirv> duflu: I know, then I'll reinstall
<duflu> Ha. Living dangerously
<duflu> ^^^ mir_connection_* means a valid MirConnection is required :)
<Mirv> duflu: this is from running in terminal app on unity8 session
<Mirv> maybe the connection is not initialized correctly by QInputInfoManagerMir
<duflu> Mirv: Try the 'mirin' tool which should do the same thing
<duflu> Mirv: Or for Unity8:   mirin -- --desktop_file_hint=unity8
<Mirv> duflu: ok! I'm getting 6 devices on my chromebook and 3 on my krillin. that's good to know.
<duflu> alf_: Launchpad is complaining that USC has no releases made in the 0.7 series (https://launchpad.net/ubuntu/+source/unity-system-compositor). But also the ones that were made recently are not marked as released yet
<duflu> alf_: But to be fair that still makes it a better managed project than many others
<alf_> duflu: Well, I just added a release, but LP still complains that 0.7.1 is older than the package 0.7.1+...
<duflu> alf_: That complaint is normal. Always happens
<duflu> I think it's backwards
<duflu> alf_: Still some old "unreleased": https://launchpad.net/unity-system-compositor/+series
<lpotter> Mirv: patch set 3 is working
<Mirv> lpotter: great! I'll update the PPA again.
<dandrader> anpok, was trying out ~andreas-pokorny/mir/nested-hardware-cursor yesterday (will continue today)
<dandrader> anpok, commented out all code in qtmir related to hiding the mir cursor. but still couldn't see the mir cursor. anything I should check? or any tips?
<dandrader> funny that in the past I had trouble hiding it. now it's the other way around :)
<dandrader> anpok, that's on my test laptop, btw
<anpok> dandrader: hm
<anpok> can you show me what you have right now?
<dandrader> anpok, lp:~dandrader/qtmir/controlMirCursor
<dandrader> anpok, it's mixed with code updating qtmir to mir's latest API
<TheKit> so EGL_BAD_DISPLAY happens right after eglCreateContext(egl_display, egl_config, EGL_NO_CONTEXT, default_egl_context_attr) call on my device
<dandrader> anpok, isn't usc configured to not show a cursor on desktop or something like that?
<anpok> yes it is .. but thats fine since the nested server shows the cursor image with an overlayed buffer stream
<anpok> TheKit: so try a different egl_config ...
<dandrader> anpok, I did call the_cursor()->show() in qtmir. Are you saying I should call the show() that takes an image as a parameter?
<anpok> dandrader: in other words the branch - when working as expected - also does everything to disable the usc-cursor
<anpok> hmm
<anpok> if you dont there would be a default arrow it would use
<dandrader> anpok, you mean ~andreas-pokorny/mir/nested-hardware-cursor?
<anpok> dandrader|afk: you need to enable the host cursor control mode..
<dandrader> anpok, ok, didn't do that yet
<dandrader> anpok, still nothing
<anpok> dandrader|afk: wasnt there also  code in qtmir that sets a 0x0 sized CursorImage(s)
<dandrader> anpok, I also had that commented out
#ubuntu-mir 2016-08-31
<Mirv> duflu: oh, I forgot the fun part of my Chromebook. since as you remember I did the original installation from USB stick to USB stick. I copied the contents of USB stick to SSD without partitioning or anything, and then just configured grub long enough inside chroot to that partition so that Ubuntu booted. but the thing is the directories of ChromeOS and Ubuntu on that biggest (26GB) partition don't
<Mirv> clash, so I have a working dual-boot (Ctrl-D vs Ctrl-L) from the same partition..
<Mirv> duflu: it doesn't help though that if I press the space button in the boot screen, everything would be deleted of course (if not canceling before timer is up)
<Mirv> but ChromeOS doesn't detect anything being "corrupted" or anything while I have a booting Ubuntu installation there and grub installed
<Mirv> ...and now back to testing the Mir inputinfo thing on the chromebook
<duflu> Mirv: Sorry, back now. Cool...
<tsdgeos> anpok: you around? i have a touchpad question and mzanetti sent me to you :D
 * duflu 's ears prick up
<tsdgeos> i got a new laptop and the touchpad "tap" doesn't work under unity8 while it works under unity7
<tsdgeos> i.e. mouse click is not registered
<tsdgeos> i've played with the N settings of system-settings to no difference
<tsdgeos> i was wondering how to start to debug it
 * duflu shouts at apport for innocently reporting many crashes
<duflu> tsdgeos: The tick box "Tap to click" in System Settings is ticked right?
<tsdgeos> duflu: yes
<duflu> Just tried Apple Magic Trackpad and tap to click works fine. Although I'm not sure who implements it where
<tsdgeos> duflu: otoh this laptop has a separate button, a "button inside the touchpad" and the tapping in the touchpad
<tsdgeos> the first two work, the third no
<tsdgeos> maybe it is confusing something with so many "buttons"
<duflu> tsdgeos: Very weird. Tap to click works in U8 but not in Mir demo servers and the input report shows no events for it (!?)
<tsdgeos> magic!
<duflu> Indeed
<duflu> Hmm, it's a server configuration thing. I guess U8 sets tap_to_click but not our demos
<duflu> tsdgeos: Often it's a sensitivity problem with many laptops... try a very long tap or very short
<duflu> Many times...
<tsdgeos> duflu: it's weird because the system settings settings seem to do nothing basically
<tsdgeos> there's also a "two finger swipe" setting
<tsdgeos> that i can either have enabled or disabled
<tsdgeos> and two finger swipe will work anyway
<duflu> tsdgeos: Sounds plausible.. the settings themselves not working. And the default is no tap to click so it's not getting applied
<duflu> I think I've seen that happen too. Mouse & Touchpad settings sometimes ignored
<anpok> tsdgeos: re .. libinput tries to come up with defaults for the touchpad based on its hwdb. I have no idea yet why changing that configuration does not work.
<alan_g> greyback: is the only thing "needs fixing" the spurious space character? https://code.launchpad.net/~alan-griffiths/miral/initial-gdk_window_move_to_rect-inspired-placement-logic/+merge/304236/comments/786595
<greyback> alan_g: not necessarily. As you say, it can be left for the following branches, since you've chained them.
<greyback> branch approved
<alan_g> Fixed in lp:~alan-griffiths/miral/connect-gdk_window_move_to_rect-inspired-placement-logic-to-Mir-0.25-API
<TheKit> I tried exactly the same EGL_CONFIG_ID as used by SFOS (7), but still getting EGL_BAD_DISPLAY error
<TheKit> anything else I can try? - http://pastebin.com/X4Y8egEg
<TheKit> kdub, anpok_, it turns out EGL_BAD_DISPLAY wasn't because of bad EGL config
<TheKit> suddenly remembered about apitrace and used it to check
<TheKit> eglMakeCurrent(dpy = NULL, draw = NULL, read = NULL, ctx = NULL) = EGL_FALSE
<TheKit> eglMakeCurrent gets called with NULL display for some reason
#ubuntu-mir 2016-09-01
<alan_g> RAOF: are you about?
<RAOF> alan_g: Yes!
<alan_g> Do you have thoughts about the placement information we should share with clients?
<RAOF> Yes.
<RAOF> For the popup positioning case we need to tell them where (relative to the parent) we placed it.
<alan_g> Policy says we can't tell them screen position, information about avoiding edges could be used to probe this.
<RAOF> So they can render correctly.
<alan_g> So, you would send an "it's here" rectangle?
<RAOF> They *could* use this information to guess where their surfaces are relative to the edge of the screen, but there's nothing guaranteeing that we *only* move surfaces to avoid screen edges.
<RAOF> I would send a âhere's the top-leftâ relative to your parent, because they already know the size, but an âit's hereâ rectangle would also be fine.
<alan_g> @moving surfaces: lp:1616818
<alan_g> Ack, we already send resize.
<alan_g> So a client could create a fullscreen surface, never paint it, and place everything WRT that.
<alan_g> And know where all its "real" surfaces are
<RAOF> Correct.
<RAOF> That is an excellent bug!
<RAOF> Clients can even cut holes in their input surface to let input pass through, so a client drawing on a fullscreen-transparent surface can even behave semi-reasonably.
<alan_g> I'm not sure The Architect would approve
<RAOF> Oh, a client doing that is transparently (hah!) unreasonable.
<RAOF> But it's not something we can easily forbid.
<RAOF> It's not (to my knowledge) a security problem, and it's not something normal clients would actually bother to do.
<alan_g> If it is not forbidden someone will rely on it.
<alan_g> Any toolkit that assumes absolute co-ordinates can get them by a simple hack. That's easier than doing the "right thing".
<RAOF> Is it simple? They need to construct a fullscreen window and then do all their drawing on it.
<RAOF> And then they need to handle drags themselves by rendering their window in a different place on their fullscreen surface...
<alan_g> No, they just need create a fullscreen window and place every other window on it
<alan_g> If they never paint that root window it never affects input and never gets drawn
<RAOF> If they never paint it they never get to attach surfaces to it?
<RAOF> Also, you can only attach surfaces of type tip?
<RAOF> And you can't morph tipânormal.
<RAOF> To be clear: you only get âhere's the top-leftâ when you're placing a surface relative to another, and you can't do that for most surface types.
<alan_g> "most" being less than half of MirSurfaceType? ;)
<alan_g> But I see the point
<RAOF> Well, you can't place normal surfaces or (I think?) anything that can morph to normal surfaces relatively.
<alan_g> Placement only works if there's a parent
<alan_g> And we have rules for that
<RAOF> I would also be happy to restrict placement to fully-constructed (ie: with content) surfaces.
<alan_g> Doesn't really help: it can have a bufferstream with a single transparent(?) pixel
<RAOF> It then eats input.
<RAOF> Unless it shapes that away, of course ;)
<alan_g> And bufferstreams can be lightyears from the surface
 * alan_g isn't convinced by that "feature"
<RAOF> greyback wants them to be clipped to the surface.
 * RAOF shrugs. There are arguments either way.
<alan_g> OK, I've got enough to start a thread in mir-devel
<alan_g> greyback *can* modify their placement in the window management policy
<RAOF> He shouldn't be able to.
<RAOF> streams are meant to be sub-WM.
<RAOF> Or, rather, streams are meant to be invisible to the WM.
<alan_g> Then please log a bug against MirAL to hide them there
<RAOF> Will do.
<alan_g> Thanks
<RAOF> alan_g: AbstractShell currently handles stream configuration itself; how does that interact with MirAL?
<alan_g> WindowSpecification::streams()
<alan_g> The WM policy see that before passing the modification request to AS
<RAOF> So the flow goes frontend -> MirAL -> AS? OK.
<RAOF> I hope bug# 1619165 is sufficiently useful?
<alan_g> frontend -> AS -> MirAL::BasicWM -> WM policy -> MirAL::BasicWM -> AS
<RAOF> Ah, in that case MirAL doesn't need to do anything. AS strips out stream configuration before passing the request on.
<RAOF> See AbstractShell::modify_surface.
<RAOF> It first checks to see if there's any stream configuration in there, then consumes and applies it.
<RAOF> Then passes it on to the WM.
<RAOF> (If there's anything left)
<alan_g> Hmm. That would be wrong too. I'll check later. (Must go right now)
 * RAOF â EOD.
<alan_g> RAOF: I know you're EOD, but, although AbstractShell::modify_surface() strips streams, AbstractShell::create_surface() doesn't. Which is inconstant at best.
<alan_g> greyback: attente this may interest you enough to vote - https://code.launchpad.net/~alan-griffiths/mir/support-gdk_window_move_to_rect/+merge/304474
<mterry> Hello!  I'm getting an error on a branch that I tried to set approved, but when the CI built it: "Package 'uuid', required by 'mirserver', not found" -- known issue?
<mterry> alf_: ^ this was on the default-wallpaper branch
<alf_> mterry: Probably a problem in Mir trunk, I will take a look
<alan_g> alf_: mterry sounds like bug 1617435
<ubot5> bug 1617435 in mir (Ubuntu) "libmirserver-dev is missing a depends for uuid-dev" [Medium,Triaged] https://launchpad.net/bugs/1617435
<alan_g> Fixed -r 3679
<mterry> alan_g: awesome looks right.  Only scheduled for 0.25 tho, wonder when that comes out.  In meantime, stuff isn't buildable
<alf_> alan_g: right, although I think we missed a part of the fix, which is libmirserver-dev depending on uuid-dev
<alf_> mterry: USC trunk builds against Mir trunk, so we don't have to wait for release to merge
<alan_g> /o\
<alf_> alan_g: :)
<mterry> alf_: yes cool, and right on the missing Depends
<mterry> alf_: indeed if we didn't build against Mir trunk, I guess I wouldn't have seen the error  :)
<alan_g> who wants to fix it?
<mterry> I can whip up a branch, should be trivial
<alan_g> thanks
<mterry> alan_g: https://code.launchpad.net/~mterry/mir/missing-uuid-dep/+merge/304645
<alf_> mterry: alan_g: approved
<mterry> alf_: awesome thanks.  Is there a way to fast track it to trunk to unblock other branches?
<alf_> mterry: It should land within the next hour or so. If CI is being difficult we can merge manually.
<mterry> alf_: oh nice, I'm not familiar with mir landings.  But I guess that makes sense if your trunk doesn't need to track archive
<mterry> I was thinking a silo and all that jazz, but right, that's not needed
<mterry> Thanks
<alf_> mterry: Actually for USC builds to use the new version it should land in the mir-staging PPA using our mir-daily recipe. To expedite, I will trigger the recipe after the fix reaches trunk. So I guess that's 2-3 hours total.
<mterry> That's no biggie.  Thanks
<alan_g> kdub: satisfied? https://code.launchpad.net/~alan-griffiths/mir/support-gdk_window_move_to_rect/+merge/304474
<kdub> alan_g, yes, thanks
<mterry> alf_: do you have any idea why NestedServer.named_cursor_image_changes_are_forwarded_to_host would fail in the autoland run for the uuid-dev change?   https://mir-jenkins.ubuntu.com/job/build-2-binpkg-mir/2040/arch=amd64,compiler=gcc,platform=mesa,release=xenial+overlay/consoleFull
<kdub> mterry, thats one of the tests that we've been having some problems with
<kdub> you can probably just ignore/retrigger, its a racy
<kdub> https://bugs.launchpad.net/mir/+bug/1523621
<ubot5> Launchpad bug 1523621 in Mir "[ FAILED ] NestedServer.*_cursor_*" [High,In progress]
#ubuntu-mir 2016-09-02
<duflu> anpok_: I saw changes in GTK-Mir behaviour recently, but your fixes are missing still...(?)
<anpok_> hum .. I havent followed up after returning from vacation.
<duflu> That's fine. Things don't happen quickly. It's just a concern if you expected them to be released already
<anpok_> The larger chunk of changes should already be in.
<duflu> anpok_: Recreating windows on resize still happens
<anpok_> Which distribution?
<duflu> By "still" I mean I only saw it for the first time in the latest GTK
<duflu> anpok_: yakkety
<anpok_> ah I am on the gtk ppa
<duflu> And nautilus runs finally!
<duflu> Except it's as broken as everything else
<duflu> anpok_: Actually I might be wrong. yakkety got updated last night with GTK-Mir fixes. I haven't restested
<anpok_> but be aware that in mir_demo_server gtk will have the same odd behaviors like qt widget apps
<duflu> Meh. How many people ust gtk or qt?
<duflu> use
<duflu> That's dyslexic sarcasm coupled with the fact that I've been using 'ust' variable names a lot
<anpok_> The problem is due to missing pieces and bugs in the window manager policy implementations in the example servers
<anpok_> miral is .. fine .. or at least finer ..
<duflu> anpok_: It's noticeably better in demo servers on yakkety (Mir 0.24.0)
<duflu> anpok_: Are you using xenial or yakkety?
<anpok_> main machine still on xenial
<duflu> anpok_: OK. Just FYI the window management in yakkety's mir-demos is better
<mterry> Huh.  So I have a new mir build issue.  Now I can't build unity-system-compositor trunk on yakkety?  mir::graphics::NativeDisplay does not seem to be recognized
<kdub> mterry, it does look like there was breakage there since 0.24
<kdub> not aware of a compat branch
<anpok> hm builds against lp:mir it seems ..
 * alan_g once more wishes for a properly integrated CI that picks up these things
<mterry> Ooh new mir ftbfs fun
<mterry> Now I'm trying to build lp:unity-system-compositor/ubuntu in -proposed (i.e. in silo).  And I get a test run error about mismatched protobuf versions.  mir is still built against libprotobuf-lite9v5.  Looks like it needs a no-change rebuild
<mterry> ah, doko is on it already  :)
<mterry> but it ftbfs because of a protobuf test segfault
<mterry> sigh
<alan_g> mterry: https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1619616
<ubot5> Launchpad bug 1619616 in mir (Ubuntu) "mir fails to build with protobuf3" [Critical,Confirmed]
<alan_g> I'm trying to reproduce locally to debug atm
<mterry> alan_g: thank you!
<aries_m> hi guys! quick question, Im using Mir with the Ubuntu Touch Aquaris M10, but unable to change my keyboard layout with the graphical interface. Which one would be the command line equivalent to setxkbmap so I can change the keyboard layout?
<aries_m> sry, connection closed, I couldnt read the responses, if any
<mterry> aries_m: you didn't miss any responses.  You should be able to change your layout in System Settings
<aries_m> mterry: Im afraid I try, but it always resets to English alt
<aries_m> and Im aiming to English Alt /w AltGr
<mterry> aries_m: ah when I've used it, it seemed to work.  Can you correctly toggle between settings in the keyboard indicator maybe?  If you can't get it to work still, try ltinkl in #ubuntu-unity on Monday
<aries_m> mterry: I can toggle, but if I come back to the settings after closing it, its reset to English Alt
<aries_m> mterry: ltinkl?
<mterry> aries_m: Lukas Tinkl, that's his nick
<aries_m> mterry: got it! thx for the help! :)
#ubuntu-mir 2017-08-29
<alan_g> RAOF: hanging out today?
<RAOF> alan_g: Just noticed the time!
<alan_g> You must be having fun! ;)
<alan_g> Hmm. An unexpected downside to epoch...
<alan_g> 09:22:07 mir_1.0.0+fetch5145bzr4250.orig.tar.gz
<alan_g> 09:22:07 + cd mir-1:1.0.0+fetch5145bzr4250
<alan_g> 09:22:07 /tmp/hudson3553452967355580048.sh: line 24: cd: mir-1:1.0.0+fetch5145bzr4250: No such file or directory
<alan_g> https://mir-jenkins.ubuntu.com/job/build-1-sourcepkg/release=xenial/5134/console
<xnox> please don't use epochs =) they are weird in many ways.
<xnox> plus 1.0.0 >> 0.27.0 and no epoch is required.
<xnox> (at least from ubuntu perspective)
<xnox> (no epochs, if you can that is)
<alan_g> xnox: I want to merge miral into mir and that's at 1.4
<alan_g> for now, the above problem just looks like a regex for extracting "UPSTREAM_VERSION" that doesn't know about epochs.
<alan_g> Hm. No that's not it.
<xnox> alan_g, dpkg-source, when unpacking things skips epoch (as that is "debian" prefix)
<alan_g> xnox: and so it should.
<xnox>  line 24: cd: mir-1:1.0.0+fetch5145bzr4250 -> looks like something is trying to change into a directory with an epoch; yet i don't think any standard tools would create such a dir.
<xnox> anyway, not my code, i should go fix broken things instead =)
<alan_g> xnox: that's why the directory doesn't exist. I just need to correct the cd command
<alan_g> This is wrong: UPSTREAM_VERSION=`perl -n -e '/^Version:\s(.*)-[0-9]ubuntu.*$/ && print $1' ${DSC}`
<alan_g> I just need to get the right number of escapes to work in jenkins
<xnox> ooh, ok.
<xnox> in general, in debian/rules, i use "include /usr/share/dpkg/default.mk" and use the DEB_UPSTREAM_EPOCH variable or some such, I guess having a makefile is too much here.
<xnox> but that is equavalent to something liek: $ dpkg-parsechangelog -SVersion | sed -e 's/-[^-]*$$//'
<xnox> hm, nope
<alan_g> xnox: I can make this work. But if you have a better idea than an epoch, then please tell.
<xnox> from what i can tell the canonical variables as created by /usr/share/dpkg/pkg-info.mk appear to be broken
<xnox> and those parse debian/changelog, which is not extracted yet... (given that above tries to parse .dsc file)
<alan_g> xnox: I can insert "([0-9]:)?" into the the above perl but (unsurprisingly) things just break a little later
<xnox> $ cat openssh_7.5p1-8.dsc | sed -n 's|Version: [0-9]\?:\?\(.*\)-.*|\1|p'
<xnox> is my best attempt, which will not work when upstream version has dashes in it (legal) or with double-digit epoch (also legal)
<xnox> and it fails with non-epoch .dsc
<xnox> sigh
<xnox> $ echo openssh_7.5p1-8.dsc | cut -d_ -f2 | cut -d- -f1
<xnox> =)))))
<xnox> $ echo ${DSC} | cut -d_ -f2 | cut -d- -f1
<alan_g> xnox: FWIW it seemed to be just one script that was epoch-unaware. in the end I fixed the uses that broke, and left the variables alone: e.g. cd "${SOURCE}-${UPSTREAM_VERSION#[0-9]:}" (etc)
<xnox> =)
<xnox> simples
 * alan_g once again wishes the CI configuration were backed by version control.
<xnox> =/
<xnox> yeah, in our team we do use git repositories, that have jobs in yaml, and then jenkins jobs builder creates it, but i still think there are manual bootstrap jobs and/or things that are manually twiddled.
<alan_g> xnox: you didn't suggest a less bad idea than epoch. Does that mean I'm doing something sane?
<xnox> alan_g, less bad idea was to simply use 1.5 version number which is higher than miral&mir
<xnox> without epochs.
<xnox> epochs are evil =)
<xnox> as you will never ever be able to drop an epoch, and it looks weird, and people get confused.
<xnox> or e.g. 1.4.1
<ogra_> if you want friendly epochs ... use snaps ;)
<xnox> alan_g, and just because version number i 1.4.1 it is still perfectly fine to claim that mir api/abi is 1.0.Y
<xnox> or not, as you wish.
<alan_g> I suspect that going from 0.27 to 1.5 is no more popular.
<xnox> alan_g, go from 0.27 to 28?
<xnox> =)
<alan_g> But I'll test that out.
<xnox> yeah, it's all very physcologically driven.
<alan_g> greyback: concerns addressed? https://code.launchpad.net/~alan-griffiths/mir/move-miral-to-mir/+merge/329455
<xnox>  but do expect people to refer to the new thing a 1.1.0.0, because people do not notice the colon epoch 1:1.0.0
<xnox>  but do expect people to refer to the new thing as 1.1.0.0, because people do not notice the colon epoch 1:1.0.0
#ubuntu-mir 2017-08-30
<RAOF> There's nothing that I like more than hakcing around in mir-jenkins.
<RAOF> Booo!
<RAOF> I can't avoid making cross-compilation work properly; sbuild won't load binfmt_misc, so the armhf-on-amd64 binary doesn't run.
<alan_g> RAOF: I know you're done for the day, but could you add reviewing this to your list for tomorrow? https://code.launchpad.net/~alan-griffiths/mir/move-miral-to-mir-no-more-miral-packages/+merge/329822
<RAOF> Sure
<RAOF> It'll give me something to do that's not contorting CMake into ever more convoluted cross-compiling knots.
 * alan_g wonders how much cross-compiling is needed.
<RAOF> I could commit the generated header, I guess...
<RAOF> Hmm. Or generate it pre-build?
<alan_g> That's not totally stupid. I have a target to (re)generate miral/symbols.map but it is also committed
 * alan_g wonders why one working copy keeps hitting "internal compiler error" when the same code & build options works fine in another.
#ubuntu-mir 2017-08-31
<alan_g> xnox: after your comments on my using an epoch, can I get your thoughts on my attempt to avoid it? (I'm not confident of my debian incantations) https://code.launchpad.net/~alan-griffiths/mir/move-miral-to-mir-no-more-miral-packages/+merge/329993
<xnox> alan_g, let me tell you a secret =)
<xnox> alan_g, binary package version number, may not match source package version numbers =)
<alan_g> xnox: tell me more
<xnox> alan_g, ideally you should keep libmiral binary packages, as each shared library, ideally, should be shipped in a stand alone package (e.g. like src:boost1.64 ships gazillion libboost*foo packages)
<xnox> alan_g, and you can specify override_dh_ commands with -p options to set particular version numbers for some packages
<xnox> e.g. let me find an example
<xnox> such that e.g. src:mir generates libmir1 at 1.0.0 yet libmiral at 1.5.0
<xnox> etc.
<alan_g> There is really only libmiral that it makes sense to keep
<xnox> but one has to be careful to derive the version numbers right, such that they are based on debian/changelog and increment
<xnox> alan_g, yeap exmaples, binaries, dev can all go, but libmiral1 or what not is useful to have
<xnox> alan_g, i have a call, but i will review and get back to you!
<alan_g> xnox: great! thanks
<alan_g> xnox: did you find an example?
<xnox> alan_g, i'm still in meetings =)
<alan_g> xnox: np.
