[00:00] <bryce> I'm pretty sure it skips directly to the LTS
[00:04] <mnemo> mmkay
[00:18] <pwnguin> heh
[00:19] <pwnguin> "ubuntu needs to stop shipping new kernels and xorg builds every release"
[00:21] <pwnguin> http://lunduke.com/?p=429
[00:39] <bryce> pwnguin: heh
[00:39] <bryce> pwnguin: of course, would we skip revving xorg for a release, we'd get equally skewered
[00:41] <bryce> hmm, what if we hadn't revved jaunty
[00:43] <bryce> today we'd be on xserver 1.5.2-ish, mesa 7.2, librandr 1.2, -intel 2.4.1
[00:44] <bryce> we could have stuck with fglrx 9.3, which would be nice.
[00:45] <bryce> ATI hardware would not be as well supported, but Intel stuff could probably have been backported
[00:58] <pwnguin> oh, the guy is full of crack
[00:58] <LLStarks> ?
[00:58] <LLStarks> did i miss something?
[00:58] <jcristau> no
[00:59] <pwnguin> LLStarks: nothing X related
[00:59] <LLStarks> i'm not sure if you guys are following the conversation in #intel-gfx but i was wondering if dri2 swapbuffers even has a shot at making karmic.
[01:12] <LLStarks> ?
[01:18] <Sarvatt> LLStarks: I'm about to add jbarnes' cursor flicker patch to edgers in a bit after the new drm builds and everything incase you dont want to build it yourself :D
[01:19] <LLStarks> i know how to build, but i miss out on all the debian patches.
[01:20] <LLStarks> also, i posed this question a few minutes and it went unanswered: "i've always been curious as to how good (quality and performance-wise the linux intel driver is when compared to windows or mac. i can understand that windows likes to abandon device support and forces the user to use older drivers. i like how linux drivers are furiously updated on almost a monthly basis."
[01:20] <LLStarks> any thoughts?
[01:23] <jcristau> seems pretty obvious that drivers for other platforms are more mature..
[01:23] <Sarvatt> i havent compared them because i dont use intel video on anything i care about performance on
[01:23] <jcristau> also get more development effort put into them, since they actually matter.
[03:07] <superm1> bryce, er intel 2.4 driver /does/ work on jaunty though.  siretart set up a backport on his ppa :)
[03:08] <superm1> been the only way i could confidently get decentish performance
[03:27] <bryce> superm1: yep I know
[05:07] <quentusrex> Ok, what is the best way to check the ram usage of Xorg?
[07:07] <tjaalton> bryce: sounds like the lunduke guy didn't get the memo
[07:08] <tjaalton> also, he seems pissed that fglrx dropped support for the old hw, although it's not mentioned
[07:30] <bryce> tjaalton: link?
[07:31] <tjaalton> http://lunduke.com/?p=429
[07:32] <tjaalton> a lot of handwaving
[07:32] <bryce> ah, right was looking at that earlier
[07:33] <bryce> wears me out.
[07:36] <bryce> fscking backseat drivers.
[07:40] <tjaalton> yeah
[07:45] <bryce> it's scary when I can just listen to people describe their problem with no mention of the hardware and know what driver they're using
[07:46] <tjaalton> heh
[07:51] <bryce> yeah this guy doesn't understand X.org
[08:00] <pwnguin> indeed
[08:00] <pwnguin> he could have been much more specific with his hate
[08:00] <bryce> yep
[08:00] <pwnguin> three letters
[08:00] <pwnguin> xkb
[08:05] <bryce> I don't agree with his assertion that "good Linux software can only be made by well paid developers"
[08:05] <bryce> I would offer Inkscape as a counter-example.
[08:44] <tjaalton> bryce: ok to sync -keyboard and drop the hangul hack? evdev is used by default anyway
[08:45] <bryce> tjaalton: yes, that sounds ok by me
[08:46] <tjaalton> good, I'm filing the rest that are syncable
[08:46] <bryce> awesome
[08:48] <tjaalton> aiptek, suncg3, suncg6, suntcx
[09:00] <tjaalton> I should merge the input packages next
[09:05] <pwnguin> bryce: don't worry, inkscape is obviously crap because he says so
[09:05] <pwnguin> artists need adobe because that's the standard
[09:05] <pwnguin> i dont even know why you Free Software hackers bother trying
[09:06]  * bryce snorts
[09:06] <pwnguin> on the hubris scale, i think this guy takes second place
[09:07] <pwnguin> the ex-microsoftie who declared ubuntu was violating the spirit of the GPL by forking debian still holds king
[09:07] <bryce> hehe
[09:07] <pwnguin> s/holds/is/
[09:08] <pwnguin> who, by his own logic, debian itself largely violates the GPL spirit
[09:08] <pwnguin> grammar's not on my side tonight
[09:10] <pwnguin> he does have a point though; the community college i work for runs a graphic design program that feeds into places like hallmark
[09:11] <pwnguin> unfortunately, he murders this point by declaring nobody anywhere can avoid adobe
[09:12] <bryce> yeah, anything that goes "Everyone does foo" ends up just being a straight man for something new.
[09:14] <pwnguin> bringing peace to the middle east by converting everyone to hinduism
[09:14] <pwnguin> that reminds me to polish up my Linux Packaging form reply
[09:15] <bryce> right
[09:58] <tjaalton> hmm, evdev is syncable
[10:00] <tjaalton> sorry, isn't
[10:05] <tjaalton> actually, it is. having an extra fdi file that loads evdev for mice & keyboards isn't harmful, and those can be then dropped from hal
[11:03] <jcristau> tjaalton: it's probably doable to make debian/rules only install the fdi if(!ubuntu)
[11:17] <tjaalton> jcristau: yeah, but it might go away later, so it's not a huge deal right now
[11:17] <jcristau> ack.
[11:52] <jcristau> is there any replacement for http://people.ubuntu.com/~bryce/Xorg/versions_current.html? that seems to fail.
[11:53] <tjaalton> hmm, works here
[11:53] <jcristau> hrm
[11:54] <jcristau> f*cking firewalling.
[11:54] <tjaalton> heh :)
[11:58] <jcristau> works when i work around that.  thanks :)
[12:11] <tjaalton> I'll merge mesa 7.4.1 and clean up the diff, waiting for 7.5rc2 before working on it..
[12:12] <tjaalton> +start
[12:33] <jcristau> 7.4.2 looks like it should be coming soon
[12:47] <tjaalton> heh, so it seems
[13:12] <Sarvatt> 7.5rc2 was supposed to be out 2 days ago, was waiting around to update the ppa for it but gave up :D
[13:13] <tjaalton> 7.4.1-1u1 uploaded
[13:13] <tjaalton> jcristau: what was the command again you use to check the consistency in the git repo?
[13:14] <tjaalton> s/in/of/
[13:14] <jcristau> git clean -dnx
[13:14] <jcristau> to check if there are no spurious files
[13:15] <tjaalton> thanks, I'll add it to the wiki
[13:35] <tjaalton> bryce: seems you have stuff to push to xorg-server git?
[13:48] <jcristau> there.  Subject: [Mesa3d-announce] Mesa 7.4.2 released
[13:49] <Sarvatt> there's 7.4.2 like 30 minutes after you pushed it, repeat of intel 2.7.1 right after bryce pushed 2.7.0 :D
[13:53] <tjaalton> hah
[14:26] <jcristau> xorg-server's 100_xserver_exa_force_greedy.patch looks weird.  how do you make sure EXA_MIGRATION_GREEDY doesn't conflict with EXA_HANDLES_PIXMAPS?
[14:27] <tjaalton> sshh, it'll go away
[18:01] <apw> jbarnes, hiya ... wondering about KMS, i see you are poking that ship quite a bit
[18:02] <jbarnes> apw: yep, I wrote big chunks of it
[18:02] <apw> am struggling to find any up to date patches or even discussions on it and wondering what is planned to hit soon and where i might find patches
[18:02] <apw> so i can eval what might make karmic
[18:03] <apw> obviously intel mostly hit the tree in .29, wondering about ati etc.
[18:04] <jbarnes> yeah intel support is in 2.9
[18:04] <jbarnes> .29
[18:04] <jbarnes> with tons of bug fixes since it first landed
[18:04] <jbarnes> 2.6.x was the first 2d driver to really support it
[18:05] <jbarnes> ati support should be coming in .30
[18:05] <jbarnes> err .31
[18:05] <apw> yeah we are tracking for at least .30
[18:05] <apw> so ati is likely .31 material
[18:05] <jbarnes> but airlied has a branch he's shipping in F11 with all the ati bits
[18:05] <jbarnes> so if you ended up on .30 you could take the upstream ati development driver
[18:05] <apw> is there a a preview branch for the planned ati stuff?  against currentish heads?
[18:06] <apw> where might i find that ... i need to get my ducks lined up to help make some decision on what we are shooting for
[18:07]  * jbarnes digs up the urls
[18:07] <apw> thanks ... that'll make my life a lot easier :)
[18:07] <jbarnes> http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=summary
[18:08] <jbarnes> the drm-rawhide branch has the latest radeon support
[18:08] <apw> hmm i poked about in his repo and it all seems 2.6.29-rc based.  which seemed wrong
[18:09] <jbarnes> yeah he hasn't updated in awhile it looks like
[18:09] <jbarnes> but I think all you need is the drivers/gpu/drm and include/drm stuff anyway
[18:10] <apw> yeah i am sure its not beyond me to rebase it should it be neeed
[18:10] <jbarnes> lemme ping glisse, he might have a tree too
[18:10] <apw> any idea where the nv supprot is kms wise?
[18:11] <jbarnes> I know the red hat guys are working furiously on it
[18:11] <jbarnes> but I don't know what the current status is
[18:12] <apw> thanks for your help :)
[18:12] <jbarnes> you might try sending a note to dri-devel too, Jerome Glisse is the main radeon kms guy right now afaik, and Ben Skeggs is the nouveau guy iirc
[18:13] <apw> cool.  will do that ...
[18:13] <jbarnes> ah apparently glisse has a kms tree for radeon: git://anongit.freedesktop.org/~glisse/drm-next drm-next-radeon
[18:14] <jbarnes> http://neo-technical.wikispaces.com/kms-glisse
[18:16] <jbarnes> http://jglisse.livejournal.com/1822.html
[18:16] <jbarnes> apw: the things you get when you ask a simple question on #dri-devel :)
[18:17]  * apw adds that to his list of irc channels
[18:20] <jbarnes> seems like there's a lot of interest in ati kms so everyone jumped on me when I asked ;)
[18:20] <tormod> you can find those things on planet.freedesktop.org
[18:58] <apw> heh i bet there is :)  i am sure we will be shouted at if we don't have it in kk
[19:04] <tormod> there will be shouting whatever you do
[19:06] <tormod> I am a bit worried now with all bugs moving into the kernel, will X debugging gets a lot more difficult? will we need serial console to sort out mode problems?
[19:07]  * tormod didn't try kms yet
[19:42] <tormod> anyone here understanding MTRR ranges? http://launchpadlibrarian.net/26765241/dmesg
[20:16] <LLStarks> bryce, you there?
[20:18] <jbarnes> bryce: btw fix for https://bugs.freedesktop.org/show_bug.cgi?id=21488 is a good one, might be the root cause of the 965 hangs
[20:48] <rzr> tormod: hi
[20:49] <tormod> hi rzr
[20:49] <rzr> tormod: my membership is about to expire and https://bugs.launchpad.net/bugs/189393 is still open :)
[20:50] <rzr> tormod: i have to track this
[20:50] <tormod> rzr: membership?
[20:52] <tormod> rzr: do the Options mentioned in the upstream bug help?
[20:53] <rzr> no
[20:58] <tormod> rzr: I suggest following up upstream - they are aware of the problem. make sure you always try latest git, just in case
[20:59] <rzr> i have the git changelog in my rss feed 
[21:00] <tormod> I am not there yet, but I check cgit.freedesktop.org quite often :)
[21:02] <tormod> Sarvatt: did you make that mesa hook? otherwise I'll take a stab on it
[21:11] <Sarvatt> tormod: sprry. no i didnt
[21:13] <Sarvatt> sorry too :)
[21:36] <bryce> tjaalton: pushed.
[21:36] <bryce> tjaalton: just flipping the debug patch back on
[21:38] <bryce> we can probably get rid of 100_xserver_exa_force_greedy.patch; we've not been forcing greedy on intel for a while so that patch is obsolete.  besides, -> uxa.
[21:46] <LLStarks> hey bryce
[21:50] <bryce> heya LLStarks
[21:51] <LLStarks> bryce, i'm not sure if you've overheard my interest in seeing dri2 swapbuffers get backported into karmic.
[21:52] <LLStarks> but i am of the opinion that we shouldn't have to wait until next april to have it in a release.
[21:53] <LLStarks> i can easily see the requisite code for dri2proto, mesa, xserver and xf86-video-intel making the cut
[21:54] <LLStarks> the problem will most certainly lie within a decision to use 2.6.30 rather than 2.6.31
[21:55] <LLStarks> in that case, a backports to 2.6.30 may be in order.
[21:55] <LLStarks> bryce, what do you think?
[21:55] <bryce> mm
[21:56] <bryce> I don't know enough about the patch in particular, but yes I do sense we're going to need a lot of kernel stuff backported just in general, if we're going to make kms work well
[21:56] <LLStarks> this code will be very desirable if karmic is dri2+uxa+kms
[21:56] <bryce> LLStarks: can you file a bug with the git url for the thing that needs pulled, so we can keep track of it?
[21:56] <LLStarks> bryce, the patches in question will allow tear-free output
[21:56] <mnemo> i guess it will be decided at UDS, but is it more likely at this point that we get .30 for karmic?
[21:56] <LLStarks> bryce: http://virtuousgeek.org/blog/index.php/jbarnes/2009/05/07/pageflipping_blocking_etc
[21:57] <LLStarks> the 3rd comment has the requisite bits
[21:57] <bryce> LLStarks: set a milestone for it and target it to the karmic release.  That will ensure it gets reviewed
[21:57] <LLStarks> what packages should i file against? all requisites?
[21:57] <bryce> LLStarks: mm, how about linux and -intel?
[21:58] <LLStarks> gotcha
[21:58] <bryce> even though it sounds like there's nothing to do for -intel, it'll help us keep track of it.
[22:00] <bryce> mnemo: well, I would guess .30 but it's a kernel team decision ultimately, and I think they plan to decide it at UDS
[22:00] <bryce> mnemo: apw knows about the -ati/.31 stuff so I suspect they'll be factoring into the decision whether to do the backport in .30 or move ahead to .31
[22:00] <mnemo> ok nice
[22:08] <bryce> mnemo: I'm also a bit concerned that X bugs are going to be moving into the kernel, which could make them tricky for us to debug, however we've got a good kernel team, so it may be a net win for us
[22:08] <bryce> mnemo: in any case I'm hoping to chat with with them about bug process
[22:11] <mnemo> yea its going to be different for sure
[22:11] <mnemo> i guess no more EDID in xorglog with KMS, heh
[22:16] <bryce> dunno, maybe; people will still want to xrandr their screen to other rez's
[22:16] <LLStarks> bryce: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/377090/
[22:30] <tormod> oops already a 7.4.2 regression, fdo #21756
[22:34] <mnemo> sounds like the whole intel QA team was playing ut2004 ;)
[22:36] <mnemo> ops no I looked at the wrong bug :)
[22:51] <Sarvatt> tormod: thats also present in 7.5 and 7.6, have had that problem for awhile.
[23:01] <Sarvatt> mnemo: you dont get EDID in the log? I do - http://sarvatt.com/downloads/Xorg.0.log.txt
[23:02] <bryce> Sarvatt: it seems inconsistent.  Some logs have it, some don't.  I haven't figured what makes it show sometimes, and not other times
[23:03] <bryce> I'd really like to force the edid to always be printed in the log.
[23:03] <mnemo> yea that'd be nice
[23:03] <mnemo> im upgrading my intel box to karmic right now and it got hosed big time when I turned on edgers
[23:03] <bryce> there's a few things I'd like to change about the logs, if I ever get the time
[23:03] <mnemo> its a G45 though, was that a know issue?
[23:04] <bryce> like, I'd like it to consistently put the nicely formatted lspci stuff in the log, so we can stop asking people to post their lspci -vvnn
[23:05] <bryce> mnemo: 'hosed'? sure
[23:05] <mnemo> yeah doesnt boot at all
[23:05] <mnemo> i get that "the greeter program crashed, trying another one"
[23:05] <mnemo> but this is after I added edgers
[23:06] <bryce> well you'd need to look at your Xorg.0.log and gdm logs to see why it failed
[23:06] <mnemo> hehe... yup
[23:09] <Sarvatt> was it kubuntu?
[23:09] <mnemo> nah
[23:10] <mnemo> rebooted it again now with no changes and now it started... xorglog says im now 2.7.99 now
[23:10] <mnemo> I get 4:3 resolution though which is wrong
[23:10] <Sarvatt> what type of input?
[23:11] <Sarvatt> vga?
[23:11] <mnemo> dvi
[23:12] <mnemo> apport found an intel oops now it seems
[23:14] <mnemo> bug 377107
[23:15] <mnemo> nothing on fdo for that one
[23:22] <mnemo> the dmesg keeps spamming "unable to read EDID from VGA-1" ... and i just doubled checked, its connected using dvi for sure
[23:34] <Sarvatt> ah of course you're on x64
[23:34] <Sarvatt> i was going to say you might want to try it with the latest drm-intel-next code added to the kernel and i have it here http://sarvatt.com/downloads/2.6.30-5.7/ but didnt build it for x64
[23:50] <Sarvatt> hopefully that stuff gets pulled into rc6 that should be coming in the next day or two
[23:50] <Sarvatt> speak of the devil, already did
[23:55] <Sarvatt> mnemo: http://lists.freedesktop.org/archives/intel-gfx/2009-May/002391.html looks sort of relevant, https://bugs.freedesktop.org/show_bug.cgi?id=21210
[23:57] <Sarvatt> i can apply the patch and throw the driver up on a ppa if you want to test it