Sarvattoh yeah tjaalton, you have a 965 dont you? i think yours can recover from those errors that hang me if so00:00
=== ripps|sleep is now known as ripps
RAOFWhose got an nv50+ class card and would like to try nouveau?01:41
Sarvattinstalling it now02:13
Sarvattwell 300mb of other updates to grab too02:14
Sarvattshould nouveau-kernel-source recommend the ddx or anything?02:17
Sarvatthmm the kernel's not even trying to load nouveau02:26
SarvattFATAL: Module nouveau not found.02:27
RAOFSarvatt: Actually, the kernel module sholud be useful even without the DDX; it *should* provide working suspend/resume.02:29
RAOFSarvatt: Pulling from xorg-edgers into lucid?02:30
Sarvattyeah i have edgers on that laptop02:30
Sarvattgot the 1217 one02:30
RAOFWorks nicely on _this_ laptop.02:31
RAOFYou've got a nv5x class chip?02:31
Sarvattno modules in /lib/modules/2.6.32-8-generic/updates/dkms02:31
Sarvatt8400M GS02:32
RAOFOk, that's weird.02:32
RAOFYay!  Tester for firmware loading.02:32
RAOFSo, 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
Sarvattweird, looks like it built it for 2.6.32-702:34
RAOFIs that your running kernel?02:34
Sarvatt2.6.32-8 was i was sure, on -8 now though02:35
Sarvattwhats the command to build it again?02:35
Sarvattnouveau, 0.0.15+git20091217, 2.6.32-7-generic, x86_64: installed 02:36
Sarvattguess i installed -8 then installed nouveau-kernel-source before rebooting..02:36
RAOFOh, right.02:36
RAOFYes!  And dkms is no longer run on boot, and I haven't changed the postinst to build for all available kernels.02:37
RAOFdkms build -k 2.6.32-8-generic -m nouveau -v 0.0.15+git2009121702:38
Sarvattthats 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 nouveau02:38
Sarvattguess i should have sudo-ed that, tons of no permission to delete errors02:39
RAOFAs 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
RAOFYeah, you should've ;)02:39
bryceyeah that should eliminate a whole class of bugs02:42
RAOFWhere the module isn't available at boot & X starts up too fast? :)02:42
Sarvatthmm looks like it installed to 2.6.32-7 again...02:42
RAOFAlso, makes sense for nouveau, 'cause it'd quite like to be in the initramfs.02:42
RAOFSarvatt: You _may_ need to run that command again with "install" rather than "build".02:43
Sarvattoh thanks02:43
Sarvattthere we go, rebooting again02:43
Sarvatti'm doing it without nouveau.modeset=1 and quiet splash added just to see if it works right02:44
Sarvattcouldnt start without quiet removed before02:45
Sarvattlooks like i cant now still02:45
Sarvattnew spam in dmesg every 10 ns :D02:46
Sarvattgdm greeter garbled02:46
SarvattKernel command line: BOOT_IMAGE=//vmlinuz-2.6.32-8-generic root=UUID=7f0c72b4-6c48-4ef9-9bfd-46a724d96bc5 ro02:48
Sarvattthat worked, had to remove quiet splash still.. wish i knew why02:49
Sarvattx is on :1 it looks like though02:50
Sarvattworks fine though, dont see any difference from the 12-04 package http://sarvatt.com/downloads/nouveau.txt02:56
RAOFYou won't need nouveau.modeset=1; kms is enabled by default.03:05
RAOFHm.  nouveau is getting loaded suspiciously late in your boot sequence... is /etc/initramfs-tools/hooks/nouveau_kms_hook executable?03:06
Sarvatti just ran a manual update-initramfs -u to try to put it in and got a bunch of errors putting the firmware in03:07
Sarvattignore the last error, the latest initramfs-tools is making it give that for all kernels03:08
RAOFAlso, it's not loading the firmware; I'm therefore surprised that it "works fine", because you've got no acceleration :)03:08
Sarvattoh its not loading the ihex-ed firmwares in the initramfs hooks?03:09
RAOFHm.  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
Sarvattnouveau_kms_hook is executable03:10
Sarvattthe firmwares all have .ihex extentions in /lib/firmware/nouveau/ here03:10
RAOFHm, true.  Nothing else seems to...03:11
SarvattI dont notice any difference without acceleration to be honest :D03:11
RAOFWell, I would, because I've got compiz ;P03:11
RAOFI might need to actually build the firmware in some way...03:11
Sarvatti think you can use ctxfw=1 to make it load the firmware for your card?03:12
Sarvattparm:           ctxfw:Use external firmware blob for grctx init (NV40) (int)03:12
RAOFYeah.  I'd need to grab the firmware though, too.03:12
Sarvattis just adding nouveau to the initrd enough? will it pick up ttm and the others automatically?03:16
RAOFYes, it should.03:18
RAOFIndeed, it does; the hooks pick up the transitive dependencies of a kernel module.03:19
RAOFIt might not pick up the firmware, though.  Let me check...03:19
Sarvattcan 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 kernel03:33
RAOFI 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
Sarvattcan ya add a make firmware_install job to it somewhere?04:01
RAOFThat would be the plan, yes.04:06
RAOFGah.  You need a whole host of stuff to make firmware_install work.04:39
RAOFPhargh.  Where did debian/tmp go?05:55
tjaaltonSarvatt: yep09:08
tjaaltontseliot: hey, have you started working on the new nvidia packages?09:48
tseliottjaalton: yep09:51
tjaaltontseliot: was there a consensus on the renaming business?09:51
tjaaltonor will you use the ones we have now until it's decided09:52
tseliottjaalton: I think we agreed to use nvidia-current and nvidia-173 and nvidia-9609:52
tjaaltonwell I was dropped off because of the ddos ;)09:53
tjaaltonso didn't get to say anything09:53
tseliotwhat's your take on this?09:53
tseliotpitti let bryce and I decide09:54
tjaaltonI talked to bryce last night and he advised to contact you :)09:55
tseliotok, if you have any objections to the new names just let me know09:55
tjaaltonare those for the source packages?09:56
tseliotno, just for the binaries09:56
tjaaltonso what's the "current" source package going to be?09:56
tseliotbetter ideas are always welcome09:57
tjaaltonwhat about dropping the current part? does it serve a purpose?09:57
tseliotnot in the source09:58
tjaaltonI (again, after 2y) looked at how debian did them..09:58
tjaaltonthe latest is n-g-d, produces nvidia-glx, and ton of other binaries09:58
tseliotso would it be nvidia-graphics-driver, nvidia-graphics-driver-173 and nvidia-graphics-driver-96?09:58
tseliotit will generate only 3 binaries09:59
tjaaltonlegacy ones are n-g-d-legacy-96xx etc, produce n-glx-legacy-96xx etc09:59
tseliot-current, -current-dev, -current-modaliases09:59
tjaaltonyeah it's fine to ship the binaries in one package09:59
tseliotthey were a bit against "-legacy" for binaries but maybe it's ok for sources10:00
tjaaltonwe don't have to change the legacy ones, they are fine as they are10:00
tjaaltonn-g-d-173 etc10:00
tjaaltonsource and binary10:01
tjaaltonoh wait10:01
tjaaltonn-g-173 binary10:01
tjaaltoncan't be -glx if it ships more than just the lib10:01
tjaalton(what a mess..)10:01
tseliotmaybe we can talk again about this when I'm back. I have to go now10:02
tjaaltonbryce: 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
tjaaltontseliot: I think that calling the merged blob 'nvidia-glx' makes sense, since it's been like that forever11:09
tseliottjaalton: but that can be confusing as it's not just glx and users will start asking where the kernel source is11:10
tjaaltonand 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 driver11:10
tjaaltonthey don't need to know?11:10
tjaaltonsince it's installed already11:10
tseliotwell, nvidia-glx-$VER is installed11:11
tjaaltonProvides: nvidia-kernel-source11:11
tseliotyes, of course11:11
tjaaltonbut what other package needs it? why would someone need to find it?11:12
tjaaltonso the binary will still have a version number?11:12
tseliotno other package needs it11:13
tseliotno, only legacy drivers will have a version number11:13
tseliot-current will always be just -current11:13
tjaaltondebian doesn't have one either (even the binary, so they don't care about upgrades breaking)11:14
tseliotnvidia-common will deal with upgrades in our case11:14
tjaaltonnot with apt-get11:14
tjaaltonnot everyone uses update-manager11:15
tseliotI know but11:15
tseliot1) we support dist-upgrades only through update-manager11:15
tjaaltonlet launchpad know that as well ;)11:15
tseliot2) nvidia-common will complain through debconf and let users know what to install11:15
* tseliot didn't choose 1)11:16
tjaaltonwho said that?11:16
tselioteither mvo_ or pitti11:16
tseliotI *guess*11:16
tjaaltonwell, I don't think it's a huge issue11:16
tseliotif users choose apt-get they will know what to do when they see 2)11:17
tseliotso, 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
tjaaltonthe former, imo11:19
tseliotI have no strong opinions on this11:19
tseliotok then11:19
tjaaltoncan't describe why I don't like "current" :)11:19
tseliotthey use it in Mandriva and it seems to work well11:20
tjaaltonit just doesn't feel right11:20
tseliotit could be "latest" but that wouldn't be entirely correct either11:20
tjaaltonmakes the name longer, that's for sure :)11:20
tseliotI 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
tjaaltondebian 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 well11:24
tseliotyes, for the source11:24
tseliotit makes sense11:24
tjaaltonok that one is clear then :)11:25
tjaaltonwell, I don't care about the binary that much to fight against -current, if that's already been ok'd11:26
tseliotok, it sounds like we got to an agreement and/or a compromise ;)11:27
tjaaltonsomething along those lines yeah11:27
tjaaltonnow get crackin' :)11:27
tjaaltonI was thinking that maybe the packaging could be in bzr or so, apart from the binaries11:28
tseliotI was about to ask you about it11:28
tseliotyes, maybe it's better if we use a bzr branch as ubuntu packages use bzr11:29
tseliotwell, most of them11:29
tjaaltonI 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 what11:29
tseliotgood 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 practice11:31
tseliotmaybe keeping only the packaging in bzr is a better idea11:32
tjaaltonbut one possibility would be to not have the binaries in bzr, but I don't know if that's possible11:32
tjaaltonlike, it auto-imports every upload AIUI11:32
tjaaltonotherwise it would just mean copying the binaries from the source package to the tree, and debuild -S  etc11:32
tseliotexample: the diff for this is 77.8 Mb :-/  http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/karmic/nvidia-graphics-drivers-180/karmic/revision/2111:34
tseliotdoes git work any better with binaries?11:35
tjaaltonI don't know11:35
james_whi tseliot 11:41
sporkHi all.  I'd like to get Xorg 1.7 on Karmic, with nVidia drivers.  Is this possible?11:41
tjaaltonspork: no11:41
tjaaltonspork: meaning that there are no packages for it11: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
sporkso it's build from source, or suffer?11:42
sporkpossibly those are the same thing  ;)11:42
tjaaltonyou mean nvidia binary driver?11:42
tseliothi james_w11:43
sporkWell...  I want dual-head from one of the cards - last time I checked nv driver couldn't do that?11:43
tseliotjames_w: tjaalton and I were wondering how bzr would work to maintain nvidia drivers in a branch11:43
tjaaltonspork: no, but nvidia has twinview11:44
tjaaltonand that works just fine with 1.511:44
sporkright, but that doesn't work for two cards11:44
tseliotjames_w: as nvidia drivers contain the packaging scripts and some big binary blobs11:44
sporkso I can't run the third screen11:44
tjaaltonspork: how does 1.7 change it?11:44
sporkreintroduced support for multiple cards11:45
sporklibpciaccess broken it at 1.4->1.5, but apparently they fixed it recently11:45
tseliotjames_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 binaries11:46
tjaaltonspork: nvidia doesn't use that11: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
tjaaltonspork: if you mean vgaarb, it's for free drivers AIUI11:47
* spork is looking for the xorg bug11:47
* tseliot -> brb11:48
sporkhttp://lists.freedesktop.org/archives/xorg/2009-April/045379.html is some discussion about it11:53
sporkthey mention a vga arbiter (as something that didn't exist at that point, I think)11:53
sporkah, here's the bug: https://bugs.freedesktop.org/show_bug.cgi?id=2081611:53
ubottuFreedesktop bug 20816 in Server/general "Make multi-card xorg work again" [Normal,New]11:54
tjaaltonyes, 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 all11:54
tjaaltonit should be possible to use a combination of xinerama+twinview11:54
sporkit was, at 1.411:55
sporkalthough it made more sense to use xinerama across all 311:55
sporksome odd behaviour with full-screening applications otherwise11:55
tjaaltontry it on lucid alpha111:56
sporkyeah, I was considering that.  I hear Lucid is a bit wobbly still?11:57
sporktempting though11:57
tjaaltonthat's why there are livecd's11:57
tjaaltonfor testing11:57
sporkthis 9.10 install is fresh anyway11:58
sporkI may as well upgrade it and see if the explosions are pretty or not11:58
tjaaltonfirst of all, there is no working nvidia blob yet11:59
tjaaltonand since you need that, the livecd won't work either11:59
sporkwell, I could still test to see if both cards come up12:00
sporkI'll just have dual head on different monitors  :)12:00
sporkcentre and right instead of centre and left12:01
sporkI thought I'd seen someone running 1.7+nvidia on a Arch Linux forum12:01
* spork googles again12:01
spork* nvidia 190.42 supports xorg 1.7 if you have a nvdia card gf6 or up12:02
tjaaltonthere's some ppa where it's packaged12:02
* tseliot -> lunch12:03
virtualdnow that radeon kms is default, are someone working on power management?12:04
james_wtseliot: it should work fine12:05
james_wtseliot: it may not be terribly efficient, but shouldn't be too bad12:05
virtualdmy x comes up on like every other boot12:05
tseliotjames_w: ok, thanks13:03
=== jldugger is now known as pwnguin

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!