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:11 |
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:12 |
Sarvatt | i upgraded everything last night and saw this this morning | 00:13 |
Sarvatt | about 24 hours hours ago | 00:13 |
RAOF | Ok. Let's see if the new unity works here, then… | 00:17 |
RAOF | Yup. Unity runs fine here. | 00:20 |
RAOF | Or is this only on nouveau that you find Unity fails to start? | 00:21 |
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:24 |
RAOF | That would mean I'd need to restart my irc bouncer in order to get the i945 un-hidden. | 00:25 |
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. | 00:28 |
Sarvatt | 0 luck figuring this out | 03:29 |
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:30 |
Sarvatt | anyone know if there is an archive of daily livecd's anywhere? | 03:31 |
Sarvatt | watch it be something wacky like a conf file that was exporting CLUTTER_VBLANK only getting cleaned up recently | 03:34 |
RAOF | Well, there _was_ that, as a part of the OMG! UNITY'S BROKEN firedrill. | 03:40 |
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:42 |
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:43 |
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:44 |
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:45 |
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:46 |
Sarvatt | you wont want to hear this :) | 03:49 |
Sarvatt | oh not all rosy | 03:49 |
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:50 |
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:52 |
* RAOF was looking forward to pointing at a very small diff between what we've got an 7.9 final. BA BAW! | 03:53 | |
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:54 |
* Sarvatt goes insane holding enter again for hours | 03:55 | |
RAOF | Does that sandybridge stuff work reasonably, at least? | 03:56 |
Sarvatt | hah! | 03:56 |
Sarvatt | actually it almost tries to work now | 03:56 |
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:57 |
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:58 |
RAOF | There may be *different* problems on nvidia, but none of this will affect them. | 03:59 |
bjsnider | i don't think there are different problems, because i'm using clutter and it works fine | 04:00 |
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:01 |
bjsnider | well, there are bugs, and then there are bugs | 04:02 |
RAOF | It's also possible that there's a bug in *clutter*. After all, that was the problem with Unity. | 04:03 |
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:12 |
Sarvatt | well when an intel quarterly release comes out i should say. speaking of which i see clutter 1.4 just released | 04:16 |
RAOF | Yup. | 04:18 |
RAOF | Hm. I think it's unlikely that 7244406093056108580 is going to be a valid X drawable... | 04:20 |
RAOF | Yeah. That __GLXDRIdrawable's just garbage. | 04:21 |
RAOF | So, why is it still in the hash table? | 04:23 |
palhmbs | so the Numlock bug - has been fixed in Maverick? | 04:29 |
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:48 |
RAOF | Hm. Is it GetBuffersWithFormat that's dying? | 04:52 |
RAOF | Oh, no. It died in CreateDrawable. | 04:54 |
Sarvatt | wow I implemented a lot more of DRI2 in xtruss than I remember - http://sarvatt.com/downloads/qpl-xtruss-bad.txt | 04:57 |
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:00 |
RAOF | Right. So, the difference is that something's now trying to call DRI2CreateDrawable on an invalid drawable. | 05:06 |
RAOF | Bah! glxHashDestroy != glxHashDelete | 05:47 |
RAOF | Ok. | 06:02 |
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:05 |
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:06 |
RAOF | That's why reverting the new glx drawable GC fixes quadrapassel, at least. | 06:07 |
RAOF | Now. What part of ^^^ isn't according to spec? :) | 06:08 |
RAOF | Let's see if this mesa build fixes it. | 06:44 |
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. | 09:02 |
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:09 |
mvo | tseliot: aha, so with the ubuntu desktop test profile I get further, lets see what it outputs | 13:19 |
tseliot | mvo: maybe it's failing to build the kernel module | 13:48 |
tseliot | and that's expected | 13:48 |
Sarvatt | RAOF: http://cgit.freedesktop.org/mesa/mesa/commit/?id=4b70fe8421f5132c585ff1dfb8d90229be26e71f | 14:00 |
Sarvatt | \o/ fixes quadrapassel and unity | 14:36 |
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:50 |
tseliot | mvo: ah | 14:56 |
tseliot | Sarvatt: ^^ | 14:56 |
tseliot | Sarvatt: maybe we should add xserver-xorg-video-7, as mvo suggests? | 14:57 |
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:06 |
tseliot | mvo: ^ | 15:07 |
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:08 |
tseliot | yep | 15:09 |
mvo | Sarvatt: I can test what will happen in a vm if that helps - ie. if the added breaks breaks the world | 15:12 |
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:17 |
* Sarvatt doesn't know how to override packages during a release upgrade to simulate what would really happen | 15:18 | |
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:20 |
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 | 15:22 |
=== JanC_ is now known as JanC | ||
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 | 18:18 |
=== yofel_ is now known as yofel |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!