[00:26] <RAOF> Sarvatt: You still up?  Have any opinions on the fbdev vs vesa for i8xx conundrum?
[00:28] <ScottK> RAOF: Is fbdev what we had for Lucid/currently in Maverick?
[00:29] <RAOF> For Lucid we had intel + UMS.
[00:29] <RAOF> With all the GPU hangs / crashes that entails.
[00:29] <ScottK> That was mostly 845/855, right?
[00:29] <RAOF> Yeah.  865 isn't in the blacklist.
[00:30] <RAOF> i830, i845g, i855
[00:30] <ScottK> OK.
[00:30] <ScottK> Every time I see 8xx, I get nervous.
[00:30] <ScottK> My 865 isn't doing too badly.
[00:31] <RAOF> That's good.  Intel obviously had got some of the hardware bugs out of the system by then :)
[00:32] <ScottK> New Mesa plus fragment_shader=false looks like a big win on the one 945 box I've tested it on so far.
[00:33] <RAOF> I've got your bug down for bug #631413
[00:33] <ubot4> Launchpad bug 631413 in mesa (Ubuntu) "[FFe] Mesa 7.9 (affects: 2) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/631413
[00:33] <ScottK> I have two others and a 965 box (plus the 865) yet to test it on.
[00:33] <ScottK> Cool.
[00:35] <soreau> Hello, I was wondering if you can bisect packages with xorg-edgers repo or are the packages kept around or constantly discarded
[00:35] <bjsnider> Sarvatt, major new beta blob: http://www.nvnews.net/vbulletin/showthread.php?p=2314331
[00:36] <bjsnider> they've removed all OpenGL, VDPAU, CUDA, and OpenCL header files
[00:36] <soreau> ie. if you find any bug in x or driver, can you bisect using the repo somehow or is this information overwritten
[00:39] <bjsnider> is nvidia-current-dev even going to be necessary now?
[01:08] <RAOF> soreau: You can sometimes grab older packages out of xorg-edgers, but they get culled pretty ruthelessly.
[01:12] <EagleScreen_> hello
[01:13] <EagleScreen_> has this channel relation to xorg-edgers?
[01:14] <EagleScreen_> xserver-xorg-video-intel driver 2.12.0 give crashes in some hardwares
[01:15] <kklimonda> EagleScreen_: xorg-edgers tend to do things like that ;)
[01:16] <EagleScreen_> a build of version 2.9.1 for maverick would be nice for that people
[01:16] <EagleScreen_> it could be renamed to xserver-xorg-video-intel-legacy
[01:16] <EagleScreen_> so people in maverick could be happy
[01:17] <EagleScreen_> i have tried to upload a rebuild for maverick in my ppa, buit it does not build
[01:17] <EagleScreen_> ../../uxa/uxa-render.c:456: error: too few arguments to function 'image_from_pict'
[01:25] <EagleScreen_> I have taken this idea from openSUSE, which has two driver versions in the repository, the 2.12.0 and the 2.9.1
[01:25] <EagleScreen_> some people need the 2.9.1 and some people prefers the 2.12.0
[01:26] <RAOF> There are a couple of legacy options - there's the actual legacy branch in a PPA, and the newer shadow branch in another PPA.
[01:29] <RAOF> The 2.9.1 driver with UMS isn't enough of a stability win for me to bother with it.
[01:31] <EagleScreen_> RAOF: 2.9.1 works well with KMS
[01:31] <RAOF> And 2.12 doesn't?
[01:32] <RAOF> Can you point to a bug report?  All that I've seen suggest that 2.12 is a pretty much unqualified win over 2.9 + KMS.
[01:33] <EagleScreen_> 2.12 doesnt
[01:33] <RAOF> On what hardware does 2.12 not work where 2.9 did?
[01:34] <RAOF> Is there a bug report?
[01:35] <EagleScreen_> yes
[01:36] <EagleScreen_> RAOF: take a look at this https://bugs.freedesktop.org/show_bug.cgi?id=26937
[01:36] <ubot4> Freedesktop bug 26937 in Driver/intel "X server freezes when watching flash videos in Firefox in full screen mode" [Normal,Reopened]
[01:50] <RAOF> EagleScreen_: And that works on 2.9.1?  There doesn't seem to be any indication of when that bug first appeared, except that it “also occurs on 2.10”
[01:51] <EagleScreen_> RAOF: yes it works with 2.9.1
[01:52] <RAOF> That would be something very useful to add to that bug report; even more useful would be identifying which commit broke it by running a git bisect.
[01:53] <EagleScreen_> ops
[01:53] <EagleScreen_> I'll mention it
=== EagleScreen_ is now known as EagleScreen
[10:30] <doko> bryce: any idea about bug #632594? (btw, difficult to catch if you're not on #ubuntu-devel or #distro)
[10:30] <ubot4> Launchpad bug 632594 in xorg-server (Ubuntu) (and 1 other project) "xvfb 1.9 and/or metacity not working on the buildds (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/632594
[13:11] <ScottK> Sarvatt: mesa from your PPA looks good on i865.  I've got all the default effects except blur (no suprise there) after I manually enable effects.
[15:09] <Sarvatt> ScottK: thanks for the feedback! 965 + KDE is what I'm worried about with it, whipping up a patch to disable fragment shaders by default on gen3 intel right now
[15:10] <ScottK> Sarvatt: Sure, but I figure additional test results that show now regression are helpful.
[15:11] <Sarvatt> yeah they are, thats why I thanked ya! :)
[15:20] <Sarvatt> RAOF: I mentioned it in #ubuntu-kernel yesterday but I really think KMS + fbdev is the way to go instead of blacklisting KMS so vesa can be used. I haven't gotten a single report that fbdev didn't work when vesa did and it has the bonus of working at native resolution on more machines. not to mention opting in to intel buggyness is just an xorg.conf option away instead of forcing on KMS and using the xorg.conf. plus we can maintain that outside 
[15:20] <Sarvatt> of the kernel :)
[15:22] <jcristau> i've got at least one report of kms not working on a 830
[15:24] <Sarvatt> failing before X?
[15:24] <jcristau> iirc yes
[15:26] <Sarvatt> hmm, that stinks. I haven't seen any that weren't just KMS+intel being busted
[15:26] <jcristau> hmm, or maybe not
[15:27] <jcristau> the pointer he gave me was https://bugzilla.kernel.org/show_bug.cgi?id=15070
[15:27] <ubot4> bugzilla.kernel.org bug 15070 in Video(DRI - Intel) "kernel mode switching broken on i830" [Normal,Needinfo]
[15:32] <Sarvatt> our plymouth crap might screw with it up too since it talks directly to drm
[15:33] <Sarvatt> I see why it goes black in that bug though
[15:33] <Sarvatt> [   14.612773] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
[15:33] <Sarvatt> [   14.614920] Console: switching to colour dummy device 80x25
[15:33] <jcristau> ugh yeah, vga=0x305
[15:35] <jcristau> thanks for pointing that out
[15:36] <Sarvatt> vga= breaks the drmfb handoff?
[15:36] <jcristau> vga= gets vesafb loaded
[15:37] <jcristau> i'm not sure handoff works reliably
[15:38] <Sarvatt> we always have vesafb loading in ubuntu and grub2 is using it, handoff works fine here but i've seen some bugs where it isn't but I'm not sure if initramfs-tools is doing something wacky when vga= is passed. I saw something in the changelog recently about it
[15:38]  * jcristau doesn't know
[15:39] <Sarvatt> first thing i do on every machine in ubuntu is pass vesafb=sucks to stop it from loading :D
[15:39] <jcristau> heh
[15:49] <Neko> swing!
[15:49] <Neko> is there a readily available tool on maverick to trace X server behavior, calls, time spent doing whatever? I have an X server here (on top of fbdev) which is acting weird and soaking up 90% CPU time just in a terminal
[15:51] <Neko> I think I'm seeing 629910 or 617994
[15:51] <Neko> but this is armel.. no nvidia or ati proprietary drivers (yet :)
[16:03] <Sarvatt> Neko: you've got xrestop and xtrace, but the problem is most likely above X and a normal system profiler like sysprof, perf or oprofile would be the best place to start looking. have you tried different gtk themes out?
[16:05] <Sarvatt> disabling font smoothing/hinting might help a bunch as well, what color depth are you running at? does xterm have the same problems?
[16:06] <Neko> 16 bit for now but I am going for 32
[16:07] <Neko> oprofile sounds like the best solution then
[16:08] <Neko> don't have perf, still on 2.6.31 :(
[16:23] <Sarvatt> ScottK: here's where the fragment_shader option was enabled by default on 915/945 with some rationale btw - http://cgit.freedesktop.org/mesa/mesa/commit/?id=a58514cc9c5cc5867f9140700462c5ac5749550d
[16:24] <Sarvatt> sounds quite probably it may be working by release time, will have to check when we get a more recent snapshot/RC but reverting that in a patch is easy enough if not
[16:25] <bjsnider> Sarvatt, are you planning on updating nvidia-current to the 260 beta  in x-updates or waiting for a stable 260 blob?
[16:25] <Sarvatt> bjsnider: I still haven't looked at it, yeah I'll update it
[16:26] <ScottK> Sarvatt: I can retest if it's working at release time.
[16:26] <ScottK> Sarvatt: I'm slowly working through all my Intel boxes to see how we do with the new mesa.
[16:26] <Sarvatt> I plan on testing too, got the same 945GME but it's my main work machine :)
[16:27] <ScottK> That's what live sessions are for.
[16:29] <Sarvatt> yeah but disappearing from IRC isn't an option so I gotta set up another machine while I do it which is why I was bugging you (sorry and thanks btw) :)
[16:38] <Sarvatt> crazy how much nvidia has been extending glx in the blob, wish open source drivers could take advantage of some of this stuff like GLSL over glx
[16:42] <seb128> Sarvatt, hey
[16:42] <Sarvatt> heyo, whats up?
[16:43] <seb128> Sarvatt, will you update pixman in maverick?
[16:43] <seb128> cairo 1.10 wants pixman 1.18.4
[16:43] <Neko> if possible pls bump to 1.19.x :]
[16:43] <Sarvatt> seb128: I'm not a core dev but I bumped it in debian and jcristau just uploaded it if you can sync it? it's a bug-fix only update
[16:43] <seb128> we have 1.18.2 currently but I've read on IRC that debian updated your work
[16:44] <seb128> Sarvatt, we had a diff it seems
[16:44] <seb128> pixman (0.18.2-1ubuntu1) maverick; urgency=low
[16:44] <seb128>   * Add 100_check_read_accessor.patch: Fixes corruption seen in firefox
[16:44] <seb128>     due to REPEAT_NONE for a XRGB source fallback being triggered in a
[16:44] <seb128>     composite operation. (LP: #608613)
[16:44] <Sarvatt> the diff is upstream in 0.18.4
[16:44] <Sarvatt> it was just backported
[16:44] <seb128> Sarvatt, I'm happy to sponsor your upload
[16:44] <seb128> oh ok
[16:44] <seb128> so let me sync
[16:44] <seb128> thanks!
[16:44] <Neko> I have an interest in some of the new neon stuff.. 
[16:44] <Sarvatt> thanks seb128!
[16:44] <Sarvatt> Neko: there's only one new neon fastpath in 0.19 over 0.18 I believe?
[16:44] <jcristau> slomo asked for 0.18.4 for cairo
[16:45] <Sarvatt> Neko: I have 0.19.x packages in the xorg-edgers PPA if you want to test local builds
[16:46] <ricotz> seb128, https://bugs.edge.launchpad.net/ubuntu/+source/pixman/+bug/633194
[16:46] <ubot4> Launchpad bug 633194 in pixman (Ubuntu) "FFe: Sync pixman 0.18.4-1 (main) from Debian experimental (main) (affects: 1) (heat: 8)" [Undecided,New]
[16:47] <seb128> ricotz, thanks
[16:47] <bjsnider> Sarvatt, emailed you the updated packaging scripts for the 260 blob
[16:48] <Neko> Sarvatt, well, one in 0.19.x release but two in master which will end up there
[16:48] <Sarvatt> bjsnider: awesome, thanks!
[16:48] <Neko> I dunno if pixman manages versions like even stable odd unstable?
[16:48] <jcristau> Neko: it does
[16:49] <Neko> if it's "unstable" then don't bother, but I wonder if those fast paths can be patched in
[16:49] <Sarvatt> Neko: the latest master is what I've got a snapshot of in xorg-edgers
[16:49] <Neko> I really need to figure out why those are being added though, there must be a user somewhere which relies on this particular compositing operation that is slow
[16:51] <Neko> 32-bit pixmap with a seperate 8 bit alpha channel being rendered down to 16-bit.. it's probably highly common to convert 32->16 but a seperate alpha channel? maybe font rendering on 16bit or do?
[16:53] <jcristau> ask the people adding them?
[16:57] <Neko> just did :]
[16:57] <Neko> I was hoping not to annoy
[16:57] <Neko> "off-list" as it were
[17:09] <Sarvatt> sounds like the 0.18.4 pixman requirement on cairo is bogus since it doesn't even contain the fixes they needed to pass the test suite anyway - http://cgit.freedesktop.org/pixman/commit/?id=de0320258167c24fc652d28f4aeca8713243323e and http://cgit.freedesktop.org/pixman/commit/?h=0.18&id=13951851cbbd81f9850d8ba132e155e3196ab522
[17:10] <Sarvatt> apw: btw if you didn't hear, anholt no longer maintains the intel git trees so the drm-intel-next mainline kernel is dead
[17:11] <Sarvatt> http://lists.freedesktop.org/archives/intel-gfx/2010-September/008018.html
=== yofel_ is now known as yofel
[17:20] <ScottK> Sarvatt: With the new mesa (and the .drirc), the HP Mini 110-1000 has lovely kwin effects (including blur), but effects are disabled by default (not just temporarily suspended).  The details of the system are in Bug #630632.  Could you have a look and see what bits I need to push on to get it to enable by default?  I assume there's a blacklist somewhere that it can be removed from.
[17:20] <ubot4> Launchpad bug 630632 in xserver-xorg-video-intel (Ubuntu Maverick) (and 1 other project) "[i945GME] Kwin compositing fail on maverick (affects: 1) (heat: 1161)" [High,New] https://launchpad.net/bugs/630632
[17:20] <ScottK> Shoot.  Wrong bug.
[17:21] <ScottK> Nope.  Right bug after all.
[17:21] <ScottK> (sorry, I've got about five different ones for tracking different systems)
[17:21] <Sarvatt> thats odd, because its the same system basically as the other 945gme you were testing
[17:22] <ScottK> Yep.
[17:23] <ScottK> It's not different because it's in a live CD session is it?
[17:25] <Sarvatt> it's most likely something in one of the kwin fallback mechanisms automatically disabling it, I don't see anything that would be causing that outside of there
[17:25] <Sarvatt> maybe it saw it was broken with the old mesa and remembered that the next boot?
[17:26] <Sarvatt> we need a livecd with the mesa package with the fragment_shader option disabled by default for testing
[17:26] <ScottK> No.  I deleted the entire .kde between boot.
[17:27] <ScottK> boot/restart
[17:27] <ScottK> sudo stop kdm, switch to vt1, rm -rf ~/.kde, sudo start kdm
[17:27] <ScottK> That should be sufficiently thorough
[17:28] <Sarvatt> there were other ways it disabled the effects like if it sees they are too slow, could that have happened maybe?
[17:28] <Sarvatt> anything in ~/.xsession-errors?
[17:29] <ScottK> Already dumped the session.
[17:29] <Sarvatt> ah darn, it looked like it would be verbose in there if it saw any problems when I was looking at the code
[17:29] <ScottK> I've got one more 945gme system to test (Latitude D430).
[17:29] <ScottK> It is probably similar.
[17:30] <ScottK> If it doesn't fail to start automatically, I'll fire up the HP again.
[17:32] <Sarvatt> about to upload a mesa to ppa:sarvatt/mesa with fragment_shaders disabled by default btw
[17:37] <ScottK> Cool.
[17:37] <ScottK> Please let me know when it's built so I can quit messing with config files
[17:38] <Sarvatt> will do, should be about 45 minutes or so
[17:53] <ScottK> Sarvatt: Here's the relevant .xsession-errors bits from one that doesn't start effects by default: http://paste.ubuntu.com/490436/
[17:55] <Sarvatt> hmm thats a 945GM, it's not blacklisted and now that I look again nothing will match the blacklist since the version string is different
[17:56] <ScottK> Here's the one that works http://paste.ubuntu.com/490441/
[17:59] <Sarvatt> i'm really stumped, can't think of any reason outside of kwin why that might happen and I'm not having any luck looking at the kwin source finding where it might be going wrong
[18:00] <ScottK> OK.  Thanks for looking.  I'll ask mgraesslin the next time he appears then.
[18:01] <Sarvatt> there are so many ways it can decide to not use effects, hopefully it's something easy
[18:01] <Sarvatt> be sure to mention it fails on one machine and works on another identical machine
[18:02] <Sarvatt> the two 945GME's not that dell d430
[18:05] <ScottK> OK
[18:24] <apw> Sarvatt, i didn't hear.  not much point in building them anymore (mainline kernels from there)
[18:48] <ScottK> Sarvatt: No need to tell me.  I got it.
[18:51] <Sarvatt> ScottK: sorry, was just mentioning that because I had a feeling his first response would be that the drivers are screwed up and it doesn't happen on nvidia but that emphasizes something else is going on :)
[18:52] <ScottK> Sarvatt: I was referring to the new mesa package.  Sorry.
[18:52] <ScottK> He said he didn't know.
[18:52] <Sarvatt> oh! I'm eating lunch, didn't see it was built yet
[19:20] <ScottK> Sarvatt: I got word your .drirc helped someone on gentoo running tip of the latest everything, so I doubt we'll be re-enabling it.
[19:23] <Sarvatt> yeah seems like the right thing to do for now, will have to keep an eye on it though because things will be dependant on it in the future and a lot of work is being done to make it work right.
[19:29]  * ScottK nods
[20:25] <era> i'd like to apologize if i came off a bit strong with my mailing list post this morning, but it had to be said.
[21:18] <ScottK> Sarvatt and RAOF: How close are you to being ready to upload mesa?  I don't think it's fair for me to put my release team hat on and approve it (I'm hardly neutral), but I think sooner is better than later (with additional smaller updates as needed) and I'm willing to push it in the release team for someone else to review.
[21:26] <era> mesa 7.9?
[21:36] <ScottK> Git snapshot leading up to it probably.
[21:39] <Sarvatt> ScottK: we could have it ready by tomorrow most likely if you really think its better that way instead of waiting for a RC or rebasing it on the stable branch when they push that, I'm about to head out for the day. we just need to move the nouveau classic mesa driver for old cards over to libgl1-mesa-dri-experimental and fix up the changelog to be more informative
[21:39] <ScottK> OK.  I'll start grumbling about it.