[00:08] <Sarvatt> Ng are you using the 2.6.31-rc3 kernel?
[00:08] <Ng> yup
[00:08] <Sarvatt> input modules werent getting frozen on suspend and they were screwing up on resume beforee
[08:35] <Sarvatt> why the heck is this high importance?!
[08:35] <Sarvatt> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/399559
[10:25] <bryce> it could probably be reduced
[10:32] <Ng> tjaalton did it an hour ago or so :)
[10:33] <hyperair> isn't there something seriously wrong when any driver gets slower than vesa?
[10:34] <hyperair> i mean all other drivers are supposed to have GPU-specific features which improve performance among other things, right?
[10:43] <Sarvatt> i think the question is more, is there a card made in the past 10 years with a recent ddx that is faster than vesa at gtkperf?
[10:44] <hyperair> O_o you mean vesa actually beats them all?
[10:44] <hyperair> if that was the case then something should be done shouldn't there? like copying some code from vesa or something =\
[10:46] <Sarvatt> how about, does gtkperf performance mean anything or is it glxgears for 2d? :D
[10:47] <hyperair> ah. ._.
[10:52] <Ng> glxgears isn't a useful test of anything, gtkperf tests the performance of rendering gtk widgets, which is something that desktops do do, right? :)
[10:53] <Ng> it's just not something they do in tight loops
[10:55] <jcristau> hyperair: if you accelerate some stuff, but not everything, you sometimes have fallbacks.  and falling back once in a while is enough to make performance worse than an all-software thing.
[10:56] <hyperair> i see
[10:56] <hyperair> that maketh much sense.
[12:14] <Sarvatt> http://global.phoronix-test-suite.com/index.php?k=profile&u=robert-14462-8152-19051
[12:15] <Sarvatt> yay my radio button speed is going down! :D
[12:15] <apw> Sarvatt, do we expect xrandr to work with kms?
[12:16] <Sarvatt> yep, not working for you?
[12:17] <apw> not sure.  ran tremulous and it left me in 640x480
[12:17] <apw> i uses xrandr to go to 1024x768
[12:17] <apw> and once there i could not change again
[12:19] <Sarvatt> intel or radeon?
[12:19] <apw> intel
[12:21] <Sarvatt> downloading it now to see if it happens to me
[12:23] <apw> i guess i should try changing now, see if its a general issue or not
[12:24] <Sarvatt> worked fine here, thats odd
[12:24] <apw> hrm ...
[12:24] <apw> yeah switching back and forth seems to work
[12:25] <apw> apw@dm$ xrandr -q
[12:25] <apw> xrandr: output LVDS1 cannot use rotation "normal" reflection "none"
[12:25] <Sarvatt> i didnt do anything, just started it and it went to 640x480 then joined a game and quit and it went back to 1024x600
[12:25] <apw> what does that mean?
[12:26] <jcristau> i think it means the driver is confused
[12:26] <jcristau> :)
[12:26] <apw> i just ran extreme tux racer and on quit i am in some other mode, not the one i am meant to be in
[12:26] <Sarvatt> robert@ubuntu-9{/opt/source/xorg-pkg-tools}:xrandr -q
[12:26] <Sarvatt> xrandr: output LVDS1 cannot use rotation "normal" reflection "none"
[12:26] <apw> and am getting that poop
[12:26] <Sarvatt> dunno but I get it too! lol
[12:26] <apw> and now i can't fix it
[12:27] <apw> anything i can collect before i logout
[12:29] <Sarvatt> apw: just apply the settings in display properties
[12:29] <Sarvatt> resets it
[12:29] <Sarvatt> i didnt change anything, just applied it and its working right again
[12:30] <apw> ok HOW did it do it when xrandr cannot!
[12:30] <Sarvatt> just hit another bug like that, xrandr command line tool wasnt in sync with the server changes
[12:38] <Sarvatt> guess theres no reflection property in KMS and the game sets the value on exit and confuses xrandr?
[12:38]  * Sarvatt has no idea
[14:13] <apw> Sarvatt, must be something like that
[14:14] <apw> Sarvatt, when i VT swtich back to X under KMS the screen comes back nice and fast, all there, and then X redraws it all and it all flashes nastily, is that nromal
[14:18] <Sarvatt> i get that too, guess its normal
[14:18] <Sarvatt> it used to be alot worse, VT>X would change modes in 1.6.0 even under KMS
[19:28] <Solarion> any idea why karmic gdm just keeps cycling instead of actually coming up?
[20:45] <bryce> Solarion, check your gdm logs
[21:09] <fishor> hallo all, did any one has some problem with tadays intel driver on gm915 graphic? xorg on my latop goin to resart loop.  workaround is to install oder one.
[21:09] <fishor> s/oder/older/
[22:17] <jbarnes> Sarvatt: libdrm 2.4.12?
[22:18] <Sarvatt> havent updated it because it was just a version bump with no changes since the last one. will do it in a bit, in the middle of setting up a pc now
[22:19] <jbarnes> cool
[22:19] <jbarnes> it has a big bo cache fix
[22:19] <jbarnes> which should keep gem object usage waaaay lower than it is today
[22:20] <Sarvatt> already got that commit in there
[22:21] <Sarvatt> and its super nice!
[22:21] <Sarvatt> 71MB gem_objects, 3 days uptime with compiz :D
[22:24] <jbarnes> cool
[22:27] <Sarvatt> phew, took 2.5 hours to set up a second stage debootstrap of arm karmic on my G1
[22:28] <Sarvatt> beat qemu by 2 hours at least
[22:30] <Sarvatt> now to compile pixman for no reason
[22:40] <bryce> amazingly, I've almost made it through all the -intel bugs for the first time in a long long time
[22:40] <bryce> just 15 bugs left to upstream
[22:40] <jcristau> can i get a clone of Sarvatt for debian?
[23:03] <Sarvatt> what do you mean? i doubt i packaged it right, i am still very new to things but heres the changelog https://edge.launchpad.net/~sarvatt/+archive/xorg-testing/+sourcepub/676434/+listing-archive-extra
[23:03] <Sarvatt> dreading packaging all these changes for xserver master in the past few days :(
[23:11] <Sarvatt> yuck, looks like it'll take another 2-3 hours to bring in the build deps for it :D
[23:12] <jcristau> hehe
[23:37] <Sarvatt> you're a monster bryce, thats so many bugs!
[23:42]  * bryce wields broom of bug death
[23:45] <Sarvatt> ugh, i dont even know where to start. inputproto libxi libX11 xextproto libXext fixesproto libXtst renderproto and still have to rebuild all video drivers except vesa intel and ati. whee! :)
[23:47] <Sarvatt> server 1.6 branch is begging for me to come back to it :)
[23:59] <Sarvatt> i should have just done this in a debian chroot, for some reason karmic is super slow unpacking things on arm