[00:06] <rickspencer3> bryceh, I'm installing Sauerbrten right now
[00:06] <bryceh> hmm, with current lucid bits, I'm seeing a [drm:drm_mode_getfb] *ERROR* invalid framebuffer id and some garbage. 
[00:06] <bryceh> rickspencer3, ok
[00:06] <rickspencer3> *the* definitive graphics stress test
[00:06] <bryceh> hah
[00:06] <bryceh> it's a good one
[00:08] <BUGabundo> eheh
[00:08] <RAOF> How are we with the work-items for nouveau?  In particular, what can we do about nouveau-firmware?
[00:09] <BUGabundo> it really pushes my laptop to its limits
[00:09]  * bryceh uninstalls plymouth and eliminates the fb id issue
[00:09] <BUGabundo> bryceh: :D
[00:09] <BUGabundo> half of lucid test users, will end up without it :D
[00:09] <bryceh> RAOF, I think the kernel team intends to obsolete nouveau-firmware with the generator thingee upstream is doing
[00:10] <bryceh> I don't know if it's at the top of their todo list at the moment though, but it might be good to remind them if they don't get to it in the next few weeks
[00:11] <RAOF> Ok, but that's not going to land before A3 :).  I've been tracking it in #nouveau, though, and it looks like mwk's making progress.
[00:11] <bryceh> RAOF, in the meantime I agree we should add it as a dependency, although I'm not sure exactly where
[00:12] <bryceh> RAOF, I need to read your email more closely
[00:12] <bryceh> RAOF, does it need to be a kernel-level dependency?  If so then I suggest we bring it to apw and sconklin and let them decide
[00:13] <RAOF> nouveau-firmware?  It pretty much is a kernel-level dependency, in that the kernel module shipped in lbm-nouveau wants the firmware.
[00:14] <superm1> why not just put it in lbm-nouveau for now then and pull it out when it's time to go?
[00:14] <superm1> would keep things far simpler without needing to obsolete the package
[00:15] <RAOF> One reason might be it's uncertain licensing, but it *would* be simpler it it were just shipped in lbm-nouveau.
[00:17] <superm1> what's this generator thing that upstream is working on?  it generates it on the fly for the HW?
[00:18] <RAOF> Yes.
[00:18] <RAOF> They're presume that's how the blob does it, too.
[00:18] <superm1> what's it generating it from then?  the VBIOS?
[00:19] <RAOF> From primitive operations & a description of the actual card hardware, I think.
[00:19] <RAOF> There's already a voodoo generator for nv4x, which is why my laptop doesn't need the nouveau-firmware package.
[00:19] <superm1> so then where did the firmware that exists today actually come from?
[00:20] <RAOF> MMIO traces of the binary blob.  It's a dump of how the binary driver initialises the card.
[00:20] <superm1> yucky
[00:20] <RAOF> Hence “uncertain licensing”
[00:20] <superm1> so more importantly, what's the HW do w/o that firmware in place then?
[00:21] <RAOF> It's not quite firmware.  It is really a small GPU program that's run on context switches.
[00:21] <RAOF> So, without the voodoo you don't get context switches, which means you don't get any acceleration.
[00:23] <superm1> so not the end of the world, just fairly inconvenient
[00:23] <RAOF> Yeah.
[00:23] <RAOF> It interacts badly with the fact that nv5x+ chips don't expose a linear framebuffer, though, which means that CPU fallback is quite a lot slower.
[00:24] <RAOF> So nouveau needs to read VRAM, unswizzle the bits, do the CPU fallback, reswizzle, then push back to VRAM.
[00:28] <RAOF> Current status of the voodoo generator for nvAx cards appears to be “[In quake 3] depending on place in the level where you're standing, and the direction you're looking, you can get anything from perfect display, through textures replaced with pink, up to totally bogus geometry”
[00:57] <rickspencer3> bryceh, so, this is totally subjective, but saurbraten seems smoother and more stable in Lucid
[00:57] <rickspencer3> I suppose that's mostly -intel
[00:59] <bryceh> nice
[00:59] <bryceh> there has been some performance work done with -intel
[01:00] <rickspencer3> bryceh, yeah, I'll really test it out this weekend when I have more than 10 mins ;)
[01:30] <RAOF> tseliot's done a bang-up job on making the binary nvidia driver work nicely - Enabling & Disabling nvidia in Hardware Drivers just works.
[01:32] <bryceh> sweet
[01:47] <RAOF> Sarvatt: Your xorg-edgers mesa packages don't actually build nouveau's gallium driver because you've misspelt “--enable-gallium-nouveau” - you've got “--enable-nouveau-gallium”.
[01:48]  * Sarvatt slaps forehead
[01:49] <Sarvatt> uploaded a fixed one just now
[01:49] <Sarvatt> sorry about that
[01:51] <Sarvatt> was just that last upload with the problem, ran into some problems with the rules and did it by hand
[01:51] <RAOF> You can make it up to me by telling me about how you build those packages, so I can fix it myself next time :).  I understand that there's a script that you run to automate the package uploads.
[01:52] <Sarvatt> do you have auto-xorg-git?
[01:53] <Sarvatt> ./auto-xorg-git -H hooks -g -d origin/ubuntu -p mesa -a 0ubuntu0sarvatt is what I use for mesa, I need to update the hooks though in bzr
[01:53] <RAOF> Where's auto-xorg-git?
[01:54] <Sarvatt> i'll update xorg-pkg-tools in bzr now
[01:54] <Sarvatt> https://code.edge.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools
[01:59] <snap-l> Having some problems with an Intel card and a new load of Karmic
[01:59] <snap-l> The graphics for programs like Nexuiz and Stellarium are corrupted
[01:59] <snap-l> Nexuiz won't display other players/ floors, etc. intermittently
[02:00] <snap-l> Stellarium displays the toolbars with some fuzzed out look (like some memory corruption).
[02:01] <snap-l> Any thoughts on how I can get 3D working properly on this machine?
[02:03] <snap-l> It's an Asus K60I with an Intel® Graphics Media Accelerator 4500M
[02:04] <snap-l> 32 bit load of Ubuntu 9.10. Seems to be using the i915 driver
[02:13] <RAOF> snap-l: Hm.  I've got the same chipset, but on Lucid, and I haven't noticed any corruption.
[02:13] <RAOF> That said, I'm not the most demanding of 3D users.
[02:13] <snap-l> Yeah, Compiz works just fine, but this is a bit strange
[02:13] <snap-l> it seems like anything that requires several layers of textures gets messed up
[02:14] <snap-l> Not sure if it's memory allocation or something else.
[02:15] <Sarvatt> RAOF: for the nouveau ddx I use ./auto-xorg-git -H hooks -t + -g -d origin/ubuntu -a 0ubuntu0sarvatt nouveau    mesa: ./auto-xorg-git -H hooks -g -d origin/ubuntu -p mesa -a 0ubuntu0sarvatt
[02:15] <RAOF> There have been any number of fixes to the Intel drivers in Lucid; you might want to try an alpha 3 livecd in a couple of days to see if it's fixed there.
[02:15] <Sarvatt> anything with a + in the changelog is something i do by hand
[02:16] <RAOF> Sarvatt: Ta.  I should probably make it so that the xorg-edgers nouveau DDX contains the driver date; it's a useful piece of debugging information.
[02:16] <RAOF> Also, nouveau gallium works again on nv4x, modulo crazy update slowness.
[02:18] <Sarvatt> i have to disable that snapshot date patch because you try to patch configure that doesnt exist after a git checkout, it clones then patches then runs autoreconf after the patching
[02:19] <RAOF> Oooh, and wobbly works, too!
[02:22] <RAOF> I think that you should actually be able to apply that patch now.  Why don't I check? :)
[02:23] <Sarvatt> comment out the line in hooks/xserver-xorg-video-nouveau.prepatch
[02:24] <Sarvatt> actually just drop the -H hooks line from it completely
[02:24] <Sarvatt> that patch removal is the only hook
[02:25] <Sarvatt>  ./auto-xorg-git -t + -g -d origin/ubuntu -a 0ubuntu0raof nouveau would work :)
[02:27] <RAOF> Bah.  No, of course it doesn't just work.  In fact, it'd be wrong, wouldn't it?
[02:27] <RAOF> What actually needs to happen is to run get-orig-source and import that...
[02:34] <Sarvatt> could just run the script with the hook, let it build then reenable the patch in the series and debuild -S -sa again
[02:36] <Sarvatt> i'll just do that next time i update it
[02:37] <RAOF> I was thinking of running get-orig-source in the prepatch hook, git-import-orig'ing it, and then letting it do it's funky thing.
[02:37] <RAOF> Also, nouveau gallium is awesome until compiz stops updating the screen.
[02:40] <bjsnider> i wonder if the nvidia drivers are really working as well on lucid as you think RAOF 
[02:41] <Sarvatt> hmm maybe try toggling the unredirect fullscreen windows option RAOF?
[02:41] <bjsnider> there are loads of complaints all day in +1
[02:41] <RAOF> bjsnider: And when I followed up with one of them, they'd manually installed the drivers from the nvidia website and broken everything.
[02:41] <bjsnider> hahahaa
[02:41] <bjsnider> you're kidding
[02:42] <bjsnider> are you kidding?
[02:42] <RAOF> Well, no.  They had, at one point in the recent past manually installed the drivers from nvidia.com.
[02:42] <bjsnider> but you'd have to remove jockey for that
[02:42] <RAOF> Do you?
[02:42] <RAOF> Why?
[02:42] <bjsnider> you'd have to remove ubuntu-desktop
[02:42] <RAOF> Do you?  Why?
[02:43] <bjsnider> because jockey blocks the nvidia installer
[02:43] <Sarvatt> jockey is optional :)
[02:43] <bjsnider> jockey isn't part of ubuntu-desktop?
[02:43] <Sarvatt> nope, i dont have it installed and ubuntu-desktop is installed
[02:44] <bjsnider> somehow i automatically associate everything on a default system with a metapackage
[02:44] <bjsnider> it's on a default system anyway
[02:45] <RAOF> Jockey blocks the nvidia installer?  AWESOME.
[02:45]  * Sarvatt would love a ncurses jockey he could actually use
[02:46] <bjsnider> what about the guy who said the 195 driver is crashing his rig every few minutes? what about all of the people who say they've lost opengl?
[02:46] <Sarvatt> most of the problems are from nvidia.com or installing PPA versions and screwing things up from what i see
[02:46] <RAOF> I guess that upgrades might be broken?  But my best guess would be Sarvatt's, yeah.
[02:47] <bjsnider> can someone go over to that channel and explain that? these complaints are getting annoying
[02:48] <bjsnider> all issues with jockey not being able to activate the appropriate alternatives are solved right?
[02:50] <Sarvatt> yep, i did see a bug earlier where someone was upgrading from hardy-lucid and didn't have a new enough dpkg to set up the alternatives though
[02:58] <Sarvatt> bryceh: we're going to get those record extension patches in the next xserver update already
[03:00] <Sarvatt> just a heads up they'll be obsoleted with the next merge from debian, they'll be on 1.7 branch next point release (i think friday)
[03:02] <Sarvatt> i've been watching that bug for a few weeks getting ready to pounce on it when they hit, just went on server-1.7-nominations 2 hours ago
[03:05] <bjsnider> Sarvatt, you're going to pounce on a defenseless little bug?
[03:12] <Sarvatt> bjsnider: are you using the blob right now? can you tell me the number returned from xlsclients | wc -l if so?
[03:14] <bjsnider> not on lucid, no
[03:14] <bjsnider> on karmic it's 22
[03:17] <Sarvatt> was just wondering how the heck BUGabundo had >256 the other day
[03:34] <bryceh> Sarvatt, ok no prob, just wanted to ensure the patch didn't get dropped
[03:35] <bryceh> oh there's another 1.7 point release in the works?  nice
[03:45] <Sarvatt> wonder how much space we could save on the cd dropping some dri drivers that arent even usable like sis and mach64, they're about 2.3MB each
[03:46] <bjsnider> Sarvatt, a guy in +1 just left a list of things the nvidia-installer left behind: http://paste.ubuntu.com/382004/
[03:46] <bjsnider> fascinating
[03:46] <Sarvatt> so he didnt even run the installer with --uninstall then...?
[03:46] <bjsnider> i'm not sure
[03:47] <bjsnider> but it leaves stuff behind even if you do
[03:47] <Sarvatt> i think its --uninstall anyway, --help tells you the uninstall command
[03:47] <bjsnider> and now mysteriously his lucid system has no opengl
[03:47] <Sarvatt> it deletes that stuff when i use the uninstaller
[03:47] <bjsnider> gee, i wonder why...
[03:47] <Sarvatt> heck, i think its actually called nvidia-uninstall
[03:47] <Sarvatt> installs a progam called that i mean
[03:48] <bjsnider> do you trust it?
[03:48] <Sarvatt> another case of pebkac if he didnt run that :)
[03:48] <Sarvatt> yeah i use it all the time
[03:48] <bjsnider> of course these people could say they uninstalled it whent hey really didn't
[03:49] <Sarvatt> i've always used them straight from nvidia.com instead of using ppa ones, one of the reasons i dont like having an alternative installed in mesa :)
[03:49] <bjsnider> if you don't know enough to use the uninstaller between drivers, should you be using the nvidia-installer?
[03:50] <Sarvatt> i think the nvidia.com installers should work again once libgl is moved back to /usr/lib though
[04:55]  * bryceh flushes xserver-xorg-video-nv bugs
[04:55]  * bryceh ker-puuushes
[04:58] <RAOF> Whoop!  Whoop!
[05:00] <bryceh> allgone
[05:05] <RAOF> What is occasionally killing X when I press enter?
[05:05] <RAOF> Is that plymouth attacking me *again*?
[05:12] <bryceh> yep
[05:13] <RAOF> Argh.
[05:13] <RAOF> Next question: what's causing evolution-data-server to consume a core!  It's a non-stop cavalcade of fun1
[05:14] <bryceh> nfi
[05:14] <bryceh> maybe ask on #ubuntu-desktop once seb128 is online
[05:15] <RAOF> I'll see if there's anything obvious in gdb first.
[06:35] <bryceh> interesting, when I try forcing fbdev to load via xorg.conf I get lots of lines like this:
[06:35] <bryceh> (EE) FBDEV(0): FBIOPUTCMAP: Invalid argument
[07:29] <alkisg> I installed Lucid a while ago, and the -pae kernel was automatically selected for me. On some updates the non-pae kernel was pulled in, so I now have both of them installed. The problem is that I can't uninstall the non-pae kernel, without removing xorg:
[07:29] <alkisg> sudo LANG=en_US.UTF-8 apt-get purge linux-image-2.6.32-14-generic
[07:29] <alkisg> The following packages will be REMOVED:
[07:29] <alkisg>   linux-backports-modules-nouveau-2.6.32-14-generic* linux-backports-modules-nouveau-lucid-generic* linux-image-2.6.32-14-generic* xserver-xorg-video-all*  xserver-xorg-video-nouveau*
[07:29] <alkisg> Is that problem caused by the nouveau driver?
[07:30] <RAOF> bryceh (should have) fixed that with the most recent xserver-xorg-video-nouveau updload.
[07:31] <alkisg> Ah thanks, let me try to update, I haven't updated in the last 2 days...
[07:50] <bryceh> yeah alkisg let me know if it does not fix it
[07:50] <alkisg> bryceh: thanks, I think it's not published yet, so I'll wait until it does and give some feedback then.
[07:58] <kklimonda> hmm, my laptop doesn't wake up from sleep anymore.. damn
[07:58] <kklimonda> how can I get some informations?
[08:05] <alkisg> kklimonda: I've read this a while ago, maybe it could help you: https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume
[08:14] <kklimonda> alkisg: thanks - I'll probably wait till a3 is released and try it on the fresh system
[08:32] <alkisg> BTW, would anyone care to help me troubleshoot nouveau? It doesn't work for me, I have a laptop with 8600 GT M.
[08:37] <bryceh> hmm, to -intel 2.10 or not -intel 2.10
[08:37] <bryceh> tjaalton, any strong opinions?
[08:38] <tjaalton> bryceh: no, haven't tried it myself
[08:38] <tjaalton> but maybe it's more tested against the .33 drm
[08:38] <tjaalton> dunno
[08:39] <bryceh> ok.  I don't know of pressing issues impelling us to 2.10, but since it drops UMS I'm hesistant to go with it.  Hard to make a firm decision though.
[15:10] <tseliot> bryceh: a colleague reported that -sharevts + rootless X causes X to crash with Ctrl-C (it works fine without that paramter)
[15:11] <jcristau> means the vt is not put in raw mode
[15:11] <jcristau> (also i assume by rootless you don't mean rootless, but euid != 0)
[15:13] <tseliot> rootless as in run without root privileges
[16:35] <bryceh> tseliot, filed a bug?
[16:35] <tseliot> bryceh: nope
[16:37] <jcristau> tseliot: see hw/xfree8/os-support/linux/lnx_init.c.  we only set RAW mode if (!ShareVTs).  my guess is, whoever owns the vt should do that.
[16:48] <tseliot> jcristau: ok, thanks
[16:49] <tseliot> bryceh: do you mind if I fix bug #467490?
[16:50] <bryceh> tseliot, sure feel free to reassign
[16:50] <tseliot> ok
[17:14] <Sarvatt> RAOF: you're getting the sigquit when pressing enter after first boot problem?
[17:15] <jcristau> Sarvatt: i've seen a sigquit report on bugzilla a few days ago... #26689
[17:18] <tjaalton> fdo bug 26689
[17:18] <tjaalton> i'm lazy :)
[17:19] <tjaalton> bah
[17:19] <Sarvatt> http://bugs.freedesktop.org/show_bug.cgi?id=26689
[17:19] <tjaalton> freedesktop bug 26689
[17:19] <tjaalton> yeah
[17:21] <Sarvatt> RAOF: can you compile this and load it before hitting enter and reproducing it? http://sarvatt.com/downloads/trace-signal.c
[17:25] <Sarvatt>  touch Makefile ; make obj-m=trace-signal.o -C /lib/modules/`uname -r`/build M=`pwd` modules    will compile it
[17:27] <Sarvatt> wonder if gentoo is using plymouth too, that'd rule that out if not.. it didn't happen without plymouth here before and I cant reproduce it at all anymore even with plymouth :( the majority of people hitting the bug are using the blob though
[17:32] <Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=22679
[17:35] <Sarvatt> OsSigHandler (signo=3 there too, thread on it here http://www.mail-archive.com/xorg@lists.freedesktop.org/msg07782.html
[17:37] <jcristau> oh, i'd forgotten about that threa
[17:37] <jcristau> d
[18:59] <_stink_> hey folks.  i'm trying to debug an X driver using the gdb info here: http://www.x.org/wiki/Development/Documentation/ServerDebugging
[18:59] <_stink_> the problem is that X never really starts using this driver.
[18:59] <_stink_> how can i still hook gdb in if X doesn't stay running, but crashes during the startup procedure?
[19:00] <_stink_> fwiw, it's kind of an obscure driver, and not one that's widely used or anything.
[19:00] <_stink_> so i'm not reporting a huge bug or anything. :D
[19:01] <jcristau> if you're lucky you can start X from gdb
[19:01] <jcristau> otherwise, get X to dump core, and run gdb on that
[19:02] <_stink_> jcristau: thanks!
[19:03] <_stink_> i should be using something other than startx to start it if i'm invoking from gdb, right?
[19:11] <_stink_> looks like xinit is what i want
[20:55] <baptistemm> hi there, do you need other information for https://bugs.edge.launchpad.net/ubuntu/+source/xorg/+bug/526662
[20:58] <jcristau> yes.  need a reliable way to reproduce.
[20:59] <baptistemm> jcristau, that's the problem ...
[20:59] <jcristau> because afaik 1.7.5 has all the existing fixes in this area, so if you still have issues there then you need to tell us how to reproduce, or give us a patch
[21:00] <baptistemm> chrisccoulson, ^^ you said this afternoon some bits could be missing, and you had a patch
[21:05] <chrisccoulson> baptistemm, jcristau, yeah, i think i might know what happens there. baptistemm, do you see the screen dim first (if you're on battery)?
[21:05] <chrisccoulson> i'll discuss it in a bit though
[21:05] <chrisccoulson> i'm busy with other things atm
[21:05] <baptistemm> yeah, not a problem
[21:07] <bjsnider> RAOF, is docky using xrender or opengl?
[21:14] <chrisccoulson> baptistemm, jcristau, see gnome bug 609720 for the remaining race i found in gpm
[21:14] <chrisccoulson> we committed a patch to fix it, but it actually caused more issues
[21:14] <chrisccoulson> so it's been reverted again for now
[21:14] <baptistemm> chrisccoulson, thanks a lot
[21:14] <chrisccoulson> baptistemm, i'm not saying for certain that's your issue, but i can occasionally hit that issue
[21:15] <baptistemm> chrisccoulson, should I reopen the bug as the patch was reverted
[21:15] <chrisccoulson> baptistemm, please do. that's on my list of things to look at soon
[21:29] <jcristau> hrm, there's http://bugs.freedesktop.org/show_bug.cgi?id=26469 which might be related, i guess?
[21:41] <chrisccoulson> jcristau, that's possibly related
[21:41] <chrisccoulson> although less exposed now, as gnome-screensaver doesn't directly rely on the idletime counter now
[21:42] <chrisccoulson> although, thinking about it, gpm only registers a single alarm anyway
[21:45] <RAOF> bjsnider: docky is using cairo, which is using xrender.
[21:45] <bjsnider> RAOF, understood, sir
[21:46] <Sarvatt> bryceh: looks like 2.9.1 with some way to selectively disable KMS by default on 8xx is the way to go. can you think of an easier way to implement that logic outside of patching the kernel? a kernel patch to do it wouldn't be that hard if not I'm pretty sure
[21:48] <bryceh> Sarvatt, "that logic" == blacklisting kms on 8xx?
[21:48] <bryceh> yeah apw has talked about that but I don't know the implementation details of how that's done
[21:48] <Sarvatt> yeah using modeset=0 just on specific pci id ranges
[21:48] <bryceh> right, I think we need to mindmeld with apw and sconklin about that
[21:49] <bryceh> but yeah I'm also getting more and more certain about 2.9.1 rather than 2.10
[22:18] <RAOF> Sarvatt: X died just as I was building trace-signal on my first boot; I've upgraded, rebooted, insmoded, and will drop you dmesg when X does it's swandive.
[22:19]  * BUGabundo comments nouveua PPA
[22:19] <BUGabundo> are you serious?
[22:19] <BUGabundo> I was about to upgrade
[22:19] <Sarvatt> if it didnt happen the first time you pressed enter it probably wont happen this boot RAOF, no need to leave it modprobed
[22:19] <Sarvatt> everything in xorg-edgers/nouveau is already in lucid BUGabundo 
[22:19] <Sarvatt> i'm curious how fbdev over inteldrmfb works for 8xx people
[22:20] <BUGabundo> Sarvatt: so where's the 3D?
[22:20] <Sarvatt> xorg-edgers/ppa
[22:20] <Sarvatt> if we did ship 2.10 and 8xx isnt fixed, can we just provide say a xserver-xorg-video-intel-legacy with 2.9.1 that has a modprobe.d conf with options i915 modeset=0?
[22:22] <BUGabundo> Sarvatt: did that nvidia settings got updated?
[22:22] <BUGabundo> so I can test that comand you told me to improve speed of nvidia blob
[22:22] <Sarvatt> no i have no idea if thats why, that option doesnt work if your card isnt new enough anyway so that might be why
[22:23] <BUGabundo> 8400mG
[22:23] <BUGabundo> 2 yo
[22:23] <RAOF> Sarvatt: Aaaand there it goes!  Crash when I pressed enter to say “It doesn't always crash on the first press of enter” :)
[22:23] <Sarvatt> i think only G96+ supports the stuff, GT200+ and some older things like 8200 integrated and ion
[22:24] <BUGabundo> Sarvatt: I think mine is g85 or older
[22:26] <Sarvatt> RAOF: got the dmesg output when it sigquit?
[22:26] <RAOF> Sarvatt: Have an (unfortunately trunkated) dmesg: http://paste.ubuntu.com/382574/
[22:28] <Sarvatt> ok its in there at line 1599 at least, looks the same as that fdo bug :(
[22:28] <RAOF> The rest made it into syslog, so if you'd like (much, much!) more context, I can fish it out of there.
[22:30] <bryceh> Sarvatt, re: splitting out a -legacy intel driver yeah that's an option.  honestly though, looking through the changelog for 2.10 most of it is code deletions.  There's the Xv stuff which is new, and a few random things that might be bug fixes
[22:31] <Sarvatt> bryceh: http://sarvatt.com/downloads/patches/103_increase_idgng_stride.patch http://sarvatt.com/downloads/patches/102_disable_bo_reuse_on_shadowfb.patch  2 backports from 2.10+ that I saw that would  be relevant on 2.9.1
[22:32] <bryceh> ok
[22:47] <Sarvatt> hmm src/libplybootsplash/ply-terminal.c is screwing with the tty
[23:24] <apachelogger> hullos
[23:24] <apachelogger> could someone help me debug a problem with xsetroot?
[23:24] <Sarvatt> i'm guessing theres something racy, and ply_terminal_set_buffered_input (around line 196 of src/libplybootsplash/ply-terminal.c) is sometimes not getting the original term attributes and resetting the ISIG flag on X's VT so the enter key (0x1c) becomes the quit character (0x1c)
[23:24] <apachelogger> or at least I think it is because of xsetroot :D
[23:41] <Sarvatt> hmm http://suse-moblin.com/obs-status/Moblin:Factory/aaa_base/aaa_base-bootsplash.patch