| bryce_ | jcristau, tjaalton: I just got a response from intel that they're no longer going to support 81x any longer | 10:24 |
|---|---|---|
| bryce_ | http://bugs.freedesktop.org/show_bug.cgi?id=16729 | 10:24 |
| ubottu | Freedesktop bug 16729 in Driver/intel "[815]3D apps cause horizontal line corruption and freezes" [Major,New] | 10:24 |
| tseliot | bryce: what is the file that does the hardware detection when no driver is specified in the Device section of the xorg.conf? | 10:42 |
| tseliot | bryce: if no driver is specified I should detect which driver is loaded for the xorg-options editor | 10:45 |
| bryce_ | you'll need to parse that from the Xorg.0.log | 10:46 |
| bryce_ | I don't know of any reliable way to determine that otherwise | 10:46 |
| bryce_ | hm, or maybe you could look up the pci id in /usr/share/xserver-xorg/pci/ | 10:47 |
| tseliot | bryce_: ok, thanks I'll look up the pci id then | 10:57 |
| tjaalton | bryce_: bah, thypical | 11:16 |
| tjaalton | -h | 11:16 |
| bryce_ | heya tjaalton | 11:21 |
| tseliot | bryce_: hardware detection works well now ;) | 11:32 |
| bryce_ | tseliot: nice | 11:33 |
| jcristau | looking in /usr/share/xserver-xorg/pci/ is probably not future proof | 11:33 |
| bryce_ | 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 |
| tseliot | bryce_: ok, I'll do it | 11:34 |
| tseliot | jcristau: what do you suggest then? | 11:35 |
| jcristau | i don't know why you need that info for | 11:35 |
| jcristau | also, what's with the BOMs | 11:36 |
| tseliot | 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 |
| jcristau | right | 11:37 |
| tseliot | BOMs??? | 11:38 |
| tseliot | and why isn't it future-proof? | 11:38 |
| jcristau | yes, U+FEFF. there's one at the beginning of every one of your lines. | 11:39 |
| jcristau | or, almost every one | 11:39 |
| jcristau | it's not future proof because it'll probably go away at some point | 11:39 |
| tseliot | jcristau: U+FEFF??? I'm a bit confused by acronyms | 11:40 |
| jcristau | it's an unicode codepoint | 11:41 |
| jcristau | so whatever you use for irc is broken and puts that everywhere | 11:41 |
| tseliot | I can't notice the problem here, using pidgin on Hardy | 11:42 |
| tseliot | tjaalton reported a similar problem though | 11:42 |
| tseliot | bryce_: I have updated the wiki. I might do something more later | 12:33 |
| bryce_ | tseliot: excellent thanks | 12:44 |
| bryce_ | tseliot: http://www.phoronix.com/scan.php?page=article&item=xorg_driver_persistent&num=1 | 13:33 |
| tseliot | 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:04 |
| jcristau | err. maybe we haven't read the same discussion then. what more agreement do you need? | 14:05 |
| tseliot | "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:07 |
| jcristau | and the answer was hal for system-wide defaults, gconf for user-specific, iirc? | 14:08 |
| bryce_ | tseliot: great, sounds good. Since it sounds like an xserver 1.6 thing, I guess we can look into that for Intrepid+1 | 14:09 |
| tseliot | bryce_: ok, I'll think about it when it's (almost) ready then | 14:12 |
| BUGabundo | his Alberto Milone arround? | 18:35 |
| BUGabundo | his = is lol | 18:37 |
| mario_limonciell | 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 |
| mario_limonciell | i'm very surprised that something like this wouldn't be handled directly by the kernel module when loaded | 19:58 |
| mario_limonciell | 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 |
| mario_limonciell | you'll see that those modules are created for you | 19:59 |
| mario_limonciell | or devnodes i should say | 19:59 |
| mario_limonciell | well i filed a bug for now, bug 249565 | 20:04 |
| ubottu | 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:04 |
| tseliot | mario_limonciell: thanks, I'll have a look at it later | 20:30 |
| mario_limonciell | tseliot, i filed another bug about the init script for nvidia-glx too | 20:30 |
| tseliot | link? | 20:30 |
| mario_limonciell | tseliot, and it's existence makes me uneasy (in addition to the bug) since it just goes mucking around /usr/ like that | 20:30 |
| mario_limonciell | but that's not what i filed the bug about | 20:30 |
| mario_limonciell | sec | 20:31 |
| mario_limonciell | https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-173/+bug/249566 | 20:31 |
| ubottu | Launchpad bug 249566 in nvidia-graphics-drivers-96 "/etc/init.d/nvidia-glx doesn't use LSB functions" [Undecided,New] | 20:31 |
| mario_limonciell | 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:32 |
| tseliot | mario_limonciell: whatever it is (my connection seems to have some problem now) I will fix it. Don't worry ;) | 20:35 |
| tseliot | mario_limonciell: what version and revision of the driver are you using? | 20:42 |
| tseliot | I removed /etc/init.d/nvidia-glx a few releases ago | 20:42 |
| mario_limonciell | tseliot, then it must have come from dist-upgrading then | 20:43 |
| mario_limonciell | let me purge all versions and do a fresher install | 20:43 |
| tseliot | mario_limonciell: ok | 20:43 |
| mario_limonciell | tseliot, it wasn't around in hardy right? so people who do hardy_>intrepid jump won't end up with it | 20:44 |
| mario_limonciell | i probably just have it from an earlier use of your packages updated to a newer version | 20:44 |
| mario_limonciell | tseliot, ah yeah neither of those appear to be present in the final ones :) | 20:46 |
| mario_limonciell | you don't need /etc/default/nvidia-glx-### though anymore then either | 20:47 |
| mario_limonciell | which is still present after i purged and reinstalled | 20:47 |
| tseliot | /etc/default/nvidia-glx-### ??? | 20:47 |
| tseliot | it's not in my packages | 20:48 |
| mario_limonciell | i have an /etc/default/nvidia-glx-177 somehow? | 20:48 |
| mario_limonciell | i purged all nvidia-* and reinstalled and saw it there | 20:48 |
| mario_limonciell | i'll purge once more to ensure though | 20:48 |
| tseliot | remove it manually | 20:49 |
| tseliot | that was from TLS | 20:49 |
| tseliot | which I removed | 20:49 |
| mario_limonciell | no it definitely came in from nvidia-glx-177 | 20:50 |
| mario_limonciell | when i installed that | 20:50 |
| mario_limonciell | it's in it's package listing (dpkg -L nvidia-glx-177) | 20:50 |
| tseliot | which revision? | 20:51 |
| tseliot | ubuntu5? | 20:51 |
| mario_limonciell | ubuntu6 | 20:53 |
| tseliot | mario_limonciell: do a "dpkg --contents name_of_the_package" please | 20:58 |
| tseliot | don't rely too much on dpkg -L | 20:58 |
| mario_limonciell | http://paste.ubuntu.com/28113/ | 21:00 |
| mario_limonciell | yeah it's in there | 21:00 |
| tseliot | mario_limonciell: 173 is not affected though. Weird. Let me check the code | 21:02 |
| tseliot | 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:11 |
| mario_limonciell | ah | 21:12 |
| mario_limonciell | yeah that's most likely how it ended up there | 21:12 |
| mario_limonciell | tseliot, i was thinking of something useful that you might consider putting into EnvyNG at some point | 21:13 |
| tseliot | shoot | 21:13 |
| mario_limonciell | 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 |
| mario_limonciell | and let it spit out a package in case they aren't out and ready yet in backports etc | 21:13 |
| mario_limonciell | 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:14 |
| tseliot | mario_limonciell: I could do that but I don't think the other devs/motus would be extremely happy about this | 21:16 |
| tseliot | since they wanted EnvyNG to install only packages from the official repos | 21:17 |
| mario_limonciell | well i mean as long as it always used the source from the archive to build these newer packages | 21:17 |
| mario_limonciell | it could be a temporarily solution | 21:17 |
| mario_limonciell | think of it as the same model that is in the AMD drivers now | 21:17 |
| mario_limonciell | 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:17 |
| mario_limonciell | just since NVIDIA doesn't provide such a system, you fill the gap with envyng | 21:18 |
| mario_limonciell | it's just an idea to think about at least | 21:19 |
| tseliot | 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 |
| tseliot | I'll think about it | 21:23 |
| mario_limonciell | tseliot, remember too that you'll never make all the devs happy. it's a closed driver ;) | 21:23 |
| tseliot | heh | 21:25 |
| tseliot | 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 |
| mario_limonciell | haha | 21:26 |
| mario_limonciell | well when we receive beta drivers from nvidia, it's easy enough to manually do these sorts of things | 21:26 |
| tseliot | too bad ;) | 21:27 |
| tseliot | 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:40 |
| mario_limonciell | yeah | 21:41 |
| mario_limonciell | well they were doing bad when i had init scripts sitting around still | 21:41 |
| mario_limonciell | but since those are gone, they didn't do anything anymore | 21:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!