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