[00:06] <RAOF> Well, as long as you don't want to actually bring up X, nouveau-kernel-source now does KMS on all cards I have access to.
[00:08] <bryce> heh
[00:09] <RAOF> If you'd like it to bring up X, we'll need a newer libdrm-nouveau :)
[00:11] <RAOF> And I'll need to remember how to git.
[00:12] <RAOF> At least the new kernel module was satisfyingly easy to build out-of-tree.
[00:15] <bryce> RAOF, have you looked at the bits we've got in xorg-edgers and sarvatt's ppas?
[00:15] <RAOF> Some of it, yes.
[00:16] <RAOF> But shipping an entirely new kernel for the nouveau modules isn't the friendliest idea :).  For the purposes of making that work, I'm just hacking everything locally.
[00:24]  * bryce nods
[00:25] <bryce> I played with it some myself last week
[00:26] <bryce> wasn't able to get up X - probably same problem you're seeing
[00:26] <bryce> just a black screen
[00:26] <RAOF> Well, now rather than getting X to crash I can get it to hardlock my system.  That's progress, I guess.
[00:28] <RAOF> Works fine without KMS, at least.
[00:30] <RAOF> So, I guess it might be worth updating, next time libdrm is updated.
[00:31] <RAOF> Damn, nvidia hardware with nouveau is _so_ _much_ _faster_ than intel.
[00:34] <Sarvatt> .........at what?
[00:34] <RAOF> At 2d.
[00:34] <RAOF> Specifically, at GNOME-Do.
[00:35] <RAOF> Sarvatt: If you'd like an updated nouveau-kernel-source package that doesn't require building an entire kernel in your PPA, I've got one here.
[00:36] <Sarvatt> upload it to edgers?
[00:36] <RAOF> Not sure if I'm in that group.  I guess I can join if I'm not!
[00:37] <RAOF> Mmmmmm.  Karmic's GTK isn't the stablest toolkit ever used by man.
[00:41] <Sarvatt> if you want to send me the source i'll upload it for ya, think tormod has it moderated and he went to bed
[00:42] <Sarvatt> its got the drm to support it up there already
[00:59] <Sarvatt> RAOF: do you have it up on another ppa where we could copy it or something?
[03:53] <RAOF> Well, netconsole is surprisingly easy to set up.
[09:28] <maxb> Which package should get "KMS breaks usplash" bugs?
[09:29] <maxb> and ditto "KMS breaks desktop brighness applet" bugs?
[09:30] <maxb> Hmm, I guess I'm in the wrong channel, actually :-)
[09:32] <jcristau> maxb: not sure about usplash, but the latter is kernel.
[10:54] <Unggnu> hi all
[10:55] <Unggnu> Are there still plans for an X testing live cd or are they suspended? I am interested in KMS testing for -ati without messing up my system :)
[10:57] <Unggnu> Is it worth a bug report against -intel KMS when it uses the wrong resolution at start but xrandr shows still all and the correct one works fine?
[10:59] <Unggnu> I don't think that a quirk is needed because standard x modesetting doesn't have this problem
[11:08] <dazjorz> Hi guys :)
[11:08] <dazjorz> I'd love to help test the Nouveau driver for my card, 7900 GS
[11:10] <dazjorz> I need to go in a moment, have some more questions (for example: can I choose a driver to use for this session when I boot?); if I come back in about ten hours I'll try to get it up :)
[11:12] <Unggnu> dazjorz: Not much around atm
[11:12] <Unggnu> dazjorz: just come back later :)
[11:12] <dazjorz> I'll stay around :)
[11:16] <RAOF> dazjorz: Shoot.  I've done most of the nouveau packaging for Ubuntu.
[11:16] <RAOF> You can't really choose which driver on boot; the binary blob and nouveau drivers are mutually exclusive.
[11:17] <dazjorz> ah
[11:18] <dazjorz> I thought there was this page which described current progress for most cards, so I'll check whether mine is in there
[11:18] <dazjorz> anyway, I really need to go now
[11:18] <dazjorz> bye :)
[16:53] <geofft> Has the regression with xserver-xorg-video-intel on the Thinkpad T400 been reported? 
[16:53] <jcristau> "the regression"...
[16:54] <geofft> "it doesn't work any more" 
[16:55] <jcristau> even less details and it'd be perfect.
[16:56] <geofft> I'm assuming that if it had been reported then that would be unambiguous :) 
[16:57] <geofft> Basically, with -0ubuntu9.3, X dies with an error about being unable to allocate enough memory. -0ubuntu9 is fine 
[16:58] <geofft> I'm happy to re-upgrade and post my Xorg.0.log, but I was wondering if this is known 
[16:58] <geofft> looks like not? 
[17:00] <jcristau> talking about jaunty, then, i guess.  maybe bryce knows.
[17:04] <geofft> yup. Jaunty, x-x-video-intel 2:2.6.23-0ubuntu9.3, Intel integrated video 
[17:51]  * jbarnes looks for jithin
[17:56] <Sarvatt> jbarnes: i doubt he tried it, or he wasnt using xorg-edgers with it so it didnt work :D
[17:56] <Sarvatt> he probably saw the changelog didnt have the right patch name
[17:57] <Sarvatt> both people i was talking to said it fixed it for them
[18:22] <ccheney> jbarnes: i showed you the thinkpad x200 back at UDS that had the problem with ghost DVI ports showing up and causing KMS to set the internal display to the wrong (too high) resolution, you mentioned there already being a fix out of tree for that, do you know what the status of that is currently?
[18:47] <jbarnes> ccheney: I think that fix has been pushed into drm-intel-next
[18:48] <ccheney> jbarnes: do you know when that will go into the kernel?
[18:48] <jbarnes> Sarvatt: yeah jithin confirmed too... I think he tried to apply my patch after I had pushed some stuff that conflicted
[18:48] <ccheney> jbarnes: 2.6.31?
[18:48] <jbarnes> ccheney: yeah
[18:48] <ccheney> ok
[18:49] <superm1> bryce, i just uploaded the 9-6 AMD driver to karmic. i had to hunt down a whole bunch of patches to get it compiling on 2.6.30.  it might be useful for that x-updates PPA or edgers PPAs that people are using 2.6.30 with older ubuntu releases.  the patches only get applied when you are building against 2.6.30.
[18:50] <Sarvatt> ccheney, if you want to try it out without interfering with the ubuntu kernels http://sarvatt.com/downloads/tormod-kernel/
[18:50] <Sarvatt> just built one with drm-intel-next last night to test out the suspend/resume stuff
[18:50] <ccheney> Sarvatt: ok, if i get some spare time i'll take a look at it
[18:51] <Sarvatt> (thats 2.6.31 as of last night)
[18:51]  * ccheney is busy with moblin at the moment
[18:53] <ccheney> the ubuntu bug i filed is bug 391720
[19:18] <Sarvatt> ahhhh i thought that was happening but i couldnt get anyone on 965 to install driconf to disable it http://cgit.freedesktop.org/mesa/mesa/commit/?id=b8e638d4895d2d342306bb6443a455f73903ce20
[19:18] <Sarvatt> a few people were having the same exact crashes i get on 945 when i enable texture tiling and it was only disabled on <965 before
[21:41] <Sarvatt> what package should be attached to this bug? netbook-remix metapackages dont pull in ubuntu-standard which udev-extras is a part of so they dont get permissions set right to enable DRI atall on karmic
[21:41] <Sarvatt> https://bugs.edge.launchpad.net/bugs/384934
[21:43] <jbarnes> Sarvatt: 945 texture tiling won't really work right now
[21:43] <Sarvatt> ubuntu-meta?  it probably affects other metapackages as well if they dont pull in ubuntu-standard
[21:44] <Sarvatt> yeah, someone on 965 had the same exact error i did when i enable it with blender dropdowns giving a bus error 
[21:44] <Sarvatt> but i couldnt convince them to install driconf to try turning off texture tiling
[21:45] <Sarvatt> oh nice, thats fixed now with tiling on
[21:46] <Sarvatt> of course blender dropdown menus still dont render on 945 at all but at least it doesnt crash blender anymore :)
[21:49] <Sarvatt> wonder if theres a mesa extension i can disable to fix that, LIBGL_ALWAYS_SOFTWARE=1 works, it hasnt worked since december when i got this aspire one and started messing with it
[21:49] <jbarnes> maybe one of the front buffer rendering bugs
[21:50] <Sarvatt> the changes for DRI2GetBuffersWithFormat make the buttons show in the right place before though, without it the buttons would leave the window and overlap my gnome panel up top 
[21:50] <Sarvatt> unlike before rather
[21:52] <Sarvatt> dang, compiz is really broken on i965 right now, that has to be the 10th bug report since yesterday with the same problem
[21:53] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/391808
[21:55] <Sarvatt> bryce: are you sure 109_release_direct_rendering_resources.patch apples to mesa 7.4.1? they didnt bring that back into 7.4 branch only in 7.5 and master
[21:55] <bryce> Sarvatt, how do you mean?
[21:56] <bryce> Sarvatt, it seemed to apply and build okay; are there problems with it?
[21:57] <Sarvatt> i dont know, its just there are quite alot of compiz failing to start with the same backtrace since the mesa update
[21:58] <bryce> hrm
[21:58] <Sarvatt> all on 965
[21:59] <Sarvatt> let me pull up some
[21:59] <Sarvatt> the one i linked, plus https://bugs.launchpad.net/bugs/391694 and umm..
[21:59] <Sarvatt> https://bugs.launchpad.net/bugs/391703
[22:01] <bryce> ok yeah was just looking at one of these
[22:01] <bryce> Sarvatt, you've traced it definitively to 109?  Perhaps that should just be disabled then
[22:02] <Sarvatt> no i havent, i just looked at it and saw that what you picked for 109 hasnt been pulled into 7.4 branch but 108 has
[22:03] <Sarvatt> it was just a guess that it might not apply on 7.4, it could be 108 needing more updates from 7.4 branch too, its just definitely something in those 2 patches that have been added
[22:04] <Sarvatt> http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_4_branch&id=1dbbc39f48ce5f9aa63ab42930b14e48938b326f
[22:04] <Sarvatt> that was added to 7.4 branch right after 108 got added
[22:05] <Sarvatt> and they had to release a 7.4.4 that just had that
[22:05] <bryce> ok, getting a better backtrace from one of the reporters, that may help narrow it down
[22:06] <bryce> https://pastebin.canonical.com/18959/
[22:06] <Sarvatt> backtrace is in 3: /usr/lib/dri/i965_dri.so(intel_renderbuffer_set_region+0x41) [0x7f003dea5f01] and that update touches that
[22:06] <Sarvatt> dont have access to that pastebin
[22:06] <bryce> hrm, that backtrace doesn't look useful
[22:07] <Sarvatt> do you see a null anywhere in 3?
[22:08] <bryce> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/391808
[22:09] <bryce> #4 0x00007f1e9af1f66d in DrawableGone (glxPriv=0x0, xid=0)
[22:14] <Sarvatt> i'm really not good at tracking that down, but http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_4_branch&id=1dbbc39f48ce5f9aa63ab42930b14e48938b326f  was important enough for them to release a 7.4.4 right after 7.4.3 and seems to touch the problem with the 108 patch's commit
[22:15] <Sarvatt> maybe they should install libgl1-mesa-glx-dbg and libgl1-mesa-dri-dbg to get more info
[22:15] <bryce> ok yeah, I am digging through the code and will verify
[22:17] <Sarvatt> yeah here we go
[22:17] <Sarvatt> http://bugs.freedesktop.org/show_bug.cgi?id=22408
[22:17] <bryce> bingo
[22:18] <bryce> hmm, sounds like really we need to merge in 7.4.4
[22:18] <bryce> but we can patch for now
[22:21] <Sarvatt> if you arent going to pull in 7.5 anytime soon because of the decision about gallium for sure, that should merge cleanly and build fine.. there was another fix besides 108 and 109 for the memory leaks  but i'm not sure how they interact with 7.4 because neither were added to 7.4 branch (he said 7.4.3 would be the final 7.4 series but that null fix was major enough to do a 7.4.4)
[22:21] <bryce> Sarvatt, think we should snag http://cgit.freedesktop.org/mesa/mesa/patch/?id=4b8cd0b0ad48c3b0129451924f7461ffcbbc8597 too?  Was also referred to in that bug
[22:23] <Sarvatt> oh yeah that looks like part of it too
[22:28] <bryce> Sarvatt, all these bugs can be duped to bug #391808, which is the one I'm working on
[22:29] <Sarvatt> ok i'll do that now
[22:33] <bryce> ok, stuck package in my ppa, and am running a build locally to doublecheck
[22:33] <bryce> I sure wish mesa built faster
[22:34] <bryce> I think it really ought to be split up per driver instead of being one big ball of everything
[22:36] <Sarvatt> got all i could find on the ubuntu-x mailing list
[22:37] <Sarvatt> yeah its really bad now with 7.5+ because the build process fails 90% of the time on amd64 ever since they redid the osmesa build process
[22:38] <bryce> erf
[22:38] <bryce> what was the gallium decision you mentioned?  I've been horrible about not following upstream discussions lately
[22:39] <Sarvatt> havent been able to work out how to get it to build right, its a race in the install part of the packaging but adding -j1 to cd $(DEB_BUILD_DIR)/$* && $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install didnt help it
[22:40] <Sarvatt> maybe cd $(DEB_BUILD_DIR)/$* && sleep 5 && $(MAKE) DESTDIR=$(CURDIR)/debian/tmp install ?
[22:40] <Sarvatt> hmm
[22:40] <Sarvatt> its on debian-x mailing list, let me see if i can find it
[22:40] <Sarvatt> gallium builds by default now and they were asking if they should package it or disable it
[22:43] <bryce> Sarvatt, pushed to my ppa:  https://edge.launchpad.net/~bryceharrington/+archive/ppa
[22:44] <bryce> Sarvatt, yeah given how intricate mesa can be, I think I'd be most comfortable waiting until it's packaged in debian.  They're good at sorting out a lot of the packaging issues and such
[22:44] <bryce> s/good/much better than me/ :-)
[23:03] <Sarvatt> bryce: you didnt include 111 in the series
[23:03] <Sarvatt> just testing without it? didnt know if it was intentional or not
[23:04] <bryce> oh crap
[23:13] <bryce> Sarvatt, btw, how's the DDX rewrite for -ati going?
[23:15] <Sarvatt> nothing really changed, they're cleaning the older one they have up a little so it works without KMS/libdrm-radeon1 though -- http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/log/?h=kms-support
[23:18] <maco> what nixternal was saying about -10 breaking intel graphics yesterday...was that just a side effect of his computer having poor KMS support? like, if i'm currently running with KMS no problem, should i be ok with -10?
[23:19] <RAOF> I certainly am.
[23:19] <RAOF> People keep saying -10 doesn't boot right.  It's worked fine for me :)
[23:22] <Sarvatt> oh shoot, here I was packaging up a mesa 7.4.4 from the tarball and updating the patches to apply but debian already did it
[23:22] <Sarvatt> it was a side effect of him not having an xorg.conf maco
[23:23] <maco> you need one now?
[23:23] <Sarvatt> you'll be fine if it worked previously
[23:23] <Sarvatt> no theres a bug where fbdev kills the server if its loaded and it gets loaded when you dont have an xorg.conf
[23:24] <maco> oh. ok thanks. ill go get updates then
[23:26] <bryce> Sarvatt, <maxb> bryce: It's working fine for me. I can't crash it by doing what I could reliably crash 1ubuntu3 by doing
[23:27] <Sarvatt> good to hear :)
[23:27] <bryce> Sarvatt, so 110 alone seems to fix the crash.  But I'll put in 111 as well just in case
[23:27] <Sarvatt> debian has 7.4.4 as well as 7.5 with gallium disabled now btw, jcristau has been  busy :)
[23:28] <bryce> yep
[23:28] <Sarvatt> ubuntu patches 104 105 108 110 and 111 are all upstream in 7.4.4
[23:29] <bryce> Sarvatt, btw I uploaded the patch which fixes bug 388032 too; I'll go ahead and close it
[23:29] <Sarvatt> woohoo!
[23:29] <bryce> Sarvatt, yep, all cherrypicks.  Like I said, maybe we should just pull 7.4.4
[23:30] <bryce> esp. if it looks like 7.5 is still not quite ready for primetime
[23:46] <Sarvatt> i havent heard anything but good things about 7.5, wouldnt say its not quite ready for primetime by any means. all of the stability fixes go in there and they test stuff on 7.6 before pulling it back into 7.5. they merge the stability fixes into 7.6 every week or so so i've been having to cherry pick from 7.5 into master.. very odd
[23:48] <Sarvatt> (test new stuff that isnt just a fix on 7.6 I mean)
[23:48] <Sarvatt> they just pulled in alot of the intel goodies from master to 7.5 last week :)
[23:52] <Sarvatt> its just the build process i run into problems with but i have a feeling the refreshed 04_osmesa patch might fix that, i've been dropping it completely
[23:57] <Sarvatt> 7.6 is going to be required for radeon KMS if that gets decided upon, i kind of question how stable 7.6 is going to get by release time because of all the problems on the radeon side with radeon-rewrite in there.. they seem to be taking a KMS/libdrm-radeon1 or nothing approach to it for the time being, the same major bugs have been in the dri1 side for quite some time  :D