[02:34] <Sarvatt> so, after disabling DRI on sandybridge, is it worth another upload reverting the compiz blacklist?
[02:36] <RAOF> I'd guess yes; who's maintaining compiz nowadays?  Still mvo?
[02:40] <Sarvatt> RAOF: ok we need to --disable-gallium-radeon whenever we update mesa again next
[02:40] <Sarvatt> they made r300g the default
[02:40] <RAOF> Whyso?
[02:41] <Sarvatt> built by default, takes the place of r300g I think in the build output?
[02:41] <RAOF> So we need to update the bit of the rules file where we delete that, then.
[02:41] <Sarvatt> might be confusing it with intel, hmm
[02:41] <Sarvatt> err r300c
[02:41] <RAOF> It still ends up in gallium/r300_dri.so, right?
[02:41] <RAOF> (Because we'd still quite like r300g for the egl/gles/openvg stuff)
[02:42] <Sarvatt> doesn't look like they moved it so yeah
[02:43] <Sarvatt> sorry, got mixed up. the mesa build gives me a headache :)
[02:43] <RAOF> Heh :)
[02:43] <Sarvatt> adding a new build target for llvm will be fun if we ever do it! :)
[02:43] <RAOF> Eh.
[02:44] <RAOF> We'll just turn it on unconditionally on amd64, and ignore it for i386 :)
[02:44] <RAOF> We don't need to build mesa any *more* times! :)
[02:45] <Sarvatt> too bad i believe most of the people who benefit the most from llvm will be stuck on i386 (old ati IGPs)
[02:46] <Sarvatt> pentium m and earlier era ones
[02:47] <Sarvatt> * Add kubuntu_29_fallback_to_xrender_compositing.diff
[02:47] <Sarvatt>  fallback to XRender compositing in case of Software Rasterizer.
[02:47] <Sarvatt>  (backport from trunk)
[02:47] <Sarvatt> \o/ \o/
[02:47] <RAOF> Yup.
[02:48] <Sarvatt> ScottK: that was the fix for swrast?
[02:48] <Sarvatt> i was kind of hoping they would just make the GL compositing fall back to xrender instead of disabled
[02:49] <ScottK> Sarvatt: I think that's what it does.
[02:49] <Sarvatt> ahh ok
[02:49] <ScottK> (the kwin patch)
[02:49] <Sarvatt> awesome if so, fixes a lot more than swrast then
[02:51] <ScottK> Sarvatt: http://bazaar.launchpad.net/~kubuntu-members/kdebase-workspace/ubuntu/annotate/head:/debian/patches/kubuntu_29_fallback_to_xrender_compositing.diff
[02:51] <Sarvatt> thanks, was just digging for it :)
[02:51] <ScottK> I think it's just swrast
[02:51] <Sarvatt> ah only swrast :(
[02:52] <ScottK> You can talk to mgraesslin in person at UDS about extending it for KDE 4.6.
[02:54] <RAOF> I should point him at the GL|ES 2.0 docs; apparently mesa should be growing a “ES compatibility in desktop GL” mode, and (also apparently) the ES docs have a nice appendix with “here's all the stuff we mandate that various hardware doesn't implement”
[03:05] <Sarvatt> oh really? it's got a nice list of hardware limitations?
[03:05] <Sarvatt> that's exactly what i've been looking for
[03:06] <RAOF> I haven't read it, but the “What GL calls can you safely use” session basically ended with “Look at the ES docs!”
[03:09] <Sarvatt> not seeing it, maybe in the GL 4.1 docs since thats where the ES compat stuff was added. hmm
[03:09] <RAOF> That might be it?
[03:09] <RAOF> From memory, it should be appendix A
[03:15] <Sarvatt> can't find it in any of these, but this will be good reading material for the flights to UDS and plumbers at least :)
[03:20] <RAOF> Oooh!
[03:21] <RAOF> That might fix kwin desktop effects switching!
[03:22] <Sarvatt> what, the commit 2 hours after you packaged one for ScottK last night? :)
[03:22]  * ScottK waits to try.
[03:23] <RAOF> You mean "hold on to drawables if we're just switching to another context"?
[03:23] <Sarvatt> yup
[03:24] <Sarvatt> saw that on master and of course it was cherry picked right after you packaged one up :)
[03:25] <RAOF> ScottK: Building the sucker right now for you.
[03:32] <Sarvatt> the bug was saying the problem it was fixing was caused by one of the commits we reverted in 0ubuntu2 and it was still broken there, but there have been a bunch of other changes that might interact with it
[03:34] <RAOF> Yes.  The patch on the bug doesn't apply, because it was against the 7.8 code that we reverted to in 0ubuntu2 that was removed in 7.9 (and hence doesn't appear in ubuntu1 or ubuntu3).
[03:36] <Sarvatt> I meant https://bugs.freedesktop.org/show_bug.cgi?id=30234 referenced in that commit's log
[03:36] <ubot4> Freedesktop bug 30234 in Mesa core "Mesa xdemo manywin aborted" [Major,Resolved: fixed]
[03:36] <RAOF> Ah, right.  Yeah.
[03:38] <Sarvatt> hmm yeah blender's user preferences is broken here too
[03:40] <bryceh> what's the problem?
[03:41] <Sarvatt> and i've got that commit, odd
[03:45] <Sarvatt> there's a freeze on kwin effect setting changes on intel, and raof just spotted a commit that might fix it. i was just off in lala land testing out the other broken things mentioned in the bug for that commit
[03:46] <Sarvatt> since restarting into KDE on the only machine I use IRC on is a PITA :)
[03:46] <RAOF> :)
[03:46] <bryceh> gotcha
[04:20] <RAOF> Ah, mesa.  sink of endless CPU time.
[04:39] <RAOF> We should probably ensure libGL doesn't needlessly link to libstdc++ for natty.
[04:43] <Sarvatt> thats just the swx11 libGL isn't it?
[04:43] <Sarvatt> (that the warning is for)
[04:45] <RAOF> Possibly.  I was just watching the warnings stroll past.
[04:47] <RAOF> ScottK: New packages are available for your testing pleasure; again on cooperteam.net/Packages
[04:47] <bryceh> RAOF, file a bug for now?
[04:47] <ScottK> Thanks.
[04:50] <Sarvatt> I'm still wondering if we should be shipping gl.pc from the dri build target
[04:51] <Sarvatt> in libgl1-mesa-dev, it has a bunch of extra Requires.private packages in it compared to the one we ship
[04:51] <RAOF> Interesting.  That could well be important.
[04:52] <Sarvatt> Requires.private: libdrm >= 2.4.15 dri2proto >= 2.1 glproto >= 1.4.11 x11 xext xdamage xfixes xxf86vm is what libgl1-mesa-glx actually needs
[04:52] <Sarvatt> Requires.private: x11 xext is what the one we ship from another build target has
[04:52] <Sarvatt> well thats edgers and probably only there from another confflag i'm using, the one in maverick might not have anything
[04:53] <ScottK> Installed.  We'll see.
[04:59] <ScottK> RAOF: Victory!
[04:59] <ScottK> Also I had effect on login an that very rarely happens on this machine (it does sometimes, so I might have just been lucky).
[05:00] <ScottK> I was able to reset effect with them enabled and neither freeze nor crash.
[05:02] <ScottK> RAOF and Sarvatt: My hope is we'll try and get this tested and get it in before RC if it makes sense.
[05:04] <RAOF> Oh, man.  This fixes so much kde.
[05:04] <Sarvatt> ScottK: what would you consider the absolute latest deadline for that to be for future reference? It would be extremely nice if we could time it with an actual release instead of another git checkout
[05:04] <RAOF> Present windows also now has actual windows.
[05:05] <ScottK> Sarvatt: It would need to be in the archive on Monday.
[05:05] <Sarvatt> got ya, so testing what you have there it is
[05:05] <RAOF> Ahem.  And has just locked the GPU, so it's not _all_ peaches and cream.  But it did that before.
[05:06] <ScottK> Well sure.  If Mesa ever was fully tamed you'd be dissapointed and board.
[05:10] <Sarvatt> RAOF: tried  INTEL_NEW_FS=1 on your gm45 lately?
[05:11] <Sarvatt> supposedly wins as many piglits as the old one now
[05:11] <RAOF> I have not tried that.
[05:15] <Sarvatt> man, no touchpad scroll *really* sucks, poor people stuck with alps touchpads
[05:17] <RAOF> Hm.  Yep, it really is present windows that's locking the GPU.
[05:17] <RAOF> I should really switch the alt-tab away from that :/
[05:32] <Sarvatt> i still can't believe we got a fglrx that works with xserver 1.9 and its not on phoronix yet :)
[05:35] <Sarvatt> hmm quite a few id's were ripped out of here in these maverick ones
[05:37] <Sarvatt> 1002:17xx? never seen those before, maybe its hd 6xxx series but they are gone from the 8.780 ones
[08:10] <dandel> Is it a bug to be unable to change the tv format on live cd of ubuntu 10.10 (using kms and xrandr)
[08:16] <RAOF> dandel: With which video driver?  Most should have an xrandr property to change that, I believe, although I think nouveau takes that as a module parameter instead.
[08:17] <dandel> hmm... radeon driver.... got it figured out a bit
[08:20] <dandel> i just happend to crash the xserver a few times by using this command (drm failure)... xrandr --output s-video --set tv_standard ntsc
[08:20] <dandel> it didn't crash when i changed the output to a valid target tho lol.
[08:21] <RAOF> Hme
[08:21] <RAOF> Hm.
[08:21] <RAOF> Feel free to file a bug if you can get a backtrace of that.
[08:21] <RAOF> But also good to hear that it works, too :)
[08:24] <dandel> now for a slight kicker... I'm using this to help fix another driver (namely the lack of analog support happauge hvr 1250 tuner cards)
[08:24] <dandel> i got short backtrace on the laptop also... one sec while i get the xorg file
[08:27] <dandel> RAOF, here's the backtrace: http://pastebin.ubuntu.com/499512/
[08:29] <RAOF> ta
[08:29] <dandel> happens on any invalid output
[08:30] <RAOF> Hm.  That's not very useful :)
[08:30] <RAOF> Backtracing X is a somewhat arcane art, though.
[08:30] <RAOF> wiki.ubuntu.com/X/
[08:30] <dandel> one sec... i'll see if 10.04 reproduces.
[08:31] <RAOF> wiki.ubuntu.com/X/Backtracing gives some clues.
[08:31] <dandel> i'm on a laptop which is fairly new which has a little effect.
[08:32] <dandel> however, it's not new enough to cause too much problems
[08:42] <RAOF> I'm surprised that backtrace doesn't appear to have any driver-related frames at all.
[08:44] <dandel> I know, and I'm not exactly certain as to what happened either.
[14:16] <andrewaclt> Is the wiki correct in saying that I need to intall the mainline kernel in lucid to debug intel gpu freezes?
=== ara__ is now known as ara
[15:04] <tseliot> mvo: have you had the chance to have a look at bug 645064 ?
[15:04] <ubot4> Launchpad bug 645064 in update-manager (Ubuntu) (and 1 other project) "nvidia-current from Ubuntu-X-Swat PPA is blocking the upgrade from Lucid to Maverick (affects: 1) (heat: 8)" [High,Triaged] https://launchpad.net/bugs/645064
[15:05] <mvo> tseliot: not yet, sorry, was hunting a race all afternoon (frustrating that)
[15:06] <tseliot> mvo: np, I can understand ;)
[16:05] <Sarvatt> the sandybridge pain never ends, now tiling has to be disabled for resume to work properly on .35
[16:07] <tseliot> :/
[17:19] <cwillu_at_work> [672621.387536] [drm] nouveau 0000:01:00.0: no space while hiding cursor
[17:19] <cwillu_at_work> under nouveaux with compiz, lucid, 2.6.36-rc4 kernel
[17:20] <cwillu_at_work> few hundred in dmesg, occurs when moving the mouse from my left monitor to the right monitor;  an extra cursor is left behind on the left monitor until I bring the mouse back
[17:22] <cwillu_at_work> also triggers while typing after mouse movement (i.e., when the mouse cursor would normally be hidden)
[17:22] <Sarvatt> using xorg-edgers or something?
[17:22] <cwillu_at_work> yes
[17:23] <cwillu_at_work> how else do I get compiz love out of nouveau? :p
[17:23] <Sarvatt> on lucid? rebuild mesa from maverick :D
[17:24] <Sarvatt> but wouldn't work with that kernel anyway
[17:25] <Sarvatt> if it doesn't happen without nouveau_dri.so its pretty much guaranteed upstream wont care about a bug report
[17:25] <cwillu_at_work> I haven't run into this on earlier kernels;  I'm assuming it's just something out of sync then?
[17:25]  * cwillu_at_work shrugs and puts maverick on this box :p
[17:27] <cwillu_at_work> incidently, if any of you recall my babbling about broken suspend in a slightly odd fashion earlier this year, I tripped over an lkml thread from the 2.6.28 release cycle talking about a fairly common problem with 64kb lowmem corruption;  maverick's kernel has some debugging enabled to detect such corruption, which also has the effect of avoiding those crashes (as the kernel avoids using that memory), with the cute side effect that the laptop now sus
[17:27] <cwillu_at_work> pends and resumes fine :p
[17:28] <Sarvatt> odd, that kernel config option has been enabled since 2.6.28 i'm pretty sure
[17:28]  * Sarvatt remembers disabling it specifically in his own kernels during 2.6.29
[17:29] <cwillu_at_work> Sarvatt, I'm getting the memory corruption warnings in dmesg now, which I never got before
[17:29] <Sarvatt> oh maybe it was fixed to actually work now then! :D
[17:29] <cwillu_at_work> heh
[17:34] <Sarvatt> RAOF: from idr - "I'd like to have a 7.9 release candidate on Monday (9/27).  Assuming there are no major issues, I'd like to have a final release on the following Monday (10/4).  Does that work for people?"
[17:35] <tseliot> idr?
[17:36] <Sarvatt> yeah intel guy handling the mesa release
[17:36] <tseliot> aah
[17:36] <Sarvatt> cutting it so close :(
[17:36] <tseliot> are we still considering 7.9 for inclusion?
[17:36] <Sarvatt> 7.9 is already in
[17:37] <tseliot> oh, I didn't notice
[17:37] <ScottK> Sounds like the best plan is an updated snapshot next monday (after testing), the mesa RC after Ubuntu RC and then SRU to 7.9 final.
[17:37] <tseliot> having an RC would be more than welcome then ;)
[17:37] <tseliot> ScottK: +1
[17:39] <Sarvatt> need to check if there are mesa 7.9-devel specific KDE blacklist strings because the version string will change and the blacklists will be lost
[17:39]  * Sarvatt goes digging
[17:42] <Sarvatt> looks fine to me, its only got 7.7.1 and 7.8.2 in the blacklist
[17:45] <Sarvatt> new snapshot->RC will have a very minor amount of changes, the crack commiters are focused on 7.10 already :)
[17:48] <Sarvatt> ScottK: so the new snapshot did fix your KDE freezing problem? sounded like RAOF's freeze was with a specific plugin not enabled by default?
[17:48] <ScottK> Sarvatt: It did.
[17:48] <Sarvatt> awesome
[17:49] <ScottK> Still can't logout though ....
[17:49] <Sarvatt> RAOF: can you please push what you have to git? I'm going to screw you up if I do it again when you already have it locally :)
[17:50] <Sarvatt> RAOF seems confident he can get that fixed up ASAP, holding off on another major bug fix x-x-v-intel upload until he cracks it 
[17:51] <ScottK> OK.  Great.
[18:18] <andrewaclt> Do I have to run a mainline kernel to debug intel gpu freezes?
=== yofel_ is now known as yofel