[03:22] <Sarvatt> nvidia 260.19.x seems to have killed most gt310 and gt330 users, and the CustomEDID option some people with optimus are using is broken to boot :(
[03:23] <RAOF> sarvatt: That's re: the current #ubuntu-desktop discussion?
[03:23] <Sarvatt> oh? didn't see, I just see tons of bugs and posts on nvnews about it
[03:24] <Sarvatt> everyone seems to be on one specific model sony vaio actually
[03:24] <Sarvatt> VPCF11
[03:25] <Sarvatt> ah the vpc f11 bugs are all using CustomEDID which is hanging
[03:25] <RAOF> Not bug #655446
[03:25] <ubot4> Launchpad bug 655446 in xorg (Ubuntu) "Xorg won't start (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/655446
[03:26] <Sarvatt> http://www.nvnews.net/vbulletin/showthread.php?t=155218
[03:45] <Sarvatt> looks like its all vaio gt3xx's, vaio z which needed a huge amount of hackiness to even use 256.xx is broken too
[03:46] <bjsnider> there are also a lot of +1 channel discussions from blob users who have a black screen on boot
[03:47] <Sarvatt> these crappy vaio's are popular machines it looks like :(
[03:48] <bjsnider> i wonder if nvidia is going to release another blob in the very near future
[03:50] <Sarvatt> vaio gt2xx's had the same problem dating back a year ago too and it was only fixed in 256.44 - http://www.nvnews.net/vbulletin/showthread.php?t=140482
[03:50] <bjsnider> perhaps the 256.53 would be the lesser of two weevils
[03:50] <Sarvatt> i wonder if the fix didn't make it to 260.19.x because they developed them in parallel and 256.44 was newer or something
[03:51] <RAOF> Or we could just blacklist it, and give them vesa!  That'll be popular :)
[03:51] <bjsnider> i don't know how you go back to the 256 now that you've already got the 260
[03:52] <RAOF> The 260 also (apparently) fixes a pretty major performance regression in text rendering, so it's not exactly a win-win.
[03:52] <RAOF> It'd technically be very easy to go back to 256.  :)
[03:53] <Sarvatt> 260.19.06-really-256.53.whatever
[03:53] <bjsnider> that would be ugly
[03:54] <Sarvatt> 256 would mean backporting 260 with the fix wouldn't be possible and we'd be stuck with the slow 256's
[03:54] <bjsnider> but then a whole bunch of people wouldn't be able to use it at all
[03:55] <bjsnider> that's one way to get people on the nouveau driver
[04:01] <Sarvatt> RAOF: if nouveau works I think I'd lean towards keeping 260 and updating later for sure because the impact is limited to vaio's with quad core cpu's, dual core optimus ones didn't work out of the box as it was anyway
[04:02] <Sarvatt> for gt3xx generation gt2xx generation did and it is a regression there though
[04:02] <Sarvatt> ugh :(
[04:03] <bjsnider> gt2xx can't be all bad. i'm ok on it
[04:03] <RAOF> But do you have a VPCF11 sony viao laptop?
[04:03] <Sarvatt> just vaio
[04:03] <bjsnider> you mean all the people who have come into the +1 channel today bellyaching about this are using vaios?
[04:03] <Sarvatt> VPCCW is the big gt2xx vaio fixed in 256.44 and broken again in 260
[04:04] <Sarvatt> i *only* see reports from vaio users
[04:04] <RAOF> sarvatt: I don't think there's any way we'd drop back to 256 on the basis of a specific single make of laptops having a problem.
[04:04] <bjsnider> well, i'll ask the ones tomorrow about it
[04:08] <Sarvatt> here's a Sager Np5125 but thats an optimus laptop and is broken because the CustomEDID option is broken 
[13:46] <hallyn> is https://help.ubuntu.com/community/BinaryDriverHowto/Nvidia/Nouveau still the right way in maverick to try out nouveau if i'm currently using nvidia drivers?
[13:47] <hallyn> (only have one laptop handy so prefer to keep experimentation to a minimum right now, but OTOH i'm getting these random 0-10 second delays in screen updates that are just not conducive to getting work done)
[13:48] <Sarvatt> hallyn: to use nouveau you just disable the binary drivers
[13:48] <Sarvatt> if you want 3D support with nouveau you install libgl1-mesa-dri-experimental
[13:50] <hallyn> 'disable' the binary drivers by removing the nvidia-glx package?
[13:50] <hallyn> (sorry, the whole thing about nto having an xorg.conf just has me all confused these days :)
[13:57] <Sarvatt> hallyn: in system - administration - additional drivers
[13:57] <Sarvatt> the disable button next to nvidia-current there
[13:58] <hallyn> do you know the name of the program that brings up?
[13:58] <Sarvatt> jockey-gtk
[14:01] <Sarvatt> you can just purge nvidia-current and remove your /etc/X11/xorg.conf by hand if thats easier
[14:01] <hallyn> thanks - i'm running jockey-gtk right now.  didn't see a disable tickie-mark, so i hit 'remove'
[14:01] <hallyn> maybe not what i wanted :)
[14:01] <hallyn> was sort of hoping for a symlink i could redirect
[14:03] <Sarvatt> you can switch with update-alternatives/ldconfig but its a pain in the rear
[14:03] <hallyn> Sarvatt: cool, seems to be done, i'll re-log-in in a bit to test - thanks!
[14:03] <Sarvatt> hallyn: thanks, let me know if it works out because I'm curious
[14:17] <bjsnider> Sarvatt, i've got a guinea pig here who's got a blob issue but not on a vaio
[14:18] <Sarvatt> bjsnider: 256.xx was fine for them and 260.xx doesn't work?
[14:18] <bjsnider> i'm trying to get that info
[14:18] <Sarvatt> because i'm not doubting there's blob issues
[14:55] <hallyn> Sarvatt: worked out great, actually.  In fact, now I get the high-res console to see the rest of bootup messages before x actually starts.  (with glx it just goes blank).  and (crosses fingers) so far none of the random hangs.  still have my 1600x900 resolution, not using any 3d right now so not sure if that's working
[14:55] <Sarvatt> hallyn: need to install libgl1-mesa-dri-experimental to get accelerated 3D in case you want that :)
[14:56] <Sarvatt> it may have problems and isn't supported by upstream yet so its not installed by default but it works great here
[14:57] <hallyn> Sarvatt: yup, i installed that.  just don't have any 3d apps ahandy :)
[14:57] <hallyn> oh, look at that, got a hang
[14:57] <Sarvatt> hah! :)
[14:57]  * hallyn starts to wonder if xterm is the problem
[14:58] <Sarvatt> if you install it compiz starts by default and that may be a problem
[14:58] <hallyn> no, i'm running wmii...
[14:58] <hallyn> at first is uspected compiz (i was using that with glx very pbriefly)
[14:59] <hallyn> this is crazy.  switching to gnome-terminal...
[15:00] <Sarvatt> are there any errors in dmesg?
[15:00] <Sarvatt> worst case scenario, you may need to boot with nouveau.noaccel=1 added to the kernel command line
[15:01] <hallyn> Sarvatt: but it also happened with nvidia... still worth trying noaccell in that case?
[15:01] <Sarvatt> oh? odd..
[15:01] <hallyn> nothing in dmesg :(
[15:03]  * Sarvatt isn't familiar with wmii
[15:03] <Sarvatt> what hangs, just individual terminals or the whole screen? how do you recover?
[15:03] <hallyn> it just recovers after awhile.  often jsut the terminal hangs, i *think* sometimes the whole screen does, but i could be wrong about that
[15:20] <hallyn> Sarvatt: well, it's pretty random, so it not having happened doesn't mean much, but it really may be xterm hanging
[15:21] <Sarvatt> hallyn: a wmii problem would be my first guess, i see a few bugs on their tracker about some apps hanging with a blank window that might be related
[15:23] <hallyn> Sarvatt: no, it happens with gnome+metacity as well
[15:23] <hallyn> heck, could be the keyboard driver for all i know
[15:24] <hallyn> need to write a little app that read kbdinput and prints out timestamps next to each char it reads
[15:24] <hallyn> then have my kids sit there and type 2 chars per second for a few minutes :)
[15:24] <hallyn> a lego robot, maybe
[16:14] <Cobalt> Hey guys. I just got a Apple Magic Trackpad. I was wondering how I could force it to use the Synaptics driver in Xorg.
[16:28] <bjsnider> Sarvatt, the guy i was mentioning earlier has an 8400 gs and it won't work with the 260 blob
[16:30] <Sarvatt> Cobalt: sudo mv /usr/share/X11/xorg.conf.d/60-magictrackpad.conf{,.bak}
[16:30] <jcristau> or just override it in xorg.conf
[16:30] <Cobalt> Sarvatt: Sorry, on Karmic.
[16:31] <Cobalt> jcristau: That's what I wasn't too sure how to do. The Ubuntu Wiki had a blurb on adding a section in Xorg. They edited out of the page yesterday and I can't find it anymore.
[16:31] <jcristau> i don't remember what was in karmic.
[16:31] <Cobalt> I don't want anything fancy, I was just wondering if I could get single-click to work.
[16:32] <Sarvatt> not sure about karmic, i'm surprised it works at all there
[16:32] <Cobalt> It points, but no click actions except with the nubs. And only button1 too.
[16:32] <Cobalt> Hence my wish for exploring a bit further. Oh I will upgrade, but since everything else works fine, I'm not in too much of a hurry.
[16:34] <Sarvatt> Cobalt: it might just work™ if you try a maverick kernel but that might cause other problems
[16:35] <Cobalt> I tried a Lucid kernel on this once. It messed up the wireless pretty bad. Eee PC, you know. I have reservations about a bolt-on Maverick kernel.
[16:36] <Sarvatt> yeah rt2600 is no fun
[16:36] <Cobalt> What's the command to dump a sample Xorg config file to standard output?
[16:37] <Cobalt> Well, RT nothing is fun, actually. I've had only grief with their products.
[16:39] <Sarvatt> sudo X :1 -configure ?
[16:39] <Cobalt> Ah yeah, just Googled that actually. Seemed a bit too simple. Gah sometimes, something obvious is just too obvious.
[16:39] <Sarvatt> should be one at ~/xorg.conf.new after that
[16:47] <raymondjtoth2> any one know how to install Mesa 3D GL driver for intel grahic
[16:47] <raymondjtoth2> i never did icpiling like to get all new stuff i just install Mesa 3D GL driver
[16:48] <raymondjtoth2> any one here
[16:48] <raymondjtoth2> ?
[16:52] <raymondjtoth2> any one know how to install Mesa 3D GL driver for intel graphic card
[16:53] <raymondjtoth2> i did install Mesa 3D GL driver
[16:53] <raymondjtoth2> i mean
[16:53] <raymondjtoth2> libgl1-mesa-dri-experimental
[16:53] <raymondjtoth2> i need help install mesa 3d gl driver i did install libgl1-mesa-dri-experimental
[16:54] <raymondjtoth2> any one
[16:56] <raymondjtoth2>  any one know how to install Mesa 3D GL driver for intel grahic
[16:56] <raymondjtoth2> <raymondjtoth2> i never did icpiling like to get all new stuff i just install Mesa 3D GL driver
[16:56] <raymondjtoth2> <raymondjtoth2> any one here
[16:56] <raymondjtoth2> <raymondjtoth2> ?
[16:56] <raymondjtoth2>  i did install libgl1-mesa-dri-experimental
[16:56] <raymondjtoth2> <raymondjtoth2> any one
[16:57] <raymondjtoth2> :(
[17:02] <raymondjtoth2> any one
[17:03] <raymondjtoth2>  any one know how to install Mesa 3D GL driver for intel grahic
[17:03] <raymondjtoth2> <raymondjtoth2> <raymondjtoth2> i never did icpiling like to get all new stuff i just install Mesa 3D GL driver
[17:03] <raymondjtoth2> <raymondjtoth2> <raymondjtoth2> any one here
[17:03] <raymondjtoth2> <raymondjtoth2> <raymondjtoth2> ?\
[17:06] <Cobalt> You need to be patient, I think.
[17:07] <jcristau> it's installed by default, you don't have to do anything.
[17:07] <tseliot> maybe he meant gallium?
[17:09] <raymondjtoth2> how i upgade to new build of it
[17:09] <raymondjtoth2> i ike to have all new stuff in it
[17:09] <raymondjtoth2> i need 3d for 945GM Graphics how i get the driver for that one
[17:09] <raymondjtoth2> thanks?
[17:09] <raymondjtoth2> flash video seam slow 
[17:09] <raymondjtoth2> on it
[17:09] <raymondjtoth2> and laging
[17:09] <jcristau> tseliot: there is no intel gallium driver
[17:09] <raymondjtoth2> what i do
[17:10] <raymondjtoth2> jc i got a 945GM Graphics
[17:10] <raymondjtoth2> intel 945GM Graphics
[17:10] <jcristau> you said that already.
[17:10] <raymondjtoth2> o ok 
[17:10] <raymondjtoth2> jc any thing i can do
[17:11] <raymondjtoth2> never did conpiling befor
[17:11] <raymondjtoth2> or hand install driver
[17:11] <raymondjtoth2> jcristau any idea
[17:13] <Duke`> :|
[17:14] <raymondjtoth2> any i dea
[17:14] <Cobalt> See, with this Bluetooth pairing thing, is it guaranteed every time I reboot my Magic Trackpad will be on /dev/input/event13? I have a funny feeling the answer might be 'NO'.
[17:15] <Cobalt> Also, I have a trackpad on my laptop which does not come up with X -configure.
[17:15] <jcristau> no
[17:15] <Cobalt> I wonder if its configs lie elsewhere.
[17:15] <raymondjtoth2> any one eles see my q
[17:16] <Cobalt> raymondjtoth2: Not me.
[17:17] <penguin42> Cobalt: I bet it'll always be /dev/input/by-id/something
[17:17] <Cobalt> penguin42: Yeah, but it would be a bummer to have to manually change xorg.conf each time manually to factor that in.
[17:18] <penguin42> Cobalt: No, I mean the bit after by-id/ will always be the same
[17:18] <Cobalt> Oh.
[17:19] <Cobalt> Strange, it mentions something from 'Broadcom'. Which is not what it is. :S
[17:20] <Cobalt> I think it's grabbing the BT adapter.
[17:20] <Cobalt> Still, something to try next time.
[17:20] <Cobalt> First I need to restart X to see if any of that actually works.
[17:20] <penguin42> Cobalt: Yeh so there is by-id and there is a by-path, but the path might change depending where you plug it in
[17:21] <Cobalt> It's an internal Bluetooth adapter. Some devices don't show up. But event13 which is the Apple Trackpad shows up as Broadcom something.
[17:21] <Cobalt> And Broadcom is the make of the BT adapter.
[17:22] <bryceh> http://www.weebls-stuff.com/songs/Narwhals/
[17:24] <Cobalt> I've got it already.
[17:28] <raymondjtoth2> is jc here'
[17:50] <Sarvatt> man, i want to see the bug count graph after today's over because i'm going crazy on the intel apport bugs
[17:53] <Sarvatt> got a pretty good routine going on how to spot dupes fast. start by picking a generation, run intel_error_decode on i915_error_state.txt, and you can categorize them by EIR PGTBL_ER and IPEHR matching to spot the dupes
[17:54] <Sarvatt> literally hundreds of these go through though and intel_error_decode in maverick's intel-gpu-tools isn't good enough to grab the info for all generations
[17:56] <Sarvatt> when chipset generation EIR and PGTBL_ER match the triggers described in the bug are almost always matching up
[17:57] <bryceh> Sarvatt, why don't you add that logic to the apport hook so it dupes things up properly?
[17:58] <Sarvatt> just matching EIR isn't enough, on 965 class hardware i'm seeing 3 different PGTBL_ER's with EIR: 0x00000010 so far
[17:58] <bryceh> (when you're done with the awesome cleanup)
[17:58] <Sarvatt> bryceh: because I'm just figuring this out now, will do :)
[18:00] <Sarvatt> quite a few are just the same people submitting lots of the same thing
[18:02] <bryceh> aside from being dupes, are you finding the collected crash reports are actionable or upstreamable?
[18:03] <Sarvatt> not at all
[18:04] <bryceh> hrm
[18:04] <Sarvatt> people just hit submit and dont describe whats happening 99% of the time
[18:05] <bryceh> they probably think the magic of apport collection gathers 100% of the needed info
[18:05] <bryceh> in which case ironically the apport script might be doing more harm than good
[18:05] <Sarvatt> the info is useful when i find a real bug report and have the big database of potential dupes to get more info from though  :)
[18:05] <bryceh> wish we had a crash database separate from the bug tracker
[18:06] <Sarvatt> now *that* would be nice
[18:06] <Sarvatt> BlackZ: what's up?
[18:07] <bryceh> it might be possible to have the apport script prompt the user with a dialog to provide more info or something
[18:07] <BlackZ> Sarvatt: oh, if you want, we can talk in #ubuntu-motu or here, both channels are OK for me
[18:08] <BlackZ> Sarvatt: but I think the question I was about to do you is a bit OT for this channel :)
[18:09] <Sarvatt> considering us X guys made ppa-purge for xorg-edgers I dunno about that :)
[18:12] <Cobalt> Sarvatt: It autodetects the Magic Trackpad then automatically loads evdev. I can't seem to disable evdev and make it use Synaptics instead, to find if there's some better usability there. :S
[18:19] <Sarvatt> why does this have to be so complicated? need to create a team so other people can commit to ppa-purge since its just using xorg-edgers now
[18:22] <bryceh> Sarvatt, didn't it get added to the repo that contains add-apt-repository?
[18:23] <Sarvatt> not that i'm aware of?
[18:26] <bryceh> hmm there is https://bugs.edge.launchpad.net/ubuntu/+bug/446216
[18:27] <ubot4> Launchpad bug 446216 in software-properties (Ubuntu) (and 1 other project) "add-apt-repository should have an option to remove ppa from sources.list (affects: 11) (heat: 48)" [Wishlist,Fix released]
[18:27] <bryceh> and https://code.edge.launchpad.net/~bryceharrington/software-properties/rm-apt-repository/+merge/25988
[18:29] <bryceh> anyhoo, time for some breakfast
[18:33] <Sarvatt> it's hard working up the will to go back to these other 40+ bug tabs I had open now that I got distracted :)
[18:34] <raymondjtoth2> any one see my q
[18:44] <cnd> jcristau, hi there
[18:44] <cnd> as I'm trying to do some development on X, I'm wishing the debian packaging worked more like ubuntu's kernel packaging
[18:45] <cnd> we keep everything in git, and the debian packaging and our own patches we apply on top of the upstream kernel are maintained as separate commits to the tree
[18:45] <cnd> when a new upstream kernel is released, the whole tree is rebased
[18:45] <cnd> it makes patch work much simpler, and allows us to easily track upstream development
[18:45] <Sarvatt> booo, hiss!! :)
[18:45] <cnd> what would be your thoughts on doing something similar for debians X packaging?
[18:46] <cnd> Sarvatt, are you not in favor of the ubuntu kernel approach, or are you just trying to incite a riot :)
[18:47] <Sarvatt> very much in favor of using the upstream tarballs and patching on top of that, I love the way it's set up now personally :)
[18:47] <raymondjtoth2> how i install 915resolution
[18:47] <raymondjtoth2> i dont see it
[18:47] <jcristau> you don't
[18:47] <raymondjtoth2> why that
[18:47] <raymondjtoth2> tell me i need it if 8 or 9 card
[18:47] <cnd> Sarvatt, it'
[18:48] <cnd> it's still patching on top of upstream
[18:48] <cnd> just in git form instead of tarball + quilt patches
[18:49] <cnd> the orig tarball can still exist as is, the debian diff would look odd though
[18:50] <cnd> my gut instinct says who cares what the debian diff looks like if we can do our development much faster/better
[18:50] <jcristau> why would the debian diff look odd?
[18:51] <jcristau> wouldn't it just be the same as it is today, with the patches applied inline instead of in debian/patches?
[18:51] <cnd> jcristau, yes, that's what I'm thinking
[18:51] <cnd> it would just look odd if you expect it to have stand alone patches
[18:51] <jcristau> (today it's a mix)
[18:51] <cnd> ahh, I didn't know that
[18:51] <cnd> I'm actually working on a tree right now
[18:52] <cnd> sort of a rough draft of this work flow
[18:52] <cnd> let me push it somewhere
[18:52] <jcristau> when a patch is already upstream we normally just cherry-pick it to the debian branch
[18:54] <cnd> ahh, that makes sense
[18:54] <cnd> which is sort of half of the work flow I'm envisioning
[18:54] <Sarvatt> xorg-edgers will be... fun.. if that change happens, only as easy as it is now because ubuntu changes are self contained patches on top of debian. guess i'd have to add some logic to maintain lists of commits to revert instead of patches to disable like it works now
[18:55] <cnd> Sarvatt, it should be easier actually
[18:56] <cnd> use git revert
[18:56] <cnd> which creates a new commit that undoes the debian patches we don't want
[18:56] <Sarvatt> and hope the commit didn't touch the changelog so it actually reverts?
[18:56] <cnd> when you rebase onto the latest X, it will come along too
[18:56] <cnd> the ubuntu kernel commits don't actually change the changelog
[18:56] <cnd> the changelog is generated at build time
[18:57] <cnd> well, actually it's generated at upload time
[18:57] <cnd> we'd need to replicate what the ubuntu kernel does there
[18:57] <cnd> ok, I'm remembering things now, the ubuntu kernel workflow adds a new git commit for each upload to the archive
[18:58] <cnd> and the contents of the commit is just the changelog entry
[18:58] <cnd> so all the patch commits leave the debian changelog alone
[18:58] <cnd> so you can easily revert things
[19:04] <jcristau> would you mind taking that to email e.g. on debian-x?
[19:04] <cnd> jcristau, sure
[19:04] <cnd> I'll make a tree and send an email about it
[19:14] <Sarvatt> barely put a dent in them - http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-maverick-workqueue.svg
[19:16] <Sarvatt> RAOF: asking about the vaio 260.19.xx problem in #nvidia to see if its a known problem, bug reports are still flooding in and they are all vaio gt2xx or gt3xx systems so thats holding up
[19:39] <tjaalton> Sarvatt: that's.. a depressing graph :)
[19:42] <bjsnider> it still looks to me like there's more broken hardware than justt he vaio
[19:53] <penguin42> Sarvatt: I think the good news is the free Radeon driver is actually getting useable and I suspect more people are using it so finding more bugs
[19:54] <Sarvatt> the radeon problems are almost all in the kernel, intel is the one thats making it nuts
[19:57] <cnd> Sarvatt, jcristau: how are ubuntu changelog entries handled when debian moves from one release to another, but there were ubuntu entries in between
[19:57] <cnd> it seems like we interleave them
[19:58] <Sarvatt> yeah we merge them back with merge-changelog
[19:58] <cnd> Sarvatt, ok, I'll take a look at it
[20:05] <cnd> Sarvatt, based on the merge-changelog code (I just glanced at it, man page was no help), it looks like it merges the changelogs and orders entries based on the package version?
[20:06] <cnd> does that sound right?
[20:06] <Sarvatt> yep
[20:07] <cnd> Sarvatt, so is this the process when you make a new ubuntu release:
[20:07] <cnd> 1. make changes
[20:07] <cnd> 2. run merge-changelog
[20:07] <Sarvatt> our goal is to not have a diff over debian as much as possible in the first place
[20:07] <cnd> 3. dch -i
[20:07] <cnd> ?
[20:07] <cnd> of course :)
[20:08] <cnd> actually, I'm guessing 2 and 3 are swapped
[20:09] <Sarvatt> which package are you using as an example? it varies a lot, some are perpetually ubuntu versioned like the server
[20:09] <cnd> I'm interested in xorg-server right now
[20:09] <cnd> what do you mean by perpetually ubuntu versioned?
[20:10] <Sarvatt> never need to run merge-changelog, i fix up the changelog diff with git mergetool when merging the debian branch into ubuntu
[20:10] <cnd> ahh
[20:10] <cnd> ok
[20:40] <Sarvatt> cnd: ./auto-xorg-git -t + -H hooks -d origin/ubuntu -u git://yourgitrepo.git -b yourbranch -g -p xorg-server -a 0ubuntu0cnd would work for the server if you have master and your changes in that branch, just need to add the patches to drop in hooks/xorg-server.prepatch, if you're just testing locally its easier to not bump the abi's in hooks/xorg-server.prebuild and just rebuild what you care about against it
[20:41] <Sarvatt> i just run it once and let it fail then fakeroot debian/rules clean and retry after adding the patch to drop in the hook to work out what patches in ubuntu need to be fixed or dropped
[20:43] <Sarvatt> there's only 3 or 4 ubuntu specific patches that are really needed anyway out of that huge mess in the server
[20:43] <cnd> Sarvatt, thanks for the pointers
[20:43] <cnd> I'll give it a go
[21:17] <cnd> jcristau, Sarvatt, to follow up, I think Sarvatt's scripts fulfill my needs, and I'm not sure the gitorized packaging branches would have worked out the way I intended in the end
[21:29] <Sarvatt> woohoo 3 of the arrandale/clarkdale bug reporters with (IPEHR: 0x01820000) are saying its fixed, need to ask for retesting on this mass of other bugs with the same error after duping them
[21:33] <Sarvatt> that error state seems common to lid closing or dpms events
[21:35] <Sarvatt> maybe i shouldn't dupe them and just ask for testing individually instead, all it takes is one person to say no to keep a bug with 50 dupes open :)
[21:36] <jcristau> just close it when one of them say it's fixed :)
[21:50] <Sarvatt> well at least I learned to say hibernate in 4 languages looking at PGTBL_ER: 0x00000003 bugs :)
[21:55] <Sarvatt> that one looks to be common across gen3 and gen4 but i'm not duping cross chipset just in case, got separate master bugs
[22:00] <Sarvatt> lol I was amazed I found an actual bug that could go upstream, then I see it's in karmic and I'm sure its fixed https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/510738
[22:00] <ubot4> Launchpad bug 510738 in xserver-xorg-video-intel (Ubuntu) "[g45] Stormbaan Coureur crashes: 'render error detected' (EIR: 0x00000010 PGTBL_ER: 0x00800000 IPEHR: 0x780a0101) (affects: 2) (heat: 10)" [Undecided,Confirmed]
[22:14] <Sarvatt> got the apport bugs condensed to 60 so far and I'm stopping for the day, there's still about 30 left to run intel_error_decode on not counting the ones where the people didn't use the apport generated title - https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bugs?field.searchtext=PGTBL_ER
[22:30] <Sarvatt> bryceh: weren't you looking for examples of when fdo bug statuses dont show up right in launchpad?
[22:31] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/634683 https://bugs.freedesktop.org/show_bug.cgi?id=30097
[22:31] <ubot4> Launchpad bug 634683 in xserver-xorg-video-intel (Ubuntu) (and 1 other project) "[gm45] Running piglit/occlusion-query-discard locks GPU (affects: 4) (heat: 163)" [High,Triaged]
[22:31] <Sarvatt> verified fixed critical shows up as confirmed critical
[22:32] <Sarvatt> guess the fdo bug should be resolved instead of verified or does that look right?
[22:33] <RAOF> High, Triaged?  That got closed in the 20100924 mesa snapshot upload.
[22:34] <bryceh> hang on, gotta reboot
[22:34] <Sarvatt> RAOF: oh I didn't even look at the launchpad side of the bug, I swear you closed it in the mesa changelog!
[22:35] <RAOF> It was probably during that time where LP wasn't closing bugs for us.
[22:38] <bryceh> Sarvatt, it's possible (likely) that the watch just didn't get triggered to update
[22:38] <bryceh> I'll reset it
[22:39] <bryceh> Sarvatt, ok, check it again in about an hour and ping me if it's not set correctly then
[22:50] <Sarvatt> well I guess it could be worse - http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-lucid-workqueue.svg
[22:53] <Sarvatt> oh thats only a little over a month, whoops
[22:54] <penguin42> Sarvatt: What was the release date back then?
[22:54] <Sarvatt> 4/29
[22:55] <penguin42> so you get a whole raft of fglrx-installer ones in the last few weeks until it just works by release?
[22:56] <Sarvatt> looks like someone cleaned those up right before october 1st for maverick
[22:57] <Sarvatt> mid september rather
[22:57] <penguin42> Sarvatt: What do you reckon for something I've suggested as bug 636418
[22:57] <ubot4> Launchpad bug 636418 in jockey (Ubuntu) "update should clean up/warn about jockey (affects: 1) (heat: 176)" [Undecided,New] https://launchpad.net/bugs/636418
[22:59] <Sarvatt> the warning would be nice, but as of the latest packages it already cleans up the installed ones right so that wont happen since tseliot added abi checks
[23:00] <penguin42> ah ok
[23:01] <penguin42> we just get so many people arriving on +1 suddenly finding they can't get graphics in an alpha/beta/rc
[23:01] <Sarvatt> fglrx->natty xserver 1.10 will remove fglrx on upgrade, the checks weren't there this cycle though and it was a mess
[23:01] <Sarvatt> wait, I may be wrong
[23:02] <dandel> I'd say contact amd first, and check to see when/if xserver 1.10 will be supported before just blindly removing fglrx.
[23:02] <Sarvatt> not sure if there are blacklists for specific drivers or if it removes everything wth the old abi
[23:03] <Sarvatt> they'll gladly not support it for years if no one ships it
[23:04] <dandel> xserver 1.10 is slatted for 11.x right?
[23:04] <Sarvatt> that was just an example, hasn't been decided or anything
[23:05] <Sarvatt> if 1.9.x rocks as much as 1.7.x did maybe not
[23:06] <Sarvatt> haven't seen a 1.10 release schedule yet
[23:06] <dandel> The only real concern i have is the fglrx kernel bugs.
[23:07] <Sarvatt> oh wait, its 6 months, pretty much for sure it'll be 1.9.x
[23:07] <Sarvatt> had a brain fart there, intel guy is the release manager so was thinking 3 months :)
[23:07] <dandel> I just hope that libva will get fixed correctly.
[23:07] <Sarvatt> i doubt it, libva is a real mess
[23:07] <dandel> maverik is missing packages.
[23:08] <RAOF> :)
[23:08] <dandel> it'd be good if libva could get ramped semi-frequently.
[23:08] <RAOF> What are we missing, libva-wise?
[23:08] <dandel> glx
[23:08] <Sarvatt> 965 "support"
[23:08] <RAOF> Sarvatt: You mean the 965 support that results in an assert as soon as something tries to use it? :){
[23:08] <dandel> for one... libva-glx or libva-glx1 
[23:08] <Sarvatt> i'm sure the debian maintainer could use the help if you want to help out with it
[23:09] <dandel> i just flat installed the libva 1.0.4 packages from the experimental debian repo.
[23:09] <Sarvatt> yeah it's not even released in debian
[23:09] <Sarvatt> just been brewing in git for a long time
[23:10] <dandel> libva is a pain, but is important and should of been properly put into the 10.10 release (but packages are missing)
[23:11] <Sarvatt> so why not help out with it?
[23:11] <RAOF> It'd be more important if anything used it.
[23:11] <RAOF> And a reasonable selection of hardware supported it :)
[23:13] <Sarvatt> i want to stab my eyes out every time i look at that code
[23:14] <RAOF> It'd be nice if there was a (free) gstreamer libva element.  That'd make me care about libva a lot more.
[23:15] <RAOF> Fluendo's gstreamer elements are kick-arse.
[23:15] <dandel> RAOF, it's in use by newer releases of vlc, ffmpeg, xbmc, mplayer, gnash and is picking up support increasingly on the api's. 
[23:17] <jcristau> if it doesn't support any hw that's kind of moot
[23:17] <dandel> It's supports nvidia video cards via vdpau.
[23:18] <RAOF> And fglrx via the (non-free?) xvba thingy.
[23:19] <dandel> an amd dev said that xvba got too much news coverage early in the dev cycle and it has no set ready date.
[23:19] <Sarvatt> jcristau: poulsbo and fglrx isn't good enough for you? :)
[23:19] <jcristau> Sarvatt: surprisingly, no
[23:19] <bryceh> *cough*
[23:20] <RAOF> I mean, I'm in no way against having it in the archive, and will give it some support, but it's hard find the motivation to invest time in it when it'll only run on top of the existing APIs of blobs.
[23:21] <RAOF> Which means that it'll become more interesting as it actually starts to support Intel hardware.
[23:23] <dandel> anyways, xvba doesn't work for me (yet), but that's somewhat anticipated... i have a evergreen based video card.
[23:24] <RAOF> Doesn't fglrx support evergreen properly yet?
[23:25] <dandel> it supports evergreen properly... it's just i don't have video accelerated decoding yet.
[23:25] <Sarvatt> http://wiki.debian.org/DebianMultimedia has some places to go to see what the status is for libva
[23:26] <RAOF> So, not full support for evergreen then.
[23:26] <dandel> however, i do get to run unigine heaven with tessellation enabled.
[23:27] <dandel> and the rendering for that program is correct... however, gluxmark2 (last i checked) had some defects in the 10.8 and 10.9 driver.
[23:28] <dandel> it's just that ati has no proven bug report methods that get quick results and testing... The location i use to report bugs has long delays. (a month just for confirmation of the bug as reproduce-able)
[23:30] <dandel> RAOF, do you want to actually see what i get when i try to run a vaapi based decode?
[23:32] <RAOF> Not particularly, no :)
[23:32] <dandel> i get a moziac of the output image.
[23:33] <dandel> the output is decoded with the gpu, but it's just that the output images are incorrect.