[09:13] <tjaalton> hum, what's the diminutive english word for "wave"? (wavelet?)
[09:29] <tjaalton> nevermind
[13:11] <ilmari> tjaalton: microwave :)
[13:13] <tjaalton> hehe :)
[15:05] <Sarvatt> mdeslaur: how did nouveau 3D go for you?
[15:05] <Sarvatt> unity work?
[15:07] <mdeslaur> Sarvatt: yeah, unity worked. But I'm back to nvidia, unfortunately. images.google.com is basically unusable with nouveau, and when I viewed a couple of large images in firefox, all my desktop pixmaps stopped working
[15:08] <mdeslaur> Sarvatt: I'll try and reproduce later to file a bug
[15:08] <Sarvatt> mdeslaur: hmm, what GPU do you have?
[15:08] <mdeslaur> a black one? :)
[15:08] <mdeslaur> hold on, I'll look
[15:09] <mdeslaur> NVIDIA GPU Quadro NVS 140M (G86) at PCI:1:0:0 (GPU-0)
[15:09] <bjsnider> that is what blocked it from working, instead of compiz? i'd never have guessed
[15:09] <bjsnider> what about in a different browser than firefox?
[15:10] <mdeslaur> bjsnider: in chromium, images.google.com works fine
[15:10] <bjsnider> yeah, firefox on linux is a piece of crap
[15:11] <mdeslaur> bjsnider: well, it's something particular about the way firefox handles images.google.com
[15:12] <Sarvatt> don't tell me images.google.com uses webgl in firefox 4.0 now too :)
[15:12] <bjsnider> i've heard people say that firefox is faster out of wine than the native linux version, so clearly it must be optimized for windows performance
[15:14] <mdeslaur> Sarvatt: I had the same images.google.com issue with firefox 3 in maverick with nouveau
[15:15] <bjsnider> i think we're really headed towards chromium as the default browser in ubuntu eventually
[15:15] <Sarvatt> mdeslaur: thanks, was just curious what your experience was with the 3D side since we don't get much feedback. will try to reproduce that on my G86 when I can hijack it from the wife :)
[15:16] <mdeslaur> Sarvatt: during the limited testing I did with unity, it worked great
[15:17] <mdeslaur> Sarvatt: I did install libgl1-mesa-dri-experimental even if I didn't know if I needed it or not
[15:18] <mdeslaur> oh, I guess I do...geforce 4 is ancient
[15:19] <JanC> bjsnider: the Mozilla binary build for linux is also faster than the one in the Ubuntu package...
[15:19] <Sarvatt> yeah it was, would like to enable it by default or make it easier to install (like through jockey) at some point, we should probably put out a call for testing for it
[15:20] <Sarvatt> if anything just to get more exposure that people can use unity without the blob on a livecd with it
[15:20] <mdeslaur> Would be nice to have unity working on nvidia without the binary driver
[15:42] <Sarvatt> wow cairo xlib actually faster than the image backend for images.google.com on the blob
[15:42] <Sarvatt> [  0]     xlib                    firefox-4    0.148    0.150   1.84%    6/6
[15:42] <Sarvatt> [ # ]    image: pixman 0.18.4
[15:42] <Sarvatt> [  0]    image                    firefox-4    0.160    0.162   0.95%    6/6
[15:42] <Sarvatt> sure as heck isn't on intel
[15:42] <Sarvatt> [  0]     xlib                    firefox-4    1.044    1.093   2.23%    6/6
[15:42] <Sarvatt> [ # ]    image: pixman 0.21.2
[15:42] <Sarvatt> [  0]    image                    firefox-4    0.724    0.731   1.65%    6/6
[16:05] <Sarvatt> bjsnider: just waiting for the nocompat32 release to update the blob in the PPA
[16:06] <Sarvatt> they didn't upload stuff to the FTP this time
[16:24] <bjsnider> i don't see a new driver
[16:25] <bjsnider> oh, now i see
[16:27] <bjsnider> http://www.nvidia.com/content/DriverDownload-March2009/confirmation.php?url=/XFree86/Linux-x86_64/260.19.29/NVIDIA-Linux-x86_64-260.19.29-no-compat32.run&lang=us&type=GeForce
[16:27] <Sarvatt> thanks, I didn't see it anywhere
[16:29] <bjsnider> i just typed the no-compat32 part into the url figuring it might be there and it was
[17:12] <tseliot> Sarvatt: are evergreen cards fully supported in Natty?
[17:14] <Sarvatt> tseliot: nope
[17:14] <Sarvatt> tseliot: needs a git x-x-v-ati
[17:15] <tseliot> Sarvatt: ah, so mesa should be fine, right? I'm sure about drm
[18:03] <bryceh> tseliot, Sarvatt, I'm writing the X.org report for this week... got anything I should include mention of?
[18:08] <Sarvatt> hm, could mention the nvidia/fglrx xorg.conf thing maybe. nothing really exciting on my end
[18:10] <bryceh> Sarvatt, ahh yes good idea
[18:11] <bryceh> I've posted status to https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-12-14
[19:37] <hrw> hi
[19:37] <hrw> does someone know why 'intel' driver does not load on i855 chipset in maverick?
[19:39] <hrw> it matches only vesa and fbdev.
[19:40] <hrw> when I used Debian 'sid' on this machine months ago all was working.
[19:40] <hrw> KMS works fine - inteldrmfb works
[19:43] <hrw> brb
[19:50]  * ilmari is getting occasional X hangs on resume from supend with the latest maverick kernel update (2.6.35-24.42)
[19:51] <ilmari> i915/arrandale
[19:52] <hrw> i915.... lucky you
[19:53] <hrw> i855 here - piece of crap
[19:53] <ilmari> it's actually core i7 integrated graphics ;)
[19:54] <ilmari> i915 is just the kernel driver name
[19:54] <hrw> ah
[19:55] <hrw> ilmari: try http://askubuntu.com/questions/4658/how-to-install-intel-82852-855gm-driver-on-ubuntu-10-10-maverick-meerkat maybe?
[19:56] <hrw> ignore 855 in it - it just gives younewer driver
[19:56] <ilmari> well, it didn't do this with the previous maverick kernel, so it seems like a regression
[19:58] <bryceh> hrw, the 8xx support has been decaying upstream and accumulating regressions.  It's proven too time consuming to support in ubuntu, esp. since we don't have anyone on the ubuntu-x team with that hardware
[19:58] <bryceh> ilmari, I think that's a known issue... an incompatibility between the newer kernel and older -intel.  You need to update to a newer -intel to use it with the newer kernel.
[19:59] <bryceh> ilmari, get a newer -intel for maverick from the x-updates ppa.
[19:59] <ilmari> ppa:ubuntu-x-swat/x-updates ?
[19:59] <bryceh> that's the one
[20:07] <hrw> bryceh: Canonical hardware lab also lacks i855 devices?
[20:07] <hrw> ~curse intel for i855
[20:08] <bryceh> hrw, they do not have i855, no
[20:08] <hrw> this laptop is still fine for my wife when it comes to size/hwardware (12", pentium m 1.6GHz)
[20:09] <bryceh> however even if they did, I'm uncertain if their testing procedures would be sufficient to catch the types of bugs we see
[20:09] <hrw> bryceh: if this can help then I can take this laptop with me for ubuntu platform rally in dallas,tx
[20:11] <bryceh> hrw, no, like I said it's too time consuming to support 8xx so we pretty much don't support it anymore
[20:11] <hrw> ok
[20:11] <hrw> will have to live with fbdev then
[20:12] <hrw> good that at least inteldrmfb works
[20:12] <bryceh> it's not that we need to just fiddle a few bits to make it work, but that someone needs to sit down and do some serious debugging/development work on it, and that could take several man-weeks 
[20:12] <hrw> waste of time then it would be
[20:12] <bryceh> as well as routine and regular testing for regressions on new code drops (e.g. xorg-edgers), and working with upstream to get issues resolved
[20:13] <hrw> 1.6GHz pentium m is still fast enough to do some desktop effects in software
[20:14] <hrw> 5-6 years old hardware requires some sacrifice
[20:16] <hrw> bryceh: thanks for help
[20:16] <hrw> bye guys
[20:16] <bryceh> hrw, sure, ssorry it isn't better news
[21:13] <speakman> hi folks
[21:14] <speakman> how dow I enable TCP listening on X? I'd like to connect remotely with DISPLAY env var
[21:28] <Sarvatt_> good question, gdm sets that and I'm not seeing the option to disable it in a GUI anymore
[21:29] <speakman> seems like it's configured in gconf nowadays?
[21:29] <speakman> but no idea how..
[21:30] <Sarvatt_> if it's anything like the other args passed to gdm now it might be hardcoded in the gdm source, hope thats not true..
[21:31] <speakman> http://ubuntuforums.org/showthread.php?t=1590100
[21:31] <speakman> That's not very clear...
[21:31] <Sarvatt_> speakman: ahh /etc/X11/xinit/xserverrc:exec /usr/bin/X -nolisten tcp "$@"
[21:32] <Sarvatt_> speakman: looks like you can remove it from there, and change the gconf key
[21:33] <Sarvatt_> ...which i'm not finding
[21:33] <speakman> is it really hard coded..?
[21:34] <Sarvatt_> oh edit /etc/gdm/custom.conf and add [security]
[21:34] <Sarvatt_> DisallowTCP=false
[21:34] <Sarvatt_> nope, -nr is though :(
[21:34] <speakman> exactly, but your paste of xserverrc looks scary
[21:34] <speakman> -nr ?
[22:37] <bryceh> Sarvatt, btw with pulling a new -ati into the archive, I'd be cool with it.  We've even shipped git snapshots of -ati with decent results in the past.
[22:38] <bryceh> Sarvatt, is there anything to beware of that you know of with -ati 6.13.99 if I were to pull it into ubuntu now-ish?
[22:38] <bryceh> (Or would it be better to wait until after we're all back from holidays?)
[22:39] <Sarvatt> bryceh: nothing that I'm aware of, evergreen acceleration was making X crash with SIGBUS until recently but we have a fixed up kernel in natty
[22:40] <bryceh> Sarvatt, ok I may do the -ati merge if I have time this week
[23:38] <bjsnider> Sarvatt, i can do that nvidia blob if you're busy
[23:40] <Sarvatt> bjsnider: sure, thanks for that. my cable modem resets every 5-10mb uploaded and haven't been able to be without net that long today to do it
[23:41] <bjsnider> why the bleep does it do that?
[23:42] <bjsnider> you must have north american internet to put up with that crap
[23:43] <Sarvatt> you know it.. I tried to upload it on 3G earlier but apparently they dont let you upload more than 30MB at once on it, yay t-mobile
[23:44] <bjsnider> what is your ISP's pathetic excuse for the cable modem issue?
[23:45] <Sarvatt> they're comcast
[23:46] <bjsnider> that's what they said? "we're comcast"?
[23:46] <Sarvatt> got a fios install schedule for next month, goodbye comcast :)
[23:47] <bryceh> yay!
[23:48] <bryceh> yeah comcast sucks, although thats a level of suckatude I hadn't experienced when I was on it
[23:50] <Sarvatt> bryceh: the only gotcha I forsee with an ati checkout..
[23:50] <Sarvatt> they are doing funky version bumps
[23:51] <Sarvatt> they change the version on master from 6.13.99 down to 6.13.x, release, then bump it back up to 6.13.99 after
[23:51] <bryceh> huh
[23:51] <Sarvatt> not sure if it should be 6.13.3 for a git snapshot
[23:51] <Sarvatt> guess we can check what fedora is doing
[23:51] <bryceh> yeah
[23:52] <Sarvatt> sorry I was in a call when you asked earlier and forgot to mention that
[23:52] <Sarvatt>   84 * Wed Dec 01 2010 Dave Airlie <airlied@redhat.com> 6.13.2-0.3.20101201gite142e55c5
[23:55] <Sarvatt> 6.13.3 is probably going to be newer than our 6.13.99 checkout if we do it normally looking at what they did with 6.13.[12]
[23:55] <Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=cc5005af61f45a3552f7358dc5aa711e42f5af54 and http://cgit.freedesktop.org/xorg/driver/xf86-video-ati/commit/?id=ad999e633ff41d27eed9d2c6535e163a7181b0bd