[05:10] <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:11] <tjaalton> hmm, slightly outdated though, there are more
[05:12] <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:13] <tjaalton> superm1: libvdpau can be synced too, it won't break anything?
[05:14] <tjaalton> oh and lifeless should merge libx11 ;)
[05:15] <tjaalton> ok, list updated
[05:25] <superm1> tjaalton, although it's unlikely to break, it would be better to test it first
[05:37] <tjaalton> superm1: ok, sure
[05:37] <tjaalton> left it out from the list
[05:39] <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:40] <superm1> tjaalton, okay well after all that's in place i'll try a build and look at it again
[05:44] <tjaalton> there was a sync request for the proto, confirmed it now so hope that it'll get synced soon
[06:32]  * RAOF prepares to hang his system by trying to suspend.
[07:10] <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:11] <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:56] <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:57] <tjaalton> doesn't change the vt for you?
[07:58] <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:59] <tjaalton> heh, no. looks like it's missing ctrl for some reason?
[08:00] <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:03]  * mvo was also missing nouveau-firmware for some reason
[08:04] <tjaalton> nothing depends on it
[08:05] <tjaalton> but aiui it won't be needed for long
[08:06] <RAOF> Indeed; the .33 drm backport kernel also has the voodoo generator backported to it, too.
[08:35] <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:37] <tjaalton> do you have a -pae kernel?
[08:45] <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:48] <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:50] <RAOF> Hm.  Feel free to throw up your dmesg.
[08:51] <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:52] <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:53]  * mvo tries that now
[08:54] <mvo> the prospect of having free driver finally is just too tempting :)
[09:02] <mvo> RAOF: I'm much impressed, works like a charm now with the apw/red kernel
[09:02] <RAOF> Good to hear.
[09:04] <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:05] <mvo> http://paste.ubuntu.com/388159/
[09:05] <tseliot> yes, compiz shouldn't work
[09:06] <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:07] <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:08] <RAOF> I guess that's the new alternatives system making nvidia no longer *totally* break every other driver.
[09:09] <mvo> RAOF: mailed
[09:10] <RAOF> But leaving libgl just broken enough that compiz thinks everything's ok, but is actually horribly broken.
[09:19] <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:20] <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:21] <tseliot> superm1: thoughts? ^^
[09:22] <tseliot> note: this may break dist-upgrades
[09:23] <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:24] <tseliot> tjaalton: yes but unless you choose the correct alternative automatic mode kicks in
[09:25] <tseliot> i.e. the alternative with the highest priority wins
[09:26] <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:27] <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:28] <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:29] <tseliot> and even if we fixed this in update manager, things would still be broken for dist-upgrades from the command line
[09:30] <tjaalton> and the hw manager would then suggest to enable the nvidia libs
[09:30] <tjaalton> isn't that what happens?
[09:31] <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:32] <tjaalton> the kernel module would be loaded, no? or does the alternatives touch that too?
[09:32] <tjaalton> the ddx driver loads it
[09:34] <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:35] <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:36] <RAOF> But there wouldn't be any other alternative for the blacklist file, right?
[09:37] <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
[10:26] <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:29] <RAOF> What does your computer *do* in the 23 seconds before it starts udev?!
[10:30] <mvo> RAOF: I don't know, I was making tea - I can start it again and see if its reproducable
[10:31] <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:33] <mvo> RAOF: sure, I can do that
[10:34] <mvo> RAOF: I just checked, nouveau is way before vga16
[10:49] <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:55] <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:56] <RAOF> Yes, please.
[10:58] <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:59] <RAOF> Yeah, or that. :)
[10:59] <RAOF> Is -t really a synonym for --list?
[10:59] <RAOF> Yes it is.  How strange.
[11:02] <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:03] <ara> I am getting a lot of X crashers in a dell mini 9 (with an i945), is it known¿
[11:04] <ara> (lucid, of course)
[11:05] <jcristau> hard to say with 0 details
[11:11] <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:12] <mvo> RAOF: exists, executable, http://pastebin.com/UrGTFc9b is the content - is that outdated?
[11:12] <mvo> RAOF: heh :) 
[11:51] <apw> RAOF, yay i beat the docbook failure
[12:44] <alkisg> How can I debug 100% xorg usage problems? (lucid, ancient ati)
[12:44] <apw> strace perhaps?
[12:45] <alkisg> strace xorg? ugh, any specific functions to look for?
[12:46] <tjaalton> check with gdb where it's spinning
[12:47] <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:51] <tjaalton> not really, google around
[12:51] <alkisg> Thanks
[13:26] <alkisg> Heh, an update solved my 100% xorg usage problem with ati :)
[13:51] <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
[14:35] <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:36] <Sarvatt> ...if i'm not mistaken, checking
[14:38] <Sarvatt> http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h=7b9c5abee98c54f85bcc04bd4d7ec8d5094c73f4
[14:40] <tjaalton> bryceh: expect a yet-another merge clash with xorg, since you didn't push the changes :)
[14:41] <tjaalton> just the changelog though, as usual
[14:50] <Sarvatt> so yeah that commit is only in drm-intel-next only, wont make it back to stable until its merged I guess anyway
[15:06] <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:07] <tseliot1> superm1: right, at this point I would rather not make too many changes. I will only re-enable the nvidia installer
[15:08] <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:09] <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:10] <Sarvatt> ahh
[15:11] <bjsnider> he has to refresh ffmpeg first
[15:12] <bjsnider> and x264, theora, vorbis, et al.
[15:13] <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
=== ara_ is now known as ara
[15:17] <superm1> bjsnider, yeah it's an annoying problem :(
[15:18] <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:19] <bjsnider> the debian version is in no sense upstream. it's horribly outdated
[15:20] <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:21] <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:22] <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:23] <bjsnider> well, debian/ubuntu and specifically ffmpeg? who else is there?
[15:24] <bjsnider> the 5.1 release notes specifically mentioned the linker bug that he fixed
[15:29] <bjsnider> it's also awfully late in the lucid cycle for a multimedia refresh
[15:31] <superm1> well if nothing else then, perhaps patching mplayer to not FTBFS
[15:33] <bjsnider> why not just delete it until it's fixed
[15:35] <superm1> that sounds like a waste of archive administration resources to me
=== ara_ is now known as ara
[15:46] <tjaalton> hm, need to merge xorg since xorg-dev is uninstallable
[16:34] <bjsnider> does nvidia-current have a provides: nvidia-libvdpau or something like that?
[16:38] <tseliot> nope
[16:39] <bjsnider> are there provides at all?
[16:40] <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:41] <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:42] <superm1> probably wouldn't work
[16:42] <bjsnider> it would error out if the dependent packages weren't there i assume
[16:43] <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:44] <bjsnider> does nvidia-current have a conflicts: nvidia-glx-xxx?
[16:46] <bjsnider> without that i guess dpkg would fail due to duplicate files
[16:47] <tseliot> no, its doesn't conflict with that
[16:58] <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:59] <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/
[17:00] <bjsnider> but are they using mesa or are they using nvidia-s glx?
[17:00] <bryceh> morning
[17:01] <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:02] <bjsnider> ah, so you do not in fact need to use jockey to install the driver
[17:03] <superm1> nvidia-xconfig is probably writing out a lot of unnecessary content to xorg.conf though
[17:04] <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:05] <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:06] <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:10] <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:27] <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
=== radoe_ is now known as radoe
[17:40] <superm1> Sarvatt, that doesnt help if you need to master an image with nvidia in it already 
[17:43] <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:46] <Sarvatt> we should be able to add the fglrx/nvidia to the autoconfiguration list at this point in xserver I imagine also
[17:47] <Sarvatt> that way we dont need an xorg.conf for nvidia anymore
[17:48] <superm1> bryceh had some patches for that, but they needed work
[17:48] <bryceh> hmm?
[17:49] <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:50] <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:51] <Sarvatt> i'll test it out in a bit
[17:52] <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:55] <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 :(
[18:05] <Sarvatt> rebooting to the new xserver without an xorg.conf now
[18:05]  * Sarvatt crosses fingers.
[18:06] <Sarvatt> it worked
[18:07] <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:08] <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:09] <Sarvatt> so glx is not loading with no xorg.conf but 2D works fine
[18:11] <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:12] <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:13] <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:14] <Sarvatt> nice!
[18:14] <Sarvatt> is that new?
[18:14] <superm1> i added it a release or two ago to jockey
[18:15] <Sarvatt> sweet, thank you for that because I use that machine headless 99% of the time
[18:19] <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:36] <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:37] <Sarvatt> yay for a mesa upload at 3KB/second
[18:41] <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:45] <superm1> bjsnider, https://lists.ubuntu.com/archives/lucid-changes/2010-March/007277.html
[18:48] <Sarvatt> apw: might still want to enable the powersave=0 i915 module parameter default patch on -16, still have the hangs here after resume
[19:43] <bjsnider> well, siretart has decided to go with a very conservative release
[19:44] <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:45] <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
[21:32] <apw> bryceh, RAOF, finally have gotten what i think is the upgrade packages for drm33.  all in my red PPA
[21:33] <bryceh> apw, great thanks
[21:56] <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
[22:04] <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:06] <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:07] <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:08] <bryceh> I don't know what augenkrebs is
[22:09] <bdrung_> maybe going cross-eyed (direct translation would be eye cancer, but this is meant metaphorically)
[22:11] <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:40] <Trinity33> hi anyone here?
[22:41] <Trinity33> knock knock........
[22:42] <BUGabundo> no
[22:43] <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:52] <Sarvatt> Trinity33: there is no catalyst for lucid to test yet unfortunately
[22:54] <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:55] <Sarvatt> because its a closed source driver and only ATI can do it
[22:56] <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:57] <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:59] <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.
[23:10] <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:13] <bryceh> johanbr, not afaik
[23:13] <bryceh> at least not currently
[23:14] <johanbr> alright, thank you
[23:15] <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:32] <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:33] <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:34] <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:35] <RAOF> #nouveau is likely to be a better resource for actual debugging.
[23:37] <johanbr> alright, thanks