[00:01] <tormod> (I love that Firefox tells me it is an OLD file.)
[00:04] <tormod> virtuald: would you mind reporting it on bugs.freedesktop.org ?
[00:05] <tormod> virtuald: you should try to get a "full backtrace", see https://wiki.ubuntu.com/X/Backtracing
[00:10] <virtuald> i really should sleep
[01:01] <virtuald> lets try something
[02:30] <virtuald> https://bugs.freedesktop.org/show_bug.cgi?id=21535
[14:13] <mnemo> bryce: ping?
[19:11] <mnemo> is this supposed to work or am I doing something wrong? --> https://bugs.launchpad.net/xserver-xorg-video-intel/+bug/371774
[19:22] <Duke`> I have the same issue
[19:23] <Duke`> but I read somewhere that there was some things to setup with kernel modules before it could work
[19:23] <mnemo> ah, can you try to find the url again?
[19:23] <mnemo> i really would like to try out kms
[19:26] <Sarvatt> debian fixed that in initramfs-tools
[19:26] <Sarvatt> if you're building your own kernel, just enable KMS by default and boot with nomodeset when you dont want to use it
[19:27] <Duke`> mnemo: I searched about it few days ago, and I don't really remember, but it has to do with initramfs yes
[19:27] <Sarvatt> it works fine on the ubuntu 2.6.30-2-3-generic just by adding options i915 modeset=1 to /etc/modprobe.d/whatever.conf
[19:27] <Duke`> Sarvatt: or by adding i915.modeset=1 to kernel parameter line, in grub/menu.lst?
[19:28] <Sarvatt> no that doesnt work until initramfs-tools gets updated..
[19:28] <Sarvatt> at least for me
[19:28] <mnemo> Sarvatt: so how can I try it today on ubuntu?
[19:30] <Sarvatt> install 2.6.30-2-3, sudo nano /etc/modprobe.d/i915.conf
[19:30] <Sarvatt> options i915 modeset=1
[19:30] <Sarvatt> put that in it, and reboot
[19:31] <mnemo> Sarvatt: thanks man
[19:31] <Sarvatt> or you can just build KMS by default in your own kernel
[19:31] <Sarvatt> and if you dont want to use it for some reason boot with nomodeset on the grub command line
[19:32] <mnemo> i also found this --> http://wiki.debian.org/KernelModesetting
[19:32] <mnemo> would it be sufficient to run this:
[19:32] <mnemo> update-initramfs -k `uname -r` -u
[19:32] <mnemo> or do I need a new kernel for sure?
[19:32] <Sarvatt> that just rebuilds an initramfs..
[19:32] <mnemo> ok
[19:33] <Sarvatt> ah sorry just opened it up
[19:33] <Sarvatt> I'm pretty sure that requires the updated initramfs-tools
[19:34] <mnemo> ok, well I guess they have that in debian then
[19:34] <Sarvatt> http://git.debian.org/?p=kernel/initramfs-tools.git;a=summary
[19:34] <Sarvatt> we're on 0.92
[19:35] <mnemo> right and we need this commit? --> http://git.debian.org/?p=kernel/initramfs-tools.git;a=commit;h=652423c6f5b636f95899254aba213d417caff158
[19:38] <Sarvatt> dont think thats it, have you tried whats on that wiki? that might end up working without any updates
[19:39] <mnemo> i'll try it
[19:39] <Sarvatt> it didnt work for me last i tried it but that was in jaunary, i've been enabling KMS by default every kernel since
[19:43] <mnemo> well it sort of worked actually
[19:43] <mnemo> it brings up gdm and X in 4:3 on my widescreen
[19:44] <mnemo> if I vt switch to F1 then I get graphics corruption
[19:44] <mnemo> then if I go back to CTRL-ALT-F7 it goes back to normal again
[19:47] <Sarvatt> ah nice, sorry about that, i saw the update in initramfs-tools but didnt actually read what it did lol
[19:47] <Sarvatt> well not nice you get VT corruption
[19:48] <Sarvatt> what intel packages are you using?
[19:48] <mnemo> x-updates
[19:48] <Sarvatt> try xorg-edgers, there were a bunch of fixes for that since 2.7.0
[19:48] <mnemo> ah good idea
[19:53] <Sarvatt> get the drm too if you arent adding the repo, one of the post 2.4.9 libdrm updates was related to VT corruption
[19:53] <mnemo> ok
[19:56] <Sarvatt> the latest libdrm/mesa/-intel stack on edgers is a real winner for me, i havent been able to use UXA stable since december until 3 days ago
[19:59] <mnemo> in jaunty final UXA is better than EXA for me (on G45)... in EXA glxgears leaves repaint dirt when you move the window and also EXA is slower etc
[20:00] <mnemo> Sarvatt: whats the difference between drm-snapshot "2.4.9+git20090502.68103b27-0ubuntu0sarvatt" and the one with "r1" in the version number?
[20:01] <mnemo> wait, one of them is for karmic...
[20:01] <mnemo> is that the only difference then?
[20:01] <Sarvatt> get the karmic one if you're on karmic, the jaunty one replaces linux-libc-dev drm headers because jaunty has old ones
[20:02] <mnemo> ok
[20:05] <Sarvatt> exa is 2x faster than UXA for me on a 945GME, theres no more EXA though now in intel drivers :( UXA used to crash whenever I used firefox or ran glxgears in the background of another app
[20:05] <Sarvatt> thats just glxgears speed though, actual 3d benchmarks arent that much different at all
[20:06] <Duke`> Sarvatt: but you fixed your problem with glxgears/firefox/UXA, right?
[20:06] <Sarvatt> yup!
[20:08] <Sarvatt> plus mesa 7.6 gets me 120fps more in glxgears in uxa vs 7.4.1, 7.4.x really was a dud lol
[20:09] <mnemo> nice
[20:14] <bryce> Sarvatt: glxgears?
[20:16] <Sarvatt> yeah I know, just swap buffer performance :D openarena went up 7 FPS too
[20:19] <bryce> ah, good
[20:20] <Sarvatt> the 120fps glxgears increase is a more than 50% increase for me is why I was saying its good
[20:34] <bryce> yeah, but even increases in glxgears numbers does not always correlate with better performance
[20:34] <bryce> and decreases don't always correlate with reduced performance
[20:34] <bryce> I should just disable the fps output of that command
[20:34] <mnemo> we should give people a real benchmarking tool which is as easy to use as glxgears
[20:35]  * bryce nods
[20:35] <bryce> I would think games would be easy enough...
[20:38] <mnemo> different commands to enable FPS printing in different games... also different levels have different complexity etc so its less comparable... 
[20:38] <bryce> true
[20:38] <mnemo> it should be super repeatable... and it should have windows version so we can benchmark against that later on
[20:38] <bryce> phoronix?
[20:38] <bryce> what's 'windows'?
[20:39] <mnemo> I mean we should benchmark our progress compared to Windows 7 drivers etc
[20:39] <mnemo> the target needs to be to beat them of course
[20:40] <mnemo> phoronix is a good step forward, but I'd like something simpler, more repeatable still..
[20:41] <mnemo> Sarvatt: vt switch gives me corruption on 2.6.99 as well :( and I did the full xorg-egers so I got the libdrm fix as well I guess
[20:46] <Sarvatt> dang, was worth a shot at least.
[20:46] <albert23> mnemo: do you have the fbcon module loaded?
[20:47] <mnemo> albert23: no why do you wonder? I got these loaded --> http://pastebin.com/f6c4707c7
[20:47] <albert23> mnemo: then make sure to load fbcon
[20:48] <mnemo> ok thanks I will try it
[20:52] <bryce> uff, heh, just ran into another report of performance change evidenced only by glxgears numbers
[20:53] <bryce> k, that's gotta go.
[20:59] <bryce> gone
[21:01] <bryce> heya michaellarabel
[21:01] <michaellarabel> Hi bryce
[21:10] <mnemo> i threw in fbcon in /etc/modules now and it works... I get a KMS vt on CTRL-ALT-F1 ... however, a few seconds after that xorg SEGV'd --> http://pastebin.com/m72073d94
[21:11] <bryce> mnemo: dunno, a full backtrace would be more interesting
[21:12] <bryce> not sure what aperture space is, but sounds like it doesn't have enough of it or something
[21:12] <mnemo> aperture is the memory that intel shares with the CPU i think
[21:13] <mnemo> anyway, I will see if I can repro this and file a good bug on it
[21:13] <bryce> thanks
[21:13] <mnemo> bryce: it would be neat with an official guide on how to test KMS on ubuntu... right now I felt like I did some stuff without really understanding what I was doing... so im not entirely sure its "supposed" to work on this config
[21:13] <bryce> mnemo: btw, I notice a lot of people use ppracer as a second choice for fps measurements... think that's more sane?
[21:14] <bryce> maybe we could just recommend that to everyone, to get more consistent measurements
[21:14] <mnemo> bryce: oh, i've never tried that.. sounds better than glxgears though
[21:14] <mnemo> yea
[21:14] <bryce> mnemo: yes, that's a really good idea, would you be willing to help me draft it?
[21:14] <tormod> yey -ati finally has exa by default upstream!
[21:14] <mnemo> bryce: sure.. I will post it mailing list later
[21:15] <bryce> ok cool, I'll figure out a good spot in the wiki to put it
[21:16] <tormod> ppracer? I tried etracer and it was much slower - I guess it uses more features
[21:18] <bryce> what's etracer?
[21:19] <bryce> ultimately I suspect we may really need multiple tools that exercise different aspects of performance
[21:19] <bryce> but coding such a thing is well beyond my time availability
[21:19] <jcristau> "when you're bored with ppracer, use OA"
[21:21] <mnemo> "[note: this is an automated message] dear bug reporter, please collect 10 fish in tuxracer and then attach your xorg.log to this bug report. thank you."
[21:22] <bryce> :-)
[21:23] <tormod> etracer = extreme tux racer, next generation of planet penguin racer
[21:23] <tormod> I think ppracer has stalled, and only etracer is worked on
[21:23] <bryce> wonder if it'd be feasible to automate the 10 fish collection
[21:23] <mnemo> :)
[21:23] <bryce> does ppracer have a benchmark mode?  I know some games have that, and it'd make results more comparable
[21:24] <bryce> tormod: actually that's good... if we're going to use it for benchmarking we don't want the fps to improve just because of game code changes
[21:25] <tormod> bryce: true. just that etracer makes the driver/card work harder (I think)
[21:36] <michaellarabel> bryce: ppracer isn't much of a good test since it will not build on x86_64 and has other problems
[21:38] <jcristau> not build on x86_64?
[21:38] <michaellarabel> IIRC, the last released version of ppracer will not build on x86_64 or had other x86_64 issues.
[21:39] <jcristau> sounds fixable..
[21:39] <michaellarabel> true, though etracer seems to replace ppracer and that has proper x86_64 support.
[21:50] <bryce> hmm, I was able to install and launch it on amd64
[21:50] <bryce> although I wouldn't say it worked.  also messed up dual-head.  but it played music and stuff
[21:51] <jcristau> libsdl probably talks xf86vidmode, which doesn't quite like randr.
[21:52] <bryce> someone really ought to fix that ;-)
[21:53] <michaellarabel> World of Padman is one of my favorite tests that uses ioquake3 and works with the current Mesa stack.
[21:53] <bryce> michaellarabel: short of phoronix, do you know of a simple glxgears-class tool/game/test people could run?
[21:54] <pwnguin> bryce: what are you looking to indicate?
[21:54] <pwnguin> relative 3d performance?
[21:54] <pwnguin> or just the presence of accelleration at all?
[21:54] <michaellarabel> There's lots of good ones... On Jaunty you can just do: sudo apt-get install phoronix-test-suite and experiment :) say then, phoronix-test-suite benchmark ioquake3-games to see how well all of the different ioquake3 games run
[21:55] <bryce> pwnguin: relative 3d perf
[21:55] <pwnguin> ioquake3 is at least a close approximation of modern games usage
[21:55] <pwnguin> ie, has textures
[21:55] <pwnguin> and geometry
[21:55] <Sarvatt> something short would probably be good, darn openarena benchmark takes a good 10 minutes per run
[21:56] <bryce> yeah, I imagine the users we need to convert have an attention span of maybe 30 sec
[21:56] <pwnguin> you'd be surprised
[21:57] <pwnguin> windows gamers slave over framerates
[21:57] <Sarvatt> well it runs 3 times by default in phoronix so it adds up :D
[21:57] <bryce> ok, certainly they're obsessive...
[21:57] <michaellarabel> Sarvatt: It runs multiple times in PTS for accuracy
[21:57] <pwnguin> 3dmark takes easily 10 minutes
[22:01] <michaellarabel> Unigine Tropics is beautiful, but good luck getting that to work with Mesa.
[23:14] <virtuald> note to self: monitors didn't wake standby, gdm showed flying donuts after reboot
[23:31] <wgrant> jcristau: Did you notice that the xserver-xorg-input-synaptics source was auto-decrufted from unstable a week after you uploaded it?
[23:31] <jcristau> wgrant: i didn't, but dato did. there's an ftp.d.o bug about that.
[23:32] <jcristau> bugs.debian.org/526078
[23:32] <wgrant> jcristau: Thanks. That had me very confused for a while.
[23:33]  * jcristau just pinged that bug
[23:33] <jcristau> thanks for the reminder :)
[23:33] <wgrant> jcristau: I'm glad you finally did the rename.
[23:35] <jcristau> we just got xf86-video-omapfb to compensate for taht
[23:35] <jcristau> that, even
[23:36] <wgrant> Heh.