[00:00] <Sarvatt> ripps: just no change rebuild libvdpau on your PPA for now since it'll build fine there :)
[00:13] <ion> sarvatt: :-)
[00:15] <Sarvatt> actually it may just be fail in the detection scripts, let me take a look
[00:15] <Sarvatt> X.org 7.1.1.901, required X.org 7.5.1.0. -- looks like its just failing
[00:19] <ion> sarvatt: Oh, btw, i made http://heh.fi/tmp/fglrx-installer-abiver.patch earlier, but didn’t get around to posting it anywhere since fglrx failed to install on my system at the time due to me not having patches for kernel 2.6.35. I copied the rules to provide xserver-xorg-video-$ABIVER from the nvidia driver packaging verbatim.
[00:21] <Sarvatt> the one in x-updates failed on 2.6.35? it works fine here!
[00:21] <ion> No, before i found a package with the patches in the PPA. :-)
[00:22] <Sarvatt> ion: personally i dont think they should be providing an abi at all since they arent tied to an abi
[00:22] <Sarvatt> nvidia-current works with multiple video abi's and the packaging only provides one, and it took a week and a half for it to get no change rebuilt against the new abi even though it worked :(
[00:23] <ion> Ah, ok. Dunno what is the right way to go, i just came up with that when fglrx stopped working after an xorg update in maverick. It would have been nice if that version of the fglrx package had blocked that xorg update.
[00:25] <Sarvatt> yeah thats true, it probably would be more helpful on ati :)
[00:25] <Sarvatt> since they take 6 months to update things
[00:25] <Sarvatt> nvidia supported xserver 1.8 back in november or december
[00:26] <ion> And the free drivers supported it... pretty much immediately. :-P
[00:31] <Sarvatt> trying to figure out where it gets that 7.5.1.0 string from
[00:32] <Sarvatt> ion: do you have an xorg log from a failed boot by any chance?
[00:32] <Sarvatt> ah its in atiddxSetup from what you pasted, nevermind
[00:34] <Sarvatt> i've got an fglrx machine now so i can test hex editing the blob to work around it :)
[00:35] <Sarvatt> doesn't look like its a registry option that can be adjusted but i need to go over some more strings to be sure
[00:36] <ion> Hehe
[00:38] <Sarvatt> ya remember if that atiddxSetup error happened after loading a specific module?
[00:40] <ion> I’ll install fglrx and save the log this time, a moment.
[00:42] <ion> I’ll have to take a look at making nvidia_supported work again with the new nvidia release at some point. (I contributed the original _supported scripts.)
[00:46] <Sarvatt> oh really? thank you for doing that, i couldn't work it out
[00:48] <Sarvatt> my fglrx machine is finally done compiling chromium so i can do it
[00:50] <ion> Ok, the new nvidia driver no longer has the duplicate PCI ID list, so that heuristic can’t be used anymore. I’ll come up with something new.
[00:51] <ion> Alright
[00:55] <Sarvatt> ah looks like fglrx-2.6.33.patch isnt needed anymore
[00:56] <Sarvatt> gotta upload a new version without it
[01:13] <Sarvatt> darn, that message doesn't even show up for me - http://pastebin.com/At3G7UUY
[02:14] <Sarvatt> hmm http://sarvatt.com/downloads/xserver.gdb.txt
[02:38] <ripps> Yo, I'm back.
[02:40] <ripps> Sarvatt: Since BlackZ not here, I'll tell you. I'd file a bug, but since I don't have amd64, it feel like it's inappropriate. Also, I can't file bugs against ia32-libs because since the package isn't availble for my computer, apport tells me the package doesn't exist.
[03:32] <Sarvatt> ripps: just upload libvdpau to your PPA to fix it..
[03:32] <Sarvatt> make it 0.4-5+ripps or something
[03:33] <ripps> Sarvatt: yeah, that sounds like a good plan. I was just hoping that this could be fixed for everybody, not just me.
[03:34] <Sarvatt> you're telling me you want me to file the bug because you need ubuntu-bug or something?
[03:34] <Sarvatt> i can't upload it :)
[03:36] <ripps> Sarvatt: well, I actually started this in ubuntu-motu. But it got moved over here somehow :P
[03:37] <ripps> I can't file bugs against ia32-libs, because apport will only let me file bugs against my i386 packages. How do you file bugs manually these days?
[03:38] <ripps> Did you guys find a fix? you mentioned something about VDPAU_MODULEDIR
[03:39] <Sarvatt> superm1: any idea what to do about libvdpau-dev needing ia32-libs now and not being in main? as far as I can tell just dropping the lib32vdpau package is fine for now since we never shipped a seperate 32 bit version
[03:39] <Sarvatt> ripps: no
[04:01] <superm1> Sarvatt, agree
[04:02] <superm1> i wish debian would do what we did with putting all the nvidia stuff in a single package
[04:02] <superm1> seems so much more sensible this way
[04:03] <Sarvatt> ion: it looks like fglrx 10.6 in x-updates works with xserver 1.8, I was wrong!
[04:03] <bjsnider> since when does libvdpau-dev require ia32-libs?
[04:03] <Sarvatt> problem is, jockey's xorg.conf doesn't work
[04:04] <Sarvatt> ion: http://pastebin.com/2Ti6wMNe
[04:15] <Sarvatt> BusID "PCI:1:0:0" is required in xorg.conf in fglrx 10.6, ati just mentioned it
[04:15] <Sarvatt> or whatever the busid is for your system, fun
[04:41] <ion> Alright. Yay for nerfing autoconfiguration. :-P
[04:45] <ion> I didn’t manage to come up with a future-proof way to scrape PCI IDs from the nvidia driver yet. I tried to find a consistent code path from a non-obfuscated symbol to the list, but failed so far. Perhaps i’ll just do another heuristic that may work for a few years and then fail with some future release, requiring yet another new heuristic. :-P
[04:47] <Sarvatt> they aren't going to add new ones to the old releases, can't we just include all pci ids included in the new ones or does it contain more than it supports?
[04:47] <ion> New releases add support for new cards with new PCI IDs.
[04:48] <Sarvatt> yeah, is there no way to dump every pci id in that blob since it only has the ones it works with?
[04:48] <ion> That’s exactly what nvidia_supported does. :-)
[04:49] <ion> The trick is scraping the data from the blob in a way that doesn’ṭ require tinkering for every release.
[04:49] <ion> The previous trick worked a long time, but now they changed stuff and it doesn’t work anymore.
[04:49] <Sarvatt> oh, i thought it was removing some from that list for some reason
[04:50] <ion> If the data was behind a consistent symbol in the object file, everything would be fine. But it’s behind an obfuscated symbol which changes names on every release.
[04:52] <Sarvatt> why dont we just pull it from html/supportedchips.html?
[04:54] <ion> At the point i originally wrote nvidia_supported, the HTML list wasn’t maintained properly. In every release, it had major differences to the actual data. I should check if that’s fixed by now, actually.
[04:55] <Sarvatt> ahh gotcha, i've been checking it since around 185.35.15 and its been updated every time they add new cards at least
[04:57] <ion> They were updating it, yes, but it almost seemed as if a human received a list of added and removed PCI IDs and manually updated the HTML for every release, and errors kept creeping up every time :-P. One would think they could just autogenerate the HTML from the source code, but that wasn’t a case at least back then.
[04:58] <ion> the case
[05:01] <Sarvatt> ahh gotcha, checking how other distros do it now
[05:06] <ion> Anyhoo, it’s easy enough to modify nvidia_supported to detect the list from the current release and from a number of foture releases as long as they don’t change the format again. I don’t expect that to happen for a while. I was trying to come up with an almost completely future-proof solution, but that might not happen. And yeah, i’ll compare the list from the blob from the newest release to the HTML, perhaps they’ve fixed it.
[05:15] <Sarvatt> hmm, went to look at nvidia-installer to see how it checks since its open source, and just saw there was a new nvidia release
[05:35] <Sarvatt> darn, the nvidia 256.35 x86_64 ftp directory has the x86 one in it so i cant package it up yet
[05:45] <Sarvatt> found it, check_for_nvidia_graphics_devices() - http://cgit.freedesktop.org/~aplattner/nvidia-installer/tree/misc.c?id=19a9146a421689b409588c9505364024378e1dd1
[05:45] <Sarvatt> gotta run though, will see what it does when i get back :)
[06:01] <ion> Ok, it only has a list of legacy devices, and anything nVidia && VGA that isn’t in it is deemed supported.
[06:08] <Sarvatt> can we just use 0x04** - 0x0F** or do we have to explicitly define each one?
[06:09] <Sarvatt> ah nope their other devices are in that namespace too
[06:12] <ion> In any case, any list that is not directly based on the actual code of the newest release available for each series has a chance of being inaccurate, and nVidia’s track record hasn’t been good with such lists.
[06:13] <ion> Using such a list would probably work for most users, but then there would be hard-to-verify bug reports from users that just happen to have a card that the list missed.
[06:19] <superm1> Sarvatt, ion what about taking the approach of what NV installer does and just say everything is supported, and then maintain a blacklist of (earlier) stuff that isn't?  
[06:19] <superm1> they do announce when they drop support generally, don't they?
[06:20] <Sarvatt> does jockey understand pci device namespaces?
[06:20] <Sarvatt> it uses libpciaccess?
[06:20] <Sarvatt> i mean you need to tell it to restrict it to 10de vendor id's and only look at video devices
[06:23] <Sarvatt> or is that info in the modalias already? i dont know what everything in pci:v00001002d00009715sv*sd*bc*sc*i* means
[06:25] <Sarvatt> how would you tell jockey to use everything is what I'm asking basically
[06:27] <ion> sarvatt: Here’s the diff from blob to HTML for 256.29, btw: http://gist.github.com/444604#file_list.diff
[06:28] <ion> From HTML to blob, i mean.
[06:28] <ion> The blacklist of earlier stuff would still need to be parsed the same way.
[06:29] <Sarvatt> blob is reporting some false positives then
[06:29] <ion> I’d trust the code maintained by coders more than the HTML maintained by documenters. :-P
[06:30] <Sarvatt> 0cxx is the highest pci id they have for the newest generation gpu's though
[06:30] <Sarvatt> maybe those other devices are agp-pcie bridge chips, lessee
[06:31] <Sarvatt> and that would make sense because the actual pci id of the card is hidden behind the bridge chip and not listed on that list i bet
[06:31] <Sarvatt> same problem i had with extracting pci id's on nv
[06:33] <superm1> Sarvatt, well i dont think jockey can right now; that would have to be an additional patch to it
[06:34] <Sarvatt> yep the 02xx ranges in the blob extracted one are indeed bridge chip pci ids that we'd need to add
[06:34] <Sarvatt> html is definitely out :)
[06:35] <Sarvatt> 08xx ranges are IGP's
[06:38] <ion> I wonder if nvidia would put the table (it’s just data: the PCI IDs and some flag bits probably designating each chip’s features) behind a non-obfuscated symbol if we asked nicely? :-)
[08:22] <Sarvatt> would it be wrong to hack up a postinst to run aticonfig --initial after install for fglrx? ati is insisting its required and something tells me they're not going to fix what they broke making it really be required now
[08:58] <Sarvatt> heh all of those id's I thought were wrong in your list were all removed in 256.35
[08:59] <Sarvatt> probably prerelease cards they meant to keep internal
[08:59] <Sarvatt> the 0Dxx-0Exx ones
[09:00] <ion> Ok
[09:01] <Sarvatt> this still works though - objdump --section=.rodata --full-contents --start-address=0x3940 --stop-address="$((0x3940+0x2540))" NVIDIA-Linux-x86-256.35/kernel/nv-kernel.o | sed -nr 's/^ [0-9a-f]+ ([0-9a-f]{2})([0-9a-f]{2})0000.*/\2\1/p' | sort | uniq | grep -vx 0000
[09:01] <ion> Probably by accident, and you may have a slightly incorrect range.
[09:02] <ion> I’ll get some sleep soon, but after that i’ll try to get around to making the necessary changes to nvidia_supported.
[09:03] <Sarvatt> there's only a 3k difference in all files combined in .35, pretty much the same thing as .29
[09:03] <Sarvatt> night!
[09:03] <ion> I’ll finish this episode of B5 first, though. :-)
[09:07] <ion> objdump --section=.rodata --syms .../nv-kernel.o | less, and find the one with length near 0x2540 starting near 0x3940, and pass those numbers to the --full-contents snippet to get the correct list. But i’m going to script a bit of heuristics to get the right symbol deterministically.
[09:10] <ion> To find the symbol starting at 0x3940 in the first place (for 256.29), i just ran objdump --section=.rodata --full-contents .../nv-kernel.o | less and searched for 4200 (a random PCI ID i expected to find, 0x0042 in little-endian order) in an area that looked like a nice list of IDs, picked the offset of the beginning of the list and looked up the matching symbol from --syms.
[09:18] <ion> sarvatt: nvidia_supported originally accepted multiple versions of nv-kernel.o as parameters and didn’t add PCI IDs to older versions that were supported by a newer version. Is that functionality still needed? The script could be simplified by dropping it, since it doesn’t seem to be used.
[09:22] <Sarvatt> i'd drop it personally, it's useful to be able to use the old drivers on newer cards where support overlaps to test stuff
[09:22] <ion> Alright
[17:51] <Sarvatt> looks like i'm disappearing for awhile..  it's been fun you guys
[18:05] <johanbr> Sarvatt, oh! thank you for your all your work
[19:05] <Duke`> disappearing for awhile !!?
[19:31] <Sarvatt> yeah bad timing between cutting back on work thinking i was getting another job and having to find a new apartment at the last minute :(
=== vish is now known as MrAcosta
=== MrAcosta is now known as vish
[23:39] <ion> sarvatt: http://gist.github.com/raw/445368/ab14590fc18aedbf5f10b3b74feddb853f7fbfbc/nvidia_supported
[23:39] <ion> sarvatt: That should work for all versions of the driver.
[23:45] <ion> sarvatt: Changed it a bit: http://gist.github.com/raw/445368/6b54c1c04836d3d9d9061cdf0b25c60b8c4c0e38/nvidia_supported