[05:21] <RAOF> Oh, balls.  Nouveau's gained DRI2 vsync support, and it looks like it's going to crash in *exactly* the same way intel's and then radeon's did.
[05:22] <hyperair> intel's vsync crashed?
[05:23] <RAOF> Yeah, on client close.
[05:25] <RAOF> Because DRI2 buffers aren't reference counted, and get destroyed on client close, and the vsync event can occur after the request is queued and the client shutdown...
[08:41] <bryceh> RAOF, heh phoronix thinks you should enable gallium 3d for nouveau
[09:33] <jcristau> wait what?  phoronix thinks?
[10:25] <bryceh> jcristau, I'm trying to figure out how to merge the words "phoronix" and "paparazzi"
[11:15] <Ng> paphonorazzix!
[11:15] <tjaalton> "phoronazzi" ?-)
[11:15] <Ng> if in doubt, smush things together with as much force as possible ;)
[11:15] <jcristau> tjaalton: sounds a bit too much like nazi
[11:15] <bryceh> heh
[11:16] <tjaalton> jcristau: meh :)
[11:23] <bryceh> it's harder than it seems it should be
[11:26] <bryceh> phopronozzi is best I've come up with but it has prono in it
[11:27] <jcristau> maybe that's a good thing.  pr0n is good for page hits.
[11:27] <bryceh> lol
[16:12] <Sarvatt> apw: ok there's more to it, every other boot with gfxpayload=keep is screwed in grub space still, it's stuck before the kernel selection screen
[16:13] <apw> Sarvatt, i don't see that behaviour on any of my kit, i always get to a kernel before things go wrong
[16:13] <apw> not that it supprised me there is some h/w which gets broken
[16:32] <Sarvatt> sheesh, moving drm.so out of the way isn't helping anymore either, I guess it's just really racy and I got lucky because it was doing a fsck that one time. almost done building an i386  kernel with Sanitize modesetting registers.(v2)
[16:36] <Sarvatt> htop is fun on tangerine.buildd, guess you need 2560x1600 to use it with 64 cores :)
[16:56] <Sarvatt> argh
[16:56] <Sarvatt> apw: If I cold boot Sanitize modesetting registers.(v2) fixes it every time, 11 boots that way worked perfect
[16:57] <Sarvatt> apw: but if I reboot instead, it hangs at GRUB loading.
[16:57] <apw> hrm
[16:57] <apw> (v2) ?
[16:57] <Sarvatt> yeah from your bug https://bugs.freedesktop.org/show_bug.cgi?id=32078
[16:57] <ubot4`> Freedesktop bug 32078 in DRM/Intel "Intel N10 graphics does not initialise correctly if GRUB hands off the display in a graphics mode" [Major,New]
[16:58] <apw> Sarvatt, damn i'd started the previous one building and been on the release meeting ... and
[16:59]  * apw restarts his build ... gah
[17:00] <Sarvatt> can you grab it from /home/sarvatt on tangerine?
[17:05] <apw> Sarvatt, its nearly built again now anyhow ... but thanks
[17:18] <Sarvatt> i'm totally stumped now, cold boot with that patch for sure works right but a reboot hangs in grub every time
[17:49] <Sarvatt> using vesafb sure does make VT's suck on the blobs
[18:07] <Sarvatt> apw: I haven't heard any complaining about radeon yet, with intel fixed maybe this will work this cycle :)
[18:07] <apw> Sarvatt, the vesafb stuff looooks _sooo_ bad :)
[18:07] <apw> but yeah there is some hope perhaps
[18:08] <Sarvatt> yeah wish we could kill it in a fire, I know I'll still be disabling it on all my systems by booting with vesafb.sucks=1 :)
[18:09] <Sarvatt> it's not like it helps that much even with the blobs since they turn off the display when X starts unconditionally, I see the splash for all of 1 second
[18:11] <Sarvatt> text plugin progress dots loaded in the initramfs early for everyone looks best to me :) it's just the Ubuntu 10.10 words that look like crap in text mode
[18:13] <Sarvatt> well the Ubuntu 10.10 text looks nice on a drmfb at native res, but crappy on 80x25
[18:19] <apw> Sarvatt, hehe yeah sometimes i wonder if that would be a better plan overall
[18:34] <Sarvatt> hmm, if i boot an old kernel (2.6.35-23) then grub works after a reboot, if i boot 2.6.37-7-generic with or without that patch grub hangs after a reboot every time. 
[18:34] <Sarvatt> 2.6.37-5 hangs
[18:38] <Sarvatt> 2.6.36-1 is the last good kernel that reboots right, fun
[18:42] <bryceh> Sarvatt, have you tried any backports of -intel to maverick?  Is it at all feasible?
[18:43] <Sarvatt> yeah just needs a newer xutils-dev, lowered of the xserver-xorg-dev build-dep to 1.9.0 and a natty libdrm backport
[18:43] <Sarvatt> want me to put it in x-updates while i'm bisecting?
[18:45] <bryceh> Sarvatt, yes that would be great
[18:45] <bryceh> Sarvatt, I'm thinking it might help on bug 682712
[18:45] <ubot4`> Launchpad bug 682712 in xserver-xorg-video-intel (Ubuntu) (and 3 other projects) "x server crashes with: [drm:i915_gem_mmap_gtt_ioctl] *ERROR* Attempting to mmap a purgeable buffer (affects: 3) (heat: 18)" [High,Triaged] https://launchpad.net/bugs/682712
[18:46] <Sarvatt> but thats lucid?
[18:46] <bryceh> some of the reporters mention maverick
[18:46] <bryceh> although they may be seeing different bugs
[18:47] <Sarvatt> it fixes all of these https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/626967
[18:47] <ubot4`> Launchpad bug 626967 in xserver-xorg-video-intel (Ubuntu) "[arrandale] GPU lockup 85a8ad2d (IPEHR: 0x01820000) (affects: 8) (dups: 20) (heat: 120)" [Medium,Confirmed]
[18:47] <bryceh> Sarvatt, that's a real good sign
[18:47] <Sarvatt> which was fixed by http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=a44a63d2ff6c01c3dc61de6f736dd441ddd25e52
[18:47] <bryceh> ooh
[18:48] <bryceh> Sarvatt, well, a maverick build of that driver would probably help move things forward
[18:48] <bryceh> if that works for the maverick folks, then if apw still needs it on lucid maybe we can look at building it for that too
[18:52] <bryceh> Sarvatt, is that worth considering backporting to maverick?
[18:54] <Sarvatt> yes very much so just haven't had a chance to do it
[18:59] <Sarvatt> apw: oh fun, it looks like some ubuntu specific patch is breaking the boot on this netbook. mainline 2.6.37-rc3 can reboot fine, 2.6.36-1 is the last ubuntu kernel that can reboot
[19:01] <Sarvatt> ahh didn't try 2.6.37-2 or 2.6.37-3, whoops. 2.6.36-1.7 is good though
[19:16] <Sarvatt> bingo, https://lists.ubuntu.com/archives/natty-changes/2010-November/001282.html broke reboot for me
[19:19] <Sarvatt> ah darnit, 2.6.37-4.12 was broken that time, booted the wrong one
[19:20] <Sarvatt> yep 2.6.37-3.11 is bad, 2.6.37-2.10 is good
[19:42] <jewsucanuse> hey sarvatt, is alpha broken on the stable intel/mesa bits for natty?
[19:44] <Sarvatt> not on mine, booting is broken without disabling gfxpayload=keep in grub here though
[19:49] <jewsucanuse> sarvatt: http://paste.ubuntu.com/539524/
[19:49] <jewsucanuse> white boxes and everything
[19:49] <jewsucanuse> i945gm
[19:50] <Sarvatt> have you ever had the touhou game working in wine?
[19:50] <Sarvatt> because i never have had any of them working
[19:50] <jewsucanuse> yes.
[19:50] <Sarvatt> as far back as jaunty
[19:50] <jewsucanuse> if you have dx9 libs installed
[19:52] <jewsucanuse> where are glx settings stored?
[19:53] <Sarvatt> any idea where it stopped working? did it work in maverick?
[19:53] <jewsucanuse> yeah
[19:53] <jewsucanuse> could i downpin to maverick for drivers?
[19:54] <Sarvatt> have you tried changing the orm= options in winetricks to see if it works in one of the others by any chance?
[19:55] <jewsucanuse> yeah
[19:55] <jewsucanuse> backbuffer loads faster
[19:55] <jewsucanuse> still white boxes
[19:56] <jewsucanuse> no textures whatsoever
[19:56] <jewsucanuse> wine 1.3.8
[19:57] <jewsucanuse> glxgears is fine though
[19:57] <jewsucanuse> lemme try 1.2
[20:04] <Sarvatt> what gpu do you have? I can try it with a few mesa versions if its a 945
[20:04] <Sarvatt> [#Comiket](C78) Yousei Daisensou - Touhou 12.8 Sangessei - The Great Fairy Wars.zip ? using an english patch?
[20:04] <jewsucanuse> yeah
[20:06] <jewsucanuse> 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller])
[20:06] <jewsucanuse> need vendor id?
[20:07] <Sarvatt> nope, perfect
[20:07] <Sarvatt> grabbing Great Fairy Wars English Patch v1.1
[20:10] <jewsucanuse> japanese version is messed up too
[20:10] <jewsucanuse> doesn't really matter
[20:13] <jewsucanuse> btw, brb restarting x
[20:15] <Sarvatt> jewsucanuse: well, works out of the box with wine 1.3.8 and mesa 7.10 from git, hm
[20:16] <Sarvatt> heh outside of unity being screwed up http://sarvatt.com/downloads/Screenshot.png
[20:17] <Sarvatt> oh I take that back, I'm using mesa from the archives
[20:17] <erappleman> unity is a mess right now. it can't handle video player windows right.
[20:17] <Sarvatt> 7.9+repack-1ubuntu3
[20:17] <erappleman> they creep upwards.
[20:17] <Sarvatt> this is a 945GSE, it's the same gpu to mesa's eyes
[20:18] <Sarvatt>  i have no dx overrides and no non standard config changes
[20:18] <Sarvatt> do I have to go into the actual game to have it screw up?
[20:18] <erappleman> no
[20:19] <erappleman> lemme screenie
[20:19] <Sarvatt> menus are fine, i'd put it down to a wine config problem
[20:19] <erappleman> i cleared the configs
[20:19] <erappleman> winetricks and wine
[20:20] <Sarvatt> erappleman: do you have vertex shader support on none and unchecked allow pixel shader too?
[20:20] <Sarvatt> mine's set to vista also
[20:21] <erappleman> everything's default
[20:21] <erappleman> http://img593.imageshack.us/img593/5980/screenshotyouseidaisens.png
[20:21] <Sarvatt> http://pastebin.com/fCibRJ76
[20:22] <Sarvatt> hmm
[20:22] <Sarvatt> i've got an idea
[20:23] <Sarvatt> wget -O ~/.drirc http://sarvatt.com/downloads/drirc.txt
[20:23] <erappleman> driconf it?
[20:23] <Sarvatt> driconf cant adjust vblank_mode for dri2, gotta do it manualy
[20:24] <Sarvatt> vblank_mode enabled screwed up with white screens like that with clutter apps for me sometimes and i'm using that, just a long shot
[20:24] <erappleman> dri2 on screen 0?
[20:25] <erappleman> or should it be i915?
[20:25] <Sarvatt> needs to be dri2
[20:25] <Sarvatt> driconf only adjusts the i915 driver and it doesn't work unless its for the dri2 driver
[20:26] <erappleman> Driver "dri2" is not installed or does not support configuration.
[20:26] <Sarvatt> save your ~/.drirc and overwrite it with that one and move it back later if anything
[20:27] <Sarvatt> you adjust other things in there? that could screw it up too
[20:27]  * Sarvatt tries to screw it up
[20:28] <Sarvatt> hmm it doesn't fullscreen for you?
[20:29] <erappleman> it does
[20:30] <erappleman> dri2 is my only drirc entry. doesn't fix it.
[20:30] <Sarvatt> this is slow as heck on this netbook
[20:30] <Sarvatt> you have window borders in that screenshot is why i was asking, theres a checkbox I can't read because no jp support in wine on this thing, maybe that toggles fullscreen
[20:31] <erappleman> 1st option
[20:36] <erappleman> lemme try edgers
[20:38] <erappleman> do i sudo driconf?
[20:40] <Sarvatt> nope that'd only change settings for root and running wine as root screws everything up
[20:47] <Sarvatt> darn gnome classic session is all kinds of screwed up, gnome-panel segfaulting on start
[20:48] <erappleman> unity: fixing what isn't broken
[20:49] <bryceh> Sarvatt, kees was complaining about that yesterday
[20:54] <Sarvatt> erappleman: yeah outside of being horribly slow on an atom cpu it's working fine here with stock natty packages outside of wine 1.3.8 even windowed, I'm stumped
[20:55] <Sarvatt> the error spam from wine is a red herring, I get it all even though it works
[20:56] <erappleman> well, what i'm seeing is what i see whenever alpha channel is broken in the drivers yet doesn't always affect the gnome environment
[20:59] <Sarvatt> ahh enabling stub ARB_occlusion_query and ARB_fragment_shader support trying to break it is what killed the speed
[20:59] <erappleman> lemme try the windows world of goo demo
[20:59] <erappleman> doesn't that force glsl on 945gm?
[20:59] <Sarvatt> yea
[20:59] <Sarvatt> was trying to screw with options to get it to mess up
[21:00] <Sarvatt> thanks for giving me an excuse to play touhou at work btw :)
[21:00] <erappleman> world of goo is screwed up too
[21:00] <erappleman> lemme see native linu
[21:01] <Sarvatt> world of goo native is fine here
[21:01] <erappleman> native is fine here too
[21:02] <erappleman> goo on wine isn't
[21:02] <Sarvatt> hmm, you on amd64?
[21:02] <bryceh> hmm, the wayland mesa fails to build on natty
[21:03] <erappleman> i686
[21:03] <Sarvatt> just a thought that you have old mesa in ia32-libs
[21:03] <Sarvatt> darn
[21:03] <bryceh> nouveau_context.c:132:9: error: too many arguments to function 'nouveau_channel_alloc'
[21:03] <bryceh> /usr/include/nouveau/nouveau_channel.h:51:1: note: declared here
[21:03] <bryceh> make[7]: *** [nouveau_context.o] Error 1
[21:03] <bryceh> http://launchpadlibrarian.net/60063332/buildlog_ubuntu-natty-i386.mesa_7.10.0%2Bgit20101118.3dcc3153-0ubuntu1~bryce9~natty_FAILEDTOBUILD.txt.gz
[21:03] <Sarvatt> yeah need git libdrm
[21:03] <bryceh> look familiar to anyone?  
[21:03] <erappleman> i need the git?
[21:03] <Sarvatt> natty libdrm doesn't have the nouveau stuff from post 2.4.22
[21:03] <bryceh> 2.4.22+git20101127.1443bea4-0ubuntu0sarvatt  new enough?
[21:03] <Sarvatt> erappleman: was talking to bryce sorry
[21:03] <erappleman> ah
[21:04] <Sarvatt> bryceh: yeah
[21:04] <Sarvatt> that already in there?
[21:04] <bryceh> ok thanks
[21:04] <bryceh> I happened to copy it in while waiting for mesa to build :-P
[21:04] <erappleman> what's making nouveau 3d still a no-go? i know it wasn't ready for lucid or maverick, but why not natty?
[21:06] <bryceh> erappleman, upstream is not yet supporting it (no bug reports)
[21:07] <bryceh> erappleman, as well, it feels like something that's going to have a lot of weird random bugs for oddball hardware or strange corner cases, and we're not sure the group of us have the skillz/time for solving them
[21:07] <erappleman> loldebian
[21:07] <bryceh> erappleman, huh?
[21:07] <erappleman> isn't debian our upstream?
[21:08] <bryceh> erappleman, nouveau upstream at fdo
[21:08] <erappleman> oh
[21:09] <bryceh> for Xorg the debian guys prefer us to work directly with X.org upstream if it's issues unrelated to just packaging
[21:18] <erappleman> ah. sarvatt.
[21:18] <erappleman> dx7 works
[21:18] <erappleman> not dx8 or dx9
[21:19] <Sarvatt> how are you changing dx modes?
[21:19] <erappleman> dxdiag in wine
[21:21] <erappleman> BINGO
[21:21] <erappleman> downgraded wine to 1.0.x
[21:21] <erappleman> nice.
[21:28] <Sarvatt> bryceh: ok intel in x-updates, sorry that took so long
[21:31] <bryceh> Sarvatt, awesome thanks
[21:33] <erappleman> thanks sarvatt
[22:29] <Azelphur> Hi I'm having a problem with X crashes, I recently replaced my nvidia 6600GT with a 9500GT, now X has started crashing. I followed the Obtaining backtraces instructions and got a backtrace, which is here http://azelphur.com/crashlog.txt.zip
[22:29] <Azelphur> I had to zip it because it's a pretty large backtrace (17MB)
[22:30] <Azelphur> It looks like libarecord is doing something crazy and recursive that's causing X to crash :s
[22:42] <Sarvatt> Azelphur: guessing you were using nvidia-173 for the 6600GT and left it installed when you switched?
[22:42] <Azelphur> I did originally, then I uninstalled anything to do with nvidia and reinstalled using jockey to ensure I had the right driver
[22:43] <Sarvatt> can ya pastebin the /var/log/Xorg.0.log of it trying to start up?
[22:43] <Azelphur> oh hey, I do have nvidia-173-modaliases
[22:43] <Azelphur> Sarvatt: sorry, it does start up, it just crashes after a few hours
[22:43] <Sarvatt> thats ok, modaliases are needed for jockey to work
[22:43] <Sarvatt> ah
[22:44] <Sarvatt> what version is the nvidia driver and what ubuntu release are you using?
[22:44] <Azelphur> even if the machine is left idle it'll crash all by itself, so I don't think there's anything I'm doing to trigger the crash
[22:44] <Sarvatt> it could be a ton of things, there should be some trace of the crash in /var/log/Xorg.0.log.old
[22:44] <Azelphur> I'm using maverick (specifically mythbuntu) and I'm using nvidia-glx-185
[22:45] <Azelphur> Sarvatt: yea, I checked there and there's literally nothing, which makes it weird
[22:45] <Azelphur> I can only guess that X is crashing before it has a chance to write anything to the log file
[22:45] <Azelphur> well not literally nothing, but nothing related to the crash
[22:46] <Sarvatt> how does it crash?
[22:46] <Sarvatt> screen go blank and not come back? does X restart?
[22:46] <Azelphur> X restarts, so I end up at the login screen
[22:47] <Sarvatt> there should definitely be something in /var/log/Xorg.0.log.old when that happens, hmm
[22:48] <Azelphur> http://pastebin.com/WFiVW0eM
[22:48] <Azelphur> I don't see anything :(
[22:48] <Sarvatt> can ya cat /var/log/Xorg.*.log | pastebinit
[22:48] <Sarvatt> err wait
[22:48] <Azelphur> haha, beat you to it
[22:48] <Sarvatt> cat /var/log/Xorg* | pastebinit
[22:49] <Azelphur> pastebin above is that
[22:49] <Sarvatt> maybe its /var/log/Xorg.1.log.old or something
[22:49] <Azelphur> yea, I did Xorg*
[22:49] <Sarvatt> oh hmm
[22:49] <bryceh> look in /var/log/gdm
[22:50] <Azelphur> bryceh: there's a lot of files in there, anything in particular?
[22:50] <Sarvatt> sudo cat /var/log/gdm/:0* | pastebinit ?
[22:51] <Azelphur> http://pastebin.com/j29tsTbQ
[22:51] <bryceh> Azelphur, usually can pick it out by last change timestamp on the file
[22:52] <Sarvatt> i'm stumped, no traces of you even logging out ever
[22:52] <Azelphur> D:
[22:53] <bryceh> dmesg?
[22:53] <Sarvatt> has it happened since you booted last?
[22:53] <Azelphur> bryceh: nothing, checked that :(
[22:53] <Azelphur> only 4 messages for the entire day, none of them relevant
[22:53] <Azelphur> Sarvatt: yes
[22:53] <Sarvatt> can ya pastebin the dmesg just in case?
[22:54] <Sarvatt> ~/.xsession-errors might be handy too but you might not want to pastebin that in case there is anything sensitive in it
[22:55] <Azelphur> http://pastebin.com/WM8HaB0S got a bit longer since I checked it at 4 lines, but nothing interesting I can see
[22:55] <Azelphur> that's all of today, and it's crashed a few times today
[22:55] <Azelphur> I don't have a ~/.xsession-errors
[22:55] <Azelphur> oh wait derp, logged in as root when I was looking at the gdm folder
[22:56] <Azelphur> http://pastebin.com/dNs0sm53 there's xsession-errors
[22:58] <bryceh> Azelphur, have you tried reinstalling the driver?
[22:58] <Azelphur> bryceh: yes
[22:59] <bryceh> this bit's interesting:
[22:59] <bryceh> #
[22:59] <bryceh> 03/12/2010 19:09:42 Scroll Detection: -scrollcopyrect mode is in effect to
[22:59] <bryceh> #
[22:59] <bryceh> 03/12/2010 19:09:42   use RECORD extension to try to detect scrolling windows
[22:59] <bryceh> #
[22:59] <bryceh> 03/12/2010 19:09:42   (induced by either user keystroke or mouse input).
[22:59] <bryceh> #
[22:59] <bryceh> 03/12/2010 19:09:42   If this yields undesired behavior (poor response, painting
[22:59] <bryceh> #
[22:59] <bryceh> 03/12/2010 19:09:42   errors, etc) it may be disabled via: '-noscr'
[22:59] <bryceh> #
[22:59] <bryceh> 03/12/2010 19:09:42   Also see the -help entry for tuning parameters.
[22:59] <Sarvatt> well I see it crashing there but nothing about why it happened.. are you sure you don't have logout mapped to a button on the remote or something maybe?
[22:59] <bryceh> #
[22:59] <bryceh> 03/12/2010 19:09:42   You can press 3 Alt_L's (Left "Alt" key) in a row to
[22:59] <bryceh> #
[22:59] <bryceh> 03/12/2010 19:09:42   repaint the screen, also see the -fixscreen option for
[23:00] <bryceh> #
[23:00] <bryceh> 03/12/2010 19:09:42   periodic repaints.
[23:00] <bryceh> #
[23:00] <bryceh> 03/12/2010 19:09:42 X FBPM extension not supported.
[23:00] <Azelphur> Sarvatt: nope, as I said I've seen it do it while all input devices where a good 5 meters are from any people :)
[23:02] <bryceh> it'd help to have symbols installed
[23:03] <Azelphur> bryceh: what's the package for the symbols?
[23:04] <bryceh> guessing librecord is capturing some event from a window, then triggering a callback via CallCallbacks, then when that's written to the client it triggers a librecord event
[23:04] <bryceh> but hard to guess without line numbers
[23:05] <bryceh> Azelphur, xserver-xorg-core-dbg maybe
[23:06] <Sarvatt> Azelphur: what's the version of your xserver-xorg-core package?
[23:06] <Azelphur> got that installed, next time it crashes I'll get another backtrace in here :)
[23:07] <Azelphur> Sarvatt: 2:1.9.0-0ubuntu7
[23:07] <Sarvatt> i'm going to go out on a limb and say some part of mythtv uses qt somewhere and you're hitting the bug fixed in maverick-updates
[23:07] <Sarvatt> because you're using xinerama too
[23:07] <Azelphur> mythtv is pretty much entirely qt, so yea...
[23:07] <Sarvatt> Azelphur: ahhh enable maverick-updates
[23:07] <Azelphur> shiny :D
[23:07] <Sarvatt> or is xorg-server not in -updates yet? :(
[23:08] <Sarvatt> xorg-server (2:1.9.0-0ubuntu7.1) maverick-proposed; urgency=low
[23:08] <Sarvatt>   * debian/patches/207_Xext_panoramiXprocs_fix_typo.patch:
[23:08] <Sarvatt>     - This prevents Qt applications from crashing when using
[23:08] <Sarvatt>       Xinerama multi-head with drivers such as nvidia (LP: #650539).
[23:08] <Azelphur> I'm not using xinerama though
[23:08] <Sarvatt> maybe when mythtv crashes because of that it restarts the session in mythbuntu
[23:08] <Azelphur> at least I shouldn't be, it's a single display
[23:08] <Sarvatt> your log said you were I thought
[23:09] <Azelphur> that's odd then, there is only one display
[23:09] <Sarvatt> 03/12/2010 19:09:42 Xinerama is present and active (e.g. multi-head).
[23:09] <Sarvatt> 03/12/2010 19:09:42 Xinerama: number of sub-screens: 1
[23:09] <Sarvatt> 03/12/2010 19:09:42 Xinerama: no blackouts needed (only one sub-screen)
[23:09] <Azelphur> fun, maybe it's an s-video out thing
[23:09] <bryceh> wonky
[23:09] <Azelphur> I have maverick-updates enabled, did you mean maverick-proposed or backports?
[23:10] <Sarvatt> Azelphur: ahh darn, I was hoping it migrated to -updates already :(
[23:10] <Sarvatt> yeah it's in proposed for sure if its not there
[23:11] <Azelphur> ok, got myself on -updates and running an upgrade now, will keep an eye on it and see if it does it again, if it does hopefully I'll have a better backtrace with symbols this time :)
[23:11] <Sarvatt> i'd enable proposed, apt-get update && sudo apt-get dist-upgrade (just to see what packages are offered, hit n) then upgrade the ones you need. should be xserver-xorg-core xserver-xorg-core-dbg xserver-common
[23:12] <Azelphur> I'm cool with -proposed, I use -proposed on my PC anyway
[23:18] <Sarvatt> anyone happen to have a machine using fglrx on natty or maverick handy that could try xorg-edgers? need to know if fglrx works without an xorg.conf with it before trying to push that into natty :)
[23:18] <Sarvatt> nvidia has been working fine for the past week of me trying to break things with no xorg.conf
[23:21] <Sarvatt> would be nice to not have things broken because of the old xorg.conf when people remove nvidia or fglrx outside of jockey
[23:28] <Sarvatt> ugh yeah we need a fixed up libvdpau for 32 bit flash acceleration to work on amd64, it works in debian
[23:29] <Sarvatt> bjsnider: install http://ftp.us.debian.org/debian/pool/main/libv/libvdpau/lib32vdpau1_0.4.1-2_amd64.deb :)
[23:29] <Sarvatt> we can't build that package because ia32-libs is in universe and libvdpau in main..
[23:40] <bryceh> yay, finally no more 8080's in my urls
[23:40] <bryceh> http://www.bryceharrington.org/X/Reports/ubuntu-x-swat/versions-current.html
[23:47] <Sarvatt> huh, how does wine manage to build-dep on ia32-libs yet be on the livecd?
[23:48] <Sarvatt> wine1.2 in universe, wine dummy package in main, hmm
[23:48] <Sarvatt> bryceh: nice, did they open port 80 or did ya fix it another way?
[23:59] <bjsnider> Sarvatt, would that work for 64-bit flash on amd64?
[23:59] <Sarvatt> bjsnider: yea
[23:59] <Sarvatt> err
[23:59] <Sarvatt> no
[23:59] <Sarvatt> no acceleration in the 64 bit flash release
[23:59] <Sarvatt> works for 32 bit flash on amd64 thogh
[23:59] <bjsnider> i don't use that