[00:11] <RAOF> Sarvatt: You say setting CLUTTER_VBLANK=none fixes it?
[00:11] <Sarvatt> yup
[00:11] <Sarvatt> has to be exported, quadrapassel and unity launched from a terminal dont accept clutter env variables
[00:12] <Sarvatt> DISPLAY=:0 CLUTTER_VBLANK=dri mutter --replace --mutter-plugins=libunity-mutter works too
[00:12] <RAOF> What‽
[00:12] <RAOF> My unity's working just fine, though.
[00:12] <Sarvatt> tried your netbook?
[00:12] <RAOF> Ah.  But there's a unity update installing now.  Are you suggesting that if I restart, I'll kill unity?
[00:13] <Sarvatt> i upgraded everything last night and saw this this morning
[00:13] <Sarvatt> about 24 hours hours ago
[00:17] <RAOF> Ok.  Let's see if the new unity works here, then…
[00:20] <RAOF> Yup.  Unity runs fine here.
[00:21] <RAOF> Or is this only on nouveau that you find Unity fails to start?
[00:24] <Sarvatt> netbook 945
[00:24] <Sarvatt> i totally wouldn't be surprised if it was something local here screwing it up
[00:24] <RAOF> Boo.
[00:25] <RAOF> That would mean I'd need to restart my irc bouncer in order to get the i945 un-hidden.
[00:28] <RAOF> Ah, ok.  That's why unsetting vblank would do something; it's dying in DRI2GetMSC, which I don't think clutter does if it can't vsync.
[03:29] <Sarvatt> 0 luck figuring this out
[03:30] <Sarvatt> if it wasn't made into such a big deal before it was fixed last i'd even start to believe it never worked at this point.. :)
[03:31] <Sarvatt> anyone know if there is an archive of daily livecd's anywhere?
[03:34] <Sarvatt> watch it be something wacky like a conf file that was exporting CLUTTER_VBLANK only getting cleaned up recently
[03:40] <RAOF> Well, there _was_ that, as a part of the OMG! UNITY'S BROKEN firedrill.
[03:42] <RAOF> I'm poking into the “(quadrapassel:3513): ClutterGLX-CRITICAL **: Unable to make the stage window 0x4800006 the current GLX drawable” code; I think that's likely where the problem is.
[03:43] <Sarvatt> that error has been spewed since the dawn of time though
[03:43] <RAOF> I think there might be more of them than when it worked :/
[03:44] <Sarvatt> quadrapassel has always done 3 for me
[03:44] <Sarvatt> at least since early lucid when i started screwing with it
[03:44] <RAOF> The problem *appears* to be that clutter calls GetMSC before there's a valid drawable bound to the context.
[03:45] <Sarvatt> what I don't get is that mesa 20100909-0ubuntu3 doesn't work with it now
[03:45] <Sarvatt> oh I should try 20100909-0ubuntu2
[03:45] <RAOF> That would be interesting.
[03:46] <RAOF> There's a plausible mechanism for that being useful.
[03:46] <Sarvatt> phew, still debs up - https://edge.launchpad.net/ubuntu/+source/mesa/7.9~git20100909-0ubuntu2/+build/1962349
[03:49] <Sarvatt> you wont want to hear this :)
[03:49] <Sarvatt> oh not all rosy
[03:50] <Sarvatt> 20100909-0ubuntu2 works with quadrapassel, and I'm wrong, theres 2 errors
[03:50] <Sarvatt> gnibbles still needs CLUTTER_VBLANK=1 to start a new game
[03:50] <Sarvatt> err CLUTTER_VBLANK=none
[03:52] <Sarvatt> oh boy, mesa 7.9 rc2 pulled in all the sandybridge stuff
[03:52] <RAOF> That's the sort of changes *I* like to see between rc1 and rc2!
[03:53]  * RAOF was looking forward to pointing at a very small diff between what we've got an 7.9 final.  BA BAW!
[03:54] <Sarvatt> you and me both! :(
[03:54] <Sarvatt> time to break on dri2_bind_context and step through what happens between the second and the third ClutterGLX-CRITICAL message
[03:55]  * Sarvatt goes insane holding enter again for hours
[03:56] <RAOF> Does that sandybridge stuff work reasonably, at least?
[03:56] <Sarvatt> hah!
[03:56] <Sarvatt> actually it almost tries to work now
[03:57] <Sarvatt> neverball plays, but the reflections on the ball are screwy
[03:57] <bjsnider> why not just use less bleeding edge code if you are worried about it working with clutter?
[03:57] <Sarvatt> swrast being 10x faster aside
[03:57] <Sarvatt> because we're worried about stuff working at all too! :)
[03:58] <RAOF> Because it (a) appeared to be working with clutter, (b) made unity work on radeon *at all*, (c) fixed KDE.
[03:58] <bjsnider> is any of this an issue on nvidia?
[03:58] <RAOF> No, of course not.  Nvidia doesn't use any of mesa.
[03:59] <RAOF> There may be *different* problems on nvidia, but none of this will affect them.
[04:00] <bjsnider> i don't think there are different problems, because i'm using clutter and it works fine
[04:01] <bjsnider> are you saying mesa is a piece of garbage?
[04:01] <RAOF> No?  Mesa has bugs; as does the nvidia driver code, and all other code.
[04:02] <bjsnider> well, there are bugs, and then there are bugs
[04:03] <RAOF> It's also possible that there's a bug in *clutter*.  After all, that was the problem with Unity.
[04:12] <Sarvatt> what I've found with clutter is that if you aren't using the same mesa/xserver versions that are in moblin/meego when it's released you're going to have problems :) the glx/dri2 stuff is so volatile
[04:16] <Sarvatt> well when an intel quarterly release comes out i should say. speaking of which i see clutter 1.4 just released
[04:18] <RAOF> Yup.
[04:20] <RAOF> Hm.  I think it's unlikely that 7244406093056108580 is going to be a valid X drawable...
[04:21] <RAOF> Yeah.  That __GLXDRIdrawable's just garbage.
[04:23] <RAOF> So, why is it still in the hash table?
[04:29] <palhmbs> so the Numlock bug - has been fixed in Maverick?
[04:48] <Sarvatt> http://sarvatt.com/downloads/quadrapassel.good.txt (git20100909-0ubuntu2) vs http://sarvatt.com/downloads/quadrapassel.bad.txt (current) from the X side of it
[04:52] <RAOF> Hm.  Is it GetBuffersWithFormat that's dying?
[04:54] <RAOF> Oh, no.  It died in CreateDrawable.
[04:57] <Sarvatt> wow I implemented a lot more of DRI2 in xtruss than I remember - http://sarvatt.com/downloads/qpl-xtruss-bad.txt
[05:00] <Sarvatt> ahh yeah i stopped messing with it because i couldn't wrap my head around how to extend it to add new events, wasn't designed for it from the start
[05:06] <RAOF> Right.  So, the difference is that something's now trying to call DRI2CreateDrawable on an invalid drawable.
[05:47] <RAOF> Bah!  glxHashDestroy != glxHashDelete
[06:02] <RAOF> Ok.
[06:05] <RAOF> So, what's happening appears to be: clutter calls glXMakeCurrent with the same context, and a different drawable.  This triggers MakeContextCurrent to call dri2_unbind_context, which treats oldGC == newGC specially by destroying the current draw & read drawables.
[06:06] <RAOF> Now when clutter tries to bind those drawables to the context again, mesa doesn't have them and calls CreateDrawable on the GLXDrawable.  But the GLXDrawable isn't an X drawable, so this fails.  And thus we get our BadDrawable.
[06:07] <RAOF> That's why reverting the new glx drawable GC fixes quadrapassel, at least.
[06:08] <RAOF> Now.  What part of ^^^ isn't according to spec? :)
[06:44] <RAOF> Let's see if this mesa build fixes it.
[09:02] <RAOF> Sarvatt: http://pastebin.com/yqj5sKzr is a fix for mesa, and http://pastebin.com/nWqFiTRc is a piglit testcase for the problem.  I'm trying to stare myself into confidence that this won't introduce a memory leak, and talk to krh when he's around.
[13:09] <mvo> tseliot: so I was trying to test the nvidia-173 upgrade, but I get "postinst failure with status 1" in the lucid image already :/ 
[13:19] <mvo> tseliot: aha, so with the ubuntu desktop test profile I get further, lets see what it outputs
[13:48] <tseliot> mvo: maybe it's failing to build the kernel module
[13:48] <tseliot> and that's expected
[14:00] <Sarvatt> RAOF: http://cgit.freedesktop.org/mesa/mesa/commit/?id=4b70fe8421f5132c585ff1dfb8d90229be26e71f
[14:36] <Sarvatt> \o/ fixes quadrapassel and unity
[14:50] <mvo> tseliot: both -96 and -173 upgrade in my test system. but I just noticed that the test is not that useful as nvidia-173 provides x-x-video-7, but x-s-core only breaks -6 and smaller (looks like a oversight)
[14:50] <mvo> that -7 is not there
[14:56] <tseliot> mvo: ah
[14:56] <tseliot> Sarvatt: ^^
[14:57] <tseliot> Sarvatt: maybe we should add xserver-xorg-video-7, as mvo suggests?
[15:06] <Sarvatt> tough call, video 7 was only in maverick for a short time period, having the breaks on the video abi did *really* stupid things to the package manager like have it upgrade some metapackages but hold back X which made the next upgrade remove all of X
[15:07] <tseliot> mvo: ^
[15:08] <Sarvatt> but I guess it needs to be done to get those nvidia packages that dont work removed since they were never updated for ABI 8?
[15:09] <tseliot> yep
[15:12] <mvo> Sarvatt: I can test what will happen in a vm if that helps - ie. if the added breaks breaks the world
[15:17] <Sarvatt> yeah that'd be a huge help because I never could work out why it was so broken and didn't add the breaks on purpose this time to not have a repeat of xserver 1.8 screwing everyone with the blob's X. want me to upload it to a PPA?
[15:18]  * Sarvatt doesn't know how to override packages during a release upgrade to simulate what would really happen
[15:20] <Sarvatt> the funny thing was having the breaks: actually made it decide to install nvidia-current with the old abi on non-nvidia machines too
[15:22] <Sarvatt> there's a lot less impact now because its just nvidia-173, nvidia-96, x-x-v-glide and x-x-v-dummy providing that abi
=== JanC_ is now known as JanC
[18:18] <Sarvatt> surprised I haven't heard about fglrx being broken in x-updates from anyone if it is, just realized the 10.10 betas in maverick ship a x760 directory and lucid would need the ones from x750
=== yofel_ is now known as yofel