[00:56] <Sarvatt> jcristau: yeah I sent the disable FBC commit to .33 stable earlier this week but not .32 yet since it needs changing
[00:58] <Sarvatt> i'm not sure if http://sarvatt.com/downloads/patches/disable_fbc.32.patch is correct and haven't had time to test it
[00:58] <Sarvatt> (for .32)
[01:02] <Sarvatt> GM45 has FBC problems on .32 and .33 too though, we're disabling it there as well soon :(
[01:02] <Sarvatt> screen flicker for GM45, getting stuck on a single color screen for 915-945
[01:12] <jcristau> oh thanks for doing this
[01:12] <jcristau> i'm not too bothered about .32 at this point
[01:12] <bjsnider> Sarvatt, did you get the nvidia 256 driver into x-updates?
[01:13] <jcristau> haven't had any issues on my gm45, but apparently some guy on bugs.debian.org/580601 does
[01:14] <Sarvatt> bjsnider: nope needs adjustments to the .install.in's to install all of the headers right, if you want to do it everything but that is in my nouveau ppa i linked earlier
[01:14] <bjsnider> wha?
[01:14] <bjsnider> i didn't understand that
[01:15] <bjsnider> i just finished earlier packaging it for pre-lucid distros, and it was a pain
[01:15] <Sarvatt> jcristau: yeah that guy is has the same problem as all of these - https://bugs.launchpad.net/bugs/538648
[01:16] <Sarvatt> bjsnider: well the packaging tries to install things from the old locations, everything is in the root directory after you extract it now
[01:16] <Sarvatt> all the headers in one place, need to manually put them in the right places in the install files
[01:16] <jcristau> Sarvatt: is there a fdo or korg bug i can link to?
[01:16] <Sarvatt> there's one on that bug where I upstreamed it but they haven't said anything on there
[01:16] <jcristau> sigh
[01:17] <bjsnider> Sarvatt, how about i take care of it here and send you the updated packaging scripts?
[01:17] <jcristau> thanks
[01:17] <Sarvatt> loading it up to link it
[01:17] <Sarvatt> http://bugs.freedesktop.org/show_bug.cgi?id=27589
[01:18] <Sarvatt> we're dropping FBC on that pci id (which happens to be the only GM45 anyway) though to work around it, odd that you dont experience it
[01:18] <jcristau> a month old..
[01:18] <Sarvatt> it took RAOF a few days to even see the flicker once on his
[01:19] <Sarvatt> but for some people its really bad, maybe dual channel/single channel memory configuration related I dunno
[01:20] <Sarvatt> would be nice of FBC was a module option that defaulted to off at this point :)
[01:21] <Sarvatt> bjsnider: send me a link to the PPA or whatever, i'll copy it over :)
[01:21] <Sarvatt> thanks a million if you do it btw
[01:22] <bjsnider> i thought i'd just build it in pbuilder here and then email the scripts to you as a tarball.
[01:23] <Sarvatt> that works if its easier for you<EMAIL_ADDRESS>[01:24] <bjsnider> very well
[02:38] <bjsnider> oh my god this is a nightmare
[02:39] <bjsnider> nvidia did this just to screw us over
[02:42] <bjsnider> the whole directory structure of the -dev package has been lost. what should i do, just throw all of the cuda, cl, gl, and vdpau headers into one directory?
[02:43] <bjsnider> or recreate the existing structure in the install script?
[02:44] <bjsnider> that's what i'll do. screw them, too
[03:08] <Sarvatt> bjsnider: yeah I said screw it and stopped when I saw that too :D
[03:10] <Sarvatt> its just like 10 headers though, just add each one to a seperate line in the -dev.install.in and have a second section after each pointing to usr/include/CL and stuff
[03:12] <Sarvatt> not sure, something like #DIRNAME#/cl.h                       #INCLUDEDIR#/#DRIVERNAME#/usr/include/CL/cl.h?
[03:12] <Sarvatt> (for each one)
[03:13] <Sarvatt> oh it installed everything to /usr/include/nvidia-current/foo/bar.h before
[03:13] <Sarvatt> so yep that should work? just gotta get the list of where everything goes from the current from the current nvidia-current-dev
[03:14] <Sarvatt> i thought it installed stuff straight into /usr/include/ hmm..
[03:15] <Sarvatt> anyway thats just 11 lines like i pasted in the nvidia-current-dev.install.in, i'll try that out
[03:16] <Sarvatt> oops meant #DIRNAME#/cl.h                       #INCLUDEDIR#/#DRIVERNAME#/usr/include/CL
[03:20] <Sarvatt> http://pastebin.com/Bv5fcMNb
[03:20] <Sarvatt> like that
[03:20] <Sarvatt> gotta fakeroot debian/rules regen-from-templates after of course
[03:25] <bjsnider> i'm testing now
[03:28] <bjsnider> it worked hahaha
[03:38] <bjsnider> Sarvatt, but the headers are only in that structure because that's how nvidia originally packaged them. if they think the headers don't need that kind of specific structure then i guess they don't
[03:51] <bjsnider> vga_arbiter_workaround.patch has to be disabled as it will not apply
[03:56] <Sarvatt> they do need that structure, nvidia-installer handles it now
[03:57] <Sarvatt> they just shoved everything in one directory :(
[03:57] <bjsnider> ok, i have it your way now except a bit shorter with wildcards
[04:00] <Sarvatt> guess XF86Config.sample is gone
[04:04] <bjsnider> yep
[04:04] <bjsnider> ok, i just successfully installed the module
[04:04] <bjsnider> so i guess the scripts i've got are appropriate
[04:04] <bjsnider> i'll pack them and email them immediately
[04:05] <bjsnider> or maybe i should reboot first?
[04:07] <bjsnider> Sarvatt, i have emailed the scripts to you
[04:13] <Sarvatt> think i've got it going too, checking the contents of every deb just incase and i'll compare to yours after
[04:21] <Sarvatt> only diff in our rules - http://paste.ubuntu.com/438134/
[04:22] <Sarvatt> looks like thats the only change lol
[04:25] <Sarvatt> includes are screwed up
[04:26] <Sarvatt> needs to go to /usr/include/nvidia-current/CL and stuff, got them in /usr/include/nvidia-current/usr/include/CL whoops
[04:28] <Sarvatt> #INCLUDEDIR#/#DRIVERNAME#/CL instead of #INCLUDEDIR#/#DRIVERNAME#/usr/include/CL
[04:29] <bjsnider> i changed the nv directory to kernel because of the change in nvidia's file obviously
[04:29] <bjsnider> i can't really think of any good reason for them to change the locations like they did
[04:30] <Bernardo> good morning
[04:31] <Bernardo> Sarvatt: can you point me where to find the meego psb drivers? Do I need to clone their whole git repo? I was looking through gitorious last night and couldn't find them
[04:33] <Sarvatt> what meego psb drivers?
[04:33] <Sarvatt> they are internal only still
[04:33] <Sarvatt> there's the kernel driver in the meego kernel-source git repo though
[04:34] <Sarvatt> there are also moblin ones with the 5.1 versioning in the moblin repos
[04:35] <Sarvatt> the meego ones are 5.3 and work with moorestown, meego has 5.1 with the appropriate kernel source in the src rpm (it's called like 2.6.32-msrt-rollup.patch I think)
[04:36] <Sarvatt> the ones in the latest moblin release from january were the ones you probably caught me talking about that were 2D only (3D needs gallium)
[04:37] <Bernardo> ok, thanks.
[04:37] <Bernardo> So those won't work with xpsb-glx?
[04:39] <Bernardo> we could live a little more without 3D, if at least xv works
[04:40] <Bernardo> I'll look into moblin then, since I am making no progress with freedesktop bug 28077
[04:52] <Sarvatt> bjsnider: tried the drivers out yet?
[05:01] <Sarvatt> i just uploaded them to x-updates since the debs look correct, wont be able to try for a few hours until the wife passes out
[05:26]  * Bernardo wonders why moblin devs had to hack the struct backlight_device
[11:47] <Bernardo|away> hi lucazade
[11:48] <lucazade> hi Bernardo
[11:50] <Bernardo> the mobline guys decision of including the module on the kernel sources is giving me a lot of trouble... :)
[11:50] <Bernardo> moblin
[11:52] <lucazade> are you trying moblin psb patches?
[11:52] <lucazade> or meego?
[11:52] <Bernardo> yes, I got their src rpms, but the patches are huge
[11:52] <Bernardo> moblin for now
[11:52] <Bernardo> meego doesn't have yet the xorg driver
[11:53] <lucazade> ok
[11:53] <Bernardo> at least that I could find
[11:53] <lucazade> didn't know
[11:53] <Bernardo> moblin guys decided to make a huge monolythic patch for psb
[11:54] <Bernardo> and change some drm files, and also redefine backlight_device in backlight.h
[11:54] <Bernardo> So I am trying to reduce the changes and build it as a dkms module,
[11:54] <lucazade> could you point me to this patch?
[11:55] <Bernardo> I extracted it from the kernel source rpm, but let me pastebin it, just a sec
[11:55] <lucazade> ok when possible :)
[11:57] <Bernardo> this is the big one - http://pastebin.com/aCFwLe3z
[11:57] <Bernardo> MRST-GFX-driver-consolidated.patch
[11:57] <lucazade> huge
[11:58] <lucazade> :O
[11:58] <Bernardo> there is also some psb related stuff in linux-2.6.31-drm-mem-info.patch - http://pastebin.com/P2Vn6NSq
[11:59] <Bernardo> I just got the 2.6.32 kernel from lucid, applied those two (correcting what wouldn't apply), then went to get it building out of tree, doing something like what is done in our current module
[12:00] <lucazade> so all these patches are related to psb drivers and not to iegd.. instead the new code drop for meego is for iegd,... right?
[12:00] <Bernardo> when I get it to build out of tree I'll have a go packaging it as a dkms module like the current one
[12:00] <Bernardo> There is also a big monster (though smaller) for IEGD
[12:01] <lucazade> *terrified*
[12:01] <Bernardo> http://pastebin.com/4eWVi81E - linux-2.6.31-iegd.patch
[12:01] <Bernardo> I left that one for you... ;)
[12:01] <lucazade> heheeh
[12:02] <lucazade> this stuff is known to work?
[12:03] <Bernardo> I think so - at least 2D
[12:03] <Bernardo> [05:36:47] <Sarvatt> the ones in the latest moblin release from january were the ones you probably caught me talking about that were 2D only (3D needs gallium)
[12:03] <lucazade> ok now is a bit clearer
[12:09] <Bernardo> I had to re-add a definition ubuntu had removed from drmP.h (DRM_PROC_PRINT)
[12:09] <Bernardo> later will see if I can remove that again and the calls to it
[12:09] <lucazade> tell me if i can help you
[12:14] <Bernardo> I'm fighting the makefile now... It seems easier to put all stuff in a single dir like the old module
[13:07] <bjsnider> Sarvatt, the build failed. your rules file is wrong in the 32-bit compat libs section. nvidia has removed some of the 32-bit compat libs.
[13:08] <bjsnider> the rules file i sent works
[14:34]  * Bernardo hates monolythic patches
[15:20]  * Bernardo gives up on moblin drivers for today
[17:06] <Sarvatt> still can't find libXvMC.so.1
[17:06] <Sarvatt> dont tell me that got moved to an alternative somewhere too..
[17:09] <tjaalton> libxvmc1: /usr/lib/libXvMC.so.1
[17:09] <tjaalton> apt-file search is your friend
[17:13] <Sarvatt> oh dangit I know the problem, I was adding the dep to the control not the control.in so it was getting removed
[17:13] <bjsnider> i already took care of this in my scripts
[17:14] <bjsnider> Sarvatt, did you remove the .so.1 links too?
[18:49] <Sarvatt> weird, glxinfo takes about 15 seconds to complete and I'm getting (WW) May 23 13:34:59 NVIDIA(0): WAIT (1, 6, 0x8000, 0x00004758, 0x00004858) in xorg.0.log when it happens, everything stalls
[18:49] <bjsnider> it's fine here
[18:56] <Sarvatt> i get it with 195 too apparently :(
[19:00] <Sarvatt> bjsnider: are you on karmic still?
[19:09] <bjsnider> negative
[19:09] <bjsnider> have you got an old card?
[19:10] <bjsnider> what opengl version does glxinfo give you?
[19:10] <bjsnider> mine is 3.3
[19:14] <Sarvatt> 8400M GS, 3.3 here too
[19:15] <Sarvatt> can you pastebin your ~/.nvidia-settings-rc?
[19:19] <bjsnider> http://pastebin.com/YkT7Ax4E
[19:19] <bjsnider> 'it's just defaults though
[19:20] <Sarvatt> 4x anisotropy and 12x FSAA is default?
[19:20] <Sarvatt> and texture sharpening enabled?
[19:24] <bjsnider> well, i have those things on full blast
[19:25] <bjsnider> everything else is default
[19:25] <bjsnider> besides i doubt any of those settings make any difference
[19:25] <bjsnider> except on windows
[19:32] <Sarvatt> enabled MSI and it's down to about 3 seconds for the freeze
[19:33] <Sarvatt> no, it didn't take the module parameter so its just luck it was faster that boot
[19:34] <Sarvatt> this doesn't happen on a 32 bit livecd with nvidia-current installed, ugh
[19:38] <bjsnider> is it really an irq issue though?
[19:45] <Sarvatt> its hanging polling the performance profile state looking at the strace
[19:46] <bjsnider> is it on a shared irq?
[19:46] <Sarvatt> nope
[19:46] <bjsnider> have you got a crap system there?
[19:47] <bjsnider> maybe the hardware's broken
[19:48] <Sarvatt> it worked fine for years with <=190 drivers
[19:49] <bjsnider> maybe it's the x server
[19:50] <bjsnider> what happens in karmic?
[19:50] <bjsnider> have you got any crazy stuff in the xorg.conf?
[19:50] <Sarvatt> its fine, its fine on a 32 bit livecd too
[19:50] <Sarvatt> nope stock
[19:52] <Sarvatt> thats highly annoying :) i forgot i disabled compiz because of this problem when we moved to 195 series
[19:53] <Sarvatt> 14 seconds to open the display 8 seconds to quit after it displays everything for glxinfo
[19:57] <bjsnider> is the cpu spiking at that point?
[19:59] <bjsnider> i don't see what the difference is in this context between a livecd and a hdd install
[20:03] <coz_> I know I have lucid on a 64 bit system with 32 bit install  ...also had 64  bit install with no issues with the 195.xx.xx drivers on either and no compiz issues..just thought I would comment :)
[20:13] <bjsnider> i think he has a hardware problem
[20:14] <coz_> I would guess the same
[20:15] <coz_> although the inability to install official nvidia drivers is a real  down side of lucid at this point  in terms of testing drivers for hardware configuration
[20:15] <Sarvatt> the livecd install is 32 bit my install is 64
[20:15] <Sarvatt> i give up on those darn 256 drivers for now, gnome panel is corrupted horribly every single boot too
[20:16] <Sarvatt> the whole display blinks on and off real quick when glxinfo is done showing the info before it actually quits too (was testing things remotely and didnt notice)
[20:20] <Sarvatt> ah should try nvidia-173 out
[20:22] <Sarvatt> hmm the panel corruption looks exactly like this guys - http://www.nvnews.net/vbulletin/showthread.php?t=149361
[20:25] <Sarvatt> oh jeeze dont tell me https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/456637 is affecting me too
[20:25] <Sarvatt> i might as well use nouveau if i have to use the highest perf state
[20:57] <bjsnider> Sarvatt, did you change powermizer settings like recommended in that thread?
[20:58] <Sarvatt> not yet, had to give the laptop back :)
[20:59] <Sarvatt> i'm just going to edit the video bios so the highest power state is the medium one if it does work
[20:59] <bjsnider> well, on that train of thought, my card doesn't have power management options because of a chip on the board being locked in position or whatever. so my card is always on full blast
[20:59] <bjsnider> and that might explain why mine works
[20:59]  * Sarvatt nods
[21:00] <Sarvatt> i mean i see it hung polling the power state info when i strace glxinfo
[21:00] <Sarvatt> just didnt have time to test forcing it
[21:04] <bjsnider> of course forcing a laptop gpu to full throttle isn't helpful in terms of power usage
[21:04] <bjsnider> nouveau is always on fullthrottle too so i bet nouveau works fine
[21:04] <Sarvatt> yeah, will try out 173 too incase that works
[21:08] <Sarvatt> it a huge hit, over 1.5 hours less battery life at max speed
[21:10] <Sarvatt> maybe i'll see how low i can push the GPU voltage at max speed instead, this GPU overclocks like crazy so it might have the headroom to go a lot lower
[21:11] <bjsnider> the changelog for the 256 blob doesn't explicitly say they fixed the powermizer issue
[21:13] <Sarvatt> i had it stable at 640mhz core clock up from 400mhz at one point with default voltages
[21:13] <Sarvatt> the windows drivers always were horrible at powermizer crap
[21:14] <Sarvatt> had to use specific releases because it was broken for months at a time
[21:18] <bjsnider> if the windows drivers were bad at it then i wonder if the problem is the shared code instead of anything linux-specific
[21:19] <bjsnider> or perhaps it's a design flaw
[21:30] <coz_> could be the card itself ?
[21:31] <coz_> could be the power supply is diing also.... change power plugs on the card to see if that helps incase it is just a bad plug
[22:13] <bjsnider> yes but this is a laptop


[13:57] <throwthecheese> Does anyone know which header to include f
[13:57] <throwthecheese> *to use MirConnection?