[00:08] Ng are you using the 2.6.31-rc3 kernel? [00:08] yup [00:08] input modules werent getting frozen on suspend and they were screwing up on resume beforee [08:35] why the heck is this high importance?! [08:35] https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/399559 [08:35] Ubuntu bug 399559 in xserver-xorg-video-ati "ATI Radeon Mobility KMS modeset=1 22% slower than vesa" [High,Incomplete] [10:25] it could probably be reduced [10:32] tjaalton did it an hour ago or so :) [10:33] isn't there something seriously wrong when any driver gets slower than vesa? [10:34] i mean all other drivers are supposed to have GPU-specific features which improve performance among other things, right? [10:43] 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] O_o you mean vesa actually beats them all? [10:44] if that was the case then something should be done shouldn't there? like copying some code from vesa or something =\ [10:46] how about, does gtkperf performance mean anything or is it glxgears for 2d? :D [10:47] ah. ._. [10:52] 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] it's just not something they do in tight loops [10:55] 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] i see [10:56] that maketh much sense. [12:14] http://global.phoronix-test-suite.com/index.php?k=profile&u=robert-14462-8152-19051 [12:15] yay my radio button speed is going down! :D [12:15] Sarvatt, do we expect xrandr to work with kms? [12:16] yep, not working for you? [12:17] not sure. ran tremulous and it left me in 640x480 [12:17] i uses xrandr to go to 1024x768 [12:17] and once there i could not change again [12:19] intel or radeon? [12:19] intel [12:21] downloading it now to see if it happens to me [12:23] i guess i should try changing now, see if its a general issue or not [12:24] worked fine here, thats odd [12:24] hrm ... [12:24] yeah switching back and forth seems to work [12:25] apw@dm$ xrandr -q [12:25] xrandr: output LVDS1 cannot use rotation "normal" reflection "none" [12:25] 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] what does that mean? [12:26] i think it means the driver is confused [12:26] :) [12:26] 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] robert@ubuntu-9{/opt/source/xorg-pkg-tools}:xrandr -q [12:26] xrandr: output LVDS1 cannot use rotation "normal" reflection "none" [12:26] and am getting that poop [12:26] dunno but I get it too! lol [12:26] and now i can't fix it [12:27] anything i can collect before i logout [12:29] apw: just apply the settings in display properties [12:29] resets it [12:29] i didnt change anything, just applied it and its working right again [12:30] ok HOW did it do it when xrandr cannot! [12:30] just hit another bug like that, xrandr command line tool wasnt in sync with the server changes [12:38] 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] Sarvatt, must be something like that [14:14] 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] i get that too, guess its normal [14:18] it used to be alot worse, VT>X would change modes in 1.6.0 even under KMS === mvo__ is now known as mvo [19:28] any idea why karmic gdm just keeps cycling instead of actually coming up? [20:45] Solarion, check your gdm logs [21:09] 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] s/oder/older/ [22:17] Sarvatt: libdrm 2.4.12? [22:18] 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] cool [22:19] it has a big bo cache fix [22:19] which should keep gem object usage waaaay lower than it is today [22:20] already got that commit in there [22:21] and its super nice! [22:21] 71MB gem_objects, 3 days uptime with compiz :D [22:24] cool [22:27] phew, took 2.5 hours to set up a second stage debootstrap of arm karmic on my G1 [22:28] beat qemu by 2 hours at least [22:30] now to compile pixman for no reason [22:40] amazingly, I've almost made it through all the -intel bugs for the first time in a long long time [22:40] just 15 bugs left to upstream [22:40] can i get a clone of Sarvatt for debian? [23:03] 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] dreading packaging all these changes for xserver master in the past few days :( [23:11] yuck, looks like it'll take another 2-3 hours to bring in the build deps for it :D [23:12] hehe [23:37] you're a monster bryce, thats so many bugs! [23:42] * bryce wields broom of bug death [23:45] 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] server 1.6 branch is begging for me to come back to it :) [23:59] i should have just done this in a debian chroot, for some reason karmic is super slow unpacking things on arm