| tjaalton | bryceh: there are some "can be synced" tags on the versions_current list, do you think that sync requests should be filed for those? | 05:10 |
|---|---|---|
| tjaalton | https://wiki.ubuntu.com/X/PackageNotes | 05:10 |
| tjaalton | hmm, slightly outdated though, there are more | 05:11 |
| tjaalton | libxi for instance is very much needed, there are some bugs filed against libxcb that this should fix | 05:12 |
| tjaalton | http://bugs.debian.org/400442 | 05:12 |
| tjaalton | superm1: libvdpau can be synced too, it won't break anything? | 05:13 |
| tjaalton | oh and lifeless should merge libx11 ;) | 05:14 |
| tjaalton | ok, list updated | 05:15 |
| superm1 | tjaalton, although it's unlikely to break, it would be better to test it first | 05:25 |
| tjaalton | superm1: ok, sure | 05:37 |
| tjaalton | left it out from the list | 05:37 |
| superm1 | tjaalton, when trying to build even: The following packages have unmet dependencies: | 05:39 |
| superm1 | pbuilder-satisfydepends-dummy: Depends: x11proto-dri2-dev (>= 2.2) but it is not installable | 05:39 |
| superm1 | is that not in lucid yet? | 05:39 |
| tjaalton | superm1: hah, no. but on the list of syncs | 05:39 |
| superm1 | tjaalton, okay well after all that's in place i'll try a build and look at it again | 05:40 |
| tjaalton | there was a sync request for the proto, confirmed it now so hope that it'll get synced soon | 05:44 |
| * RAOF prepares to hang his system by trying to suspend. | 06:32 | |
| tjaalton | RAOF: nouveau suspend works fine for me | 07:10 |
| tjaalton | it's nice how the user-switch is instant | 07:10 |
| tjaalton | +also | 07:10 |
| RAOF | tjaalton: Yeah; my laptop's just a bit of a problem-child. | 07:10 |
| tjaalton | ok, mine is a desktop | 07:10 |
| RAOF | It *has* worked with nouveau suspend in the past, but it now goes through the motions and then fails to actually power down in any way. | 07:11 |
| RAOF | I think that no_console_suspend is the next step in debugging. | 07:11 |
| mvo | can we get ctrl-alt-f2 and friends back when in X-is-in-trouble mode please? the menus are all nice but much less efficient than just going to the terminal | 07:56 |
| tjaalton | doesn't change the vt for you? | 07:57 |
| mvo | it didn't | 07:58 |
| mvo | but maybe something else was wrong too - is it mean't to work? | 07:58 |
| tjaalton | what hw? works for me on intel and nouveau | 07:58 |
| tjaalton | of course :) | 07:58 |
| mvo | nvidia (very new one) | 07:58 |
| mvo | aha .) I though it was removed for "safety" (just like ctrl-alt-backspace) | 07:58 |
| mvo | glad that its not :) | 07:58 |
| tjaalton | heh, no. looks like it's missing ctrl for some reason? | 07:59 |
| mvo | yeah, it looks like my keyboard map is wrong too | 08:00 |
| mvo | so that may explain it, I look into it | 08:00 |
| mvo | thanks | 08:00 |
| tjaalton | np | 08:00 |
| * mvo was also missing nouveau-firmware for some reason | 08:03 | |
| tjaalton | nothing depends on it | 08:04 |
| tjaalton | but aiui it won't be needed for long | 08:05 |
| RAOF | Indeed; the .33 drm backport kernel also has the voodoo generator backported to it, too. | 08:06 |
| mvo | RAOF: nouveau is not working for me, gives me a "module nouveau not found" error - do I just need to wait for a new kernel with the .33 bits backported? | 08:35 |
| tjaalton | do you have a -pae kernel? | 08:37 |
| RAOF | mvo: You could wait for the kernel, or add-apt-repository ppa:apw/red to get it now, or check that you've got the right linux-backports-modules-nouveau-lucid-FLAVOUR installed. | 08:45 |
| mvo | RAOF: odd, modprobe lbm_nouveau gives me the module and X starts but for some reasons its not loading it itself (linux-backports-modules-nouveau-lucid-FLAVOUR) | 08:48 |
| RAOF | Hm. Feel free to throw up your dmesg. | 08:50 |
| mvo | [drm] failed to load kernel module "nouveau" in Xorg.0.log - but I can wait for the new kernel to hit the archive, if -backports-nouveau is temporarely anyway its probably not worth spend (too) much time debugging | 08:51 |
| mvo | nothing in dmesg releated to nouveau, just [lbm-drm] initialized 1.1.0 | 08:52 |
| mvo | (amd64) | 08:52 |
| RAOF | Yeah. If you feel like it, check out the apw/red PPA; if that doesn't work, we've got an issue. | 08:52 |
| * mvo tries that now | 08:53 | |
| mvo | the prospect of having free driver finally is just too tempting :) | 08:54 |
| mvo | RAOF: I'm much impressed, works like a charm now with the apw/red kernel | 09:02 |
| RAOF | Good to hear. | 09:02 |
| apw | mvo is that amd64 or i386 | 09:04 |
| mvo | amd64 | 09:04 |
| mvo | I can not switch to a vt anymore, but I had a similar problem earlier so it may be unreleated | 09:04 |
| mvo | and no compiz for me (G86 I think) - but that is probalby know, the 2d bits are fine though (so far) | 09:04 |
| RAOF | mvo: Can you post your dmesg; that sounds annoyingly like a bug I was sure the backport kernel would fix. | 09:04 |
| mvo | http://paste.ubuntu.com/388159/ | 09:05 |
| tseliot | yes, compiz shouldn't work | 09:05 |
| mvo | (uname -a http://paste.ubuntu.com/388160/) | 09:06 |
| RAOF | Yeah, we don't have the 3D components in the main archive. You can try the xorg-edgers PPA; lots of people have had compiz-level success with it. | 09:06 |
| tseliot | RAOF: my late congratulations on joining Canonical :-) | 09:06 |
| RAOF | tseliot: Thanks :) | 09:06 |
| RAOF | mvo: Can I have the rest of dmesg? I think the error in there is plymouth, and unrelated. | 09:07 |
| mvo | RAOF: sure, sorry, give me a second | 09:07 |
| RAOF | tseliot: Oh, I was looking at some of the nvidia bugs, and bug 530481 sprang up as something you'd know about. | 09:07 |
| ubottu | Launchpad bug 530481 in nvidia-graphics-drivers "nvidia-graphics-drivers break libgl horribly if hardware isn't nvidia" [Undecided,Confirmed] https://launchpad.net/bugs/530481 | 09:07 |
| RAOF | I guess that's the new alternatives system making nvidia no longer *totally* break every other driver. | 09:08 |
| mvo | RAOF: mailed | 09:09 |
| RAOF | But leaving libgl just broken enough that compiz thinks everything's ok, but is actually horribly broken. | 09:10 |
| tseliot | RAOF: yes, right. It looks like mplayer's build-dep should be fixed and there is very little I can do if people install the wrong driver | 09:19 |
| tseliot | I could make mesa's libraries have the highest priority (with alternatives) so that this doesn't happen though | 09:20 |
| tseliot | and users will get the nvidia libraries only if they switch to them manually (or through jockey) | 09:20 |
| tseliot | superm1: thoughts? ^^ | 09:21 |
| tseliot | note: this may break dist-upgrades | 09:22 |
| tjaalton | tseliot: but wasn't it meant to be able to install these side-by-side? | 09:23 |
| tjaalton | hmm though in this case nvidia was probably enabled as well | 09:23 |
| tseliot | tjaalton: yes but unless you choose the correct alternative automatic mode kicks in | 09:24 |
| tseliot | i.e. the alternative with the highest priority wins | 09:25 |
| tjaalton | shouldn't the free one have that? | 09:26 |
| tjaalton | because there's no way to decide the highest priority among the blobs | 09:26 |
| tjaalton | so even if you install the blog, you need to enable it | 09:27 |
| tjaalton | that way it doesn't break any setups | 09:27 |
| tseliot | tjaalton: that's what I was suggesting but there's a use case we wouldn't cover | 09:28 |
| tseliot | think of dist-upgrades | 09:28 |
| tseliot | users with nvidia would be left with mesa's libraries | 09:28 |
| tseliot | instead of nvidia's | 09:28 |
| tseliot | and even if we fixed this in update manager, things would still be broken for dist-upgrades from the command line | 09:29 |
| tjaalton | and the hw manager would then suggest to enable the nvidia libs | 09:30 |
| tjaalton | isn't that what happens? | 09:30 |
| tseliot | yes, if X doesn't crash | 09:31 |
| tseliot | nvidia would still be in xorg.conf | 09:31 |
| tseliot | but we would have no kernel module or gl libraries for that driver | 09:31 |
| tjaalton | the kernel module would be loaded, no? or does the alternatives touch that too? | 09:32 |
| tjaalton | the ddx driver loads it | 09:32 |
| tjaalton | then X wouldn't crash, just that GL is broken | 09:34 |
| tseliot | tjaalton: no, it wouldn't be loaded because of nouveau | 09:34 |
| tseliot | the KMS moduel | 09:34 |
| tseliot | module | 09:34 |
| tjaalton | uh, so how does nvidia make it not load nouveau? | 09:34 |
| tseliot | alternatives put a blacklist file in /etc/modprobe.d/ | 09:35 |
| tseliot | then we update the initramfs | 09:35 |
| tjaalton | ok then | 09:35 |
| tjaalton | I give up :) | 09:35 |
| RAOF | But there wouldn't be any other alternative for the blacklist file, right? | 09:36 |
| tseliot | tjaalton: heh :-) | 09:37 |
| tseliot | RAOF: no, when you switch to mesa the blacklist file goes away and you (meaning jockey) will have to update the initramfs | 09:37 |
| RAOF | mvo: Have you done anything strange to your initramfs hooks? It takes 26 seconds for nouveau to start to come up, which seems strange as it should be in the initramfs. | 10:26 |
| mvo | RAOF: nothing | 10:26 |
| RAOF | What does your computer *do* in the 23 seconds before it starts udev?! | 10:29 |
| mvo | RAOF: I don't know, I was making tea - I can start it again and see if its reproducable | 10:30 |
| RAOF | I'm not entirely sure how to read that dmesg; could you just make sure that nouveau.ko appears in /lib/modules/2.6.32-16-whatever/modules.order, before vga16fb? | 10:31 |
| RAOF | mvo: Ah, well, if you were making tea! | 10:31 |
| mvo | RAOF: sure, I can do that | 10:33 |
| mvo | RAOF: I just checked, nouveau is way before vga16 | 10:34 |
| RAOF | mvo: Finally... can you check that the output of “sudo update-initramfs -u -v” contains /lib/modules/2.6.32-16-generic/kernel/drivers/gpu/drm/nouveau/nouveau.ko | 10:49 |
| mvo | RAOF: running that now - it says its running the nouveau_kms hook, but that is it. the module is not mentioned in the output (i can provide the full output if you want) | 10:55 |
| RAOF | Yes, please. | 10:56 |
| jcristau | 'zcat /boot/initrd.img-$(uname -r)|cpio -t |grep nouveau' maybe | 10:58 |
| jcristau | if you want to know whether it's in the initramfs | 10:58 |
| RAOF | Yeah, or that. :) | 10:59 |
| RAOF | Is -t really a synonym for --list? | 10:59 |
| RAOF | Yes it is. How strange. | 10:59 |
| mvo | RAOF: here it is http://pastebin.com/VjqCNVTA | 11:02 |
| mvo | RAOF: I need to leave for lunch now, but I will read scrollback | 11:02 |
| ara | I am getting a lot of X crashers in a dell mini 9 (with an i945), is it known¿ | 11:03 |
| ara | (lucid, of course) | 11:04 |
| jcristau | hard to say with 0 details | 11:05 |
| RAOF | mvo: Ok. Now I ask you whether /usr/share/initramfs-tools/hooks/framebuffer exists, is executable, and if it's both of those, to pastebin its contents. | 11:11 |
| RAOF | mvo: I will be off to the more extended version of lunch in which I lie in a bed and sleep for 8-odd hours. I shall also read scrollback :) | 11:11 |
| mvo | RAOF: exists, executable, http://pastebin.com/UrGTFc9b is the content - is that outdated? | 11:12 |
| mvo | RAOF: heh :) | 11:12 |
| apw | RAOF, yay i beat the docbook failure | 11:51 |
| alkisg | How can I debug 100% xorg usage problems? (lucid, ancient ati) | 12:44 |
| apw | strace perhaps? | 12:44 |
| alkisg | strace xorg? ugh, any specific functions to look for? | 12:45 |
| tjaalton | check with gdb where it's spinning | 12:46 |
| tjaalton | or some profiler | 12:47 |
| alkisg | I think strace or gdb would be too much for my abilities - could you propose some profiler? | 12:47 |
| tjaalton | not really, google around | 12:51 |
| alkisg | Thanks | 12:51 |
| alkisg | Heh, an update solved my 100% xorg usage problem with ati :) | 13:26 |
| apw | bryceh, ok, we have some thumbs up from RAOF for the new kernel, i am getting a whole set together in my red ppa, to make sure the interactions on upgrade work correctly ... so don't test with it till i tell you its all there ... need to get kernel lbm and meta sorted as a group, to make it a proper test | 13:51 |
| Sarvatt | apw: * (pre-stable) drm/i915: blacklist lid status: Sony VGN-BX196VP, Dell Inspiron 700m | 14:35 |
| Sarvatt | that's pointless isnt it? | 14:35 |
| Sarvatt | theres already a commit in .33 blacklisting all 8xx machines lid status | 14:35 |
| Sarvatt | ...if i'm not mistaken, checking | 14:36 |
| Sarvatt | http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=7b9c5abee98c54f85bcc04bd4d7ec8d5094c73f4 | 14:38 |
| tjaalton | bryceh: expect a yet-another merge clash with xorg, since you didn't push the changes :) | 14:40 |
| tjaalton | just the changelog though, as usual | 14:41 |
| Sarvatt | so yeah that commit is only in drm-intel-next only, wont make it back to stable until its merged I guess anyway | 14:50 |
| superm1 | tseliot1, mplayer just needs to be fixed | 15:06 |
| superm1 | dont worry about adding hacks for the fact that mplayer is doing it wrong | 15:06 |
| tseliot1 | superm1: that's for sure | 15:06 |
| Sarvatt | it wasnt even a PPA version of mplayer that was causing it but one in the archive?? | 15:06 |
| tseliot1 | superm1: right, at this point I would rather not make too many changes. I will only re-enable the nvidia installer | 15:07 |
| superm1 | i think the problem is it's not just s/nvidia blah dev/libvdpau-dev/ because mplayer FTBFS right now | 15:08 |
| superm1 | so siretart really needs to fix the FTBFS | 15:08 |
| tseliot1 | ah | 15:08 |
| Sarvatt | what mplayer package is pulling in nvidia-current? i dont see anything on 2:1.0~rc3+svn20090426-1ubuntu13 | 15:09 |
| superm1 | it's the build-deps that pull it in | 15:09 |
| Sarvatt | ahh | 15:10 |
| bjsnider | he has to refresh ffmpeg first | 15:11 |
| bjsnider | and x264, theora, vorbis, et al. | 15:12 |
| bjsnider | and then finally mplayer | 15:13 |
| bjsnider | and as far as i know none of this has been started | 15:13 |
| bjsnider | every time i ask him about it he gets snippy | 15:13 |
| === ara_ is now known as ara | ||
| superm1 | bjsnider, yeah it's an annoying problem :( | 15:17 |
| superm1 | i would think since he tries to maintain them in debian and ubuntu it would be stable in debian and more syncable though | 15:18 |
| bjsnider | the debian version is in no sense upstream. it's horribly outdated | 15:19 |
| bjsnider | the commands listed in his upstream-upgrade file for ffmpeg no longer work because there is no ffmpeg-debian to git pull from | 15:20 |
| bjsnider | so i don't know what is going on there | 15:20 |
| bjsnider | the ffmpeg 5.1 release happened yesterday i think. i went in to their irc room and asked about it. they said debian/ubuntu wanted them to release it | 15:20 |
| bjsnider | even though it's outdated code | 15:21 |
| bjsnider | debian/ubuntu i assume refers specifically to siretart i would assume | 15:21 |
| bjsnider | said assume twice there | 15:21 |
| superm1 | well there's more to the debian multimedia team than just him i thought | 15:22 |
| bjsnider | that's older code than what is currently in karmic | 15:22 |
| bjsnider | well, debian/ubuntu and specifically ffmpeg? who else is there? | 15:23 |
| bjsnider | the 5.1 release notes specifically mentioned the linker bug that he fixed | 15:24 |
| bjsnider | it's also awfully late in the lucid cycle for a multimedia refresh | 15:29 |
| superm1 | well if nothing else then, perhaps patching mplayer to not FTBFS | 15:31 |
| bjsnider | why not just delete it until it's fixed | 15:33 |
| superm1 | that sounds like a waste of archive administration resources to me | 15:35 |
| === ara_ is now known as ara | ||
| tjaalton | hm, need to merge xorg since xorg-dev is uninstallable | 15:46 |
| bjsnider | does nvidia-current have a provides: nvidia-libvdpau or something like that? | 16:34 |
| tseliot | nope | 16:38 |
| bjsnider | are there provides at all? | 16:39 |
| bjsnider | dpkg must somehow think nvidia-current is related to nvidia-glx-xxx | 16:40 |
| bjsnider | otherwise i don't see why mplayer would pull it in | 16:40 |
| tseliot | we have transitional packages for that | 16:40 |
| superm1 | it pulls in the 185 stuff | 16:40 |
| superm1 | which is transitional | 16:40 |
| bjsnider | oh, right hahahaa | 16:41 |
| bjsnider | i forgot about the transitional packages | 16:41 |
| bjsnider | those darned things | 16:41 |
| bjsnider | what would happen if those didn't exist and someone tried to install mplayer? | 16:41 |
| superm1 | probably wouldn't work | 16:42 |
| bjsnider | it would error out if the dependent packages weren't there i assume | 16:42 |
| superm1 | but remember they're build-deps and suggests right now | 16:43 |
| superm1 | not recommends or depends | 16:43 |
| bjsnider | i wonder what would happen during upgrades if the transitional packages weren't there | 16:43 |
| bjsnider | does nvidia-current have a conflicts: nvidia-glx-xxx? | 16:44 |
| bjsnider | without that i guess dpkg would fail due to duplicate files | 16:46 |
| tseliot | no, its doesn't conflict with that | 16:47 |
| bjsnider | tseliot, if someone manually installs nvidia-current, and does nvidia-xconfig to take care of xorg.conf, (bypassing jockey) are they missing anything? | 16:58 |
| bjsnider | it seems to me they're missing the glx part | 16:58 |
| tseliot | bjsnider: they will have to update the initramfs | 16:58 |
| bjsnider | tseliot, nvidia-current doesn't do that though dkms? | 16:59 |
| tseliot | bjsnider: ah, right it does that in the postinst | 16:59 |
| superm1 | s/dkms/postinst/ | 16:59 |
| bjsnider | but are they using mesa or are they using nvidia-s glx? | 17:00 |
| bryceh | morning | 17:00 |
| tseliot | morning bryceh | 17:01 |
| tseliot | bjsnider: the alternative provided by nvidia-current already has the highest priority so it should use Nvidia's gl libraries | 17:01 |
| bjsnider | ah, so you do not in fact need to use jockey to install the driver | 17:02 |
| superm1 | nvidia-xconfig is probably writing out a lot of unnecessary content to xorg.conf though | 17:03 |
| bjsnider | yes, i agree | 17:04 |
| bjsnider | at one point it was writing data that was incompatible with xorg and it was causing the driver to fail to load | 17:04 |
| bjsnider | it still writes the mouse/keyboard info to it | 17:04 |
| superm1 | i almost think it would be better to provide a shim that uses xkit in place of nvidia-xconfig to avoid that | 17:05 |
| tseliot | you can use jockey from the command line. That will give you a very minimal xorg.conf | 17:05 |
| superm1 | that or ship an xorg.conf in nvidia-current as a conffile | 17:05 |
| bjsnider | but nvidia-settings will still write that parochial data to it as well | 17:05 |
| superm1 | i thought it was patched? | 17:06 |
| bjsnider | oh, i don't know what's happening in lucid, but all other versions do | 17:06 |
| tseliot | I patched nvidia-settings to use policykit, I'm not aware of any other work on it | 17:10 |
| bjsnider | yeah, so nvidia-settings will be writing gobbledygook data to xorg.conf | 17:10 |
| tseliot | superm1: shipping a conffile can make things ugly | 17:10 |
| bjsnider | but it's nvidia's fault | 17:10 |
| Sarvatt | hmm, just had an idea.. maybe we could add a pci id check in the nvidia-current postinst that checks for a 10de vendor id before it sets the nvidia alternatives | 17:27 |
| === radoe_ is now known as radoe | ||
| superm1 | Sarvatt, that doesnt help if you need to master an image with nvidia in it already | 17:40 |
| Sarvatt | hmm, if you did that though it wouldnt use nvidia GL by default in that case and activating it in jockey would end up running the postinst wouldnt it? | 17:43 |
| Sarvatt | we should be able to add the fglrx/nvidia to the autoconfiguration list at this point in xserver I imagine also | 17:46 |
| Sarvatt | that way we dont need an xorg.conf for nvidia anymore | 17:47 |
| superm1 | bryceh had some patches for that, but they needed work | 17:48 |
| bryceh | hmm? | 17:48 |
| bryceh | yeah, tseliot was going to look into improving that but ran out of time | 17:49 |
| Sarvatt | yeah I added those :) we can add nvidia to the nouveau patch easily, our problem at the time was that we were shipping a stock xorg.conf with no explicit driver specified so it only used the first device from the autodetection list | 17:49 |
| bryceh | it gets complicated though. for nvidia there are also some xorg.conf settings aside from specifying the driver, like the depth, and autoconfiguring the driver would not set those up automatically | 17:49 |
| Sarvatt | only the nologo option, dont really need that | 17:50 |
| jcristau | wasn't fglrx the one needing to have Depth set? | 17:50 |
| bryceh | maybe it was fglrx | 17:50 |
| jcristau | (which is incredibly stupid, but hey) | 17:50 |
| Sarvatt | ah nvidia has depth and Load "glx" in it too but i didnt think they were required | 17:50 |
| Sarvatt | i'll test it out in a bit | 17:51 |
| bryceh | I seem to remember that at least many cards won't boot if depth is not specified | 17:52 |
| bryceh | anyway, I believe with some work it could be hacked around server-side, but makes the size of the effort just beyond what seems easy to do quick | 17:52 |
| Sarvatt | building xserver now with nv swapped to nvidia in the nouveau default patch to test it out real quick, will be a few hours though because I'm out of the house with a spotty connection | 17:55 |
| Sarvatt | there seems to be an x client leak with chromium/flash/nvidia blob :( | 17:55 |
| Sarvatt | rebooting to the new xserver without an xorg.conf now | 18:05 |
| * Sarvatt crosses fingers. | 18:05 | |
| Sarvatt | it worked | 18:06 |
| superm1 | i thought the problem was if you had an xorg.conf though, it doesn't use the proper fallback logic | 18:07 |
| Sarvatt | or not! :D | 18:07 |
| Sarvatt | load glx is required | 18:07 |
| Sarvatt | http://pastebin.com/0nGXwtDX | 18:07 |
| Sarvatt | that was only during the jaunty and early karmic devel stage superm1 where there was a default xorg.conf with no specific driver specified but that was dropped a long time ago | 18:08 |
| Sarvatt | so glx is not loading with no xorg.conf but 2D works fine | 18:09 |
| Sarvatt | that seems like a win to me, jockey installs the xorg.conf still and it'll still work without 3D if theres no xorg.conf for some reason | 18:11 |
| superm1 | is there a way to get it to conditionally load glx if it's using nvidia | 18:11 |
| Sarvatt | need to dig into that more when I have some time, but this would make things basically work for people who install via a terminal instead of jockey (like me) | 18:12 |
| jcristau | the server loads glx unconditionally | 18:13 |
| superm1 | Sarvatt, you can install via a terminal using jockey, jockey-text -e xorg:nvidia-current | 18:13 |
| Sarvatt | nice! | 18:14 |
| Sarvatt | is that new? | 18:14 |
| superm1 | i added it a release or two ago to jockey | 18:14 |
| Sarvatt | sweet, thank you for that because I use that machine headless 99% of the time | 18:15 |
| Sarvatt | hmm mesa is kind of screwed up now on intel, 4 glx visuals 6 glxfbconfigs and some 3D apps arent working | 18:19 |
| Sarvatt | (in edgers not lucid's packages) | 18:19 |
| Sarvatt | hmmm | 18:36 |
| Sarvatt | * Add 11_nvidia_suspend.patch: Re-enable chvt quirk for nvidia driver, to repair suspend with the current driver versions. (LP: #488720) | 18:36 |
| Sarvatt | I swear I tested that when I was looking into it and it didnt work on my machine | 18:36 |
| Sarvatt | yay for a mesa upload at 3KB/second | 18:37 |
| Sarvatt | time to test out this drm backport kernel, the -14 drm backport kernel had all kinds of problems on my intel that a .33 kernel didn't have for some reason | 18:41 |
| superm1 | bjsnider, https://lists.ubuntu.com/archives/lucid-changes/2010-March/007277.html | 18:45 |
| Sarvatt | apw: might still want to enable the powersave=0 i915 module parameter default patch on -16, still have the hangs here after resume | 18:48 |
| bjsnider | well, siretart has decided to go with a very conservative release | 19:43 |
| superm1 | mplayer doesn't build-dep on ffmpeg though does it? | 19:44 |
| bjsnider | oh yes it does | 19:44 |
| bjsnider | it uses dynamic ffmpeg like everything else | 19:44 |
| bjsnider | i tried building the 5.1 release yesterday and it still had the vhook stuff in it | 19:45 |
| bjsnider | not part of current svn code and hasn't been for a long time | 19:45 |
| bjsnider | but whatever. he's the expert | 19:45 |
| apw | bryceh, RAOF, finally have gotten what i think is the upgrade packages for drm33. all in my red PPA | 21:32 |
| bryceh | apw, great thanks | 21:33 |
| bdrung | will xserver-xorg-video-ati updated to version 6.12.191? this will fix the tearing bug #514845 | 21:56 |
| ubottu | Launchpad bug 514845 in xserver-xorg-video-ati "videos and window movements tear" [Undecided,Triaged] https://launchpad.net/bugs/514845 | 21:56 |
| bryceh | bdrung_, 6.13 just came out iirc; probably we'll move to that | 22:04 |
| bdrung_ | bryceh: great | 22:04 |
| bryceh | we'll probably need a ffe though | 22:04 |
| bdrung_ | bryceh: you can use my bug report for getting it accepted ;) | 22:06 |
| bdrung_ | bryceh: the current version in the archives hurts my eyes (found no translation for augenkrebs) | 22:06 |
| bryceh | bdrung_, no, there's not evidence that you tested the newer version and found it solved the issue, so it won't work as a base for a ffe | 22:07 |
| bryceh | I don't know what augenkrebs is | 22:08 |
| bdrung_ | maybe going cross-eyed (direct translation would be eye cancer, but this is meant metaphorically) | 22:09 |
| bdrung_ | bryceh: i tested a snapshot from 2010-02-24, but i will explicitly test 6.12.191 or 6.13. | 22:11 |
| bdrung_ | bryceh: according to http://www.x.org/wiki/radeon 6.13 is not yet released | 22:11 |
| Trinity33 | hi anyone here? | 22:40 |
| Trinity33 | knock knock........ | 22:41 |
| BUGabundo | no | 22:42 |
| Trinity33 | i just found info somewhere that is i want to help i should come over :) so i got lucid alpha 3 q9000 quadcore ati hd4850 ddr2 4gb so where is that driver i have to test:) the last one i tested from open source included in lucid doesnt work so is there anything a=else i could do? | 22:43 |
| Trinity33 | any other driver to check ? | 22:43 |
| Trinity33 | catalyst 10.2 doesnt work in 2.6.32 | 22:43 |
| Sarvatt | Trinity33: there is no catalyst for lucid to test yet unfortunately | 22:52 |
| Sarvatt | I'm kind of doubting there even will be one at this point.. | 22:54 |
| Trinity33 | why doesnt soemone make one? for me? nvidia is working in lucid | 22:54 |
| Sarvatt | because its a closed source driver and only ATI can do it | 22:55 |
| Trinity33 | the driver included in lucid doesnt work with hd4850 too it use to much cpu | 22:56 |
| Sarvatt | it stinks because we really need time to work out the packaging issues like we did with the nvidia binary driver | 22:56 |
| Sarvatt | Trinity33: try booting with radeon.modeset=0 added to the kernel command line | 22:56 |
| Sarvatt | the 2.6.32-16 kernel should hopefully help with that a bit | 22:56 |
| Sarvatt | i'm guessing you're complaining about how slow flash is with the radeon drivers? radeon.modeset=0 should help with that alot | 22:57 |
| Trinity33 | im not that good with drivers and generally linux im beginner :) so if i have to change something u need to speak english or russian i tried open source driver in karmic 2.6.31.14 and it use lot of cpu too the same like in lucid in karmic i have installed catalyst and the cpu usage is between 0 and 2% with open source driver between 30 and 50% cpu | 22:59 |
| bryceh | Sarvatt, yes there will be an -fglrx | 22:59 |
| bryceh | Sarvatt, they always deliver it in time, but only just. | 22:59 |
| johanbr | Does anyone know if it's possible with nouveau to detect a GPU lockup and do a reset (similar to what Intel does) ? | 23:10 |
| bryceh | johanbr, not afaik | 23:13 |
| bryceh | at least not currently | 23:13 |
| johanbr | alright, thank you | 23:14 |
| Sarvatt | only 965+ intel you should say :) it doesn't now but i imagine some of the newer hardware will be able to do it at some point because I'm pretty sure I remember the windows drivers doing it. nouveau is reverse engineered though so i wouldnt hold my breath for it to happen anytime soon if the blob doesn't already do it | 23:15 |
| RAOF | johanbr: It would actually be pretty easy to implement that. | 23:32 |
| johanbr | oh, alright :) | 23:32 |
| johanbr | so the nouveau people know how to "hot-reset" the gpu? | 23:32 |
| RAOF | In some cases. | 23:32 |
| RAOF | Oh, I was thinking more of “when you have detected a GPU lock up, tell someone so you can get a good bug report”. | 23:33 |
| RAOF | I'm not sure that being able to recover from arbitrary GPU lockups is easy. | 23:33 |
| RAOF | But GPU lockups are currently detected, various errors are detected, and a subset of them can be resloved. | 23:34 |
| johanbr | I get them every few days, but I'm not sure how to get the debug information... | 23:34 |
| johanbr | I could ssh in from my phone, I guess | 23:34 |
| RAOF | #nouveau is likely to be a better resource for actual debugging. | 23:35 |
| johanbr | alright, thanks | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!