[00:01] <bryceh> just following the 7.10 branch
[00:01] <bryceh> he pointed to an xserver fix, which I pulled and uploaded
[00:02] <RAOF> Have you pushed to git?
[00:02] <bryceh> yeah, pretty sure I did, let me doublecheck
[00:04] <bryceh> mesa pushed
[00:04] <bryceh> (the fix had been pushed but not the changelog entry)
[00:09] <bryceh> later
[00:36] <RAOF> Why doesn't git have a “pull --all” that does what you mean, rather than what some internal component means?
[01:00]  * penguin42 scratches his head at gtk2-engines-oxygen - the code appears to be expecting the underlying gtk to throw critical level log messages but somehow expects it not to abort 
[01:10] <cnd> RAOF, what's the timeline for pushing rc2 into ubuntu?
[01:10] <cnd> or whenever you want to tack on xi 2.1
[01:10] <RAOF> cnd: Oh, has RC2 been released?
[01:10] <cnd> I don't know
[01:10] <cnd> sorry :)
[01:10] <cnd> I can check
[01:11] <cnd> the official schedule says 1.10 will be released, final, on friday
[01:11] <RAOF> Yes, it does.
[01:11] <RAOF> I suspect the official schedule is lying through its teeth.
[01:12] <cnd> heh
[01:12] <cnd> I don't even know where to check these things
[01:13] <cnd> RAOF, where do get releases from?
[01:13] <cnd> git?
[01:13] <RAOF> uscan.
[01:14] <RAOF> http://xorg.freedesktop.org/releases/individual/xserver/ 
[01:14] <RAOF> cd -(No RC2 release)
[01:16] <cnd> RAOF, the latest 1.10 stuff there is from 06-dec-2010...
[01:17] <cnd> where's rc1?
[01:19] <RAOF> it's there - 1.9.99.901
[01:20] <cnd> that's what's in ubuntu right now?
[01:20] <cnd> from 06-dec-2010?
[01:20] <RAOF> No; we've got a snapshot.
[01:20] <cnd> oh
[01:20] <cnd> ok
[01:21] <cnd> oh yeah, hence the git part :)
[01:21] <RAOF> Because the ABI broke between RC1 and now, and I didn't want to have an ABI break in 1.10 packages :)
[01:21] <cnd> yeah
[01:21] <cnd> RAOF, so let me know when you want to push, but we have to abide by the feature freeze deadline too
[01:22] <cnd> so if x doesn't release before this coming monday, I'd suggest we push it as it is
[01:22] <RAOF> Right.
[01:22] <cnd> basically, what's in my xorg-unstable ppa right now
[01:23] <RAOF> I don't have a lot of faith in the X release actually being Friday; if you're all ready to go we could push sooner.
[01:23] <cnd> RAOF, ok, I may want to wait till the end of the week anyways
[01:24] <cnd> RAOF, bryceh: as a heads up, I realized we currently suffer a (some might say) bad regression
[01:24] <cnd> if you have a touchscreen, and an xi 2.1 capable client on a window, and you tap on the window to raise it, and your window manager is not touch aware
[01:24] <cnd> then the window won't raise
[01:25] <cnd> I think it may be most prudent to push it like that for now, we have potential work arounds
[01:25] <cnd> and I'm working on the fully "correct" solution, but I can't guarantee it before feature freeze
[01:25] <RAOF> I presume unity is touch-aware?  Is metacity?
[01:25] <cnd> no wms are currently touch aware
[01:25] <cnd> we can make specific ones touch aware
[01:25] <cnd> and we can also have a kludge
[01:26] <cnd> a daemon that sits and acts as a touch aware window manager
[01:26] <cnd> well, not really window manager
[01:26] <RAOF> There's going to have to be a proper solution upstream in... oh, my.
[01:26] <cnd> a touch "raiser"
[01:26] <RAOF> That's quite the kludge :)
[01:26] <cnd> yeah...
[01:26] <cnd> that's one work around
[01:26] <cnd> there are others
[01:26] <cnd> the problem is that we inhibit pointer events when touch events are handled
[01:27] <RAOF> What's the final solution going to look like?  I presume this is being discussed with whot and daniel?
[01:27] <cnd> we could send pointer events in parallel with touch events
[01:27] <cnd> but that probably is not going to be the final protocol
[01:27] <cnd> yes, it's being discussed
[01:27] <cnd> but the final solution is going to be an interleaving of pointer and touch events
[01:27] <cnd> so if a window has a touch grab, then you address it first
[01:27] <cnd> if it also has a pointer grab, then you address it next
[01:28] <cnd> and you check each window like this down the hierarchy
[01:28] <RAOF> I guess the other interesting piece of information here is: how many Xi 2.1 capable clients do we have?
[01:28] <cnd> RAOF, none right now :)
[01:28] <cnd> of course we're trying to kick start it all
[01:28] <RAOF> So this is a bad regression on the null set of Xi 2.1 clients :)
[01:30] <cnd> correct :)
[01:30] <cnd> if a client is not xi 2.1, there's no regression
[01:30] <cnd> so this isn't a terribly enormous problem
[01:31] <cnd> and, at worst, we can tell people: just tap the window title bar
[01:31] <cnd> or any window decorations
[01:31] <cnd> so that's why I think we should push it as it is, and then figure out how to fix it, if we do any of these kludges
[01:32] <RAOF> Right.  I don't think this needs much consideration unless you don't think you'll be able to get a fix in Natty.
[01:32] <cnd> we could also make unity and metacity touch aware
[01:32] <cnd> and leave the rest
[01:32] <cnd> and tell people if they have issues to add some stuff to xorg.conf
[01:32] <cnd> to disable xi 2.1
[01:32] <cnd> so I think there's a lot of potential work arounds
[01:32] <cnd> and the problem isn't extremely severe
[01:33] <RAOF> Yeah.  You don't think that you'll be able to get the final protocol in Natty?  That'd be an obvious solution.
[01:33] <cnd> yeah, that's the obvious solution :)
[01:33] <cnd> but it's really hard too :)
[01:34] <cnd> I think every time they have changed the input stack (i.e. add xi 1.0, xi 1.5, xi 2.0), they have completely rearchitected it internally
[01:34] <cnd> I would not be surprised if that's what happens in x 1.11
[01:34] <cnd> I will be attempting to fit the "correct" protocol into the current architecture
[01:34] <cnd> and after mapping it out some, I don't think it will be that horrible
[01:34] <cnd> but it took me three days of analyzing the xserver code to figure out how the hell it worked :_
[01:34] <cnd> :)
[01:38] <RAOF> l:)
[01:38] <cnd> x input sucks :)
[01:39] <cnd> this would be sooooooooooooooooooo^18 much easier starting from scratch (i.e. wayland :)
[01:39] <RAOF> :).  I hope you get a chance to hack on that!
[01:40] <cnd> if I can ever finish xi 2.1, I will!
[01:40] <cnd> then I'll make my own new window system so I can continue making input systems!
[01:42] <RAOF> Maybe you could finish Y?
[01:43] <RAOF> I should probably get a new nvidia card so that I have an nv5x+ card that isn't in a tiny, apallingly slow, netbook.
[01:57] <afiestas> no crashes tonight :(
[02:02] <bjsnider> RAOF, when you bought a netbook you didn't expect it to be a supercomputer right?
[02:03] <RAOF> bjsnider: Indeed I did not.  But it would be nice to have a less slow nv5x+ box; I'd test it more :)
[02:05] <bjsnider> "less slow" is not very ambitious
[02:07] <RAOF> Offgering to sponsor me a sandybridge + nvidia desktop and a fusion laptop? :)
[02:08]  * bjsnider runs screaming in the opposite direction
[02:13] <RAOF> Hm.  Surprisingly, making unity work on nv5x doesn't actually seem to make any more piglit tests pass.  There's clearly a testcase missing.
[02:17] <bjsnider> RAOF, why doesn't the nouveau project provide you with the appropriate hardware?
[02:17] <RAOF> Why would they?
[02:17] <bjsnider> because you obviously need it
[02:18] <RAOF> I'd not be developing, particularly, with it.  Just testing.
[02:19] <bjsnider> testing matters
[02:19] <RAOF> they've got plenty of testers :)
[02:19] <bjsnider> it's not a trivial thing you're doing
[02:20] <bjsnider> they've got plenty of testers who can submit meaningful bug reports?
[02:20] <RAOF> I could, of course, buy a $30 modern gpu.
[02:20] <bjsnider> not just "the thing doesn't work in the thing"
[02:22] <bjsnider> mine cost $50
=== Guest28688 is now known as NCommander
=== yofel_ is now known as yofel
[13:47] <bjsnider> Sarvatt, new nvidia blob today
[13:53] <ricotz> bjsnider, oh really? nice
[14:25] <Sarvatt> uploaded it to the ppa for natty
[14:25] <tjaalton> what changes does it have?
[14:26] <Sarvatt>    - Added NV-CONTROL event notification for
[14:26] <Sarvatt>      NV_CTRL_FRAMELOCK_SYNC_READY
[14:26] <Sarvatt>      status changes.
[14:26] <Sarvatt>    - Added support for the following GPUs:
[14:26] <Sarvatt>      GeForce GTX 560 Ti
[14:26] <Sarvatt>    - Added a new X configuration option "Interactive", which defaults to
[14:26] <Sarvatt>      enabled, but can be disabled to allow long-running GPU compute programs
[14:26] <Sarvatt>      to run concurrently with X.
[14:26] <Sarvatt>    - Fixed a bug in the VDPAU presentation queue that could cause VDPAU
[14:27] <Sarvatt>      "display preemption" when rendering to tiny or zero-sized windows or
[14:27] <Sarvatt>      pixmaps.
[14:27] <Sarvatt>    - Fixed a bug in VDPAU which prevented use of the overlay presentation
[14:27] <Sarvatt>      queue following an application exiting without gracefully destroying its
[14:27] <Sarvatt>      VDPAU presentation queue.
[14:27] <Sarvatt> oh and works with natty supposedly
[14:27] <tjaalton> ok, cool
[14:27] <tjaalton> though nouveau has been stable after switching away from firefox
[14:39] <ricotz> Sarvatt, nouveau 3d works with my nvc4 :)
[14:45] <tjaalton> ricotz: you got the fw from somewhere?
[14:48] <ricotz> tjaalton, you can get out of a mmiotrace
[14:57] <Sarvatt> ricotz: people saying this blob doesnt work in natty either in #ubuntu-desktop :(
[14:57] <tjaalton> ricotz: right
[14:59] <ricotz> Sarvatt, does it work you? (270.26)
[14:59] <yofel> got some debugging instructions for nouveau freezes? it locks up on my notebook after a few minutes with that [mi] EQ overflowing error
[15:00] <Sarvatt> ricotz: about to test now
[15:02] <Sarvatt> ricotz: hundreds of updates to grab :)
[15:03] <ricotz> Sarvatt, perhaps you could add a patch to nouveau xorg driver which currently only enables 3d on nvc0
[15:04] <ricotz> the same initialisation seems to work for nvc3 and nvc4
[15:05] <Sarvatt> yup doing that now
[15:06] <ricotz> great
[15:10] <Sarvatt> uploaded that to xorg-edgers
[15:10] <Sarvatt> xserver-xorg-video-nouveau_0.0.16+git20110214.46acb7e0-0ubuntu0sarvatt3.
[15:10] <ricotz> Sarvatt, i am currently running a custom kernel to workaround a known problem
[15:11] <Sarvatt> http://sarvatt.com/downloads/patches/0001-Also-enable-acceleration-on-nvc3-and-nvc4.patch
[15:11] <Sarvatt> oh?
[15:12] <ricotz> i think the cause is only the uninitilized "ret" variable in gpu/nouveau/nouveau_channels.c in kernel
[15:12] <ricotz> which calim mentioned
[15:13] <ricotz> but to me sure i switched to natty-master-next+linus-master+nouveau-linux-2.6
[15:38] <Sarvatt> sheesh this is a crazy amount of upgrades
[15:40] <ricotz> are you updating the world? :P
[15:41] <Sarvatt> yeah 530MB worth
[15:41] <Sarvatt> i haven't updated anything but compiz and chromium-browser since xserver 1.10 went in
[15:41] <ricotz> ah, ok, i am trying to update more often
[15:42]  * yofel will leave his notebook frozen if someone has an idea
[15:59] <tjaalton> yofel: https://wiki.ubuntu.com/X/Backtracing
[16:00] <yofel> if you need the X backtrace from the EQ overflowing error - I collected that on bug 711908
[16:00] <ubot4> Launchpad bug 711908 in xserver-xorg-video-nouveau (Ubuntu) "[natty] frequent nouveau freeze on GT218 [NVS 3100M] (rev a2) (affects: 2) (heat: 12)" [Undecided,New] https://launchpad.net/bugs/711908
=== jcristau_ is now known as jcristau
[16:02] <tjaalton> yofel: gdb backtrace would be more useful
[16:03] <tjaalton> if you can ssh in from another machine
[16:05] <yofel> just doing that
[16:05] <tjaalton> install the dbg packages first
[16:06] <tjaalton> libdrm2-dbg, xserver-xorg-video-nouveau-dbg, xserver-xorg-core-dbg
[16:06] <yofel> thansk
[16:06] <yofel> *thanks
[16:21] <ricotz> tjaalton, are there piglit packages for natty available
[16:24] <Sarvatt> ricotz: dont think so, it doesn't really lend itself well to packaging with how often its updated and is very easy to compile locally
[16:25] <Sarvatt> btw nvidia 270.26 doesn't work with natty xserver
[16:25] <Sarvatt> http://paste.ubuntu.com/567382/
[16:27] <ricotz> Sarvatt, ok
[16:27] <ricotz> Sarvatt, too bad, is it the same xserver git commit mentioned there?
[16:28] <Sarvatt> yup
[16:28] <Sarvatt> but i dont believe it
[16:28] <Sarvatt> because the extension ABI version changed in january preventing nvidias libglx from loading and it loads properly now
[16:29] <Sarvatt> building latest xserver git at the moment to see if its any different
[16:32] <ricotz> hmm, fingers-crossed ;)
[16:33] <Sarvatt> yay docs dont build
[16:35] <yofel> tjaalton: got it and added it to the report
[16:48] <tseliot> Sarvatt: BTW if you're interested, I've just pushed my changes to nvidia-current (still in git): https://github.com/tseliot/nvidia-graphics-drivers/commits/master
[16:49] <Sarvatt> tseliot: awesome!
[16:49] <tseliot> Sarvatt: they should fix bug #616214, #540143 and #704607
[16:49] <ubot4> Launchpad bug 616214 in nvidia-graphics-drivers-96 (Ubuntu Maverick) (and 5 other projects) "Should Depend: on appropriate xserver-xorg-video-$ABI (affects: 7) (heat: 58)" [Undecided,Fix released] https://launchpad.net/bugs/616214
[16:49] <ubot4> Launchpad bug 540143 in nvidia-graphics-drivers (Ubuntu) "Symlinks libnvidia-tls.so.1 are not removed on package uninstall (affects: 1) (heat: 14)" [Low,In progress] https://launchpad.net/bugs/540143
[16:49] <ubot4> Launchpad bug 704607 in nvidia-graphics-drivers (Ubuntu) "Packaging issues in nvidia-current (affects: 1) (heat: 6)" [Medium,In progress] https://launchpad.net/bugs/704607
[16:49] <tseliot> I haven't uploaded anything to Natty yet because of the ABI
[17:02] <Sarvatt> building the latest xserver with --disable-devel-docs --without-fop added works, phew
[17:06] <Sarvatt> #0  0xb5f477e3 in ?? () from /usr/lib/xorg/extra-modules/nvidia_drv.so is all I get, no change
[17:13] <tseliot> :/
[17:14] <tseliot> Sarvatt: on amd64?
[17:14] <Sarvatt> i386, i dont use amd64 on any machines i care about
[17:14] <tseliot> ah
[17:15] <Sarvatt> looks like they just allowed extension abi 5 in their libglx and didn't update the xserver checkout it was built against
[17:15] <Sarvatt> which sucks because they said they would in the next beta release on the forums
[17:16] <tseliot> Sarvatt: can you generate an nvidia-bug-report.log, please? I'd like to send it to nvidia
[17:17] <Sarvatt> sure thing
[17:18] <Sarvatt> looks like it wasnt expected that 270.26 was compiled against the old xserver again - http://www.nvnews.net/vbulletin/showthread.php?s=fc330a9c1191f1a1b11159e26b751c67&t=159610
[17:20] <tseliot> oh, maybe it's just a mistake
[17:20] <Sarvatt> tseliot: http://sarvatt.com/downloads/nvidia-bug-report.log
[17:21] <tseliot> Sarvatt: thanks
[17:23] <tseliot> Sarvatt: the log says against what commit of the xserver the driver was built
[17:24] <tseliot> i.e. 780754050bc9cb1489f92a2a890ab5665e3e6358
[17:28] <tseliot> Sarvatt: what's the commit that broke the ABI again after December?
[17:28] <Sarvatt> tseliot: there were a ton of them, lets see..
[17:29] <Sarvatt> tseliot: they fixed the extension abi break that stopped libglx from loading but didn't fix the video abi breaks
[17:30] <tseliot> Sarvatt: ok
[17:35] <tjaalton> yofel: thanks, that's exactly what I've seen too
[17:35] <tjaalton> well, the other crasher
[17:36] <tjaalton> yofel: can you forward that upstream? if not, I'll do it tomorrow, or check if there's already one filed
[17:54] <Sarvatt> ricotz: whoops looks like i uploaded the wrong thing to the PPA for nouveau, sorry about that
[17:55] <Sarvatt> oh nevermind, right one is up there
[17:56] <ricotz> Sarvatt, yeah, i checked the diff, it is fine, but havent restarted x yet
[17:56] <yofel> tjaalton: since you understand the error better than me, it would be nice if you could do it
[18:09] <bjsnider> Sarvatt, nvidia released a driver that still doesn't work with the new x server? i don't understand
[18:09] <tjaalton> yofel: sure, no problem
[18:11] <yofel> bjsnider: nope, still crashes X (270.26)
[18:15] <Sarvatt> oh boy
[18:15] <Sarvatt> The following packages have unmet dependencies:
[18:15] <Sarvatt>  xserver-xorg-input-evdev : Depends: xorg-input-abi-12.1
[18:15] <Sarvatt>  xserver-xorg-input-mouse : Depends: xorg-input-abi-12.1
[18:15] <Sarvatt> we depend on the minor version too? :D
[18:39] <Sarvatt> ricotz: http://paste.ubuntu.com/567425/ darn
[18:44] <Sarvatt> ricotz: what kernel patch did you say you needed? i'm on another machine now and dont have the logs
[18:55] <ricotz> Sarvatt, using natty/edgers packages, with the current natty kernel it boots normal without fw -- resulting in using swrast -- with fw already kms fails for me
[18:55] <ricotz> let me search for the line
[18:56] <dupondje> hi
[18:57] <dupondje> can somebody change https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/714280 to not-fixed ?
[18:57] <ubot4> Launchpad bug 714280 in xorg-server (Ubuntu) (and 3 other projects) "The error was 'BadLength (poly request too large or internal Xlib length erro'. (affects: 5) (dups: 1) (heat: 32)" [Undecided,Fix released]
[18:58] <ricotz> Sarvatt, http://cgit.freedesktop.org/nouveau/linux-2.6/diff/drivers/gpu/drm/nouveau/nouveau_channel.c?id=3428239fc054b0c6d6024aea293f5efa02b5dc95
[19:00] <jcristau> dupondje: can you get a backtrace from gdb?
[19:00] <jcristau> (break on _XError)
[19:00] <dupondje> jcristau: if you give me some hints how to :)
[19:01] <dupondje> fetching firefox-dbg :)
[19:01] <jcristau> you'll want libgl1-mesa-glx-dbg and libx11-6-dbg
[19:05] <dupondje> mmm
[19:06] <dupondje> "/usr/bin/firefox": not in executable format: File format not recognised
[19:06] <jcristau> firefox -g or something
[19:06] <jcristau> also, somebody should fix firefox's X error handler to not be so useless
[19:20] <dupondje> sorry router needed a reboot )à
[19:20] <dupondje> jcristau: http://paste.ubuntu.com/567438/
[19:22] <jcristau> dupondje: in frame 7, print *sgi_req
[19:22] <dupondje> euh ? :)
[19:23] <jcristau> at the gdb prompt, type 'frame 7'
[19:23] <jcristau> and then 'print *sgi_req'
[19:24] <dupondje> (gdb) print *sgi_req
[19:24] <dupondje> value has been optimised out
[19:26] <jcristau> bah.
[19:27] <dupondje> not very usefull eh :D
[19:29] <dupondje> if you need more info .. :)
[19:31] <jcristau> if you can get a noopt mesa build...
[19:32] <dupondje> how :)
[19:36] <jcristau> set DEB_BUILD_OPTIONS=noopt
[19:38] <dupondje> then rebuild mesa ? or ?
[19:38] <jcristau> yes
[19:38] <dupondje> works with pbuilder-dist also ?
[19:38] <jcristau> i have no idea
[19:44] <dupondje> how can I see its building with noopt ?
[19:48] <dupondje> nvm :)
[19:49] <dupondje> lets just change debian/rules ^^
[19:52] <dupondje> building
[20:05] <dupondje> still building :(
[20:05] <dupondje> :p
[20:05] <ricotz> Sarvatt_, any luck?
[20:19] <dupondje> jcristau: 
[20:19] <dupondje> (gdb) print *sgi_req
[20:19] <dupondje> $1 = {reqType = 98 'b', glxCode = 17 '\021', length = 3, vendorCode = 65539, pad1 = 3, screen = 0}
[20:29] <jcristau> dupondje: hrm.  that vendorcode makes no sense.
[20:30] <jcristau> #define X_GLXvop_GetFBConfigsSGIX               65540
[20:30] <jcristau> should be that one.
[20:30] <dupondje> thats what I get ;)
[21:07] <dupondje> jcristau: got enough debug info ? :)
[21:13] <jcristau> i suppose i should try and reproduce..
[21:13] <dupondje> the link on the bugreport page gives me a crash directly :)
[21:14] <jcristau> well i'm not running ubuntu..
[22:05] <bjsnider> Sarvatt, should i bother to update the maverick/lucid blob? sounds like they didn't do anything helpful
[22:05] <Sarvatt> bjsnider: I sure as heck ain't gonna do it, up to you if you want it in there but nope it doesn't look like its anything interesting
[22:18] <RAOF> Looks like we might want f67a559daaa0 from drm-intel if we want e6510 systems to work :)
[22:18] <dupondje> bryceh: I can reproduce 714280
[22:18] <dupondje> every single time :s
[22:21] <jcristau> dupondje: i assume it goes away if you set your locale to something en_*?
[22:21] <Sarvatt> RAOF: https://patchwork.kernel.org/patch/499221/ too for the backlight to actually work
[22:22] <jcristau> RAOF: who wants a display on a laptop anyway..
[22:22] <dupondje> LANG="en_US.UTF-8"
[22:23] <dupondje> no more crash ...
[22:23] <jcristau> dupondje: ok, at least that much makes sense.
[22:23] <bryceh> dupondje, interesting
[22:24] <dupondje> normally I use nl_BE btw
[22:24] <dupondje> if you want to try to reproduce
[22:26] <bryceh> nope, still no crash
[22:31] <dupondje> weird
[22:31] <dupondje> got to test smth
[22:31] <dupondje> brb
[22:34] <dupondje> ok, now thats the weirdest thing ...
[22:34] <dupondje> changed LANG back to nl_BE .. and guess what
[22:34] <dupondje> it doesn't crash ..
[22:37] <dupondje> ah ok
[22:37] <dupondje> page was in cache in firefox, and thats why :)
[22:38] <Sarvatt> RAOF: a new xserver git snapshot will change abi's in a way that breaks all input driver packages so there will be some turmoil.. we're depending on minor abi's too :(
[22:39] <RAOF> Yeah, that was a mistake.  Although I think we *may* have needed to rebuild anyway, because they'd behave strangly if not.
[22:39] <dupondje> bryceh: can you remove page from cache ?
[22:39] <dupondje> and try to view it with locale nl_BE.UTF-8
[22:39] <jcristau> dupondje: does glxinfo or glxgears crash?
[22:41] <dupondje> nope
[22:42] <dupondje> can you set LANG to nl_BE.UTF-8
[22:42] <dupondje> run firefox
[22:42] <dupondje> and view http://support.mozilla.com/gd/questions/753448 ?
[22:43] <jcristau> as i said, i'm not running ubuntu.
[22:43] <dupondje> @ bryceh  ;)
[22:43] <jcristau> ok :)
[22:43] <dupondje> btw
[22:43] <dupondje> [GLX] currently only allowing the NVIDIA proprietary driver, as other drivers are giving too many crashes. To bypass this, define the MOZ_GLX_IGNORE_BLACKLIST environment variable.
[22:44] <dupondje> never seen that message before ... 
[22:45] <jcristau> bryceh: fwiw the locale bit is strtod("1.4") not returning 1.4 if the decimal separator in the current locale.
[22:45] <jcristau> err, add "is not '.'" at the end there.
[22:45] <bryceh> dupondje, done, visited url in a restarted firefox with that LANG... no crashes
[22:46] <bryceh> jcristau, ahh
[22:46] <dupondje> weird
[22:47] <dupondje> http://paste.ubuntu.com/567494/
[22:47] <dupondje> looks clear now its the locale ;)
[22:48] <bryceh> dupondje, fwiw that GLX warning seems sensible.  -nouveau is kinda hit or miss for 3D
[22:49] <dupondje> i'm not on nouveau
[22:49] <dupondje> but ati
[22:49] <RAOF> That's actually mozilla blacklisting everything but the binary nvidia driver; WebGL won't work on intel or amd.
[22:49] <bryceh> oh wild
[22:50] <RAOF> Yeah.  There's a pretty big thread on mesa-dev@ about it, with mozilla and chromium devs complaining about libGL crashes when they enable it.
[22:50] <jcristau> dupondje: i have no idea why you don't get the same thing from glxinfo.  it seems to do GetFBConfigsSGIX too afaict..
[22:51] <bryceh> well, I suppose WebGL is still relatively new.  Probably depends on newer GL stuff the other drivers don't have yet.
[22:51] <RAOF> Actually, they were complaining that they couldn't even probe the driver in use without libGL crashing :)
[22:52] <RAOF> Both radeon and intel should now support all the features required, though.
[22:52] <dupondje> jcristau: I wish I could give you the answer :)
[22:53] <bryceh> jcristau, are you able to reproduce the crash?
[22:53] <dupondje> <jcristau> as i said, i'm not running ubuntu.
[22:53] <dupondje> :)
[22:54] <jcristau> need to try and download a natty cd at some point i guess
[22:55] <dupondje> I can debug some more if wanted
[22:55] <dupondje> just tell me what :)
[22:55]  * albert23 can reproduce the crash with http://support.mozilla.com/gd/questions/753448, not with the link in the bug
[22:56] <dupondje> locale ?
[22:56] <jcristau> maybe break without the _XReply in getFBConfigs, see what sgi_req looks like then.  or run firefox through xtrace or wireshark.
[22:56] <jcristau> s/without/before/
[22:56] <bryceh> xtrace would be good
[22:57] <albert23> dupondje: nl_NL
[22:57] <jcristau> xtrace 1.2.0 may be better if you have a chance to sync that
[22:59] <dupondje> never used xtrace
[22:59] <bryceh> dupondje, there's adequate help on it via google
[23:00] <jcristau> works pretty much like strace or ltrace, except for X protocol instead of syscalls.
[23:00] <jcristau> so something like 'xtrace -o my_firefox_trace firefox http://support.mozilla.com/gd/questions/753448'
[23:03] <dupondje> uploaded to the bug
[23:04] <dupondje> http://launchpadlibrarian.net/64420019/my_firefox_trace
[23:10] <jcristau> ok, so vendor_op=0x00010004 is indeed GetFBConfigsSGIX.  but the 40 in front of it is supposed to be the length, and that doesn't make sense.
[23:11] <jcristau> dupondje: can you get me an xtrace from glxinfo?
[23:13] <dupondje> sure
[23:14] <dupondje> http://launchpadlibrarian.net/64420572/glxinfo
[23:14] <dupondje> there
[23:14] <jcristau> oh crap
[23:15] <jcristau> glxinfo doesn't do setlocale()
[23:15] <jcristau> so it takes the glx 1.3 path
[23:17] <jcristau> bryceh: is the ubuntu stuff in git up to date, or missing some bits?
[23:18] <bryceh> jcristau, should be up to date
[23:19] <jcristau> hrm
[23:19] <jcristau> that doesn't have the right fixes
[23:19] <bryceh> jcristau, which package?
[23:19] <jcristau> mesa
[23:20] <jcristau> you want 4324d6fdfbba17e66b476cf008713d26cac83ad1 e27913f805acbb7d00f83ba625a8605576738a13 cbe9fc12a64c3ae89fd1b20e9e165aa4b76293a5
[23:20] <jcristau> 108_fix_leaks_dri2_screen_creation.patch is unrelated to that bug
[23:21] <dupondje> anyway
[23:21] <dupondje> I go sleeping :)
[23:21] <dupondje> if some more debugging/testing is needed, feel free to add to the bug or mail me :)
[23:24] <jcristau> dupondje: thanks
[23:25] <bryceh> jcristau, got it thanks
[23:26] <jcristau> i guess there was some confusion with dupondje linking a different commit from the bug
[23:26] <bryceh> yeah
[23:35] <bryceh> dupondje, jcristau, uploaded mesa with correct fix.  Thanks for investigating, hopefully it's fixed for good now, sorry for my confusion.
[23:35] <jcristau> thanks
[23:40] <RAOF> Sarvatt: Do you have any comments on my gallium fallback RFC?