[00:00] <Sarvatt> oh yeah tjaalton, you have a 965 dont you? i think yours can recover from those errors that hang me if so
=== ripps|sleep is now known as ripps
[01:41] <RAOF> Whose got an nv50+ class card and would like to try nouveau?
[02:13] <Sarvatt> installing it now
[02:14] <Sarvatt> well 300mb of other updates to grab too
[02:17] <Sarvatt> should nouveau-kernel-source recommend the ddx or anything?
[02:26] <Sarvatt> hmm the kernel's not even trying to load nouveau
[02:27] <Sarvatt> FATAL: Module nouveau not found.
[02:29] <RAOF> Sarvatt: Actually, the kernel module sholud be useful even without the DDX; it *should* provide working suspend/resume.
[02:30] <RAOF> Sarvatt: Pulling from xorg-edgers into lucid?
[02:30] <Sarvatt> yeah i have edgers on that laptop
[02:30] <Sarvatt> got the 1217 one
[02:31] <RAOF> Hm.
[02:31] <RAOF> Works nicely on _this_ laptop.
[02:31] <RAOF> You've got a nv5x class chip?
[02:31] <Sarvatt> no modules in /lib/modules/2.6.32-8-generic/updates/dkms
[02:32] <Sarvatt> 8400M GS
[02:32] <RAOF> Ok, that's weird.
[02:32] <RAOF> Yay!  Tester for firmware loading.
[02:32] <Sarvatt> NV86
[02:32] <RAOF> So, I know that 1217 builds happily against 2.6.32-8-generic, because it's done so here.  What's your make.log say?
[02:34] <Sarvatt> weird, looks like it built it for 2.6.32-7
[02:34] <RAOF> Is that your running kernel?
[02:35] <Sarvatt> 2.6.32-8 was i was sure, on -8 now though
[02:35] <Sarvatt> whats the command to build it again?
[02:36] <Sarvatt> nouveau, 0.0.15+git20091217, 2.6.32-7-generic, x86_64: installed 
[02:36] <Sarvatt> guess i installed -8 then installed nouveau-kernel-source before rebooting..
[02:36] <RAOF> Oh, right.
[02:37] <RAOF> Yes!  And dkms is no longer run on boot, and I haven't changed the postinst to build for all available kernels.
[02:38] <RAOF> dkms build -k 2.6.32-8-generic -m nouveau -v 0.0.15+git20091217
[02:38] <Sarvatt> thats pretty nasty because it seems like what most people installing a new release > a week after release is going to be doing for nvidia or fglrx or nouveau
[02:39] <Sarvatt> guess i should have sudo-ed that, tons of no permission to delete errors
[02:39] <RAOF> As I understand it, it's now the responsibility of nouveau-kernel-source to build against all installed kernels when it gets installed/updated, and after that dkms will get triggered on kernel install.
[02:39] <RAOF> Yeah, you should've ;)
[02:42] <bryce> yeah that should eliminate a whole class of bugs
[02:42] <RAOF> Where the module isn't available at boot & X starts up too fast? :)
[02:42] <Sarvatt> hmm looks like it installed to 2.6.32-7 again...
[02:42] <RAOF> Also, makes sense for nouveau, 'cause it'd quite like to be in the initramfs.
[02:43] <RAOF> Sarvatt: You _may_ need to run that command again with "install" rather than "build".
[02:43] <Sarvatt> oh thanks
[02:43] <Sarvatt> there we go, rebooting again
[02:44] <Sarvatt> i'm doing it without nouveau.modeset=1 and quiet splash added just to see if it works right
[02:45] <Sarvatt> couldnt start without quiet removed before
[02:45] <Sarvatt> looks like i cant now still
[02:46] <Sarvatt> new spam in dmesg every 10 ns :D
[02:46] <Sarvatt> gdm greeter garbled
[02:48] <Sarvatt> Kernel command line: BOOT_IMAGE=//vmlinuz-2.6.32-8-generic root=UUID=7f0c72b4-6c48-4ef9-9bfd-46a724d96bc5 ro
[02:49] <Sarvatt> that worked, had to remove quiet splash still.. wish i knew why
[02:50] <Sarvatt> x is on :1 it looks like though
[02:56] <Sarvatt> works fine though, dont see any difference from the 12-04 package http://sarvatt.com/downloads/nouveau.txt
[03:05] <RAOF> You won't need nouveau.modeset=1; kms is enabled by default.
[03:06] <RAOF> Hm.  nouveau is getting loaded suspiciously late in your boot sequence... is /etc/initramfs-tools/hooks/nouveau_kms_hook executable?
[03:07] <Sarvatt> i just ran a manual update-initramfs -u to try to put it in and got a bunch of errors putting the firmware in
[03:08] <RAOF> Hm.
[03:08] <Sarvatt> http://paste.ubuntu.com/343234/
[03:08] <Sarvatt> ignore the last error, the latest initramfs-tools is making it give that for all kernels
[03:08] <RAOF> Also, it's not loading the firmware; I'm therefore surprised that it "works fine", because you've got no acceleration :)
[03:09] <Sarvatt> oh its not loading the ihex-ed firmwares in the initramfs hooks?
[03:09] <RAOF> Hm.  I thought it should be, but I don't have an nv5x class card to test on, and they've already included a nv4x voodoo generator in the drm.
[03:10] <Sarvatt> nouveau_kms_hook is executable
[03:10] <Sarvatt> the firmwares all have .ihex extentions in /lib/firmware/nouveau/ here
[03:11] <RAOF> Hm, true.  Nothing else seems to...
[03:11] <Sarvatt> I dont notice any difference without acceleration to be honest :D
[03:11] <RAOF> Well, I would, because I've got compiz ;P
[03:11] <RAOF> I might need to actually build the firmware in some way...
[03:12] <Sarvatt> i think you can use ctxfw=1 to make it load the firmware for your card?
[03:12] <Sarvatt> parm:           ctxfw:Use external firmware blob for grctx init (NV40) (int)
[03:12] <RAOF> Yeah.  I'd need to grab the firmware though, too.
[03:16] <Sarvatt> is just adding nouveau to the initrd enough? will it pick up ttm and the others automatically?
[03:18] <RAOF> Yes, it should.
[03:19] <RAOF> Indeed, it does; the hooks pick up the transitive dependencies of a kernel module.
[03:19] <RAOF> It might not pick up the firmware, though.  Let me check...
[03:33] <Sarvatt> can ya just ship the extracted firmware with it? looks like they just ihexed it so it wouldnt ship binaries that get cleaned when you make clean the kernel
[03:36] <RAOF> I don't have the extracted firmware :).  I guess I need to work to build the ihex into usable firmware; it can't be that hard.
[04:01] <Sarvatt> can ya add a make firmware_install job to it somewhere?
[04:06] <RAOF> That would be the plan, yes.
[04:39] <RAOF> Gah.  You need a whole host of stuff to make firmware_install work.
[05:55] <RAOF> Phargh.  Where did debian/tmp go?
[09:08] <tjaalton> Sarvatt: yep
[09:48] <tjaalton> tseliot: hey, have you started working on the new nvidia packages?
[09:51] <tseliot> tjaalton: yep
[09:51] <tjaalton> tseliot: was there a consensus on the renaming business?
[09:52] <tjaalton> or will you use the ones we have now until it's decided
[09:52] <tseliot> tjaalton: I think we agreed to use nvidia-current and nvidia-173 and nvidia-96
[09:53] <tjaalton> well I was dropped off because of the ddos ;)
[09:53] <tjaalton> so didn't get to say anything
[09:53] <tseliot> oh
[09:53] <tseliot> what's your take on this?
[09:54] <tseliot> pitti let bryce and I decide
[09:55] <tjaalton> I talked to bryce last night and he advised to contact you :)
[09:55] <tseliot> ok, if you have any objections to the new names just let me know
[09:56] <tjaalton> are those for the source packages?
[09:56] <tseliot> no, just for the binaries
[09:56] <tjaalton> so what's the "current" source package going to be?
[09:57] <tseliot> nvidia-graphics-driver-current?
[09:57] <tseliot> better ideas are always welcome
[09:57] <tjaalton> what about dropping the current part? does it serve a purpose?
[09:58] <tseliot> not in the source
[09:58] <tjaalton> I (again, after 2y) looked at how debian did them..
[09:58] <tjaalton> the latest is n-g-d, produces nvidia-glx, and ton of other binaries
[09:58] <tseliot> so would it be nvidia-graphics-driver, nvidia-graphics-driver-173 and nvidia-graphics-driver-96?
[09:59] <tseliot> it will generate only 3 binaries
[09:59] <tjaalton> legacy ones are n-g-d-legacy-96xx etc, produce n-glx-legacy-96xx etc
[09:59] <tseliot> -current, -current-dev, -current-modaliases
[09:59] <tjaalton> yeah it's fine to ship the binaries in one package
[10:00] <tseliot> they were a bit against "-legacy" for binaries but maybe it's ok for sources
[10:00] <tjaalton> we don't have to change the legacy ones, they are fine as they are
[10:00] <tjaalton> n-g-d-173 etc
[10:01] <tjaalton> source and binary
[10:01] <tjaalton> oh wait
[10:01] <tjaalton> n-g-173 binary
[10:01] <tjaalton> uh
[10:01] <tseliot> ;)
[10:01] <tjaalton> can't be -glx if it ships more than just the lib
[10:01] <tjaalton> (what a mess..)
[10:01] <tjaalton> :)
[10:02] <tseliot> maybe we can talk again about this when I'm back. I have to go now
[10:02] <tjaalton> sure
[10:09] <tjaalton> bryce: please use UNRELEASED if you won't upload right away. xorg-server now shows "karmic" as the release :)
=== mac_v is now known as _
=== _ is now known as _7hills
=== _7hills is now known as mac_v
[11:09] <tjaalton> tseliot: I think that calling the merged blob 'nvidia-glx' makes sense, since it's been like that forever
[11:10] <tseliot> tjaalton: but that can be confusing as it's not just glx and users will start asking where the kernel source is
[11:10] <tjaalton> and shipping the vdpau support in the same package doesn't mean much. even the free drivers will likely ship it with the rest of the driver
[11:10] <tjaalton> they don't need to know?
[11:10] <tjaalton> since it's installed already
[11:11] <tseliot> well, nvidia-glx-$VER is installed
[11:11] <tjaalton> Provides: nvidia-kernel-source
[11:11] <tseliot> yes, of course
[11:12] <tjaalton> but what other package needs it? why would someone need to find it?
[11:12] <tjaalton> so the binary will still have a version number?
[11:13] <tseliot> no other package needs it
[11:13] <tseliot> no, only legacy drivers will have a version number
[11:13] <tjaalton> ok
[11:13] <tseliot> -current will always be just -current
[11:14] <tjaalton> debian doesn't have one either (even the binary, so they don't care about upgrades breaking)
[11:14] <tjaalton> +potentially
[11:14] <tseliot> nvidia-common will deal with upgrades in our case
[11:14] <tjaalton> not with apt-get
[11:15] <tjaalton> not everyone uses update-manager
[11:15] <tseliot> I know but
[11:15] <tseliot> 1) we support dist-upgrades only through update-manager
[11:15] <tjaalton> let launchpad know that as well ;)
[11:15] <tseliot> 2) nvidia-common will complain through debconf and let users know what to install
[11:16]  * tseliot didn't choose 1)
[11:16] <tjaalton> who said that?
[11:16] <tseliot> either mvo_ or pitti
[11:16] <tjaalton> ok
[11:16] <tseliot> I *guess*
[11:16] <tjaalton> well, I don't think it's a huge issue
[11:17] <tseliot> right
[11:17] <tseliot> if users choose apt-get they will know what to do when they see 2)
[11:19] <tseliot> so, shall we use nvidia-graphics-driver, nvidia-graphics-driver-173, nvidia-graphics-driver-96 or nvidia-graphics-driver-current, nvidia-graphics-driver-173 and nvidia-graphics-driver-96?
[11:19] <tjaalton> the former, imo
[11:19] <tseliot> I have no strong opinions on this
[11:19] <tseliot> ok then
[11:19] <tjaalton> can't describe why I don't like "current" :)
[11:20] <tseliot> they use it in Mandriva and it seems to work well
[11:20] <tjaalton> it just doesn't feel right
[11:20] <tseliot> it could be "latest" but that wouldn't be entirely correct either
[11:20] <tjaalton> makes the name longer, that's for sure :)
[11:21] <tseliot> true
[11:22] <tseliot> I don't think it really matters if we use another name, as long as we have the latest driver (i.e. the one which NVIDIA consider as non-legacy) in the same source package+
[11:22] <tseliot> s/+//
[11:24] <tjaalton> debian has just n-g-d, and though it'll likely never be merged, I guess it makes sense to keep the same name here as well
[11:24] <tseliot> yes, for the source
[11:24] <tseliot> it makes sense
[11:25] <tjaalton> ok that one is clear then :)
[11:26] <tjaalton> well, I don't care about the binary that much to fight against -current, if that's already been ok'd
[11:27] <tseliot> yes
[11:27] <tseliot> ok, it sounds like we got to an agreement and/or a compromise ;)
[11:27] <tjaalton> something along those lines yeah
[11:27] <tjaalton> now get crackin' :)
[11:28] <tseliot> right
[11:28] <tjaalton> I was thinking that maybe the packaging could be in bzr or so, apart from the binaries
[11:28] <tseliot> I was about to ask you about it
[11:29] <tseliot> yes, maybe it's better if we use a bzr branch as ubuntu packages use bzr
[11:29] <tseliot> well, most of them
[11:29] <tjaalton> I don't know how the tools work with giant binaries.. for instance if I replace one with another, will the diff be a huge binary blob or what
[11:31] <tseliot> good question. I think you would get a readable diff and a binary blob using the web bzr interface. I don't remember how it works in practice
[11:32] <tseliot> maybe keeping only the packaging in bzr is a better idea
[11:32] <tjaalton> but one possibility would be to not have the binaries in bzr, but I don't know if that's possible
[11:32] <tjaalton> like, it auto-imports every upload AIUI
[11:32] <tjaalton> otherwise it would just mean copying the binaries from the source package to the tree, and debuild -S  etc
[11:34] <tseliot> example: the diff for this is 77.8 Mb :-/  http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/nvidia-graphics-drivers-180/karmic/revision/21
[11:35] <tseliot> ouch
[11:35] <tseliot> does git work any better with binaries?
[11:35] <tjaalton> ugh
[11:35] <tjaalton> I don't know
[11:41] <james_w> hi tseliot 
[11:41] <spork> Hi all.  I'd like to get Xorg 1.7 on Karmic, with nVidia drivers.  Is this possible?
[11:41] <tjaalton> spork: no
[11:41] <tjaalton> spork: meaning that there are no packages for it
[11:42] <spork> (reason being that I need 1.7 for the multi-card support that dropped in 1.5, and GTX260 support which 1.4 doesn't have)
[11:42] <spork> so it's build from source, or suffer?
[11:42] <spork> possibly those are the same thing  ;)
[11:42] <tjaalton> you mean nvidia binary driver?
[11:43] <spork> yeah
[11:43] <tseliot> hi james_w
[11:43] <spork> Well...  I want dual-head from one of the cards - last time I checked nv driver couldn't do that?
[11:43] <tseliot> james_w: tjaalton and I were wondering how bzr would work to maintain nvidia drivers in a branch
[11:44] <tjaalton> spork: no, but nvidia has twinview
[11:44] <tjaalton> and that works just fine with 1.5
[11:44] <spork> right, but that doesn't work for two cards
[11:44] <tseliot> james_w: as nvidia drivers contain the packaging scripts and some big binary blobs
[11:44] <spork> so I can't run the third screen
[11:44] <tjaalton> spork: how does 1.7 change it?
[11:45] <spork> reintroduced support for multiple cards
[11:45] <spork> libpciaccess broken it at 1.4->1.5, but apparently they fixed it recently
[11:46] <tseliot> james_w: the problem is that when we include a new upstream release we get a diff which can be as big as 71 Mb (or more) because of the binaries
[11:46] <tjaalton> spork: nvidia doesn't use that
[11:47] <spork> ...well 1.4 worked, 1.5 didn't.  Everything I've read said that libpciaccess was the reason, but I'm willing to learn different.
[11:47] <tjaalton> spork: if you mean vgaarb, it's for free drivers AIUI
[11:47]  * spork is looking for the xorg bug
[11:48]  * tseliot -> brb
[11:53] <spork> http://lists.freedesktop.org/archives/xorg/2009-April/045379.html is some discussion about it
[11:53] <spork> they mention a vga arbiter (as something that didn't exist at that point, I think)
[11:53] <spork> ah, here's the bug: https://bugs.freedesktop.org/show_bug.cgi?id=20816
[11:54] <ubottu> Freedesktop bug 20816 in Server/general "Make multi-card xorg work again" [Normal,New]
[11:54] <tjaalton> yes, but I don't think that applies to nvidia. the vga-arb touches the kernel drm level too, and nvidia doesn't use that at all
[11:54] <tjaalton> it should be possible to use a combination of xinerama+twinview
[11:55] <tjaalton> dunno
[11:55] <spork> it was, at 1.4
[11:55] <spork> although it made more sense to use xinerama across all 3
[11:55] <spork> some odd behaviour with full-screening applications otherwise
[11:56] <tjaalton> try it on lucid alpha1
[11:57] <spork> yeah, I was considering that.  I hear Lucid is a bit wobbly still?
[11:57] <spork> tempting though
[11:57] <tjaalton> that's why there are livecd's
[11:57] <tjaalton> for testing
[11:58] <spork> this 9.10 install is fresh anyway
[11:58] <spork> I may as well upgrade it and see if the explosions are pretty or not
[11:59] <tjaalton> first of all, there is no working nvidia blob yet
[11:59] <tjaalton> packaged
[11:59] <tjaalton> and since you need that, the livecd won't work either
[12:00] <spork> ah
[12:00] <spork> well, I could still test to see if both cards come up
[12:00] <spork> I'll just have dual head on different monitors  :)
[12:01] <spork> centre and right instead of centre and left
[12:01] <spork> I thought I'd seen someone running 1.7+nvidia on a Arch Linux forum
[12:01]  * spork googles again
[12:02] <spork> * nvidia 190.42 supports xorg 1.7 if you have a nvdia card gf6 or up
[12:02] <tjaalton> there's some ppa where it's packaged
[12:03] <spork> right
[12:03]  * tseliot -> lunch
[12:04] <virtuald> now that radeon kms is default, are someone working on power management?
[12:04] <tjaalton> upstram
[12:04] <tjaalton> +e
[12:05] <virtuald> 8]
[12:05] <james_w> tseliot: it should work fine
[12:05] <james_w> tseliot: it may not be terribly efficient, but shouldn't be too bad
[12:05] <virtuald> my x comes up on like every other boot
[13:03] <tseliot> james_w: ok, thanks
=== jldugger is now known as pwnguin