[00:07] <Sarvatt> wow they sure sat on that one, 04_fedora_glx14-swrast.diff just went to xserver master
[00:09] <Sarvatt> vga16fb seems to be always loaded now since 2.6.32-7 though, fbdev should work with that?
[00:09] <Sarvatt> then again i think thats 640x480
[00:23] <Sarvatt> no change adding the and tty-device-added KERNEL=tty7 line back to the gdm upstart conf
[00:23] <bryce> hrm
[00:23] <Sarvatt> (failsafe after fsck)
[00:27] <Sarvatt> the plymouth-desktop transition is really darn nice now though using the lucid kernel
[00:30] <Sarvatt> going to try adding "and stopped udevtrigger" and see if that works for now, i know its the opposite of all this fast boot stuff wants but i'd rather not have failsafe every silent background fsck
[00:31] <bryce> Sarvatt, agreed
[00:32] <Sarvatt> where is PRIMARY_DEVICE_FOR_DISPLAY=1 exported? maybe they could add something similar for FSCK_COMPLETED or something
[00:36] <Sarvatt> switched it to this, lets see if it works like it used to
[00:36] <Sarvatt> start on (filesystem
[00:36] <Sarvatt>           and (graphics-device-added fb0 PRIMARY_DEVICE_FOR_DISPLAY=1
[00:36] <Sarvatt>                or drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1)
[00:36] <Sarvatt>           and stopped udevtrigger
[00:39] <Sarvatt> woohoo it worked
[00:39] <bryce> sweet
[01:08] <Sarvatt> hope i did that right - https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/496796
[03:01] <Sarvatt> dkms: Revert the code that runs DKMS as the user "nobody". -- sweet I can use ccache again! thanks superm1!
[03:04] <superm1> Sarvatt, yeah i really want to fix that so that it doesn't build as root, but dont have a good solution still, so this is the better way to go for now
[03:09] <Sarvatt> it was trying to create a new cache folder for the nobody user before because my /usr/local/(g)cc links to ccache, but i dug myself into that hole :D
[03:15] <superm1> Sarvatt, i might still tweak how this new bulletproof-x stuff for building the modules works.  its a functional solution right now, but has the potential to be racy
[03:40] <Sarvatt> if the upstart job has to build the module, does it just continue to failsafe while it builds?
[03:41] <Sarvatt> i'm looking at it now but not sure because fb0 would probably exist even if it needed to build
[03:43] <Sarvatt> oh i guess it checks if dkms exists every time gdm starts there and checks if it needs to build nvidia or fglrx if so, but the gdm upstart job is already started and exits if it does?
[03:44] <Sarvatt> i really need to read up on all this new upstart stuff :D
[03:46] <bryce> no it shouldn't go into failsafe just because it needs time to build the module
[03:47] <bryce> yeah I need 'upstart for dummies' too
[03:54] <verbalshadow> anyone have problems with ati graphics in the new kernel(ish) 2.6.32.8.8 i get "white scanlines" and the mouse freezes
[04:07] <Sarvatt> ohh i see, i missed the whole failsafe x upstart job in the xorg metapackage tying it all together
[04:16] <Sarvatt> so is it possible build-successful could return true and make gdm start before the graphics-device-added or udev settles I guess?
[04:35] <Sarvatt> startup - filesystem mounted (2.5 seconds in) - (dkms runs upstart job starts here?) - udev starts (6 seconds in) - fb0 initialized to vga16fb (9 seconds in) - (gdm would start here or possibly earlier if dkms upstart returns build-successful?) - nvidia module loading (10-12 seconds in) - udev settles after udevtrigger stops and gdm would start here even if graphics devices werent ready and no dkms was installed (16-24 seconds in)
[04:37] <Sarvatt> any way it could pass build-successful that fast if I'm not misinterpreting it? :D just looking at the timestamps on my nvidia box
[04:49] <superm1> Sarvatt, yeah that's the worry
[04:49] <superm1> either that or it issues build-successful while dkms is checking the status before quiting the gdm job
[04:50] <superm1> i'm going to do a more thorough look at it tomorrow to try to reproduce some of these race conditions
[04:50] <superm1> someone proposed a really novell solution on a bug that i like
[04:50] <superm1> creating a "dummy" job for fglrx and nvidia that starts on starting gdm
[04:57] <superm1> at this point they're all hypothetical anyway
[05:07] <Sarvatt> nvidia sure does load late in the boot process, and takes a full 2 seconds to load here not doing anything else
[05:35] <Sarvatt> a dummy upstart scripts that get installed with nvidia common that just returns true that gdm depends on to start, but an actual upstart script that replaces it installed along with nvidia-kernel-source maybe? :D
[05:54] <tjaalton> bryce: Ron hasn't packaged it yet, said there were still some issues
[06:12] <superm1> Sarvatt, well it would be a dummy script in the sense that all it did was delayed the boot, but yes it would be installed by the equivalent of nvidia-kernel-source
[06:12] <superm1> and fglrx-kernel-source
[07:40] <tjaalton> RAOF: do we still need a nouveau patch on top of 2.4.16? I'd think not, at least not yet
[10:02] <soren> Do we have any clue what is causing bug #494627?
[10:03] <soren> ..and more importantly: Is any sort of fix in sight? :)
[10:08] <tjaalton> soren: no idea.. switching to nouveau probably fixes it ;)
[10:10] <soren> tjaalton: Package description says " Note that these drivers are INCOMPLETE, and are only really useful for testing at this point.
[10:10] <soren> "
[10:10] <soren> Is that still accurate?
[10:10] <soren> ..or can one actually reasonably use them?
[10:10] <tjaalton> I'm not sure where we stand right now
[10:10]  * soren takes it for a spin
[10:10] <tjaalton> the kernel should pull nouveau drm, and the ddx should be updated
[10:11] <soren> The following packages have unmet dependencies: xserver-xorg-video-nouveau: Depends: xserver-xorg-core (>= 2:1.6.2) but it is not going to be installed
[10:11] <soren> :(
[10:11] <tjaalton> yes, it should be rebuilt
[10:11] <tjaalton> to provide video-abi-6
[10:11] <tjaalton> build it in pbuilder, it's not hard ;)
[10:12] <soren> Just as is? No changes?
[10:12] <tjaalton> right
[10:13] <soren> Cool.
[10:13]  * soren does that
[10:14] <soren> tjaalton: Oh, how about the one from xorg-edgers?
[10:14] <tjaalton> don't know about that one
[10:14] <tjaalton> probably has some other deps
[10:15]  * soren feels adventurous
[11:10] <tjaalton> tseliot: also first/last name
[11:10] <tjaalton> and email of course
[11:10] <tseliot> tjaalton: yes, of course
[11:10] <tseliot> tjaalton: I got stuck in the verify your account thing
[11:11] <tjaalton> dunno, been too long since I created mine
[11:13] <tseliot> hehe no wonder the patch caused the build to fail, there was a "static Bool" without a function
[11:13] <tjaalton> oh, a refresh boog?
[11:15] <tseliot> oh, maybe that was meant to be put before XkbDDXCompileKeymapByNames (which has no return type)
[11:16] <tjaalton> check the old version how it looked like
[11:17] <tseliot> yes, I was right
[11:24] <tjaalton> great, if it was that simple :)
[11:26] <tseliot> tjaalton: BTW as regards alioth I was using my username instead of my username-guest to confirm my account
[11:27] <tseliot> I have an account now
[11:27] <tjaalton> great
[11:27] <tjaalton> jcristau: could you add tseliot to pkg-xorg?
[11:28] <tjaalton> tseliot: then check the wikipage on how to get started https://wiki.ubuntu.com/X/GitUsage
[11:28] <tseliot> tjaalton: ok, thanks
[11:29] <tjaalton> lunch->
[11:29] <jcristau> done.
[11:30] <tseliot> thanks
[11:55] <tjaalton> tseliot: once you're done with the patch, feel free to push it :)
[11:58] <tseliot> tjaalton: ok
[12:02] <tseliot> tjaalton: where's the debian/patches directory in git?
[12:02] <tjaalton> tseliot: the same place?
[12:02] <tjaalton> when you cloned it, you'll end up in debian-unstable branch
[12:02] <tjaalton> git checkout -b ubuntu origin/ubuntu
[12:03] <tjaalton> and you are using our branch
[12:03] <tseliot> yes, I did that
[12:04] <tseliot> maybe I used the wrong branch, let me try again
[12:04] <tjaalton> git status will tell you
[12:26] <tseliot> tjaalton: $ git push origin ubuntu
[12:26] <tseliot> fatal: The remote end hung up unexpectedly
[12:27] <tjaalton> check the config
[12:27] <tseliot> shall I add my username in my git file?
[12:27] <tjaalton> depends how you cloned it
[12:27] <tjaalton> .git/config
[12:28] <tjaalton> change the "origin" remote to have an url like "ssh+git://tseliot-guest@git.d.o..."
[12:28] <tseliot> tjaalton: and how do I do that?
[12:28] <tjaalton> edit the file :)
[12:28] <tjaalton> xorg-server/.git/config
[12:30] <tseliot> aah, ok
[12:31] <tseliot> tjaalton: should it be @alioth.debian.org/git/ (as on the wiki page) or @git.debian.org/git/ ?
[12:31] <tjaalton> both work
[12:32] <tseliot> ok
[12:32] <tjaalton> fixed the wiki to point at git.d.o
[12:32] <tseliot> tjaalton: ok, pushed
[12:34] <tjaalton> tseliot: thanks, I'll update the changelog and release
[12:34] <tseliot> oh, I forgot to do that
[12:35] <tjaalton> you can do that as well ;)
[12:35] <tjaalton> change "lucid" to UNRELEASED
[12:36] <tseliot> ok, sure
[12:48] <tseliot> tjaalton: ok, pushed again
[12:49] <tjaalton> tseliot: thanks, I'll release it now
[12:50] <tseliot> tjaalton: thanks for your help
[12:50] <tjaalton> ..and enable the patch too :)
[12:51] <tjaalton> tseliot: btw, if you have time, check patch 135 too if it's similar
[12:51] <tseliot> someone should have had more sleep :-P
[12:51] <tjaalton> anyway, I'll upload this now
[12:51] <tjaalton> hehe
[12:52] <tjaalton> I've enabled it here, will upload now
[12:52] <tjaalton> 190 that is
[12:52] <tseliot> tjaalton: ok, I'll pull your commit from git then
[12:52] <tseliot> and have a look at 135
[12:52] <tjaalton> yes, that's usually the first thing to do, to avoid conflicts
[12:53] <tjaalton> especially when you touch the changelog
[12:55] <tseliot> right
[13:01] <tseliot> tjaalton: pushed?
[13:01] <tjaalton> btw, synaptics is in git as well. maitain it there if you don't mind
[13:01] <tjaalton> yes
[13:01] <tseliot> ok, sure
[13:01] <tjaalton> damn typos
[13:01] <tseliot> git rebase origin/ubuntu
[13:01] <tseliot> Current branch ubuntu is up to date.
[13:01] <tjaalton> git pull
[13:02] <tseliot> oh, right
[13:02] <tjaalton> rebase is kinda dangerous
[13:02] <tjaalton> uh
[13:02] <tjaalton> it's on wiki
[13:02] <tseliot> git pull = bzr pull
[13:03] <tseliot> yes, it's what I'm following
[13:03]  * tseliot -> lunch
[13:03] <tjaalton> I should probably add a git fetch there
[13:04] <tjaalton> although pull does mostly the same
[14:10] <tseliot> tjaalton: who did write patch 135?
[14:10] <tseliot> as Signed-off-by != Author
[14:15] <tjaalton> tseliot: bryce, according to the changelog
[14:28]  * tseliot 's new radeon HD4670 has just arrived
[14:28] <tseliot> \o/
[14:28] <tjaalton> with loud fans? :)
[14:29] <tseliot> it says "arctic cooling: Cool and silent"
[14:29] <tseliot> we'll see to what degree this is true
[14:30] <tjaalton> wow, that's humongous
[14:31] <tseliot> yes, it's a fan with a graphics card attached
[14:31] <tjaalton> radeon drm doesn't support proper power management yet, so the fans are always on full blast
[14:31] <tjaalton> hehe
[14:32] <tjaalton> I'm thinking of getting a passively cooled HD3xxx
[14:32] <tseliot> didn't Matthew Garret worked on power saving?
[14:32] <tjaalton> to replace the GF8600GT
[14:32] <tseliot> usually I don't get cards with fans
[14:32] <tjaalton> yes, but I'm not sure how far the support is
[14:32] <tseliot> AMD sent me this card for testing though
[14:32] <tjaalton> that's a motivator to work on it ;)
[14:34] <tseliot> absolutely
[17:55] <apw> bryce_, just a heads up that i have enabled ATI Radeon KMS again as discussed
[18:01] <tjaalton> apw: what's the status with nouveau?
[18:02] <apw> tjaalton, "near the top of my list" for review of how we can integrate it
[18:04] <tjaalton> apw: you probably know that it's going to land in .33, so pulling straight from there is probably easiest
[18:04] <apw> yeah know its in there, hope so yes
[18:10] <bryce__> apw, excellent
[18:11] <apw> bryce__, you heard of anyone complaining that they don't get nvidia output unless they supply 'nomodeset' on the kernel command line?
[18:11] <apw> unexpected i know, given there is no KMS for nvidia at the moment
[18:12] <bryce__> hmm on nvidia...
[18:12] <bryce__> apw, sarvatt was mussing with this yesterday in fact
[18:12]  * bryce__ reviews scrollback
[18:13] <bryce__> the specific issue he was chasing was https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/496796
[18:13] <apw> bryce__, yeah nvidia, i thought it most odd but they seemed to have confirmed the behaviour
[18:14] <bryce__> not sure that's exactly the issue you're looking for though
[18:14] <apw> hrm, i have suspicious he has filed a bug on the subject which is why i know about it
[18:15] <bryce__> oh wait, maybe that was against an intel chip
[18:15] <tjaalton> it was
[18:16] <bryce__> apw, in any case, that is the main bug I'm seeing people mention right now in regards to kms problems
[18:16] <apw> nothing till they say nomodeset, then all working
[18:16] <bryce__> apw, I haven't been looking at -nvidia bugs much though
[18:17] <tjaalton> well, -nv seems bust anyway
[18:17] <tjaalton> bug 494627
[20:27] <tormod> I had an X crash and back on vt1 I saw that things I had been typing in Terminal and Firefox had been echoed there. does that ring a bell for anyone? I vaguely remember some bug could cause this, something not deattached when switching vt for X or so. upstart?
[20:30] <tormod> btw, this was a clean install from the 20091215.1 iso (onto a USB stick)
[20:32] <bryce__> tormod, you're maybe thinking of that evdev bug we had a while ago
[20:32] <tormod> gdm 2.26.1-0ubuntu5 changelog mentions 81_initial_server_on_vt7.patch which could be something like this
[20:35] <tormod> bryce__, I was not able to find anything like this in the evdev changelog. do you remember when this was?
[20:37] <bryce__> there might have been a security thingee on it
[20:38] <tormod> yeah I could read a couple of my passwords on the console :)
[20:38] <bryce__> maybe jaunty?
[20:39] <bryce__> kees, do you remember a bug where keyboard strokes leaked through from X to the console?
[20:41] <bryce__> aha!!
[20:41] <tormod> evdev 1:2.0.99.3-1 mentions "to make sure the console is set to RAW mode.", related?
[20:41] <bryce__> xserver-xorg-input-evdev (1:2.0.99+git20080912-0ubuntu2) intrepid; urgency=low
[20:41] <bryce__>   * 101_evdev-close-fd.patch: Fix issue where keystrokes on tty can "leak"
[20:41] <bryce__>     into the X session after vt switch, due to an fd still being open.
[20:41] <bryce__>     (LP: #276887)
[20:41] <bryce__>  -- Bryce Harrington <bryce@ubuntu.com>  Fri, 03 Oct 2008 13:52:36 -0700
[20:41] <tjaalton> yes
[20:42] <tormod> hmm why is this not in the packaged changelog.Debian.gz?
[20:42] <tjaalton> because it was synced since
[20:43] <bryce__> http://changelogs.ubuntu.com/changelogs/pool/main/x/xserver-xorg-input-evdev/xserver-xorg-input-evdev_2.0.99+git20080912-0ubuntu5/changelog
[20:43] <tormod> tjaalton, but it has some ubuntu versions?
[20:43] <tjaalton> that has been upstream for a long time
[20:43] <tormod> the Debian package was based on Ubuntu one?
[20:44] <tjaalton> yes
[20:45] <tormod> anyway, thanks! this was the bug I had in the back of my head somewhere
[20:47] <tormod> but why would I get something like this now? I can try to boot into it again and look at Xorg's fd's
[20:47] <bryce__> watch lsof maybe?
[20:50] <tormod> I'll try. I did not switch VT myself in this case, but of course the was the initial switch.
[20:53] <tormod> ls -l /proc/`pidof X`/fd/ should do the job I think
[20:56] <kees> bryce__: yeah, it was evdev (you found it, sorry for the late reply)
[20:58] <tjaalton> doesn't leak here
[21:13] <tormod> seems like I easily ends up with two X servers, on :0 and :1
[21:13] <tormod> if i type in wrong password, gdm restarts
[21:14] <tormod> and then I have two servers. Additionally switching consoles makes for hang or panic. note I am on radeon, not intel :)
[21:19] <tormod> what's strange is that ps shows failsafe on :0 and normal on :1, but Xorg.{0,1}.log indicates the opposite
[21:20] <bryce> hmm
[21:21] <bryce> failsafe should be writing to Xorg.failsafe.log, not to a 0 or 1 log
[21:21] <tormod> I wonder if it's only me. anyone else tried a fresh install todayish?
[21:21] <bryce> I upgraded to current on my laptop a few hours ago and it rebooted ok
[21:21] <bryce> but not a fresh install
[21:22] <tormod> my main install (upgraded since karmic a2) is fine
[21:22] <superm1> bryce, keybuk indicated that this and/or case for startup of an upstart script is buggy
[21:22] <superm1> so that might be whats causing it
[21:22] <superm1> he wanted to back out all of my changes with upstart dkms etc
[21:23] <superm1> so  probably should back out the stuff to failsafe-x too
[21:25] <bryce> superm1, ok, what's the plan to solve the root cause issue?
[21:26] <tormod> bryce, ok I have Xorg.failsafe.log too, but Xorg.1.log had VESA stuff
[21:26] <bryce> hrm, this patch 135 rework is thorny
[21:26] <superm1> bryce, no more building modules during boot
[21:26] <bryce> tormod, if failsafeX is putting stuff into Xorg.1.log that sounds maybe like a bug
[21:26] <tjaalton> bryce: btw, probably we could renumber some of the patches, like the ones that are never going upstream
[21:26] <bryce> tjaalton, not a bad idea
[21:27] <superm1> which i still dont know how much i agree with, it was a very good last defense for problems
[21:27] <tjaalton> bryce: so that one should be close to 100 :)
[21:27] <bryce> tjaalton, do you think I should try sending it upstream?  I assume they'll just reject it.
[21:27] <superm1> but dkms has grown an apport package hook at least now that will allow users to file bugs on modules that fail to build
[21:28] <bryce> tjaalton, but then they do always say we don't send them feature development work, so...
[21:28] <tjaalton> bryce: I don't actually know how useful it is without apport, so can't tell
[21:28] <bryce> superm1, no building modules during boot - so will be built pre-boot all the time?
[21:29] <tjaalton> but it sounds like it could be useful.. so why not try?
[21:29] <superm1> bryce, yeah that's the idea
[21:29] <superm1> that's how they are supposed to work anyway Today already too
[21:29] <bryce> superm1, well I would favor such an approach, seems less fragile.  Key is to ensure it has really good error handling
[21:30] <superm1> well i'm thinking the error handling should be superb now, the problem is the order people install things for whether the autoinstall hook gets called for different kernels
[21:30] <tjaalton> bryce: also, to fix the driver autoconfiguration to work even when there is a conffile present would probably be valued highly upstream ;)
[21:30] <bryce> let's just hope keybuk doesn't get it in his head to speed up installation/upgrade time ;-)
[21:30] <superm1> lol
[21:31] <bryce> tjaalton, yeah on my todo list
[21:31] <tjaalton> bryce: it also touches this dkms stuff, so if something goes wrong, it should still be able to fall back to the free driver
[21:31] <tjaalton> but it's just.. work :)
[21:36] <superm1> touches what dkms stuff?
[21:37] <tjaalton> superm1: well, the idea that if there is no module available, it should still manage to get X up
[21:37] <tjaalton> or was that referring to the nvidia renam stuff
[21:37] <tjaalton> rename
[21:38] <superm1> well at least get X up in failsafe mode
[21:38] <bryce> tjaalton, if you can write up your thoughts on how the driver autoconfig stuff should work, I'll look into coding it over the holidays
[21:38] <superm1> is this that patch that i tried with you at UDS bryce ?
[21:39] <bryce> superm1, that's the one
[21:39] <superm1> sweet.  didn't it look like the main problem with it was just like a missing ;; or something?
[21:40] <tjaalton> bryce: sure. jcristau even had some ideas how to implement it
[21:41] <bryce> superm1, was missing an else.  but tjaalton's ideas are to go a bit beyond that and generalize a bit further so it works in a wider range of circumstances whether xorg.conf is there or not
[21:41] <superm1> bryce, ah very good.
[21:41] <tjaalton> bryce: also, if you've followed xorg-devel, dan has posted patches to add support for xorg.conf.d-directory, where packages can install config snippets for the drivers etc
[21:42] <superm1> bryce, something else to be cognizant of, i think that fglrx has some other demands that it wants in "xorg.conf" still other than just the driver name
[21:42] <tjaalton> and the udev backend probably will drop support for adding options in the rules files, because there should be just one place to configure things
[21:42] <tjaalton> to avoid the fdi mess
[21:43] <superm1> so if those were identified sooner rather than later, can try to ask AMD to genericize more
[21:43] <tjaalton> superm1: with the xorg.conf.d thing it would be trivial. just add some options in a file and ship it with the package
[21:43] <superm1> ah yeah, good point
[21:44] <tjaalton> like in /usr/lib/xorg/xorg.conf.d
[21:44] <bryce> heh, would you guys mind putting this into a wiki page or a bug?  I'll never remember all this :-)
[21:44] <tjaalton> sure (again..)
[21:44] <bryce> a page under wiki.ubuntu.com/X/Blueprints/ might make sense
[21:45] <bryce> or a bug report might be easier
[21:45] <tjaalton> I'll write it down after giving it some thought, and when there's time for it
[21:45] <tjaalton> the code has not been merged to master yet, so no rush
[21:46] <tjaalton> but it's something that sysadmins will learn to like
[21:46] <tjaalton> so fits lucid perfectly
[21:46] <tjaalton> (if it'll all work out :)
[21:49] <bryce> tjaalton, thanks
[21:54] <RAOF> tjaalton: No, we don't need any nouveau patches on top of libdrm 2.4.16
[21:57] <tjaalton> RAOF: yeah, I noticed that the current version didn't carry any either
[21:57] <tjaalton> 2.4.16 is waiting in git
[21:57] <tjaalton> it was rejected from debian for some copyright issues, but that shouldn't stop us from distibuting it I guess :)
[21:58] <tjaalton> nothing too serious, should just list all copyright holders in there
[22:01] <superm1> good, libvdpau finally landed in lucid today
[22:05] <pwnguin> "VDPAU (Video Decode and Presentation API for Unix) is an open source library (libvdpau) and API designed by NVIDIA originally for its GeForce 8 series and later GPU hardware"
[22:05] <pwnguin> originally? that mean my 6600gt is supported?
[22:06] <superm1> no, that means Geforce 8 and later
[22:09] <RAOF> It means that you can use it get at any vdpau implementation, as far as I understand it.
[22:10] <bjsnider> pwnguin, look up the purevideo wikipedia page and it has a chart of supported chips
[22:13] <superm1> right, the NVIDIA vdpau implementation only supports geforce 8 and newer.  a third party implementation can support far more likely
[22:14] <pwnguin> The original PureVideo engine was introduced with the GeForce 6 series.
[22:14] <pwnguin> quoth wikipedia
[22:15] <pwnguin> im guessing the one in multiverse is 8 series or higher, being official nvidia and all
[22:15] <superm1> it shouldnt be in multiverse, it should be in universe
[22:16] <superm1> the library isn't the implementation, it dlopens the implementation which is in restricted
[22:16] <bjsnider> yes but the first version didn't do much to help the cause
[22:16] <bjsnider> the pv 2-4 versions have basically all of the heavy lifting on the gpu
[22:16] <pwnguin> everything i see is in restricted/multiverse
[22:17] <RAOF> A 3rd party implementation could be build on top of an essentially-arbitrary 3D engine; I think someone plans to extend the xvmc gallium state tracker to support vdpau (or possibly VA-API or whatever ATI uses).
[22:17] <superm1> bug 497185
[22:17] <bjsnider> someone aways plans to do stuff
[22:18] <RAOF> True.  I think this is a somewhat more concrete plan than the space elevator, though.
[22:18] <pwnguin> well, thank goodness for low hurdles
[22:19] <RAOF> :)
[22:19] <pwnguin> i guess this is a sign i need to upgrade
[22:21] <bjsnider> yes, it takes your cpu down to 5%
[22:21] <bjsnider> mine has never gotten above 5% no matter the bitrate or frame size of the video
[22:21] <pwnguin> monitor's dying, system's noisy, and i cant play ridiclusly high res video smoothly
[22:22] <pwnguin> however, i just dropped this months play money on a phone
[22:33] <tjaalton> pwnguin: and that was money well spent ;)
[22:35] <bjsnider> yeah, there aren't enough phones in this world
[22:38] <tjaalton> I was referring to the brand & model :)
[22:44] <pwnguin> to relate the phone to Ubuntu X, is there a recomended set of input keys for media remotes?
[22:57] <bryce> I've rewritten the rethrow_signals patch
[22:57] <bryce> I think it'll be less bitrotty the way I've redone it