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