[00:00] <Ng> but something is very wrong with the G45 support afaics. windows seems to be just fine, but xorg crashes a lot, hates switching back to console VTs and drops the signal irregularly
[00:00] <Ng> not drops, flaps
[00:02] <bryce> weird, I'm on a 965 right now and am not seeing such problems
[00:02] <bryce> when did you start seeing this?
[00:03] <Ng> after the fix got in for it crashing when locking the screen and I switched back to compiz I think, but I lock quite a few times a day and it's only happening once a day at most
[00:03] <bryce> has it been within the last couple days, or longer?
[00:04] <Ng> yeah, it happened a few minutes before I mentioned it
[00:04] <bryce> no I mean, did it *start* happening within the last couple days?
[00:04] <Ng> oh
[00:04] <Ng> hmm
[00:06] <Ng> bryce: first time I mentioned it here was on the 16th
[00:09] <bryce> ok, when I get to a good breaking point I'll get this machine up to the latest and see if I can reproduce.  I've not updated/rebooted it since early this week
[00:12] <Ng> groovy
[00:13] <bryce> (chasing down an -ati banding issue atm)
[01:38] <Ng> is there a quick guide for what I should be building to run -intel from git?
[01:40] <bryce> Ng, you mean dependencies?
[01:41] <bryce> Ng, the current git -intel probably needs gem, which might mean git versions of mesa and libdrm
[01:43] <bryce> Ng, I went through the exercise last month - http://people.ubuntu.com/~bryce/Testing/Gem/
[01:44] <bryce> however I think we've pulled in some of that to Ubuntu now, so you may be able to just build xf86-video-intel directly 
[01:45] <Ng> hmm
[11:05] <tjaalton> wow that was fast.. svu already committed the abnt2&jp106 patch to xkeyboard-config
[11:06] <tjaalton> less than an hour after I filed the bug
[15:19] <seb128> jcristau: hi, do you plan to update pixmap in debian soon? it's required for the new cairo version ;-)
[15:19] <tjaalton> seb128: already done ;)
[15:19] <tjaalton> in experimental
[15:19] <seb128> tjaalton: ok, so the pts is lagging
[15:19] <jcristau> no, i didn't upload
[15:19] <tjaalton> ah ok
[15:19] <jcristau> should be pretty much ready in git though
[15:20] <seb128> and I meant pixman but you corrected the typo I guess ;-)
[15:20] <jcristau> yeah
[15:20] <seb128> jcristau: any reason you didn't upload?
[15:20] <jcristau> yeah. i'm trying to get work done
[15:20] <tjaalton> heh
[15:20] <seb128> ok, nothing broken in the new version
[15:20] <seb128> I was just wondering if that should be held back for a good reason
[15:20] <seb128> thanks ;-)
[15:20] <jcristau> there hasn't been any api/abi change from 0.11.8 though, is cairo not happy with that?
[15:21] <seb128> the cairo configure requires the new version
[15:21] <seb128> let me look why exactly
[15:21] <jcristau> i'll try to get to pixman over the week end. hopefully.
[15:22] <seb128> ok, thank you
[15:22] <jcristau> or i could try to blackmail you into getting #491292 fixed in debian :)
[15:25] <seb128> .la are annoying
[15:25] <seb128> I'll try to get this one fixed for the next upload ;-)
[17:03] <bdmurray> tjaalton: bryce said I should ask you if bug 248521 would be fixed now
[17:41]  * Ng has a go at building drm, mesa and xf86-intel
[17:41] <Ng> this is probably going to go horribly wrong ;)
[17:57] <Ng> oh right, fail, kernel patching required
[17:58] <Ng> I figured it was just part of the kernel bits of libdrm
[18:10] <tjaalton> bdmurray: well, we don't use vmmouse anymore in intrepid :)
[18:13] <bdmurray> tjaalton: okay, that's what I'd observed on a new install, but what happens to early intrepid adopters?
[18:13] <tjaalton> bdmurray: the same; input devices on the xorg.conf are ignored
[18:15] <bdmurray> tjaalton: that's interesting, so everything should just work?
[18:16] <tjaalton> bdmurray: yeah..
[18:16] <tjaalton> evdev steals the input devices
[18:16] <tjaalton> so while the other drivers would load, evdev stomps over them and grabs the devices
[18:20] <bdmurray> tjaalton: okay, thanks do you want to update that bug or shall I?
[18:52] <tjaalton> bdmurray: maybe I could check that they really are using input-hotplug
[18:53] <bdmurray> tjaalton: How would you check?
[18:53] <tjaalton> bdmurray: I'll ask a few questions
[18:54] <bdmurray> tjaalton: alright, I'll watch the bug to find out which questions!
[18:55] <bryce> :-)
[18:55] <tjaalton> bdmurray: heh, well there are no logfiles but the one from July, so those should reveal if evdev is used or not
[18:56] <superm1> hi guys, is wacom stuff supposed to be working OOTB on supported devices on intrepid, or should some xorg.conf poking still be necessary?
[18:57] <tjaalton> superm1: should work, but the driver is buggy
[18:57] <tjaalton> superm1: needs an update in the kernel too
[18:57] <superm1> tjaalton, well this is a usbish device, what's supposed to trigger it's detection?
[18:57] <tjaalton> superm1: hal, so if lshal doesn't show it, file a bug with lshal output
[18:57] <superm1> wacdump can read it's input file in /dev/input
[18:58] <superm1> ok let see
[18:58] <tjaalton> the wacom fdi file might not recognize it
[18:59] <superm1> lets see, /usr/share/hal/fdi/policy/20thirdparty/10-wacom.fdi right?
[18:59] <tjaalton> yep
[18:59] <tjaalton> but check lshal, is the device listed there?
[19:00] <superm1> well this is an n-trig device that is (somewhat) supported by wacom's framework, i was looking what's involved to add more full support.
[19:00] <superm1> so most definitely looking at this fdi file, it won't match on it
[19:00] <tjaalton> yeah
[19:01] <superm1> well i'll try to force add some stuff to this fdi file to match on the things coming up
[19:01] <superm1> how is hal's info.product name generated particularly?  It's a pretty ugly name
[19:01] <superm1> like HID 1b96:0001 right now
[19:03] <tjaalton> it's from the device
[19:03] <tjaalton> but that's probably not the right one
[19:03] <superm1> well it's the same event file that responds to things in wacdump
[19:03] <superm1> according to lshal
[19:03] <tjaalton> lshal usually lists a couple of udi's for every device
[19:03] <tjaalton> ah ok
[19:09] <bryce> superm1: btw I've made some progress with that gradient banding issue
[19:10] <superm1> bryce, oh? what's it's status?
[19:10] <bryce> superm1: apparently the dither registers changed with the newer hardware and that change isn't reflected in the driver.
[19:10] <superm1> bryce, that type of thing isn't abstracted by atombios?
[19:10] <bryce> apparently not
[19:10] <superm1> that seems odd
[19:11] <bryce> alex has given me new registers (not sure if the docs for this hw are available publically yet), but I tested them and they don't work
[19:11] <bryce> well, I see in the code there's already 4 different registers listed for dithering on different classes of hw
[19:13] <superm1> interesting
[19:13] <superm1> so must not be abstracted then
[19:14] <superm1> it looks like in this fdi file you don't exactly have the granularity to turn on multiple "Types" do you?  i turned on stylus for this input.product, and that works, but then i dont click touch capabilities
[19:15] <bryce> hmm, I'd think you could do that
[19:15] <superm1> yeah i guess i don't know the syntax much on it yet, so i'll poke around
[19:58] <pwnguin> i would love to find some documentation regarding hal and wacom
[20:03] <bryce> pwnguin: I put some links on wiki.ubuntu.com/X/Config iirc.  Didn't find stuff on hal + wacom specifically, but I'd also like to dig that up
[20:03] <bryce> hey, I just got an email from Michael Larabel - he likes the new bulletproof-x system, and sent me a patch, too
[20:09] <pwnguin> heh
[20:09] <pwnguin> ah, the phoronix guy
[20:10] <pwnguin> kind of wierd journalism, to post benchmarks and write code
[20:10] <superm1> pwnguin, well it looks like you can literally use every variable supported in 'man wacom'
[20:10] <pwnguin> superm1: right, but im not sure what it's setting up
[20:10] <superm1> but i'm having a hard time getting multiple instances of devices to come up (eg if the same device file is supposed to support stylus and touch)
[20:10] <pwnguin> (i dont have my tablet handy right now)
[20:11] <pwnguin> in my case, i need to do something crazy with the laptop identification
[20:11] <superm1> is the device not normally supported by the wacom driver, it just turns out you were lucky?
[20:11] <pwnguin> because it's serial connected
[20:11] <pwnguin> its a tabletPC
[20:11] <superm1> well gathering stuff like that together to put into FDI's and building a database would still be useful
[20:12] <pwnguin> indeed, but i really have no clue what the hell hal is doing. merge add append
[20:12] <superm1> i've just been using merge for my lines
[20:12] <superm1> i'm not sure about when to use add or append
[20:12] <pwnguin> im not even sure what the data structure those operations work on is
[20:13]  * pwnguin dislikes voodoo programming
[20:46] <tjaalton> bryce: check bug 272086, things missing from the new failsafe mode
[20:49] <bryce> tjaalton: looking
[21:35] <bryce> yeah those are just innocuous warnings, but I've fixed up the code anyway; we probably don't need that logic
[21:37] <tjaalton> ok, cool
[21:51] <bryce> tjaalton: with -nvidia being dropped from inclusion on the CD, do we still include -fglrx?
[21:52] <bryce> tjaalton: and if we do, should we?
[21:52] <tjaalton> we never have
[21:52] <tjaalton> only the modules, maybe
[21:52] <tjaalton> but no need for that either
[21:52] <bryce> what I'm wondering is, how sensitive are we to the late -fglrx with the CD release
[21:53] <tjaalton> it doesn't matter a bit :)
[21:53] <bryce> if fglrx isn't included on the CD, does it matter so much if it doesn't come in on time?
[21:53] <bryce> hmm
[22:00] <bryce> tjaalton: did we used to ship l-r-m on the CD?
[22:01] <tjaalton> bryce: ye
[22:01] <tjaalton> +s
[22:02] <tjaalton> I think it's still there, but since lrm no longer has modules for nvidia/fglrx..
[22:02] <bryce> right
[22:02] <bryce> interesting, this gives us some flexibility then
[22:03] <tjaalton> fglrx probably wouldn't make it to beta
[22:03] <tjaalton> won't
[22:03] <Awsoonn> I have upgraded a laptop to interpid today, and X wont start, ABI mismatch of somesort.
[22:04] <tjaalton> Awsoonn: full Xorg.0.log please
[22:04] <Awsoonn> righto.
[22:04] <bryce> Awsoonn: are you the one who reported 272086?
[22:05] <bryce> or if not, check if your Xorg.0.log matches the one in that report
[22:05] <tjaalton> I've seen a couple of those, probably fglrx related
[22:08] <tjaalton> oh yes, 271905
[22:08] <tjaalton> bug 271905
[22:12] <tjaalton> "compiled for 7.10"
[22:16] <superm1> so unfull upgrade?
[22:18] <tjaalton> maybe, straight from gutsy -> not supported
[22:20] <tjaalton> feisty had "compiled for 7.2.0, module version = 1.0.0"
[22:20] <tjaalton> hmm, 7.10 might have been 7.1.0
[22:20] <tjaalton> which would mean.. edgy. oh my
[22:21] <tjaalton> quite a desperate leap I'd say ;)
[22:23] <tjaalton> Awsoonn: so where's the log?-)
[22:23] <Awsoonn> i'm workign on cli here, give me asec
[22:23] <Awsoonn> :p
[22:23] <tjaalton> ah
[22:24] <tjaalton> Awsoonn: where did you upgrade from?
[22:24] <Awsoonn> my office
[22:24] <tjaalton> erm
[22:24] <Awsoonn> ;p
[22:24] <tjaalton> which version
[22:24] <Awsoonn> 8.04 -> 8.10
[22:24] <Awsoonn> :)
[22:24] <tjaalton> and you use fglrs
[22:24] <tjaalton> -x
[22:25] <Awsoonn> it was a fairly fresh install of hardy at that.  yea on teh fglrs
[22:25] <tjaalton> ok so purge fglrx, clean up your xorg.conf and you are fine
[22:25] <Awsoonn> attached to bug 271905... done
[22:26] <Awsoonn> alright, I'll go purge and let you know how it goes~
[22:27] <tjaalton> I know how it goes, it'll work just fine
[22:27] <tjaalton> mvo: shouldn't the upgrader purge fglrx on upgrade to intrepid?
[22:28] <tjaalton> hmm not only that, but also clean up xorg.conf..
[22:28] <tjaalton> I guess there's no de-jockey
[22:28] <superm1> dpkg-reconfigure xserver-xorg?
[22:29] <superm1> or perhaps a stub that uses python-xkit to turn off fglrx
[22:29] <tjaalton> well that would drop all other customizations too
[22:29] <tjaalton> but yeah, a clean slate works for me ;)
[22:31] <superm1> i seem to think that most people who have customized it will be able to recover from the loss of functionality
[22:31] <tjaalton> yeah
[22:31] <superm1> how easy is it going to be to turn this functionality on/off in update manager though? whenever the SRU is actually ready to fix fglrx?
[22:31] <tjaalton> I've no idea
[22:32] <superm1> er well has there been a discussion on how it's going to be implemented yet then?
[22:32] <tjaalton> not that I know of
[22:33] <superm1> well i'm assuming this will get up at the next platform or foundations team meeting then
[22:33] <superm1> bryce, could you let me know whenever it  gets put onto the agenda so I can sit in on that?
[22:35] <bryce> superm1: okay
[22:35] <Laney> Hi guys. One of the recent (last day) updates seems to have slain my X. I'm getting errors about get-edid not being installed. Quick workaround? (in a tty at the moment)
[22:36] <bryce> superm1: when do you think the last date we could accept a fglrx would be, in order to avoid having to auto-purge fglrx for everyone?
[22:36] <Laney> on intrepid btw
[22:36] <bryce> Laney: what driver are you using?  Xorg.0.log please.
[22:36]  * superm1 looks at the release schedule to think of an answer
[22:37] <Laney> bryce: Give me a minute - it's difficult to do stuff this way ;)
[22:37] <superm1> bryce, i think a solution should be ready to activate the week of oct 16 or so
[22:37] <superm1> bryce, so that there is a week to do testing prior to rc
[22:38] <superm1> and by solution ready to activate, i'm referring to the purge
[22:38] <mvo> tjaalton: I have no plan for fglrx users right now, I had kind of hoped we get a new version in time. update-manager can deal with that if required
[22:38] <Laney> Transcribing these. Xorg.0.log - http://pastebin.com/f59167dfd :0.log - http://pastebin.com/fe8c308b
[22:38] <tjaalton> superm1: did/does fglrx divert libdri.so?
[22:38] <superm1> tjaalton, yeah it does now
[22:38] <Laney> Card is an ATI of some description
[22:39] <tjaalton> mvo: ok, seems like it'll be post beta at the earliest
[22:39] <bryce> mvo, do you have an opinion on when the cutoff date should be for us to consider fglrx?
[22:39] <tjaalton> superm1: ok, so these problems are definately fglrx related then :/
[22:39] <superm1> tjaalton, well its only in the last upload or two..
[22:39] <superm1> tjaalton, and the diversion gets cleaned up on postrm
[22:39] <tjaalton> superm1: aha! :)
[22:39] <mvo> post-beta sounds not ideal
[22:40] <bryce> mvo, well I can guarantee it won't be coming before beta is out
[22:40] <mvo> bryce: I think -rc is the latest date, but even then we should prepare a backup plan (i.e. update-manager removing it etc)
[22:40] <tjaalton> superm1: you get to own that bug then :)
[22:40] <superm1> tjaalton, what bug?
[22:40] <tjaalton> bug 271905
[22:41] <tjaalton> ubottu dead
[22:41]  * superm1 kicks ubottu 
[22:41] <tjaalton> https://bugs.edge.launchpad.net/ubuntu/+source/fglrx-installer/+bug/271905
[22:41] <tjaalton> the ABI of the fglrx provided libdri.so doesn't match the server
[22:41] <superm1> are you sure they have fglrx installed?
[22:41] <tjaalton> confident
[22:42] <superm1> okay, i think i'll mark it dup of the other ABI bug
[22:42] <superm1> since they all come in together like that
[22:43] <tjaalton> ok, so seems like until the upload it was fine to have fglrx installed, but now when libdri is diverted things break
[22:43] <Laney> This seems to be what I'm experiencing. Shall I purge fglrx-installer?
[22:44] <superm1> Laney, yeah you will have to
[22:44] <Laney> Right. Will report back in a minute.
[22:44] <Awsoonn> :3 wow, tjaalton, have you been dealing with this bug all day
[22:44] <Awsoonn> or just a coinsedence?
[22:44] <superm1> well it shouldn't have been fine to have this fglrx installed anyhow though
[22:44] <superm1> with libGL diverted
[22:44] <superm1> should have seen some basic breakage there too
[22:45] <tjaalton> Awsoonn: no, but when I closed it as invalid there was this funny feeling that I did something wrong (rarely happens though)
[22:45] <tjaalton> so it got reopened, and now the reason was found
[22:45] <tjaalton> rejoice!
[22:45] <tjaalton> :)
[22:46] <Awsoonn> :) indeed
[22:48] <Laney> Excellent, that fixed it! And now I have Compiz as a bonus
[23:10] <bryce> Laney: hopefully you should find -ati is much much better than it used to be
[23:10] <Laney> bryce: It definitely seems to be. I'm just waiting for my first Compiz crash ;)
[23:10] <bryce> heh
[23:11] <superm1> given that nvidia's 177 is a beta driver too, do you  think that will be SRU worthy whenever they call a final?
[23:11] <Laney> I think it's made scrolling more laggy in Firefox though, although that could be some kind of negative placebo effect
[23:11] <superm1> (given the modularization of the drivers and all for intrepid)
[23:12] <bryce> superm1: I think with the modularization, the ability to do sru's ought to be a lot more feasible
[23:12] <bryce> esp. if we're going from 100% non-functional to functional
[23:12] <superm1> right
[23:12] <bryce> hard to argue that there could be potential regressions in that case ;-)
[23:12] <bryce> but of course it's up to the release team...
[23:12] <bryce> I'd certainly give it my +1 tho
[23:13] <bryce> Laney: well you could toggle compiz off and on and see if it makes any difference
[23:13] <tjaalton> superm1: 180 is released some time in Q4
[23:13] <Laney> bryce: I am doing
[23:14] <bryce> laney there are several configuration settings that can affect -ati performance; see man radeon
[23:14] <superm1> tjaalton, well 180 would be more of a backport type of thing, there should be a final 177 though that comes
[23:14] <Laney> It is definitely quite significantly more laggy with compiz on. Probably enough for me to leave it off.
[23:14] <tjaalton> superm1: well, if phoronix is to be trusted, 180 will be the stable version, 177 is beta
[23:15] <tjaalton> but who knows
[23:15] <superm1> tjaalton, well if that's the case, then I'd think SRU's are out of the question
[23:15] <superm1> tjaalton, but traditionally do they jump major version numbers from beta to release?
[23:16] <superm1> i thought they were pretty consistent about doing a bunch in one series until they hit a final for that series
[23:16] <bryce> laney, if there's not a bug report on it in launchpad already, feel free to file one - or ask on #radeon to see if it's a known issue or if there's a known workaround
[23:16] <tjaalton> superm1: hmm, right. 169.09 was the first stable one of that series IIRC
[23:16] <bryce> laney, I've heard some people report that using a different migration heuristic setting can help, but I think that's more in the kludge category
[23:16] <Laney> bryce: Radeon bug, not compiz?
[23:17] <bryce> laney, right
[23:17]  * Laney nods
[23:17] <Laney> I'll have a bit of a dig around
[23:17] <bryce> xserver-xorg-video-ati is the package to file bugs against
[23:17] <bryce> what's the best way to detect powerpc hardware?
[23:17] <bryce> (for bug 155685)
[23:18] <superm1> uname ?
[23:21] <bryce> uname -m it is
[23:21] <bryce> it prints "ppc" iirc?
[23:23] <superm1> er hm not too sure
[23:23]  * bryce snags source
[23:24] <superm1> it might output ppc64 on some of them 
[23:25] <superm1> if you really become desperate, you can upload  something that in it's debian/rules runs uname -m ;)
[23:26] <bryce> hmm, looks like it should print "powerpc" actually
[23:30] <bryce> hard to say though.  I'll just check for all three