[10:01] <tjaalton> bryce: ok, libdrm 2.3.1 is now released, so I can start :)
[10:01] <tjaalton> (without having to figure out if builds would break)
[10:02] <bryce> sweer
[10:02] <bryce> s/r/t/
[10:03] <bryce> tjaalton: there's a hug day for Xorg coming up on the 3rd
[10:04] <tjaalton> bryce: yeah I noticed.. we now have ~1900 bugs :/
[10:04] <tjaalton> although a lot of those have been originally misfiled and probably fixed already
[10:05] <bryce> could be
[10:05] <tjaalton> like "the input hungs" bug
[10:05] <bryce> I noticed some people have gone through and done a lot of "Ubuntu" -> "xorg" filings
[10:05] <tjaalton> yeah that's what I meant
[10:05] <Q-FUNK> some inputs are well-hung indeed.
[10:06] <tjaalton> hehe
[10:08] <bryce> tjaalton: with libdrm out, does this mean xserver 1.5 (or 1.4.99999?) is soon to come too?  :-)
[10:08] <tjaalton> bryce: should be. a couple of new RC's were released yesterday
[10:09] <bryce> sweet
[10:09] <bryce> mm, 2:1.4.99.902-1 is in experimental already, with 1.4.99.905 released upstream
[10:10] <tjaalton> yes, the merge was done against 902
[10:10] <bryce> cool
[10:11] <bryce> ok, well bedtime for me.  looking forward to the new xserver :-)
[10:11] <Q-FUNK> good night! :)
[10:11] <tjaalton> bryce: night"!
[10:11] <tjaalton> -"
[14:51] <seb128> is ati supposed to use xaa by default on intrepid?
[14:53] <jcristau> yes
[14:54] <tjaalton> only intel uses exa by default
[14:55] <seb128> bah
[14:55] <tjaalton> seb128: exa works better?-)
[14:56] <seb128> I get warnings in the logs about XAA being unsupported on radeon 9500 and newer
[14:56] <seb128> and compiz is unusably slow
[14:56] <tjaalton> that shouldn't be
[14:56] <seb128> hardy works great on the same box
[14:56] <seb128> I've a dual boot
[14:56] <tjaalton> only the driver has changed
[14:57] <tjaalton> server is the same
[14:57] <seb128> let me downgrade to the hardy version
[14:59] <seb128> bah, it takes several seconds to do the opening dialog animation
[14:59] <seb128> and xorg is using 100% cpu 
[14:59] <seb128> (still using the intrepid version)
[15:03] <seb128> no difference using the hardy version
[15:03] <tjaalton> hmmh
[15:07] <seb128> the hardy log shows xaa is used too
[15:07] <seb128> but there is line about it being unsupport and suggesting to use EXA
[15:07] <seb128> s/is line/is no line
[15:11] <seb128> in fact the warning is there too, just worded differentlu
[15:11] <seb128> differently
[15:11] <tjaalton> can you post the logs somewhere?
[15:12] <seb128> tjaalton: http://people.ubuntu.com/~seb128/Xorg.0.log
[15:12] <seb128> that's the intrepid log
[15:13] <seb128> and http://people.ubuntu.com/~seb128/Xorg.0.log.hardy
[15:14] <seb128> the log is using the hardy driver on intrepid
[15:15] <seb128> and the intrepid install is an amd64 one
[15:15] <tjaalton> hmm
[15:15] <tjaalton> somehow the intrepid log shows more supported chips than the hardy one
[15:15] <tjaalton> wonder how that's possible if the driver is the same version
[15:16] <tjaalton> and the log shows that it should be (6.8.0)
[15:17] <seb128> that's i386 against amd64 installs
[15:22] <tjaalton> I don't think it should matter..
[15:22] <tjaalton> hard to tell what could be wrong
[18:38] <tjaalton> bryce: all the poulsbo hunks failed to apply on libdrm, so I'd say that the changes are in 2.3.1 ;)
[18:47] <jcristau> tjaalton: doesn't poulsbo use ttm?
[18:51] <bryce> tjaalton: if that's the psb stuff in main, you can discard all that
[18:51] <tjaalton> hmm, actually seems like it's not there after all
[18:51] <bryce> tjaalton: as they continued updating libdrm their changes got bigger and bigger, and I ended up having to fork a UME-only libdrm 
[18:52] <tjaalton> bryce: ok, so it can be synced then
[18:52] <tjaalton> ..when 2.3.1 is in experimental ;)
[18:52] <bryce> I think jcristau is right that it contains TTM but I haven't gotten a reply from Intel when I enquire about that
[18:52] <bryce> yup
[18:52] <tjaalton> maybe they'll GEMify it too
[18:53] <bryce> I've run a request up the flag pole for them to switch to "a standard libdrm" going forward.  We'll see how that goes.
[18:56] <bryce> Dave Airlie:
[18:56] <bryce>         Stuff changed - you need this for Mesa 7.1, and Xorg 1.5
[18:56] <bryce>         Deal with it.
[18:56] <bryce> heh
[18:56] <tjaalton> :)
[18:57] <tjaalton> btw, libdrm/mesa/xserver/xorg/evdev are close to being ready
[18:57] <bryce> excellent, I was just wondering that
[20:15] <tjaalton> bryce: xorg merged.. maybe I should head home :)
[20:15] <tjaalton> before it's too chilly to cycle
[20:16] <tjaalton> bbl ->
[23:06] <tjaalton> bryce: ok, things should be ready now.. libdrm/mesa/xserver/xorg all merged and packages tested on my laptop (not run yet though, since I left it at work)
[23:08] <tjaalton> so after those are uploaded, all the drivers need to be rebuilt since both input and video ABI has changed
[23:11] <bryce> ok
[23:11] <bryce> awesome
[23:11] <bryce> how do we put in to request those rebuilds?
[23:12] <tjaalton> reupload as build1
[23:13] <tjaalton> or ubuntuX if there are changes
[23:15] <tjaalton> since the packages Provide xserver-xorg-{video,input}-ABIVER
[23:16] <tjaalton> should we hold the input-hotplug stuff until everything is built with the current versions?
[23:20] <tjaalton> or add the fdi-files to the drivers? (wacom, synaptics..)
[23:22] <tjaalton> I mean that it might we wise to get everything updated first, and then start figuring out when to push input-hotplug
[23:23] <bryce> yeah I think I agree
[23:23] <bryce> get a reference point in place first, then push input-hotplug in
[23:23] <tjaalton> right
[23:24] <tormod> tjaalton: are those packages in the ubunt branches of git.d.o?
[23:24] <tjaalton> tormod: xorg and xorg-server are, libdrm and mesa from debian-experimental
[23:24] <tjaalton> build order; libdrm - mesa - xorg-server
[23:25] <tjaalton> and xorg..
[23:25] <tormod> you're building xorg without dri then?
[23:25] <tjaalton> nope
[23:26] <tjaalton> hmm, did I not push everything..
[23:26] <tjaalton>     Re-enable dri & glx.
[23:26] <tjaalton> seems to be there
[23:27] <tormod> am I looking at the  right place: http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=shortlog;h=refs/heads/debian-experimental
[23:27] <tormod> no, got it
[23:28] <tormod> uhm not. this is 13days old: http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=shortlog;h=refs/heads/ubuntu
[23:28] <tjaalton> ok hold on
[23:34] <tormod> tjaalton: I basically wonder what you did to the dri/gl.pc stuff that xorg-server looks for
[23:35] <tjaalton> nothing really
[23:37] <tormod> xorg-server:configure looks for gl.pc which is not shipped by mesa AFAICS. I used to add them to the libgl1-mesa-dev.install in my xorg-edgers packages but I thought maybe I wouldn't need to any longer.
[23:40] <tjaalton> grepping doesn't find gl.pc from configure*
[23:43] <tjaalton> ok, xorg-server changes pushed
[23:44] <tormod> thanks. configure.ac: 827         PKG_CHECK_MODULES([GL], [glproto >= 1.4.9 gl >= 7.1.0])
[23:44] <tormod> but not in configure... hmm
[23:45] <tjaalton> glproto ships glproto.pc
[23:45] <tormod> no it's the "gl"
[23:45] <tormod> that I mean
[23:46] <tormod> it's in configure as well.
[23:47] <tjaalton> well..
[23:47] <tjaalton> checking for GL... yes
[23:47] <tjaalton> so.. :)
[23:48] <tormod> you have gl.pc on your machine maybe?
[23:48] <tormod> from which package?
[23:49] <tjaalton> mesa seems to have it, but it's not in any package
[23:49] <tormod> "seems to" ? :)
[23:49] <tjaalton> the source package
[23:50] <tormod> right. I know, that's why I added it to libgl1-mesa-dev.install for the moment
[23:50] <tormod> are you building in a pbuilder?
[23:50] <tjaalton> no
[23:52] <tjaalton> could pbuilder be taught to use it's own cache?