[06:54] <A|i> when i enable compiz, i don't see: Option "Composite" "Enable", in my xorg.conf?
[06:54] <A|i> (ati radeon 9600, ubuntu 9.04, xorg driver)
[06:56] <Duke`> check in Xorg.0.log for COMPOSITE
[06:57] <A|i> Duke`, maybe zorg 7.4 doesn't need that?
[06:59] <Duke`> this option is probably automatically enabled, look in your Xorg.0.log
[06:59] <A|i> Duke`, thanks, it is
[06:59] <Duke`> it's the case for intel
[06:59] <A|i> Duke`, i have very slow scrolling in firefox though
[06:59] <tjaalton> hasn't been needed for a long time
[07:00] <A|i> i tried Option "MigrationHeuristic" "greedy", but scroll is not smooth at all
[07:34] <tjaalton> A|i: dunno, maybe the upcoming xserver 1.6.2 might help with exa performance
[07:34] <A|i> tjaalton, any idea when is it due to?
[07:37] <tjaalton> this week, but not coming to 9.04
[07:38] <A|i> tjaalton, so we have to wait for 9.10?
[07:38] <tjaalton> although it'll likely end up in a ppa where you can install it from
[12:44] <tjaalton> bryce: what do you think if failsafe would be reworked to just move the conffile out of the way if it causes trouble? the server handles fallbacks in that case anyway
[12:47] <jcristau> tjaalton: can you file a debian bug for this fdi thing?
[12:50] <tjaalton> jcristau: I can "forward" the ubuntu bug, there's the proper explanation about it
[12:51] <tjaalton> jcristau: also, if xserver-xorg postinst for some reason fails to restart hal, the configuration fails.. maybe it should continue regardless?
[12:52] <jcristau> why would hal restart fail?
[12:53] <seb128> does it makes a difference?
[12:53] <tjaalton> I don't know, but for instance in bug 393948 it happened to someone
[12:54] <seb128> it happened on the buildds yesterday too, sysfs was used or something
[12:54] <seb128> +not
[12:54] <jcristau> on buildds invoke-rc.d should be a nop
[12:54] <seb128> in any case package installs should be robust, there is no reason an upgrade should break if a service doesn't start
[13:04] <tjaalton> jcristau: bug sent
[13:04] <tjaalton> now tennis ->
[13:16] <jcristau> tjaalton: btw i sent a [vac] message to d-private, as i'll be busy with rl stuff for the next months
[15:36] <tjaalton> jcristau: oh, I guess congrats are in order then ;)
[15:38] <jcristau> hmm?
[15:39] <jcristau> if you're thinking child, then no.  just need to write my phd thesis, and i can't do that and maintain X in debian at the same time :)
[15:41] <tjaalton> no I mean taking some time off, for whatever the reason :)
[15:41] <jcristau> hah
[15:55] <jcristau> tjaalton: it's not really time off :)
[16:30] <tjaalton> jcristau: 
[16:30] <tjaalton> uh
[16:31] <tjaalton> jcristau: I know.. I need to get cracking with my master's next month
[18:03] <bryce> tjaalton, with failsafe x, maybe we ought to re-analyze what situations it is actually useful for
[18:04] <bryce> tjaalton, like, if it is to get around driver bugs, then moving xorg.conf aside would not help much, but if it is mainly for goofed up xorg.conf syntax, then yeah
[18:09] <tjaalton> bryce: right
[18:10] <tjaalton> I don't know if the fallbacks work in the first scenario
[18:11] <tjaalton> although I believe they should
[18:11] <tjaalton> and in that case failsafe would be suited for the second scenario
[18:15] <Ng> how much do we care about 2.6.31 producing an i915 related oops immediately on booting?
[18:15] <tjaalton> not much
[18:15] <tjaalton> :)
[18:15] <tjaalton> happens here too
[18:15] <tjaalton> probably best wait for rc2
[18:15] <Ng> yeah I figured a first upload would be a bit rough :)
[18:16] <tjaalton> also, once X tries to start, the driver says "no modes"
[18:16] <tjaalton> and fails there
[18:16] <tjaalton> kms works though
[18:17] <Ng> mine didn't even get as far as kms, it was just right after grub it exploded
[18:25] <tjaalton> did you wait long enough?
[18:25] <tjaalton> my boot takes several minutes
[20:20] <Sarvatt> hmm i've been getting alot of these errors during boot since somewhere around 2.6.30-git11 and it makes my touchpad get detected as a generic mouse until i rmmod psmouse/modprobe psmouse atkbd.c: Spurious NAK on isa0060/serio0. Some program might be trying access hardware directly.
[20:21] <Sarvatt> happens like every third boot
[20:21] <maxb> Sarvatt: I'm getting occasional misdetection of my touchpad too, but I don't think I've seen those errors, do I need to turn up some debugging level somewhere?
[20:22] <maxb> oh, no, I'm just unobservant - I *do* get that error
[20:22] <Sarvatt> time to dig through kernel.org bugzilla to see if theres anything about it
[20:24] <maxb> Don't know if this helps at all, but I've seen two different failure modes: sometimes detected as "PS/2 Generic Mouse", other times detected as "PS/2 Synaptics TouchPad" NB not "SynPS/2" which is what it's supposed to be, and is on a good boot
[20:24] <maxb> For me it's happening only 1 in 10 boots or so
[20:27] <Sarvatt> ah hah
[20:27] <Sarvatt> are you on a netbook too maxb?
[20:27] <Sarvatt> http://git.kernel.org/?p=linux/kernel/git/dtor/input.git;a=blobdiff;f=drivers/input/serio/i8042-x86ia64io.h;h=924e8ed7f2cf777f5d48767c18d5618027c031e6;hp=fb8a3cd3ffd0ab4685e8e68f5f14b07068266b94;hb=9230ccb1071d2d7e4ecb6314e67203b9f7f08140;hpb=eef3e4cab72eaf5345e3c73b2975c194a714f6cd
[20:27] <Sarvatt> crap, that is matching Acer as well as AOA150 DMI's
[20:27] <Sarvatt> I'm using the gateway bios so mine shows as Gateway AOA150
[20:28] <Sarvatt> going to send him an email
[20:36] <maxb> Mine's an Acer AOA150
[20:36] <Sarvatt> that explains it
[20:36] <Sarvatt> it'll be fixed by that commit
[20:36] <Sarvatt> not in linus' tree yet though
[20:37] <maxb> Weird thing is that I only ever noticed this problem starting from 2.6.30-10
[20:44] <Sarvatt> i dont know what i8042_dmi_reset_table does yet, might be an option we can add to /etc/modprobe.d/ to do the equivalent of what its doing in that commit
[20:46] <Sarvatt> ah boot with i8042.reset=1 on the grub command line maxb
[20:48] <bryce> any opinions on whether we should just expire out the xfree86-driver-synaptics bugs, or transfer them to xserver-xorg-input-synaptics?
[20:48] <Sarvatt> my grub additional options stanza is getting rediculious here, quiet enable_mtrr_cleanup mtrr_spare_reg_nr=1 pcie_aspm=force i8042.reset=1
[20:48] <bryce> there are 19 bugs
[20:48] <Sarvatt> enable_mtrr_cleanup mtrr_spare_reg_nr=1 is required on AOA150 to have mtrrs for video if you arent using it btw maxb
[20:49] <tjaalton> bryce: it's the same driver, just renamed, so maybe best to transfer them
[20:50] <jbarnes> hm latest bits won't let me enable compiz
[20:50] <jbarnes> even though compiz --replace works fine from a terminal
[20:50] <bryce> okie
[20:52] <maxb> Sarvatt: I only get the PS/2 issue on 1 in 10 boots anyway, so it's a bit hard to test for me
[20:52] <maxb> Sarvatt: erm, what's a MTRR and how would I know if I wanted one? :-)
[20:53] <Sarvatt> well just add i8042.reset=1 to /etc/default/grub, it'll fix it up and will happen automatically here soon anyhow
[20:53] <bryce> maxb, https://wiki.ubuntu.com/X/Glossary
[20:54] <Sarvatt> cat /proc/mtrr
[20:56] <Sarvatt> when you boot with enable_mtrr_cleanup it tells you mtrr 7 is filled with bogus data and you've got a buggy bios
[20:58] <maxb> ok.... so what practical effect should I be looking for when adding these options? Is it simply a matter of enabling a faster way of talking to the GPU ?
[20:58] <Sarvatt> [    0.000000] WARNING: BIOS bug: VAR MTRR 7 contains strange UC entry under 1M, check with your system vendor!
[20:59] <maxb> I don't see that in my dmesg
[20:59] <maxb> [    0.000000]   7 base 000000000 mask 0FFFE0000 uncachable
[20:59] <Sarvatt> yeah enable_mtrr_cleanup shows that
[21:00] <Sarvatt> mtrr_spare_reg_nr=1 makes it clean things up so theres a spare one available for the GPU to open a WC one for X
[21:01] <Sarvatt> you dont notice like, slow scrolling speed for firefox and stuff?
[21:01] <maxb> So essentially "make it possible to turn write-combining on" ?
[21:01] <Sarvatt> yep
[21:02] <maxb> my scrolling seems fine
[21:03]  * maxb fiddles with grub cfg
[21:04] <Sarvatt> you do it in /etc/default/grub now then update-grub2 after if you dont want to lose it next time you update-grub :D
[21:05] <Sarvatt> GRUB_CMDLINE_LINUX_DEFAULT="x" line in there
[21:05] <maxb> !
[21:05] <maxb> New to me
[21:06] <maxb> Though on the netbook I'm manually maintaining the menu.lst since it's triple-boot intrepid/jaunty/karmic
[21:07] <Sarvatt> ah yeah goes in the # defoptions= line in there
[21:08] <tjaalton> uh, so .31 is now the default kernel
[21:08] <Sarvatt> glxgears fps will double, not that thats indicative of anything :D
[21:08] <Sarvatt> yeah, and nvidia doesnt compile under it, fun stuff
[21:09] <bryce> wee
[21:10] <Sarvatt> and a large number of systems cant even boot it because of the null dereference in acpi_get_pci_dev() that was fixed right after
[21:10] <bryce> have the -intel pci quirks been ported into the kernel yet?
[21:10] <maxb> Sarvatt: well, I get the WARNING you mention, but I don't observe subjectively any performance difference.
[21:11] <Sarvatt> do you see a write-combining mtrr covering your video ram when you cat /proc/mtrr now?
[21:12] <maxb> There's a write-combining one base=1G size=256M - sounds likely?
[21:12] <maxb> though it's reg4 not reg7
[21:13] <Sarvatt> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=412af97838828bc6d035a1902c8974f944663da6 -- those systems cant even boot 31-rc1
[21:19] <maxb> Sarvatt: In conclusion I see about a 25% improvement in glxgears fps with the mtrr cleanup. Apparently that's not enough to be perceptible in my usual workloads
[21:20] <maxb> but thanks for the tip regardless :-)
[21:21] <maxb> ooh, my keyboard doesn't work in 31-rc1
[21:22] <Sarvatt> it was really noticible on jaunty's 2.6.28 kernel, firefox scrolling speed and video playback were horrible. not so noticible now for some reason but at least that way its working as intended :D
[21:24] <maxb> Very timely advice Sarvatt, I seem to need i8042.reset=1 to make my keyboard work in 31-rc1
[21:24] <maxb> :-)
[21:24] <Sarvatt> :D
[21:24] <Sarvatt> that'll be fixed by rc2 hopefully if linus pulls dtor's input tree by then
[21:25] <Sarvatt> it'll force i8042.reset=1 for Acer AOA150's
[21:27] <maxb> ah, keyboard sometimes works without. I guess it's a new manifestation of the same issue affecting the synaptics
[21:30] <Sarvatt> i'm using evdev 2.2.99 and dont have any problems with the keyboard not starting up, wonder if its some change in there in that case
[21:31] <Sarvatt> we have the same system after all
[22:19] <proti> morning
[22:19]  * bryce waves
[22:20]  * proti waves too :-)
[22:21] <proti> Need some help with intel kms...
[22:21] <proti> At boot I get black screen immediately.
[22:21] <tjaalton> problem in the current kernel
[22:21] <tjaalton> .31 ftw
[22:21] <proti> Problem since 2.6.29-10.
[22:22] <tjaalton> ok..
[22:22] <proti> X fails to start.
[22:23] <proti> Says (EE) intel(0): Incorrect KMS mode.
[22:23] <proti> On karmic koala of course.
[22:25] <proti> The funniest thing is that the machines boots ok, and shuting down the laptop shows the splash screen.
[22:30] <proti> X.0.log is there http://pastebin.ubuntu.com/207743/
[22:31] <proti> And kern.log is here http://pastebin.ubuntu.com/207745/
[22:38] <bryce> Sarvatt, your -synaptics debdiff is uploaded
[22:49] <proti> Hum, seems that the kernel sets is wrong. '[drm] LVDS-8: set mode 0x0 19'
[23:21] <jbarnes> pitti made my day... then rained on it :p