[00:41] <RAOF> cnd: Hey, where's the canonical source for xorg-gtest?
[00:42] <cnd> RAOF, sadly, it's still my personal repo on fd.o
[00:42] <cnd> I'm still waiting for a fd.o sitewrangler to flip perms bits so it can move into xorg/test/
[00:42] <cnd> we're near a 0.1.0 release
[00:43] <cnd> I just need to not have other fires to put out :(
[00:46] <RAOF> )
[00:46] <RAOF> :)
[00:46] <RAOF> I can happily use it from your personal repo.
[00:55] <RAOF> cnd: And, just so that I can shamelessly copy some examples, where are some of your tests? :)
[00:56] <cnd> RAOF, check out lp:utouch-grail and lp:utouch-frame
[00:56] <cnd> in the test/ subdirs
[00:56] <cnd> RAOF, if you need to reply device recordings you'll find some nice classes in there
[00:57] <RAOF> That actually might be really useful.  At the moment I'll be happy with XTESTing the pointer around, I think.
[05:36] <RAOF> Sarvatt: The mesa ubuntu5 sitting in git - has that been uploaded?
[05:39] <Sarvatt> RAOF: nope
[05:39] <RAOF> Ok; I'll add more fixes to it.
[05:42] <Sarvatt> RAOF: 8.0 final is due any time now, possibly even in the next few hours
[05:43] <Sarvatt> if you're just cherry-picking things post rc2
[05:43] <RAOF> No.  I'm fixing up the -dev dependencies a bit more.
[05:44] <Sarvatt> oh cool, what else did you find?
[05:44] <RAOF> xcb-x11
[05:44] <RAOF> Bah.  x11-xcb
[05:51] <Sarvatt> sheesh, no wonder, clutter using EGL only on armel/armhf
[05:55] <Sarvatt> xcb-glx was the only one we hit between the other consumers of libegl-mesa-dev, edgers cairo wayland-demos and hadn't rebuilt mesa-utils but that would have failed too
[05:56] <RAOF> Sarvatt: You're happy for me to push mesa with the depends fixes now?
[05:56] <Sarvatt> RAOF: much appreciated
[05:59] <RAOF> Oh, bah.  Mesa doesn't build on a tmpfs because overlayfs sucks.
[06:01] <Sarvatt> pretty darn safe to say that wont fail to build :)
[06:02] <RAOF> I always like to check.
[06:02] <Sarvatt> PPA?
[06:02] <RAOF> It doesn't take *that* long to build on an i5.
[06:03] <Sarvatt> sandybridge? its about 9 minutes on an i7-2600 and ~20 on an i5-2557M
[06:05] <RAOF> Yeah, sandybridge.
[06:05]  * RAOF 's sad the i7 went to the big lenovo heap in the sky.
[06:06] <Sarvatt> RAOF: CRAP
[06:06] <Sarvatt> should have pilfered the CPU
[06:06] <Sarvatt> swapped with the i5 :)
[06:08] <Sarvatt> then again it's barely any different
[06:08] <RAOF> Did not occur to me :)
[06:08] <RAOF> Eh, a bit more cache, a bit higher clockspeed IIRC.
[15:41] <Sarvatt> ricotz: hey is precise broken after the eglibc updates on 295.17 too?
[15:45] <ricotz> Sarvatt, works fine here
[15:45] <ricotz> but i am running 3.3rc3
[15:50] <Sarvatt> ricotz: what version libc6 package?
[15:50] <Sarvatt> and have you rebooted since updating?
[15:51] <Sarvatt> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/929384
[15:51] <ubot4> Launchpad bug 929384 in nvidia-graphics-drivers (Ubuntu) (and 1 other project) "nvidia drivers broken by the recent libc update (affects: 17) (dups: 17) (heat: 176)" [High,Confirmed]
[15:59] <tseliot> cnd: how come did you update the changelog of X without any other changes in git?
[15:59] <cnd> tseliot, you'll have to ask tjaalton what happened
[16:00] <tseliot> cnd: never mind, it was some terminal corruption I guess...
[16:00] <tseliot> it looks fine now
[16:00] <cnd> ok
[16:00] <cnd> oh wait, I think it was Sarvatt
[16:00] <cnd> there was a snafu when he packaged it up last time
[16:00] <cnd> but all should be ok now
[16:02] <tseliot> it is
[16:12] <ricotz> Sarvatt,  2.15~pre6-0ubuntu10, and yeah i rebooted
[16:12] <Sarvatt> ok thats really good news
[16:14] <ricotz> but i am seeing problems with totem videoplayback (using clutter) not sure if it is related
[16:14] <ricotz> since there were some gstreamer and libav updates too
[16:26] <tseliot> ricotz, Sarvatt: I need to test it here (I'm updating my laptop) and then I'll upload nvidia
[16:28] <bryceh> tseliot, did you see 929384?  sounds like new elibc broke nvidia
[16:29] <tseliot> bryceh: it seems that the latest nvidia (beta) driver solves the problem ^^
[16:29] <tjaalton> ~15 lines above ;)
[16:29] <Sarvatt> bryceh: yes he knows :)
[16:29] <tjaalton> so we get to upload 1.12 now?
[16:29] <bryceh> great
[16:30] <tjaalton> isn't it that time of the cycle, where everything breaks before feature freeze
[16:30] <Sarvatt> tjaalton: ha, fglrx is busted with 1.11 and wont be fixed until 1.12 is supported, new nvidia upload will support it
[16:31] <tseliot> tjaalton: :D
[16:31] <tjaalton> Sarvatt: fglrx broken as well?
[16:31] <tseliot> Sarvatt: err, can we discuss fglrx in private?
[16:31] <Sarvatt> tjaalton: yeah xv crashes xserver
[16:31] <tjaalton> oh that
[16:31] <tjaalton> who needs xv anyway
[16:33] <Sarvatt> not like every video app uses it by default or anything
[16:37] <tseliot> :)
[16:41] <ricotz> Sarvatt, tseliot, yeah i am running 1.12 too which is another difference
[16:42] <Sarvatt> ricotz: eglibc problem in their libGL
[16:42] <tseliot> yep
[16:42] <Sarvatt> doubt xserver would matter
[16:42] <tseliot> let's hope it doesn't ;)
[16:43] <ricotz> ok
[16:46] <ricotz> tseliot, Sarvatt, but is sounds like this isnt specifically related to nvidia blob?
[16:49] <ricotz> maybe libc is broken
[16:49] <tseliot> ricotz: I haven't had the time to debug it properly. Apparently the issue can't be triggered with Mesa's libGL
[16:49] <tseliot> but yes, libc shouldn't break things like this...
[16:50] <ricotz> ok, my intel graphic is still running as it suppose to
[17:14] <jpds> bryceh: Hey, apw said that you might be able to help me with https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/929655
[17:14] <ubot4> Launchpad bug 929655 in xserver-xorg-video-intel (Ubuntu) "Unity randomly freezes after 11.10 upgrade (affects: 2) (heat: 12)" [Undecided,Confirmed]
[17:15] <bryceh> jpds, hi, what's up?
[17:16] <jpds> bryceh: I have someone with a laptop which keeps freezing and we're trying to figure out what the issue is.
[17:16] <bryceh> well lets take a look
[17:17] <apw> bryceh, its one of those 'invalid frambuffer id' jobs, this one restarting compiz allows the world to continue, so i am suspicious is userspace rather than kernel
[17:17] <apw> bryceh, and its an x60 so i'd expect it to work :)
[17:18] <bryceh> yeah it's not a gpu lockup
[17:18] <bryceh> jpds, it says in the report that only unity freezes?
[17:19] <jpds> bryceh: Yes, the entire graphical part just freezes up.
[17:20] <bryceh> jpds, anything printed to .xsession-errors when this occurs?
[17:22] <jpds> bryceh: Don't have a copy of that; will try and get it.
[17:22] <bryceh> jpds, I'm not spotting obvious errors in the kernel or X logs, aside from the "(EE) intel(0): Couldn't create pixmap for fbcon" that apw mentioned
[17:25] <apw> [11567.680932] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
[17:25] <apw> [11567.680943] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
[17:25] <apw> [11644.821929] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
[17:25] <apw> [11644.821937] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
[17:25] <apw> [11678.477663] init: tty1 main process ended, respawning
[17:25] <apw> [11680.331193] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
[17:25] <apw> [11680.331205] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id
[17:25] <apw> bryceh, those are in the dmesg, though a little back, that was the bottom at the time the issue occured i believe <- jpds
[17:26] <bryceh> jpds, have you tried booting without the xorg.conf?
[17:26] <jpds> bryceh: No.
[17:27] <bryceh> jpds, if there is one, move it aside, it's probably not needed
[17:28] <Sarvatt> invalid framebuffer id is 100% not a problem with anything, its just from the seamless transition not working when X is respawned from the display manager instead of from a normal boot
[17:30] <bryceh> Sarvatt, yep.  Wonder if we should silence that error to avoid the confusion
[17:31] <bryceh> or is that something that can be fixed in lightdm directly?
[17:32] <bryceh> jpds, got your hands on that .xsession-errors?  I think that's our main hope for diagnosing this.  It is sounding like the bug is in compiz rather  than X or the kernel; I'm hoping error messages in .xsession-errors will help prove or disprove that
[17:33] <jpds> bryceh: I'm awiting for sonia to reappear.
[17:34] <bryceh> Sarvatt, wish we could put .xsession-errors into the apport hook...
[17:41] <jpds> bug #870003 - weird.
[17:41] <ubot4> Launchpad bug 870003 in apport (Ubuntu) "Should collect xsession errors when the issue happens, not when the user reports it (affects: 1) (heat: 1)" [Medium,Triaged] https://launchpad.net/bugs/870003
[17:45] <bryceh> jpds, yeah we have the same problem with X bugs
[17:46] <bryceh> I've got apport hooks that run (or, SHOULD run) when X crashes, and when the GPU locks up
[17:46] <bryceh> I've my suspicions that they're not working 100%, but they're catching enough to keep us X guys fully occupied
[17:47] <bryceh> jpds, presumably compiz could use similar functionality
[17:54] <jpds> bryceh: Got it.
[18:01] <jpds> "gnome-session[1430]: CRITICAL: We failed, but the fail whale is dead. Sorry...."
[18:03] <bryceh> heh
[18:03] <bryceh> wtf kind of error message is that
[18:03] <bryceh> jpds, anything else?  that sounds like a generic fault handling error
[18:05] <jpds> bryceh: PM.
[18:08] <bryceh> (gnome-settings-daemon:1498): color-plugin-WARNING **: failed to reset xrandr-Lenovo Group Limited gamma tables: gamma size is zero
[18:08] <bryceh> ** (gnome-fallback-mount-helper:1522): DEBUG: ConsoleKit session is active 0
[18:08] <bryceh> gnome-session[1430]: WARNING: Application 'compiz.desktop' killed by signal
[18:08] <bryceh> gnome-session[1430]: WARNING: App 'compiz.desktop' respawning too quickly
[18:08] <bryceh> gnome-session[1430]: CRITICAL: We failed, but the fail whale is dead. Sorry....
[18:10] <apw> bryceh, so ... who to finger, compiz or unity :)
[18:10] <bryceh> apw, one of the two :-)
[18:10] <bryceh> probably next step is to enable more debug messages for compiz, or run it in gdb or some such
[18:11] <bryceh> these warnings actually just tell us what we already knew... compiz got stuck in a loop
[18:13] <apw> bryceh, ok, then i would suggest jpds does the gdb thing when it occurs next and we shove a compiz task on it for fun :)
[18:13] <bryceh> yep.  I can take care of the latter.
[18:14] <bryceh> also, could be entertaining to try booting into a guest session.  If *that* works, then possibly there's stray ccsm config or something in the user's session
[18:24] <apw> bryceh, thanks
[20:46] <ricotz> Sarvatt, good old eglibc ;)
[20:47] <ricotz> bryceh, ^ ;)
[20:47] <ricotz> and indeed i am on amd64
[20:48] <bryceh> ricotz, http://people.canonical.com/~doko/tmp/eglibc-2.15/i386/ looks like it may fix it
[20:49] <Sarvatt> ricotz: yeah see #ubuntu-devel, probably wont be too much longer till i386 fix for nvidia and x64 fix for audio is uploaded
[20:50] <ricotz> bryceh, everything amd64 here
[20:50] <ricotz> Sarvatt, yeah i guess i am hit by the audio one though
[20:50] <bryceh> ricotz, http://people.canonical.com/~doko/tmp/eglibc-2.15/ has amd64 too
[20:50] <ricotz> bryceh, thanks
[21:03] <bryceh> RAOF, hey is there a way to tune/disable the pointer barrier stuff?  it's a bit too grabby on dual head
[21:04] <seb128> bryceh, gnome-control-center, the appearance capplet, second tab has a slider?
[21:04] <bryceh> thanks
[21:05] <bryceh> seb128, actually that's not quite it
[21:05] <seb128> ok, dunno then
[21:06] <bryceh> that controls the speed that the dock pops up, but it appears the grabbiness of the pointer barrier is constant regardless of how that's set
[21:06] <bryceh> (possibly the two should be coupled in some fashion?)
[21:19] <Sarvatt> ricotz: oh yeah forgot to mention, i was trying to resurrect natty in edgers
[21:19] <Sarvatt> but llvm-3.0 is NOT happening
[21:19] <Sarvatt> it needs a binutils update
[21:20] <Sarvatt> don't care enough to conditionally switch mesa patches to llvm-2.9 just for natty so i'm just going to do libdrm and ddx updates automated and mesa by hand every week or so, thats what all the noise with failed builds was in the ppa yesterday
[21:21] <jcristau> you guys might want to sync up pixman 0.24.4.
[21:22] <Sarvatt> jcristau: just looked when you said uploaded, it takes an hour or two before we can, thanks for uploading that though!
[21:22] <Sarvatt> E: The versions in Debian and Ubuntu are the same already (0.24.2-1). Aborting.
[21:23] <jcristau> ah right it's only on ftp-master not on the mirrors yet
[21:24] <ricotz> Sarvatt, yeah, i noticed ;)
[21:24] <Sarvatt> ricotz: thanks for retrying the mesa ones, noticed ya fixed it :)
[21:24] <ricotz> Sarvatt, did you had a look at ppa:ricotz/unstable, if you feel like 1.12 for oneiric copy it and rebuild the world against it
[21:25] <ricotz> oh, i didnt hit retry ;)
[21:25] <Sarvatt> whoa
[21:25] <Sarvatt> i dont remember drinking that much last night..?
[21:25] <ricotz> ;)
[21:25] <ricotz> hehe
[21:26] <Sarvatt> ricotz: wow, i think ppa's actually auto retry depwaits now
[21:26] <ricotz> oh, a depwait then this could be
[21:27] <Sarvatt> wasnt awake 13 hours ago to do it
[21:28] <ricotz> it probably doing it automatically then
[21:46] <RAOF> bryceh: That's not really my department (although I am still trying to get the velocity calculations to be more useful); DBO is your man for that.
[21:50] <Sarvatt> guess i should have refreshed the bug before marking the nvidia task invalid https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/929384
[21:50] <ubot4> Launchpad bug 929384 in glibc (Fedora) (and 2 other projects) "nvidia drivers broken by the recent libc update on i386 arch (affects: 31) (dups: 23) (heat: 278)" [Unknown,Unknown]
[21:51] <bryceh> Sarvatt, maybe leave it open assigned to tseliot for him to track?
[21:52] <Sarvatt> sounds good, he was going to bring it up with nvidia on a call
[22:05] <Sarvatt> hopefully i dont screw something up cherry-picking RAOF's mesa fix to debian-experimental this way http://paste.ubuntu.com/835828/
[22:06] <RAOF> Oh, yeah.  I should have committed that to the debian-experimental branche, too.
[22:06] <RAOF> That looks right to me; thanks Sarvatt.
[22:57] <bryceh> RAOF, seems there are easily half a dozen bugs already filed on it
[22:57] <RAOF> Against xorg?
[22:57] <bryceh> unity
[22:58] <RAOF> Yeah.  As I say, I'm trying to work out how to give better data to unity.
[22:58] <Sarvatt> yay mesa 8.0
[23:18] <Sarvatt> still can't requestsync pixman
[23:51] <cnd> RAOF, bryceh: got a bit of a quandry
[23:51] <cnd> I have clickpad support working
[23:51] <cnd> it's pretty nice
[23:51] <cnd> it still has some issues with semi-mt devices, but overall it's a much-needed improvement
[23:52] <cnd> however, on synaptics semi-mt devices (and maybe others too) the mt data used for clickpad behavior comes at a different scan rate
[23:52] <cnd> this throws the pointer velocity acceleration profile off
[23:52] <cnd> so it feels like the pointer moves twice as fast
[23:53] <cnd> I don't know what to do :(
[23:53] <RAOF> Why does the reduced scan rate thorw the velocity calculation off?
[23:53] <cnd> maybe if it's synaptics branch we can kludge it by dividing the hw motion by some magic number?
[23:53] <cnd> RAOF, no idea
[23:54] <RAOF> The stuff that I've seen calculated velocity as dx/dt, which should be rate-independent.
[23:54] <cnd> one would think
[23:57] <bryceh> cnd, dividing by 2 sprang to mind, however I'd worry that would just mask bugs that'd only get found later
[23:57] <cnd> yeah
[23:58] <cnd> bryceh, I was thinking maybe for semi-mt synaptics trackpads only, divide by 2
[23:58] <bryceh> cnd, is your question about how to fix the issue, or more about whether to push it into the repo vs. hold back until it's solved?
[23:58] <cnd> well, both actually
[23:58] <bryceh> ok thought so ;-)
[23:59] <RAOF> It sounds like something I'd want to push to a PPA and get some opt-in testing.
[23:59] <bryceh> yeah, personally I'd also be reticent having it go in until the issue is at least understood if not fixed