[00:20] <robert_ancell> RAOF, on that Xubuntu list there seem to be two chipsets that have bad failures, GeForce 6150SE nForce 430 and RV370/M22. Do we have known bugs for that?
[00:30] <RAOF> robert_ancell: I haven't found any yet.
[00:56] <racarr> Off for now!
[00:56] <racarr> ill come back later and iterate on connect-display-request-merge and client-focus-notifications if people have time to review
[02:36] <RAOF> Grr. I hate this code.
[02:38] <duflu> ?
[02:45] <RAOF> Oh, splitting up the root window.
[02:46] <RAOF> I'll just get it to work now, and then refactor out all the ugly.
[02:46] <RAOF> Or at least as most ugly as possible.
[02:51] <duflu> Oh, right, multimonitor?
[03:01] <RAOF> Yeah.
[04:06] <RAOF> duflu: Oh, I seem to remember you having thoughts on a hw cursor api?
[04:08] <duflu> RAOF: Only minor thoughts...
[04:08] <duflu> Also someone started already...
[04:09] <RAOF> Oh, yeah.
[04:09] <RAOF> That's right.
[04:10] <duflu> RAOF: Bug 1189775, bug 1206780
[04:12] <RAOF> HW cursor is a prerequisite of useful GLX bypass, so I may need to pick that up.
[05:15] <tvoss|eod> good morning
[05:22] <RAOF> tvoss|eod: Good morning
[05:23] <tvoss> RAOF, hey there :) how is it going?
[05:23] <RAOF> This code is ugly, and I hate it.
[05:23] <tvoss> RAOF, the multi-monitor stuff?
[05:23] <RAOF> Yeah.
[05:24] <RAOF> But I'll get it to work, and then unuglify it.
[05:24] <RAOF> To the extent that's possible.
[05:26] <alf__> RAOF: FYI, a branch adding some of the requested extra display configuration information has landed
[05:26] <RAOF> Woot!
[05:26] <RAOF> alf__: Thanks.
[05:26] <alf__> RAOF: basically Output::type, Card::max_simultaneous_outputs, Output::preferred_mode
[05:27] <RAOF> Nifty. That'll mostly complete the read-end of randr.
[05:30] <didrocks> duflu: it seems you were right, since we remove this unity_support_test call from opengl, the ATI hang isn't showing (yet)
[05:31] <didrocks> it's still a workaround and not a fix, but good enough for me :)
[05:34] <duflu> didrocks: The guess is well-educated. Mixing multiple GL contexts with fork/exec is apparently a bad idea, sometimes
[05:35] <duflu> ... which means don't run a GL app (unity_support_test) from within a GL app (compiz)
[05:35] <didrocks> duflu: I still wonder how/why u-s-c exacerbate this behavior, but at this stage, this is good enough :)
[05:35] <didrocks> duflu: but when compiz is starting another app
[05:36] <didrocks> from the launcher
[05:36] <didrocks> it fork/exec another potential GL app
[05:36] <RAOF> Wasn't it hybris that exacerbated this behaviour?
[05:36] <duflu> didrocks: I'm more curious why a few people hit the problem a year ago, but the rest of us did not
[05:36] <didrocks> (but I guess you meant during opengl initializion)
[05:36] <didrocks> RAOF: no :/
[05:36] <didrocks> RAOF: we got more faulty ran this week-end, after we removed hybris
[05:36] <didrocks> duflu: right, that's really weird
[05:37] <duflu> didrocks: One explanation is that very few people actually attempt to use hardware that would fail unity_support_test
[05:37] <duflu> Hardware that's not a VM...
[05:39] <didrocks> possibly, but we see that ATI can fail in that case, but it never failed with plan xorg, just with xmir
[05:39] <didrocks> so it's not only hardware-related
[05:39] <didrocks> there is a chain of event
[05:48] <didrocks> duflu: argh, I talked too quick
[05:48] <didrocks> RAOF: duflu: ATI machine stuck now :/
[05:48] <didrocks> Mirv: FYI ^
[05:49]  * didrocks checks the compiz version
[05:50] <RAOF> Grargh!
[05:50] <didrocks> 1:0.9.9~daily13.04.18.1~13.04-0ubuntu4
[05:50] <didrocks> ok, we have the one with the fixed version :/
[05:51] <didrocks> RAOF: do you think anything you can do or I should reboot the machine?
[05:51] <RAOF> It might be worth attaching gdb again and confirming that it's blocked in the same place?
[05:51] <didrocks> RAOF: want access?
[05:52] <RAOF> Yeah, why not.
[05:52] <RAOF> I've realised that I can't actually get the setting part of multi-monitor to work until I can bind a surface to an output, so let's play SSH!
[05:52] <didrocks> ;)
[07:06] <dholbach> good morning
[07:12] <tsdgeos> racarr: any luck with my nexus4 issue?
[07:15] <tsdgeos> yay
[07:15] <tsdgeos> at least now it's crashing :D
[07:19] <duflu> tsdgeos: Sounds like your expectations have lowered :/
[07:24] <tsdgeos> duflu: well it was doing nothing, it now crashes
[07:24] <tsdgeos> tbh that is a small improvement :D
[08:02] <sil2100> duflu: hi! It seems the compiz unity-support-test running outside of compiz did not help in the u-s-c crashes on ati, sadly
[08:02] <duflu> sil2100: Then I am out of ideas
[08:03] <smspillaz> sil2100: stacktrace ?
[08:09] <sil2100> smspillaz: not sure if we have any, the machine is usually in really bad condition when that happens
[08:50] <duflu> tsdgeos: Confirmed, after upgrading to the latest phablet images, N4 hangs instead of rendering. Black screen :/
[08:50] <tsdgeos> \o/
[08:50] <tsdgeos> it's not only me being stupid
[08:51] <duflu> Not at all
[08:54] <duflu> tsdgeos: Do you have a bug logged in mir yet?
[08:54] <tsdgeos> i think not
[08:54] <tsdgeos> let me check
[08:54] <tsdgeos> duflu: nope, i was waiting for a second person to confirm
[08:55] <tsdgeos> can do now if you want
[08:55] <duflu> tsdgeos: Yes please. And don't be afraid to log bugs early and confirm later
[09:16]  * duflu shuts down to swap video cards
[09:22] <tsdgeos> duflu: https://bugs.launchpad.net/mir/+bug/1211694
[09:22] <duflu> tsdgeos: Thanks
[09:22] <tsdgeos> duflu: sorry i did not remember your name
[09:22] <tsdgeos> so i wrote your ircnick
[09:23] <duflu> tsdgeos: /whois duflu
[09:23]  * tsdgeos is not as good with nicks <-> names <-> faces has he'd like
[09:23] <tsdgeos> duflu: i know but you were not here when i was filling the bug :D
[09:23] <duflu> tsdgeos: Sorry, I am playing with video cards. I won't have much attention on IRC for the rest of the day
[09:24] <tsdgeos> duflu: no worries :-)
[09:27] <RAOF> smspillaz: Not (obviously) compiz's fault - X is hung in DRI2Authenticate, waiting on xmir_drm_auth_magic to complete.
[09:28] <duflu> RAOF: Any chance we will/can accept the community-provided patch for https://bugs.launchpad.net/mir/+bug/1195425 ?
[09:28] <duflu> (comment #12)
[09:29] <RAOF> Yes, I can apply that.
[09:30] <duflu> RAOF: For the record, I have nothing to do with it. Just noticed the bug and community activity therein
[09:31] <RAOF> Yeah, I was aware of the problem and the patch (which was also a reply to the upstream patch submission bit); I just didn't think we hit it.
[09:31] <RAOF> Thanks for pinging me with it.
[09:32] <duflu> RAOF: I'm playing with a Cedar card and have serious corruption in render_surfaces. But haven't tried the patch
[09:32] <RAOF> The patch is only for XMir; render_surfaces is going to be a different problem.
[09:33] <duflu> RAOF: You mean https://launchpadlibrarian.net/144789844/mir_fix_tiling.diff ?
[09:33] <RAOF> Yes
[09:33] <duflu> Hmm
[09:34] <RAOF> Possibly in the mesa patch ;)
[09:38] <duflu> RAOF: Ok, just noticed the render_surfaces bug is a recent regression. Likely caused by the switch branch and the bug is limited only to render_surfaces with its wacky buffer initialization
[10:01]  * duflu changes graphics cards again
[10:04] <RAOF> didrocks: ppa:raof/aubergine contains an annotated mir/xmir stack that'll dump info about the drm auth process.
[10:04] <duflu> Woo, 3 minutes. New record?
[10:04] <RAOF> That's nice and fast.
[10:05] <duflu> Can't do that with Windows
[10:05] <didrocks> RAOF: excellent! I think next run, when the machine will be freed, you won't be around
[10:05]  * RAOF uses his bios to switch graphics cards, so it's approximately 1 standard boot time to change.
[10:05] <RAOF> didrocks: That is highly likely :)
[10:05] <didrocks> RAOF: do you prefer to connect live when we try that? we can do that tomorrow in that case
[10:05] <RAOF> didrocks: The interesting stuff will be in /var/log/Xorg.0.log, and /var/log/lightdm/*
[10:06] <RAOF> I'm happy for this to just get run and have the logs dumped on me.
[10:06] <didrocks> RAOF: ok, let's try that :)
[10:06] <didrocks> RAOF: one run passed successfully meanwhile FYI
[10:06] <didrocks> so it's not a 100% hit unfortunately :/
[10:06] <RAOF> Yay. Race condition!
[10:07] <didrocks> RAOF: oh, I'm afraid we'll get newer Mir though throughout the day
[10:07] <didrocks> RAOF: can you try to push mir with a higher version?
[10:07] <RAOF> Allow me to upload to my ppa again, this time with an epoch?
[10:07] <didrocks> RAOF: sounds good :)
[10:07] <mlankhorst> already? haha
[10:07] <didrocks> I would never thought I would say epoch is good :p
[10:07] <didrocks> think*
[10:30] <didrocks> RAOF: I'm a little bit afraid you uploaded u-s-c to early without an artificial bump on debian/control
[10:30] <didrocks> RAOF: so it's getting published before Mir
[10:30] <didrocks> and so package dependency won't work
[11:11] <RAOF> didrocks: Oh, arse. Allow me to fix that.
[11:12] <mlankhorst> lol
[11:12] <mlankhorst> one more epoch later!
[11:17] <RAOF> Hm. The 3.11 kernel looks like it might have fixed the hsw texture corruption on suspend/resume.
[12:43] <didrocks> sil2100: RAOF: I think I just press the "I'm feeling lucky" button and just get the ati card screwed starting at the first run!
[12:43]  * didrocks now collect logs
[12:55] <didrocks> RAOF: https://bugs.launchpad.net/mir/+bug/1204939/comments/11
[12:57] <didrocks> sil2100: ok, now that those infos are extracted, I'm rebooting the ati machine FYI ^
[14:17] <sil2100> ;)
[14:17]  * sil2100 checks the logs
[14:23] <sil2100> didrocks: I guess Daniel might take a look at those logs as well, maybe he would have some ideas as well - if he has enough time to look at them
[14:24] <didrocks> yeah
[14:31] <sil2100> didrocks: I think we need to make sure everyone knows what happened
[14:31] <sil2100> didrocks: did you poke Pat and Kevin?
[14:31] <didrocks> sil2100: oliver is doing the communication work :)
[14:32] <sil2100> Awesome
[15:01] <sil2100> didrocks: Apps finished, all green :O
[15:02] <didrocks> sil2100: wooow \o/ green again
[15:02] <sil2100> :O <- shocked face
[15:02] <didrocks> sil2100: running more make it less a burden to fix issues
[15:02] <sil2100> didrocks: so it seems, as less changes are in during releases, so even less possible stacks to fail at once ;p
[15:03] <didrocks> right :)
[16:30] <xjunior> is ickle around?
[16:30] <xjunior> Chris Wilson
[20:55] <olli_> RAOF, ping
[21:04] <olli_> thomi, ping
[21:04] <thomi> olli_: Hi
[21:04] <olli_> thomi, hey
[21:05] <olli_> thomi, mind having a look at http://bazaar.launchpad.net/~ubuntu-testcase/ubuntu-manual-tests/trunk/view/head:/testcases/packages/1572_xMir to see if this is in good shape for a round of call for testing as part of balloons cadence testing
[21:05] <thomi> sure
[21:05] <olli_> thomi, focus for this should be to test mir out of archive
[21:05] <olli_> and to get some wider HW coverage from the community
[21:05] <olli_> balloons mentioned he is accepting changes via branches ;)
[21:06] <olli_> thomi, thx
[21:06] <thomi> yeah OK, there are a few tweaks I'd make
[21:06] <thomi> olli_: what's the timeline for this?
[21:06] <olli_> the CFT will happen on Sat 8/17
[21:07] <olli_> so before EOW, preferable earlier
[21:07] <thomi> olli_: OK.
[21:07] <thomi> I'll finish writing this looooong bug report, then get to it :)
[21:07] <olli_> thomi, awesome
[21:07] <olli_> thomi, we will provide them with additional information on
[21:07] <olli_> how to install etc
[21:08] <olli_> as well as release notes type of information (i.e. don't file MM not working...)
[21:08] <olli_> so you don't have to worry about it
[21:08] <olli_> but you can if you want ;)
[21:08] <thomi> olli_: if MM doesn't work, we should remove it from that list
[21:08] <olli_> I'll start putting something together and copy you on it for comments
[21:09] <thomi> cool
[21:09] <thomi> thanks
[21:09] <olli_> coolio
[21:09] <olli_> thx
[22:19] <racarr> Client-focus-notifications v5!
[22:28] <racarr> Is anyone besides tsedgos able to reproduce this mir not working on nexus 4 thing I have been hearing about
[22:28] <racarr> I just tested fresh everything and it seems fine
[22:42] <olli_> racarr, ev was having issues
[23:08] <RAOF> Ok. What the hell is going on with the jenkins ATI machine?
[23:25] <bschaefer> RAOF, hey, so I've been seeing these memory leaks, but they look like libEGL and not the clients fault: https://bugs.launchpad.net/mir/+bug/1211982
[23:25] <bschaefer> unless i've missed cleaning something up, or the demos missed cleaning something up
[23:26] <RAOF> That does look a lot like a leak in Mir's EGL, doesn't it.
[23:27] <bschaefer> RAOF, yeah, i've seen the dri2_create_screen leak for sometime now...but figure to at lease poke you about it
[23:27] <RAOF> Pity about those ??? frames :)
[23:27] <bschaefer> yeaah
[23:27] <RAOF> Got the -dbgsym packages installed?
[23:27]  * bschaefer checks
[23:27] <bschaefer> well im assuming I don't :)
[23:29] <bschaefer> RAOF, http://paste.ubuntu.com/5983019/
[23:29] <bschaefer> for the first one, still some ?? for the second, let me dig for those packages
[23:29] <RAOF> Yup, there's the leak.
[23:31] <bschaefer> RAOF, interesting, well let me collect better info and update the bug
[23:32] <bschaefer> dang... just empty ??? that are left: http://paste.ubuntu.com/5983021/
[23:33]  * bschaefer wondres which package that would be
[23:33] <RAOF> libgl1-mesa-dri-dbg, I wager.
[23:34]  * bschaefer installing
[23:35] <jono> hey all
[23:35] <jono> btw, I am collating Mir testing of gpus at https://wiki.ubuntu.com/Mir/GPUTesting
[23:35] <RAOF> Hey jono!
[23:35] <bschaefer> still question marks for that one...but it filled in a bunch of ??? for an uninted var:
[23:35] <jono> hey RAOF :-)
[23:35] <bschaefer> http://paste.ubuntu.com/5983027/
[23:35] <jono> this should provide a better idea of overall gpu coverage
[23:36] <bschaefer> RAOF, ill look for some dbg packges, and take a look at the source code to figure out which lib is being called
[23:36] <bschaefer> thanks for the info!
[23:37] <bschaefer> the full log atm: just 3 more ??? to go... http://paste.ubuntu.com/5983033/
[23:38] <RAOF> Ah. That ioctl is going to be noise.
[23:39] <bschaefer> cool, then just 2 leaks that I see in egl apps, and with sdl on the mir side of things :) which is not a lot
[23:39] <RAOF> How annoying are these leaks for you? I(should)'ve plugged the create_window_surface one, and I can check out the other one.
[23:40] <bschaefer> RAOF, not at all annoying, just saw them when I was checking my own memory leakage
[23:40] <RAOF> Ok.
[23:40] <RAOF> I'll fold them in next time I need to update mesa then.
[23:40] <bschaefer> RAOF, everything is still running smooth, and its only during creation, and termination of the program so its not a huge deal
[23:40] <RAOF> Yeah. You'll also leak once per surface you create, but you're unlikely to do that in a loop :)
[23:41] <bschaefer> one would hope :), depending on the application...but yes