[00:08] <Sarvatt> superm1: hmm your nvidia 190 drivers dont pull in libvdpau for me
[00:09] <Sarvatt> ah maybe because Depends: nvidia-190-kernel-source (>= 190.42), libvdpau, x11-common (>= 1:7.0.0), ${shlibs:Depends} when the package is libvdpau1
[00:09] <superm1> Sarvatt, it's possible i didn't add that depends (because mythtv has it inheritently when it build-depends against something with vdpau support)
[00:10] <Sarvatt> might have been libvdpau in your 0.2 version and changed to libvdpau1 in this 0.3 i'm guessing
[00:16] <Sarvatt> its libvdpau1 in the 0.2 in all your PPAs too incase you want to change that in the nvidia-glx-190 depends next time you upload to one without mythtv
[00:17] <Sarvatt> ....not that there is one without mythtv now that i look :D
[00:20] <Sarvatt> thanks for all of the help, it's working great now
[00:29] <Sarvatt> hmm, updating the nvidia-glx-190 package to Depend on libvdpau1 didn't pull in libvdpau on the update either
[00:45] <Sarvatt> debian/control.in was missing the libvdpau depends completely was the problem
[00:48] <Sarvatt> The following NEW packages will be installed:  libvdpau1 The following packages will be upgraded:  nvidia-190-kernel-source nvidia-glx-190
[00:48] <Sarvatt> phew thats more like it
[00:52] <Sarvatt> now i notice no modalias getting installed :D
[01:56] <superm1> nvidia-common dependencies need  to be adjusted for that 
[03:04] <Sarvatt> i just made it provide nvidia-185-modaliases for now
=== freeflyi1g is now known as freeflying
[06:46] <Sarvatt> nvidia-settings 190.42 needed a patch to compile against the x11proto-xf86vidmode-dev headers instead of the libxxf86vm-dev ones, errors trying to build against the lib's after the xorg 7.5 split. http://bugs.gentoo.org/attachment.cgi?id=208926
[08:57] <Duke`> Sarvatt, is there a fix specific to our problem in this new libdrm? ([drm:i915_gem_execbuffer] *ERROR* Execbuf while wedged)
[16:27] <Sarvatt> Duke`: nope, pretty sure its a kernel problem. check out the "enable memory self refresh" patch threads on the intel-gfx mailing list. the new libdrm is just overwriting the headers in linux-libc-dev and its the same as the one before it otherwise
[16:28] <Sarvatt> Duke`: what kernel are you using? I haven't had it happen on the ubuntu 2.6.32 kernel yet
[16:28] <Sarvatt> of course suspend/resume is broken on this and not on the drm-next kernels, flickering and eventually freezing on a solid color after resume
[16:42] <hyperair> memory self refresh?
[16:42] <hyperair> what's that do?
[16:47] <Duke`_> Sarvatt, i use the 2.6.32
[16:48] <tjaalton> my intel seems to make X eat the cpu (stock lucid)
[16:55] <Sarvatt> anything special about it or is it just a stock install?
[16:55] <Sarvatt> gonna check if mine does too
[16:56] <Sarvatt> haven't tried the stock environment in a few weeks
[16:56] <Sarvatt> KMS doesn't work unless I blacklist vga16fb though on 2.6.32-7
[17:00] <tjaalton> nothing special, 965GM. booting fails ~every second time, evdev crashes for some reason and falls back to vesa (which doesn't work at all due to KMS)
[17:00] <tjaalton> I'll merge new evdev & xserver tomorrow
[17:00] <tjaalton> and mesa (includes r600_dri.so)
[17:02] <Sarvatt> does it happen with compiz disabled too?
[17:03] <tjaalton> haven't tried
[17:06] <Sarvatt> sounds like a problem hyperair (i think?) had with 965 back when edgers had mesa 7.6/libdrm 2.4.14 is why i was asking
[17:07] <tjaalton> I've had this before iirc
[17:07] <tjaalton> happens after the first resume I guess
[17:08] <Sarvatt> /proc/dri/0/gem_objects was growing huge and and x was using 100% cpu i think
[17:10] <tjaalton> size is 0
[17:11] <Sarvatt> now thats odd..
[17:13] <Sarvatt> reverting back to stock lucid now but i doubt it'll be the same on my 945
[17:14] <Sarvatt> hmm The following packages are BROKEN:  xserver-xorg-core
[17:15] <Sarvatt> oh because i have a newer wacom in edgers and theres no installable wacom in the archive
[17:16] <Sarvatt> sounds like yer using vesa though if theres nothing in gem_objects?
[17:17] <Sarvatt> ah joystick is broken in lucid too
[17:18] <Sarvatt> oops i have some newer bits in a local package archive, no wonder ppa-purge didnt work right
[17:19] <tjaalton> compiz works, so doubt it's vesa :)
[17:20] <Sarvatt> do you have a /proc/dri/1 ?
[17:21] <hyperair> Sarvatt: which issue?
[17:21] <Sarvatt> X using alot of CPU like 6 months ago
[17:21] <hyperair> Sarvatt: i had two issues: one was the crazy memory leak that drove me nuts, and the other was the weird re-drawing issue.
[17:21] <hyperair> X using a lot of CPU...
[17:21] <hyperair> no i don't think i had that
[17:22] <hyperair> i just had increased swapping activity
[17:22] <hyperair> until it took up all my resources
[17:22] <hyperair> if X got oom killed in the fray, then well and good, otherwise i restart
[17:22] <Sarvatt> rebooting to stock lucid to see how things are here
[17:22] <hyperair> or i preemtively log out and kill X before it can kill the rest of my computer
[17:23] <hyperair> anyway the issue was a kernel thing
[17:23] <hyperair> if lucid uses .32, it shouldn't see such an issue
[17:23] <hyperair> no wait, there was a patch involved in mesa i think..
[17:23] <tjaalton> I won't worry too much about it, yet
[17:24] <hyperair> no wait, it was definitely the kernel. i remember sarvatt giving me a custom compiled kernel and that solved all my issues
[17:30] <Sarvatt> thats strange, 4 reboots, X only started twice
[17:30] <Sarvatt> the other 2 I got failsafe with vesa all garbled
[17:30] <hyperair> ouch
[17:31]  * hyperair makes note not to upgrade to lucid until all's clear
[17:31] <tjaalton> Sarvatt: sounds like my problem. check the gdm log
[17:33] <Sarvatt> cant find any gdm logs from the failed boots hmm
[17:34] <Sarvatt> its only got the 2 successful ones then edgers ones, failsafe doesnt have anything in it
[17:35] <Sarvatt> when it failed x tried to start on vt2, dont know if thats normal for failsafe
[17:39] <Sarvatt> wonder why it fails like that with the lucid packages and not edgers though
[17:42] <Sarvatt> do you have plymouth installed tjaalton?
[17:42] <tjaalton> yep
[17:42] <Sarvatt> me too
[17:43] <Sarvatt> theres some video trickery in there, gonna try removing it
[17:52] <Sarvatt> what the heck, 4 boots again, 2 failures again
[17:56] <Sarvatt> got an orphaned /etc/init/usplash.conf for some reason
[18:13] <Sarvatt> 164_trap-aspect-ratios.patch is the only patch we're dropping in edgers vs lucids xserver
[18:15]  * Sarvatt wonders how this edid caching works in the ubuntu kernel
[18:17] <Sarvatt> its happening every other boot reliably though for some reason
[18:18] <Sarvatt> going to try a stock 2.6.32 just to rule out any kind of patches
[18:19]  * hyperair uses 2.6.32-zen0
[18:42] <Sarvatt> 10 reboots on a stock 2.6.32 kernel from the mainline thing and no errors, pretty darn safe to say its a ubuntu kernel patch messing it up
[18:49] <Sarvatt> only thing ubuntu specific that stands sticks out is http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=c5155725948be57010c4a558a1b9c5ddefb864c3
[18:55] <Ng> hrm, my trackpad isn't showing up in "xinput list" in lucid
[18:57] <Sarvatt> that commit isnt even in 2.6.32-7 thats having problems so definitely not that then