[00:20] <fagan> hey im trying to test out the nouveu driver and xorg is saying its not configured properly, I ran Xorg -configure but it looks like its not doing anything
[00:20] <fagan> Im on lucid by the way
[00:21] <fagan> I think it may have something to do with residual config from the nvidia driver 
[00:21] <fagan> Anyone have any ideas?
[00:23] <RAOF> fagan: How are you trying nouveau?
[00:24] <RAOF> Because the version in the archives currently isn't expected to work, pending some kernel-team decision about how to get nouveau.ko in our kernel build.
[00:24] <fagan> RAOF: Im using it from the nouveau ppa
[00:25] <fagan> The one from the archive works though
[00:25] <fagan> on my machine 
[00:25] <RAOF> Really?  It doesn't build against 2.6.32 kernels, though.
[00:25] <fagan> hmmmm I just installed it rebooted and it worked 
[00:25] <fagan> dont ask me how 
[00:26] <fagan> its definitly not the nv driver
[00:26] <fagan> That sucked on my hardware
[00:26] <RAOF> Its possible that you've got nouveau-kernel-source from the nouveau ppa and the DDX from lucid, I guess.
[00:27] <fagan> I did install the -source package so thats it :)
[00:27] <fagan> RAOF: so any ideas why im running safe graphics mode?
[00:27] <fagan> It hung when I did a -configire
[00:27] <RAOF> No idea, no.
[00:27] <fagan> -configure 
[00:28] <fagan> hmmm
[00:28] <fagan> any other things I can try?
[00:28] <RAOF> What's in your xorg.conf?
[00:29] <fagan> the nvidia config 
[00:29] <fagan> which caused the problem I think
[00:29] <RAOF> Well, yes.  Can you pastebin your xorg.conf?
[00:29] <fagan> damn I just rm'd it 
[00:30] <fagan> sorry 
[00:30] <RAOF> That's OK.
[00:30] <RAOF> All it wants is "Section "driver" Identifier "nouveau" Driver "nouveau" EndSection" in it.
[00:30] <fagan> oh ok then ill give it a go
[00:31] <fagan> be back in 5
[00:35] <notlistening> A bit later and there is no difference in the cpu usage on that machine with all the extras that i installed so there must be something different between the hardware more than just CPU and GPU
[01:00] <fagan> that didnt work anyway
[01:01] <fagan> so im going to go back to the nvidia driver 
[01:02] <fagan> the conflict is http://pastebin.ubuntu.com/337674/
[01:02] <fagan> The xorg update conflicts with nvidia's driver 
[01:02] <RAOF> Yes it does.
[01:03] <fagan> so what do I do?
[01:03] <RAOF> Not use the nvidia driver in Lucid.
[01:04] <fagan> That isnt a solution because my computer looks very crap without it
[01:04] <RAOF> Beacuse it won't work.  IIUC, we need a newer nvidia driver, one that will actually work against xserver 1.7
[01:05] <RAOF> fagan: Not use Lucid?  The proprietary drivers are frequently, and often long-term broken in development.
[01:05] <fagan> I tried the 190 driver with no luck
[01:05] <fagan> hmmmmm
[01:05]  * fagan thinks maybe rolling back to an older version of xorg will help him
[01:06] <RAOF> Yes, it might.  If you can :)
[01:08] <fagan> Or maybe a newer one
[01:08] <RAOF> Well, that won't work, because the nvidia driver won't work against it.
[01:09] <fagan> Ah ill see what I can do 
[01:10] <fagan> Dont ask me how but the ppa for the xorg team worked
[01:11] <fagan> no conflict no nothing https://launchpad.net/~xorg-edgers/+archive/ppa
[01:11] <Sarvatt> 185.18.36 worked for you with that?
[01:11] <fagan> 190
[01:11] <Sarvatt> oh ok
[01:12] <fagan> Awesomeness 
[01:15] <Sarvatt> i couldnt find a 190 in a ppa that wasnt really borked when i looked at the stuff in debian/ and one screwed up being able to downgrade back, ended up just manually installing it from nvidia for now
[01:16] <fagan> Nope spoke too soon got killed at the end of installation
[01:17] <fagan> damn it
[01:17] <Sarvatt> i had a ton of dangling alternatives from the bad packages
[01:17] <fagan> im just going to get the one from nvidia themselves
[01:18] <Sarvatt> 195.22 manually installed is working great with edgers here
[01:19] <fagan> got to exit the session to install it brb
[01:27] <fagan> that worked well
[01:28] <fagan> x and nvidia now play nice
[01:28] <fagan> why are the packages so bad then?
[01:29] <fagan> If the nvidia driver works why dont we just package that up that?
[01:32] <Sarvatt> tseliot is working on it
[01:32] <fagan> thank god
[01:54] <notlistening> Can i come back to my original question, aobut the amount of CPU i am using for a video, can the frame buffer in the bios make a big difference or the amount of RAM a system has to use?
[01:55] <Sarvatt> nvidia gpu acceleration requires either 128 or 256mb last i checked
[01:56] <Sarvatt> cant remember which, i think its 256
[01:56] <fagan> mine has 512
[01:58] <Sarvatt> if you are using xbmc, i know i saw a good guide on using gpu acceleration on an ion board in ubuntu on their forums
[01:59] <Sarvatt> http://blog.xbmc.org/forum/tags.php?tag=ion
[01:59] <notlistening> the bios limits me to 256 at the moment as i only have a 1 gb a the moment
[02:01] <notlistening> Thanks Sarvatt 
[02:04] <Sarvatt> gotta be a vdpau thread out there somewhere that'll explain how to make it work, you would know if its working because you'd be getting closer to 10% cpu usage than the 80%
[02:49] <Sarvatt> ewwww http://lists.x.org/archives/xorg-devel/2009-December/004029.html
[06:40] <LLStarks> whois keybuk
[06:40] <LLStarks> damn
[07:38] <RAOF> Hm.  X seems unusually slow, and seems to be spending a lot of time in i915_gem_throttle_ioctl.  Is this something others are seeing?
[07:45] <LLStarks> how would i know?
[07:45] <LLStarks> jeez, that sounded rude.
[07:50] <RAOF> You'd know if X was being extremely laggy for you, you had an intel card, and ran gnome-system-monitor and saw X waiting for i915_gem_throttle_ioctl :)
[07:56] <tjaalton> feels quite normal here
[07:59] <RAOF> Oh, wow.  ubuntu-desktop's new libgtk kills emacs!
[08:59] <tjaalton> heh, funny.. we ship a cirrus driver with patches to support qemu, and then in xserver a patch that uses vesa for the hw id
[09:22] <tjaalton> nevermind, it depends on what type kvm is using
[09:22] <tjaalton> "std" want's mesa
[09:22] <tjaalton> urgh, vesa
[09:22] <tjaalton> s/'//
[09:24] <tjaalton> that should be upstreamed
[09:34] <tjaalton> mvo: does update-manager always run dist-upgrade, ie. remove packages when there are conflicts during the devel release?
[09:36] <mvo> tjaalton: sort of, by default it does not do this, but it will prompt for "partial upgrade" mode if it has to remove stuff and tries to be clever
[09:37] <tjaalton> mvo: ok, thanks
[09:38] <mvo> why? anything that it should do to make transitions better or something?
[09:39] <tjaalton> nah, there was just one user who claims that lucid->lucid upgrade broke everything without prompting
[09:39] <tjaalton> and I don't believe him :)
[09:39] <tjaalton> the result was that it removed all the drivers
[09:39] <tjaalton> so the system didn't get X
[09:40] <mvo> not without prompting :)
[09:41] <mvo> if he used update-manager we should have logs too
[09:41] <tseliot> tjaalton: what's the status of input drivers in lucid? An AMD engineer reported that xserver-xorg-core is not installable. Was it just because of synaptics?
[09:41] <tjaalton> yes, but I won't bother.. told him to install video-all
[09:41] <tjaalton> tseliot: no, check the mirror
[09:41] <tjaalton> at least the images build
[09:42] <tjaalton> tseliot: also, the current synaptics doesn't have your patch in it, had to upload it to make it installable
[09:42] <tjaalton> but I'll add it now
[09:42] <tseliot> ok, thanks
[09:45]  * tseliot forgot about having a lucid chroot already
[09:45] <tseliot> xserver-xorg-core was installed correctly here
[09:46] <tjaalton> if he's using fglrx, it'll get removed
[09:46] <tjaalton> only the OSS drivers work
[10:01] <tseliot> ok
[10:03] <hyperair> does anyone here using the nvidia-96 driver have issues with screen flickering?
=== seb128_ is now known as seb128
=== paran_ is now known as paran
=== mac_v_ is now known as mac_v
[17:00] <tseliot> federico1: hey, do you have a few minutes to discuss new features (one of which is more of a fix) for g-s-d and g-d?
[17:02] <tseliot> otherwise I can file 2 bug reports and we'll discuss there
[17:21] <federico1> tseliot: sure, what's up?
[17:22] <tseliot> federico1: the 1st feature is support for transformations
[17:22] <federico1> tseliot: BTW, I'm going to start integrating some of the Moblin patches for RANDR stuff
[17:22] <tseliot> mainly scaling
[17:22] <federico1> ah!
[17:22] <federico1> there *is* a patch for that :)
[17:22] <tseliot> federico1: really?
[17:22] <tseliot> I'm working on Moblin too
[17:23] <federico1> I just haven't looked at it closely
[17:23] <tseliot> federico1: can you give me the link, please?
[17:28] <tseliot> federico1: I can't find it in the Moblin 2.1 sources
[17:29] <tseliot> federico1: anyway the 2nd feature is, put simply, that we check GL_MAX_TEXTURE_SIZE in addition to the max framebuffer size
[17:30] <tseliot> i.e. that we check the 3D limitations in addition to the 2D limitations
[17:31] <tseliot> for example on i945 chips you can have 2D up to 4096x4096 and 3D up to 2048x2048
[17:32] <tseliot> and if you go beyond the 3D limit when using a compositing manager you get a black screen
[17:34] <tseliot> therefore we should not validate modes that go beyond that when using, say, mutter (in Moblin)
[17:46] <federico1> tseliot: makes sense
[17:47] <federico1> tseliot: so, I don't know much about GL.  Is the texture size limit just for textures, or does it involve the whole screen?  I.e. could a smarter compositing manager simply create two textures for too-wide windows (or something like that?)
[17:48] <tseliot> federico1: it's the area in which you get 3d acceleration
[17:49] <tseliot> I have a bug report about it
[17:49] <tseliot> https://bugs.freedesktop.org/show_bug.cgi?id=23718
[17:49] <ubottu> Freedesktop bug 23718 in Driver/intel "[945GME] attaching external monitor causes black screen, with Compiz Fusion in Karmic" [Critical,New]
[17:51] <tseliot> I've written a patch to access max texture size but I haven't tested it yet. I'll file a bug report and attach it there soon
[17:51]  * tseliot -> dinner
=== yofel_ is now known as yofel
[23:00] <Amaranth> so, my mouse keeps jumping to the center of the screen now... :/
[23:04] <Amaranth> federico1: btw, while a compositing manager could split the screen into smaller chunks to work around the texture size limit the only way to do so is to not use GLX_EXT_texture_from_pixmap at all
[23:05] <Amaranth> the other way of doing OpenGL compositing is...slow