[10:24] jcristau, tjaalton: I just got a response from intel that they're no longer going to support 81x any longer [10:24] http://bugs.freedesktop.org/show_bug.cgi?id=16729 [10:24] Freedesktop bug 16729 in Driver/intel "[815]3D apps cause horizontal line corruption and freezes" [Major,New] [10:42] bryce: what is the file that does the hardware detection when no driver is specified in the Device section of the xorg.conf? [10:45]  bryce: if no driver is specified I should detect which driver is loaded for the xorg-options editor [10:46] you'll need to parse that from the Xorg.0.log [10:46] I don't know of any reliable way to determine that otherwise [10:47] hm, or maybe you could look up the pci id in /usr/share/xserver-xorg/pci/ [10:57] bryce_: ok, thanks I'll look up the pci id then [11:16] bryce_: bah, thypical [11:16] -h [11:21] heya tjaalton [11:32] bryce_: hardware detection works well now ;) [11:33] tseliot: nice [11:33] looking in /usr/share/xserver-xorg/pci/ is probably not future proof [11:34] tseliot: btw, I added a brief blurb about the status of -nvidia to https://wiki.ubuntu.com/X/Drivers . When you get a chance it would be nice if you could flesh it out a bit more (not too detailed, but a paragraph or two would be sufficient, and links to more info would be great) [11:34] bryce_: ok, I'll do it [11:35] jcristau: what do you suggest then? [11:35] i don't know why you need that info for [11:36] also, what's with the BOMs [11:37] jcristau: I'm writing xorg-options-editor and if no device section is available (or if the device section is available but the driver is not specified) I have to rely on xorg's autodetection [11:37] right [11:38] BOMs??? [11:38] and why isn't it future-proof? [11:39] yes, U+FEFF. there's one at the beginning of every one of your lines. [11:39] or, almost every one [11:39] it's not future proof because it'll probably go away at some point [11:40] jcristau: U+FEFF??? I'm a bit confused by acronyms [11:41] it's an unicode codepoint [11:41] so whatever you use for irc is broken and puts that everywhere [11:42] I can't notice the problem here, using pidgin on Hardy [11:42] tjaalton reported a similar problem though [12:33] bryce_: I have updated the wiki. I might do something more later [12:44] tseliot: excellent thanks [13:33] tseliot: http://www.phoronix.com/scan.php?page=article&item=xorg_driver_persistent&num=1 [14:04] bryce_: yes, I had also read the discussion in the X mailing list. When (or "if") they come to an agreement I can modify xorg-options-editor accordingly [14:05] err. maybe we haven't read the same discussion then. what more agreement do you need? [14:07] "To make it persistent, Dan Nicholson had chimed in asking whether GConf or HAL fdi should be used for storing these device property values." [14:08] and the answer was hal for system-wide defaults, gconf for user-specific, iirc? [14:09] tseliot: great, sounds good. Since it sounds like an xserver 1.6 thing, I guess we can look into that for Intrepid+1 [14:12] bryce_: ok, I'll think about it when it's (almost) ready then [18:35] his Alberto Milone arround? [18:37] his = is lol [19:58] tseliot, other than the fact that "debian has it", is there a reason that we have an init script for /etc/init.d/nvidia-kernel? [19:58] i'm very surprised that something like this wouldn't be handled directly by the kernel module when loaded [19:59] yeah actually it looks like it is done by the kernel module. try stopping X, then "rm /dev/nvidia*" and then sudo X [19:59] you'll see that those modules are created for you [19:59] or devnodes i should say [20:04] well i filed a bug for now, bug 249565 [20:04] Launchpad bug 249565 in nvidia-graphics-drivers-96 "/etc/init.d/nvidia-kernel appears to be unnecessary" [Undecided,New] https://launchpad.net/bugs/249565 [20:30] mario_limonciell: thanks, I'll have a look at it later [20:30] tseliot, i filed another bug about the init script for nvidia-glx too [20:30] link? [20:30] tseliot, and it's existence makes me uneasy (in addition to the bug) since it just goes mucking around /usr/ like that [20:30] but that's not what i filed the bug about [20:31] sec [20:31] https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-173/+bug/249566 [20:31] Launchpad bug 249566 in nvidia-graphics-drivers-96 "/etc/init.d/nvidia-glx doesn't use LSB functions" [Undecided,New] [20:32] the reason i'm uneasy about that second init script existing, what if someone mounts /usr over NFS read only? You can't assume that you are able to go and change things in there [20:35] mario_limonciell: whatever it is (my connection seems to have some problem now) I will fix it. Don't worry ;) [20:42] mario_limonciell: what version and revision of the driver are you using? [20:42] I removed /etc/init.d/nvidia-glx a few releases ago [20:43] tseliot, then it must have come from dist-upgrading then [20:43] let me purge all versions and do a fresher install [20:43] mario_limonciell: ok [20:44] tseliot, it wasn't around in hardy right? so people who do hardy_>intrepid jump won't end up with it [20:44] i probably just have it from an earlier use of your packages updated to a newer version [20:46] tseliot, ah yeah neither of those appear to be present in the final ones :) [20:47] you don't need /etc/default/nvidia-glx-### though anymore then either [20:47] which is still present after i purged and reinstalled [20:47] /etc/default/nvidia-glx-### ??? [20:48] it's not in my packages [20:48] i have an /etc/default/nvidia-glx-177 somehow? [20:48] i purged all nvidia-* and reinstalled and saw it there [20:48] i'll purge once more to ensure though [20:49] remove it manually [20:49] that was from TLS [20:49] which I removed [20:50] no it definitely came in from nvidia-glx-177 [20:50] when i installed that [20:50] it's in it's package listing (dpkg -L nvidia-glx-177) [20:51] which revision? [20:51] ubuntu5? [20:53] ubuntu6 [20:58] mario_limonciell: do a "dpkg --contents name_of_the_package" please [20:58] don't rely too much on dpkg -L [21:00] http://paste.ubuntu.com/28113/ [21:00] yeah it's in there [21:02] mario_limonciell: 173 is not affected though. Weird. Let me check the code [21:11] mario_limonciell: there's no trace of such files in the rules, however I have noticed that I had left nvidia-glx-VER.default files in the debian folder of each driver apart from 173. I have removed such files and I'm rebuilding the packages [21:12] ah [21:12] yeah that's most likely how it ended up there [21:13] tseliot, i was thinking of something useful that you might consider putting into EnvyNG at some point [21:13] shoot [21:13] the ability to grab the source of the nvidia-drivers-$LATEST, and for the user to provide the .run file from the nvidia website [21:13] and let it spit out a package in case they aren't out and ready yet in backports etc [21:14] so really it would just craft the orig.tar.gz from the run file and then bump the changelog and version inside the debian packaging temporarily [21:16] mario_limonciell: I could do that but I don't think the other devs/motus would be extremely happy about this [21:17] since they wanted EnvyNG to install only packages from the official repos [21:17] well i mean as long as it always used the source from the archive to build these newer packages [21:17] it could be a temporarily solution [21:17] think of it as the same model that is in the AMD drivers now [21:17] that the source of the debian/ directory is contained and you get the same drivers if you install from AMD's website as you do if you install from the archive [21:18] just since NVIDIA doesn't provide such a system, you fill the gap with envyng [21:19] it's just an idea to think about at least [21:23] mario_limonciell: I'm not saying that it's a bad idea. I would like to keep both users and devs happy, that's all. [21:23] I'll think about it [21:23] tseliot, remember too that you'll never make all the devs happy. it's a closed driver ;) [21:25] heh [21:26] mario_limonciell: it is also true that if a firm such as Dell needed this feature, I would give it more than a thought :-P [21:26] haha [21:26] well when we receive beta drivers from nvidia, it's easy enough to manually do these sorts of things [21:27] too bad ;) [21:40] mario_limonciell: ok, problem solved with the packages. The files in /etc/default couldn't do anything bad but there was no need to keep them there. [21:41] yeah [21:41] well they were doing bad when i had init scripts sitting around still [21:42] but since those are gone, they didn't do anything anymore