=== ara_ is now known as ara
[08:13] <RAOF> Man, moving i8{4,5}5 to VESA is going to cut down on the bug reports.
[10:14] <tseliot> Sarvatt: where's the patch for nvidia to enable compatibility with kernel 2.6.36 that you mentioned yesterday?
[10:54] <jcristau> RAOF: so you're moving those to vesa?  not trying your luck with ickle's shadow branch?
[13:30] <RAOF> jcristau: I think post-beta is a little bit late for trying my luck :).  There are shadow-branch packages in a PPA.
[13:32] <ScottK> How's i865 looking on Maverick?
=== schmidtm_ is now known as schmidtm
[13:56] <ScottK> Seems ~as good as Lucid (which for this system isn't too bad).
[14:19] <ScottK> I'd be curious what the forecast is for i865 support to the next LTS?  I'd sort of assumed I'd have to leave this system at Lucid, but Maverick live session works very well.
[14:20] <jcristau> too early to tell i think
[14:21] <Sarvatt> <Sarvatt> ScottK: should potentially be better off than lucid but i'd be interested in hearing your experience with it if you do try it :) I think 865 is the only 8xx remotely working right these days
[14:21] <Sarvatt> guess I got booted there
[14:22] <ScottK> Just after I said that I got a X crash on logout.
[14:22] <ScottK> So it's not quite there yet.
[14:23] <Sarvatt> wasn't lucid working for you?
[14:23] <ScottK> Lucid is working.
[14:24] <ScottK> I'm doing this from a maverick live session.
[14:25] <Sarvatt> RAOF: ugh, copyfb patch is what's making sandybridge not work with 2.12.0-1ubuntu3, its not that its fixed in git its just that I dropped the patch in the git ones
[14:25] <ricotz> Sarvatt, hi, are you planning some upload to the edgers ppa?
[14:25] <Sarvatt> ricotz: yeah going to fix up mesa today
[14:26] <ricotz> i need to delete the lucid package of cairo, and upload it again
[14:26] <ricotz> this copying from the primary archive seems to mess something up which prevents ia32libs to build
[14:27] <ricotz> Sarvatt, the mesa package for maverick is ok?
[14:28] <Sarvatt> ricotz: yup
[14:29] <ricotz> Sarvatt, i think deleting a package takes sometime until it is really gone?
[14:30] <Sarvatt> yeah check ppa.launchpad.net/xorg-edgers/ to see when it really goes away
[14:33] <ricotz> Sarvatt, to clean up a bit - do you think the hardy,intrepid,jaunty packages can go?
[14:34] <Sarvatt> tormod wants to keep those, I suggested that too many times :)
[14:35] <ricotz> mhh, he is not around to ask again ;-)
[14:36] <Sarvatt> that was before we could filter by release and we got a space bump, i don't really mind anymore :)
[14:37] <ScottK> Sarvatt or RAOF: Would you please look at Bug #628077 and let me know if there is any additional information I should collect before I bail out of this live session?
[14:37] <ubot4> Launchpad bug 628077 in xserver-xorg-video-intel (Ubuntu) "Intel i865 crash on logout with KDM (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/628077
[14:37] <ricotz> Sarvatt, yeah, sure, but they are quite old and not to edgers-like anymore
[14:38] <Sarvatt> ScottK: hmm, odd, had the same problem in lucid and we backported a commit that fixed it but thats already in 1.9.0
[14:39] <ScottK> Sarvatt: This is at least slightly different since that one only failed for non-admin users.  This failed in the live session so it was for an admin user.
[14:41] <Sarvatt> ah the gpu did hang
[14:42] <ScottK> Do let me know if there's anything else I can add.
[14:42] <Sarvatt> ScottK: there are probably *many* of the same bug report already, will try to dig into the others and dupe it, shouldn't need more info
[14:42] <ScottK> Thanks.
[14:42] <Sarvatt> did you use KMS with lucid?
[14:44] <Sarvatt> it should have defaulted to that unless you explicitly disabled it in case you dont know
[14:44] <ScottK> Yes.  I did.
[14:44] <ScottK> (I did use default)
[14:45] <Sarvatt> ScottK: If you want it to just work for the moment I suggest using the fbdev X driver instead of intel
[14:46] <ScottK> OK.  I'm not upgrading that machine yet, so I'll just wait and see.
[14:49] <ricotz> Sarvatt, are you using mutter with edgers nouveau?
[14:50] <Sarvatt> ricotz: nope just compiz
[14:51] <ricotz> ok, compiz is fine, but mutter (gnome-shell) has some greater issues
[14:51] <ricotz> i hope your mesa update will solve some things
[14:53] <Sarvatt> i need to fix the symbols for the lucid version and refresh the osmesa patch, will be a few hours because i'm doing some bug triage and trying to get a machine running now
[14:54] <Sarvatt> ugh, 865 is in bad shape like the rest of 8xx on maverick it looks like, duping about 30 bugs to one now with the same hang
[14:54] <ricotz> Sarvatt, alirght, keep in mind cairo is missing now until i'll upload it again
[14:55] <ricotz> or isnt mesa depending on it?
[14:56] <tseliot> Sarvatt: where's the patch for nvidia to enable compatibility with kernel 2.6.36 that you mentioned yesterday?
[14:56] <Sarvatt> http://sarvatt.com/downloads/patches/nvidia-graphics-drivers-lucid-backport.patch
[14:56] <Sarvatt> wait wrong patch
[14:57] <Sarvatt> http://sarvatt.com/downloads/patches/nvidia-2.6.36-ioctl.patch
[14:57] <Sarvatt> ricotz: nope mesa doesnt need cairo
[14:58] <tseliot> Sarvatt: Thanks. I asked as I think I'll upload the new driver today
[14:58] <Sarvatt> \o/
[14:59] <Sarvatt> thanks tseliot, that should stop a bunch of bug reports :) (LP: #616023) is one for the new abi problem
[15:00] <tseliot> Sarvatt: yes, also I'll make sure to disable the workaround in Jockey
[15:04] <Sarvatt> bryceh: any idea whats going wrong with the graphs? http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-maverick-workqueue.svg
[15:10] <Sarvatt> think its too late to get a new intel-gpu-tools snapshot into maverick? not having to run intel_error_decode on every bug report to decode PGTBL_ER would be nice :)
[15:10] <Sarvatt> then again i'm starting to memorize what each one means
[15:13] <Sarvatt> need to make arsenal script one of these days that grabs i915_error_state.txt from every bug, decodes it with intel_error_decode and puts the first 15 or so lines into the bug info
[15:37] <Sarvatt> ricotz: updating mesa now
[15:37] <ricotz> one sec
[15:37] <ricotz> Sarvatt, i want to start the rebuilt of ia32libs for lucid first
[15:39] <ricotz> i still need to wait for the cairo packages to publish
[15:40] <Sarvatt> let me know when, i'll just upload maverick
[15:40] <ricotz> Sarvatt, nevermind just push it
[15:41] <ricotz> the currently broken mesa source would break the ia32lib aswell
[15:41] <Sarvatt> ah right
[15:42] <tseliot> Sarvatt: does -ati in edgers require the new xserver? Or will it build against lucid's default X?
[15:42] <Sarvatt> lucid? hmm
[15:43] <Sarvatt> tseliot: http://sarvatt.com/downloads/patches/xsfbsrevert.patch
[15:43] <Sarvatt> will need that + lowering the xserver-xorg-dev build dep in control
[15:43] <Sarvatt> but it should be fine with that
[15:43] <tseliot> Sarvatt: thanks a lot
[16:48] <Sarvatt> ricotz: argh, sorry, now the vmware build is busted on lucid
[16:48] <tseliot> Sarvatt: http://pastebin.ubuntu.com/486826/ I guess that patch wasn't enough
[16:49] <Sarvatt> needs an explicit xinerama proto dep there
[16:49] <Sarvatt> looking now tseliot 
[16:49] <tseliot> thanks
[16:49] <Sarvatt> ah darn, you do need xutils-dev
[16:49] <Sarvatt> it's safe to just use maverick's in lucid though
[16:50] <Sarvatt> it's just a build time dependency, it wont affect the binaries
[16:51] <tseliot> are you talking to ricotz now?
[16:52] <ricotz> Sarvatt, no problem, i dont bother so much about lucid ;)
[16:52] <Sarvatt> tseliot: nope that was about radeon
[16:53] <Sarvatt> any most every other x package from git
[16:53] <tseliot> Sarvatt: ah, thanks
[16:54] <Sarvatt> tseliot: sorry about that, I update xorg-edgers automatically with scripts and don't bump the build deps most of the time since everything builds against xorg-edgers where I have the updated deps
[16:55] <tseliot> Sarvatt: np, I appreciate your work and your help
[16:58] <Sarvatt> ricotz: ok new mesa for lucid with an explicit x11proto-xinerama-dev dep uploaded, its not in xserver-xorg-dev for lucid
[17:00] <tseliot> err... I guess I'll upload nvidia tomorrow
[17:01] <Sarvatt> this intel copyfb patch is a mess, I have a feeling its causing a large number of the x-x-v-intel bugs at the moment :(
=== yofel_ is now known as yofel
[17:32] <bryceh> Sarvatt, yeah I think I know, just been busy and didn't think anyone else was using the graphs :-) ; I'll try to square it away tonight
[17:33] <Sarvatt> bryceh: no worries at all its not important, I just like to see it go down when i knock out a big chunk :)
[17:33] <Sarvatt> (or get depressed when knocking out a big chunk doesn't outnumber the incoming bugs)
[18:32] <Sarvatt> RAOF, bryceh: What do you think about this for making fglrx/nvidia work without an xorg.conf? http://sarvatt.com/downloads/patches/0001-Attempt-to-get-nvidia-and-fglrx-working-without-an-x.patch
[18:33] <Sarvatt> all thats needed is that darn DefaultDepth
[18:34] <bryceh> Sarvatt, works for me, but be sure to run it by timo as well; I remember we attempted this once before but ran into some blocker (but I can't remember what it was)
[18:35] <Sarvatt> the defaultdepth 24 line yeah :( it'd be something for natty anyway
[18:57] <bryceh> Sarvatt, hey tell me about http://sarvatt.com/downloads/piglit/nouveau/ ?
[18:57] <Sarvatt> what about it?
[18:58] <Sarvatt> I dunno what ya mean, got a question about the nouveau results specifically?
[18:58] <bryceh> what is it? is it a good X test in general?
[18:58] <bryceh> is it nouveau only, or could we use it for any video driver?  where'd you find it?
[18:58] <Sarvatt> http://cgit.freedesktop.org/~anholt/piglit/tree/README has a decent description of it
[18:59] <Sarvatt> oh if you go up a level you'd see the other tests I did, http://sarvatt.com/downloads/piglit/
[18:59] <Sarvatt> its used to spot regressions in mesa, it's pretty sweet
[18:59] <Sarvatt> when they spot major bugs they add test cases to it to make sure it doesn't regress and such
[19:00] <Sarvatt> can run it on any driver, that one was just nouveau specifically
[19:00] <bryceh> is it hardware specific at all?  i.e. is there value on running it on several different radeon cards or would it produce the same results in all cases?
[19:01] <jcristau> yes
[19:02] <Sarvatt> yeah it's really hardware specific, the results aren't comparable across generations or anything
[19:03] <Sarvatt> ati has problems with it, there's a bunch of ati specific tests to work around them in there
[19:10] <Sarvatt> it'd be nice if the test names mapped to fdo bugs they were taken from more obviously though :)
[19:33] <cnd> RAOF, I've found a bug in /usr/share/X11/xorg.conf.d/50-synaptics.conf
[19:33] <cnd> I've cloned the git repo for synaptics
[19:34] <cnd> should I fix the issue in the file itself in conf/50-synaptics.conf
[19:34] <cnd> or should I add a patch in debian/patches to fix it?
[19:34] <cnd> I don't believe the file is shipped by upstream
[19:35] <Sarvatt> cnd: conf/* is shipped by upstream so patch it is :)
[19:35] <cnd> oh it is?
[19:35] <cnd> hrm, I need to poke whot then...
[19:35] <jcristau> what's the bug?
[19:36] <cnd> jcristau, the matches for synaptics doesn't specify MatchDevicePath "/dev/input/event*"
[19:36] <jcristau> that's intentional
[19:36] <cnd> jcristau, why?
[19:37] <cnd> whot said it was a bug
[19:37] <jcristau> because that would break !linux
[19:37] <jcristau> why is it a problem?
[19:37] <cnd> ok, bear with me as I explain, it's not obvious
[19:37] <cnd> two touchpad devices A and B
[19:37] <cnd> X enumerates A before B
[19:38] <cnd> they both have a /dev/input/event* node and a /dev/input/mouse* node
[19:38] <cnd> I want A to use evdev instead of synaptics
[19:38] <cnd> I set up xorg.conf to do that properly
[19:38] <cnd> A gets handled by evdev, everything is fine
[19:38] <cnd> B's /dev/input/mouse* node gets probed by synaptics
[19:39] <cnd> it doesn't match /dev/input/event* in the synaptics probe function, so synaptics runs the eventcomm AutoDevProbe callback
[19:39] <cnd> the AutoDevProbe callback finds the first evdev node that isn't grabbed by synaptics
[19:39] <cnd> in this case, it finds A
[19:40] <jcristau> i'd argue that the bug is to go trolling random devices when it doesn't like the one it's given
[19:40] <cnd> one could make that argument
[19:40] <jcristau> also who has 2 touchpads? :)
[19:40] <cnd> ummm, I do?
[19:40] <cnd> I actually have 3 :)
[19:40] <jcristau> uh
[19:41] <jcristau> didn't know that existed :)
[19:41] <cnd> not that I actually use them all at the same time :)
[19:41] <jcristau> you don't have 3 hands?
[19:41] <cnd> internal synaptics trackpad, magic trackpad, bamboo touch
[19:41] <cnd> I'm still trying to grow a third
[19:41] <jcristau> hehe
[19:41] <cnd> so yeah, the eventcomm interface probably shouldn't even have an AutoDevProbe callback
[19:42] <cnd> but I just want to fix things for maverick right now
[19:42] <cnd> the simplest solution, as pointed out by whot, is to ensure synaptics is only called on evdev nodes through MatchDevicePath
[19:42] <jcristau> right
[19:43] <cnd> so I'll just create a patch to add the match clause
[19:43] <jcristau> in debian i'd like to avoid installing a different file on different archs..
[19:43] <cnd> oh yeah, hrm
[19:43] <cnd> that's a paiin
[19:43] <cnd> jcristau, I could make a patch to not register the eventcomm callback
[19:43] <jcristau> maybe i can add an option to the driver to disable auto-dev thing, and set that in the xorg.conf.d snippet
[19:44] <cnd> are you volunteering to fix it? :)
[19:44] <jcristau> so that a regular InputDevice section still works, but the hotplugged ones don't go crazy
[19:44] <jcristau> i'd say go with your MatchDevicePath for maverick
[19:45] <jcristau> i don't know when i'll have time for this
[19:45] <cnd> sure
[19:45] <jcristau> are you going to toulouse btw?
[19:45] <cnd> yep
[19:45] <cnd> I assume you'll be there/
[19:45] <cnd> ?
[19:46] <jcristau> i should get up my ass and look at trains/hotels
[19:46] <cnd> heh
[19:46] <cnd> if only I could ride a train there
[19:46] <cnd> or anywhere for that matter...
[19:47] <jcristau> seems to be 5h30 from paris to toulouse
[19:47] <cnd> hmm, that's quite a bit longer than I would have thought
[19:48] <cnd> though I'm not that familiar with france :)
[19:50] <jcristau> hmm, or i could take a plane.  flight is 1h10.
[21:05] <Sarvatt> RAOF: yeah its definitely not hw cursor init it's hanging in, thats just where the log stops normally - http://sarvatt.com/downloads/xorglog-snb.txt
[21:07]  * Sarvatt kicks the copyfb patch some more.
[22:11] <Sarvatt> RAOF: so, a refreshed copy-fb applied to xserver-xorg-video-intel git master works. argh! http://sarvatt.com/downloads/patches/101_copy-fb.patch
[22:13] <Sarvatt> I tried bringing back the changes from that vs our 101_copy-fb.patch to 2.12 but no luck there
=== ion_ is now known as ion