| 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:00 |
| 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:02 |
| 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:03 |
| 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:04 |
| Ng | bryce: first time I mentioned it here was on the 16th | 00:06 |
| 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:09 |
| Ng | groovy | 00:12 |
| bryce | (chasing down an -ati banding issue atm) | 00:13 |
| Ng | is there a quick guide for what I should be building to run -intel from git? | 01:38 |
| bryce | Ng, you mean dependencies? | 01:40 |
| bryce | Ng, the current git -intel probably needs gem, which might mean git versions of mesa and libdrm | 01:41 |
| bryce | Ng, I went through the exercise last month - http://people.ubuntu.com/~bryce/Testing/Gem/ | 01:43 |
| 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:44 |
| Ng | hmm | 01:45 |
| tjaalton | wow that was fast.. svu already committed the abnt2&jp106 patch to xkeyboard-config | 11:05 |
| tjaalton | less than an hour after I filed the bug | 11:06 |
| 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:19 |
| 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:20 |
| 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:21 |
| seb128 | ok, thank you | 15:22 |
| jcristau | or i could try to blackmail you into getting #491292 fixed in debian :) | 15:22 |
| seb128 | .la are annoying | 15:25 |
| seb128 | I'll try to get this one fixed for the next upload ;-) | 15:25 |
| bdmurray | tjaalton: bryce said I should ask you if bug 248521 would be fixed now | 17:03 |
| ubottu | 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:03 |
| * Ng has a go at building drm, mesa and xf86-intel | 17:41 | |
| Ng | this is probably going to go horribly wrong ;) | 17:41 |
| Ng | oh right, fail, kernel patching required | 17:57 |
| Ng | I figured it was just part of the kernel bits of libdrm | 17:58 |
| tjaalton | bdmurray: well, we don't use vmmouse anymore in intrepid :) | 18:10 |
| 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:13 |
| bdmurray | tjaalton: that's interesting, so everything should just work? | 18:15 |
| 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:16 |
| bdmurray | tjaalton: okay, thanks do you want to update that bug or shall I? | 18:20 |
| tjaalton | bdmurray: maybe I could check that they really are using input-hotplug | 18:52 |
| bdmurray | tjaalton: How would you check? | 18:53 |
| tjaalton | bdmurray: I'll ask a few questions | 18:53 |
| bdmurray | tjaalton: alright, I'll watch the bug to find out which questions! | 18:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| superm1 | ok let see | 18:58 |
| tjaalton | the wacom fdi file might not recognize it | 18:58 |
| 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? | 18:59 |
| 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:00 |
| 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:01 |
| 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:03 |
| bryce | superm1: btw I've made some progress with that gradient banding issue | 19:09 |
| 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:10 |
| 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:11 |
| superm1 | interesting | 19:13 |
| superm1 | so must not be abstracted then | 19:13 |
| 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:14 |
| 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:15 |
| pwnguin | i would love to find some documentation regarding hal and wacom | 19:58 |
| 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:03 |
| pwnguin | heh | 20:09 |
| pwnguin | ah, the phoronix guy | 20:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| * pwnguin dislikes voodoo programming | 20:13 | |
| tjaalton | bryce: check bug 272086, things missing from the new failsafe mode | 20:46 |
| ubottu | Launchpad bug 272086 in xorg "could not configure display at boot, now defaults to 800x600" [Undecided,New] https://launchpad.net/bugs/272086 | 20:46 |
| bryce | tjaalton: looking | 20:49 |
| bryce | yeah those are just innocuous warnings, but I've fixed up the code anyway; we probably don't need that logic | 21:35 |
| tjaalton | ok, cool | 21:37 |
| bryce | tjaalton: with -nvidia being dropped from inclusion on the CD, do we still include -fglrx? | 21:51 |
| 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:52 |
| 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 | 21:53 |
| bryce | tjaalton: did we used to ship l-r-m on the CD? | 22:00 |
| tjaalton | bryce: ye | 22:01 |
| tjaalton | +s | 22:01 |
| 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:02 |
| 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:03 |
| tjaalton | Awsoonn: full Xorg.0.log please | 22:04 |
| Awsoonn | righto. | 22:04 |
| bryce | Awsoonn: are you the one who reported 272086? | 22:04 |
| 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:05 |
| tjaalton | oh yes, 271905 | 22:08 |
| tjaalton | bug 271905 | 22:08 |
| ubottu | Launchpad bug 271905 in xserver-xorg-video-ati "X does not start with last update (ati)" [Undecided,New] https://launchpad.net/bugs/271905 | 22:08 |
| tjaalton | "compiled for 7.10" | 22:12 |
| superm1 | so unfull upgrade? | 22:16 |
| tjaalton | maybe, straight from gutsy -> not supported | 22:18 |
| 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:20 |
| tjaalton | quite a desperate leap I'd say ;) | 22:21 |
| 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:23 |
| 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:24 |
| 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:25 |
| Awsoonn | alright, I'll go purge and let you know how it goes~ | 22:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:35 |
| 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:36 | |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| ubottu | Launchpad bug 271905 in fglrx-installer "X does not start with last update (ati)" [Undecided,Incomplete] https://launchpad.net/bugs/271905 | 22:41 |
| ubottu | Sorry, I don't know anything about dead | 22:41 |
| ubottu | Launchpad bug 271905 in fglrx-installer "X does not start with last update (ati)" [Undecided,Incomplete] | 22:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| Awsoonn | :) indeed | 22:46 |
| Laney | Excellent, that fixed it! And now I have Compiz as a bonus | 22:48 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| 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:16 |
| 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:17 |
| ubottu | Launchpad bug 155685 in xorg "vesa doesn't work with PowerPC, so failsafeXServer fails" [Medium,Triaged] https://launchpad.net/bugs/155685 | 23:17 |
| superm1 | uname ? | 23:18 |
| bryce | uname -m it is | 23:21 |
| bryce | it prints "ppc" iirc? | 23:21 |
| superm1 | er hm not too sure | 23:23 |
| * bryce snags source | 23:23 | |
| superm1 | it might output ppc64 on some of them | 23:24 |
| superm1 | if you really become desperate, you can upload something that in it's debian/rules runs uname -m ;) | 23:25 |
| bryce | hmm, looks like it should print "powerpc" actually | 23:26 |
| bryce | hard to say though. I'll just check for all three | 23:30 |
| === superm1 is now known as superm1|away | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!