| Sarvatt | oh yeah tjaalton, you have a 965 dont you? i think yours can recover from those errors that hang me if so | 00:00 |
|---|---|---|
| === ripps|sleep is now known as ripps | ||
| RAOF | Whose got an nv50+ class card and would like to try nouveau? | 01:41 |
| Sarvatt | installing it now | 02:13 |
| Sarvatt | well 300mb of other updates to grab too | 02:14 |
| Sarvatt | should nouveau-kernel-source recommend the ddx or anything? | 02:17 |
| Sarvatt | hmm the kernel's not even trying to load nouveau | 02:26 |
| Sarvatt | FATAL: Module nouveau not found. | 02:27 |
| RAOF | Sarvatt: Actually, the kernel module sholud be useful even without the DDX; it *should* provide working suspend/resume. | 02:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| Sarvatt | weird, looks like it built it for 2.6.32-7 | 02:34 |
| RAOF | Is that your running kernel? | 02:34 |
| Sarvatt | 2.6.32-8 was i was sure, on -8 now though | 02:35 |
| Sarvatt | whats the command to build it again? | 02:35 |
| 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:36 |
| RAOF | Yes! And dkms is no longer run on boot, and I haven't changed the postinst to build for all available kernels. | 02:37 |
| 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:38 |
| 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:39 |
| 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:42 |
| 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:43 |
| Sarvatt | i'm doing it without nouveau.modeset=1 and quiet splash added just to see if it works right | 02:44 |
| Sarvatt | couldnt start without quiet removed before | 02:45 |
| Sarvatt | looks like i cant now still | 02:45 |
| Sarvatt | new spam in dmesg every 10 ns :D | 02:46 |
| Sarvatt | gdm greeter garbled | 02:46 |
| Sarvatt | Kernel command line: BOOT_IMAGE=//vmlinuz-2.6.32-8-generic root=UUID=7f0c72b4-6c48-4ef9-9bfd-46a724d96bc5 ro | 02:48 |
| Sarvatt | that worked, had to remove quiet splash still.. wish i knew why | 02:49 |
| Sarvatt | x is on :1 it looks like though | 02:50 |
| Sarvatt | works fine though, dont see any difference from the 12-04 package http://sarvatt.com/downloads/nouveau.txt | 02:56 |
| RAOF | You won't need nouveau.modeset=1; kms is enabled by default. | 03:05 |
| RAOF | Hm. nouveau is getting loaded suspiciously late in your boot sequence... is /etc/initramfs-tools/hooks/nouveau_kms_hook executable? | 03:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| Sarvatt | nouveau_kms_hook is executable | 03:10 |
| Sarvatt | the firmwares all have .ihex extentions in /lib/firmware/nouveau/ here | 03:10 |
| 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:11 |
| 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:12 |
| Sarvatt | is just adding nouveau to the initrd enough? will it pick up ttm and the others automatically? | 03:16 |
| RAOF | Yes, it should. | 03:18 |
| 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:19 |
| 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:33 |
| 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. | 03:36 |
| Sarvatt | can ya add a make firmware_install job to it somewhere? | 04:01 |
| RAOF | That would be the plan, yes. | 04:06 |
| RAOF | Gah. You need a whole host of stuff to make firmware_install work. | 04:39 |
| RAOF | Phargh. Where did debian/tmp go? | 05:55 |
| tjaalton | Sarvatt: yep | 09:08 |
| tjaalton | tseliot: hey, have you started working on the new nvidia packages? | 09:48 |
| tseliot | tjaalton: yep | 09:51 |
| tjaalton | tseliot: was there a consensus on the renaming business? | 09:51 |
| 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:52 |
| 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:53 |
| tseliot | pitti let bryce and I decide | 09:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 09:59 |
| 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:00 |
| 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:01 |
| tseliot | maybe we can talk again about this when I'm back. I have to go now | 10:02 |
| tjaalton | sure | 10:02 |
| tjaalton | bryce: please use UNRELEASED if you won't upload right away. xorg-server now shows "karmic" as the release :) | 10:09 |
| === mac_v is now known as _ | ||
| === _ is now known as _7hills | ||
| === _7hills is now known as mac_v | ||
| tjaalton | tseliot: I think that calling the merged blob 'nvidia-glx' makes sense, since it's been like that forever | 11:09 |
| 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:10 |
| tseliot | well, nvidia-glx-$VER is installed | 11:11 |
| tjaalton | Provides: nvidia-kernel-source | 11:11 |
| tseliot | yes, of course | 11:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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:15 |
| * 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:16 |
| tseliot | right | 11:17 |
| tseliot | if users choose apt-get they will know what to do when they see 2) | 11:17 |
| 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:19 |
| 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:20 |
| tseliot | true | 11:21 |
| 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:22 |
| 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:24 |
| tjaalton | ok that one is clear then :) | 11:25 |
| tjaalton | well, I don't care about the binary that much to fight against -current, if that's already been ok'd | 11:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:31 |
| 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:32 |
| 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:34 |
| tseliot | ouch | 11:35 |
| tseliot | does git work any better with binaries? | 11:35 |
| tjaalton | ugh | 11:35 |
| tjaalton | I don't know | 11:35 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| spork | reintroduced support for multiple cards | 11:45 |
| spork | libpciaccess broken it at 1.4->1.5, but apparently they fixed it recently | 11:45 |
| 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:46 |
| 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:47 | |
| * tseliot -> brb | 11:48 | |
| 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:53 |
| 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:54 |
| 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:55 |
| tjaalton | try it on lucid alpha1 | 11:56 |
| 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:57 |
| 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:58 |
| 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 | 11:59 |
| 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:00 |
| 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:01 | |
| 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:02 |
| spork | right | 12:03 |
| * tseliot -> lunch | 12:03 | |
| virtuald | now that radeon kms is default, are someone working on power management? | 12:04 |
| tjaalton | upstram | 12:04 |
| tjaalton | +e | 12:04 |
| 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 | 12:05 |
| tseliot | james_w: ok, thanks | 13:03 |
| === jldugger is now known as pwnguin | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!