[00:07] <Azelphur> Sarvatt: awesome I'll get on your repo and let you know  :)
[00:08] <Sarvatt> Azelphur: thanks, the patch seems to address your exact problem even though the description leaves a lot to be desired :)
[00:08] <Azelphur> hehe
[00:39] <Sarvatt> http://www.spinics.net/lists/dri-devel/msg06034.html -- so THATS why it wasn't working with hdmi!
[02:25] <Sarvatt> I guess input-utils needs rebuilding pretty often now?
[02:25] <Sarvatt> sudo lsinput
[02:25] <Sarvatt> /dev/input/event0
[02:25] <Sarvatt> protocol version mismatch (expected 65536, got 65537)
[02:25] <Sarvatt> works when rebuilt
[02:44] <RAOF> Sarvatt: Yeah, roughly once per kernel rev.
[05:44] <DanaG> Say, how do you use synclient -m without SHMConfig?
[05:44] <DanaG> Can't access shared memory area. SHMConfig disabled?
[05:44] <DanaG> They say SHMConfig has been replaced by xinput... but xinput can't do -m.
[05:45] <DanaG> 3 lines in xorg log:  (--) Apple Wireless Trackpad: no supported touchpad found    (EE) Apple Wireless Trackpad Unable to query/initialize Synaptics hardware.   (EE) PreInit failed for input device "Apple Wireless Trackpad"
[05:45] <DanaG> I removed line breaks, of course.
[05:46] <DanaG> I do have shmconfig on... but it's ignoring it.
[05:46] <DanaG> shmget(0x5d8b, 96, 0)                   = -1 ENOENT (No such file or directory)       shmget(0x5d8b, 0, 0)                    = -1 ENOENT (No such file or directory)
[05:48] <DanaG> As far as I'm concerned, that's a regression.  They should've made the SHM area read-only and root-only.
[05:49] <DanaG> Maybe I should file a regression bug-report.
[05:49] <DanaG> odd, despite that error, edge-scrolling still works.
[05:51] <DanaG> Two-finger does not work, thanks to Gnome.  :(
[05:52] <DanaG> Can't do both together.
[06:48] <Sarvatt> RAOF: did you see your alt+tab bug was fixed? https://bugs.freedesktop.org/show_bug.cgi?id=32246
[06:48] <ubot4> Freedesktop bug 32246 in Drivers/DRI/R600 "Compiz 0.9 switcher segfaults in mipmap generation code" [Normal,New]
[06:48] <Sarvatt> new mesa uploading now
[08:14] <RAOF> Sarvatt: Awesomesauce.
[08:14] <RAOF> I'm surprised that's the fix, though.
[08:14]  * RAOF clearly doesn't (yet?) understand the mesa code.
[09:58] <hyperair> Sarvatt: all the compizes crash iwth latest mesa. what happened?
[09:58] <hyperair> http://paste.debian.net/101951/
[10:04] <Sarvatt> hyperair: what gpu again?
[10:06] <hyperair> 965
[10:06] <hyperair> 8086:2a02
[10:07] <Sarvatt> thanks, passed it along to anholt
[10:08] <hyperair> yeah i saw, thanks
[10:08]  * hyperair starts downgrading his mesa
[10:08] <RAOF> Aaah, constant buffers.
[10:09] <hyperair> there also seem to be some weird issues with fonts
[10:09] <hyperair> like weird font corruption that fixes itself a little later
[10:09] <Sarvatt> yeah they've been going back and forth on that one in #intel-gfx for the past few days
[10:09] <hyperair> ah
[10:11] <Sarvatt> oh wait, http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=9b967807c2d240488a715509649663aac3583532 isn't the in ppa
[10:11] <hyperair> Sarvatt: oh yeah everything's rendering smoothly but with significant latency, like half a sec late.
[10:11] <Sarvatt> new one uploaded
[10:11] <hyperair> weird
[10:12] <hyperair> ok
[10:13] <Sarvatt> i'll revert that mesa commit for now too
[10:14]  * Sarvatt has to be up for work in 3 hours, ha!
[10:14] <hyperair> lol
[16:55] <Azelphur> Sarvatt: your patch looks good, havn't had a crash yet.
[18:07] <Sarvatt> sent all the --no-add-needed patches to the xorg-devel list so they should hopefully stop needing Makefile.in patches in the next 5 years, hope I didn't miss any :)
[18:13] <Sarvatt> I fail at git send-email, didn't mean for them to be threaded
[18:27] <Sarvatt> ha, need to point people complaining about i915 wakeups at this thread http://comments.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/2439?set_lines=100000
[18:28] <bryceh> lengthy thread
[18:29] <Sarvatt> tldr; showing seconds in the clock applet with compiz kills the battery
[18:30] <bryceh> yeah that's kind of funny (in a sad way)
[18:48] <bdmurray> I'm planning on consolidating some fglrx package bugs about build failures that contain "kcl_ioctl.c:196: error: implicit declaration of function ‘compat_alloc_user_space’
[18:48] <bdmurray> in the DKMSBuildLog okay?
[18:50] <bdmurray> bryceh: ^
[18:50] <Sarvatt> bdmurray: what release are they using?
[18:51] <Sarvatt> afaik the fix is released to all releases back to lucid
[18:51] <Sarvatt> they just need to enable -updates
[18:51] <bdmurray> Hmm, I see the following 8.771 8.723.1 8.780 - could check releases in a minute
[18:52]  * Sarvatt double checks
[18:52] <Sarvatt> bdmurray: ah I see the problem
[18:52] <Sarvatt> only natty has it fixed for 2.6.37 kernels
[18:53] <Sarvatt> the dkms patches were limited to 2.6.36 in the previous fix
[18:53] <bdmurray> Sarvatt: okay, but its all the same bug?
[18:53] <Sarvatt> yep, lucid and maverick fglrx needs an update to work with 2.6.37+
[18:53] <bryceh> bdmurray, merging fglrx bug reports sounds good
[18:54] <Sarvatt> tseliot didn't like me fixing natty so should assign it to him :)
[18:54] <bdmurray> now, I'm not gonna get involved in personal issues like that ;-)
[18:56] <Sarvatt> bdmurray: really though, it's because he maintain the packaging in git that the OEM's pull from to make releases so he's got to fix it
[18:57] <Sarvatt> it's a really simple fix, the regex matches in debian/dkms.conf.in need updating to not only apply to 2.6.36
[18:57] <bdmurray> Sarvatt: actually shouldn't these be a dup of the one you fixed?
[18:57] <Sarvatt> good point, I don't have permission to open lucid and maverick tasks for it though
[18:58] <bdmurray> Sarvatt: I can help with that if you tell me the bug number. ;-)
[18:58] <Sarvatt> bug #671868
[18:58] <ubot4> Launchpad bug 671868 in fglrx-installer (Ubuntu) "package fglrx 2:8.780-0ubuntu2 failed to install/upgrade: fglrx kernel module failed to build (affects: 1) (heat: 109)" [High,Fix released] https://launchpad.net/bugs/671868
[19:05] <Sarvatt> pain in the butt having to dig in the logs of all of these bugs though, failed to install/upgrade: fglrx kernel module failed to build is usually also a header package problem
[19:11] <bdmurray> Sarvatt: if you tell me what to look for in the logs its not hard for me
[19:20] <Sarvatt> bdmurray: go figure all of the ones I've looked at so far need eyes on them, most were people installing fglrx manually and things were in an inconsistent state
[19:21] <bdmurray> ah that sucks
[20:21] <bdmurray> Sarvatt: what about build failures due to not matching the current kernel?
[20:22] <Sarvatt> *usually* it happens because they have -generic metapackages installed but a generic-pae kernel and there is no way to make fglrx require the correct type of headers
[20:22] <Sarvatt> (same problem with any dkms package there)
[20:44] <RAOF> Sarvatt: I thought that prospective fix for the mipmap crasher was odd, and indeed it doesn't fix it :)
[20:47] <Sarvatt> really? you had maxLevels = 15 in your backtrace and someone on #radeon mentioned bumping what he pushed fixed etuxracer aborting so had me hopeful
[20:50] <Sarvatt> this libsm libxt libxmu .pc thing looks like it'd fix hundreds of ftbs' if we reverted it, or am I misunderstanding?
[20:51] <Sarvatt> most of the failures i've come across are from things having xt in PKG_CHECK_MODULES and not picking up -lX11
[20:54] <RAOF> Let me see...
[20:55] <Sarvatt> we're removing x11 from Requires: in the .pc for xt and xmu/xmuu, and ice from sm
[20:55] <Sarvatt> so -lX11/-lICE gets dropped 
[20:56] <RAOF> That might not actually be the correct solution, though.
[20:56] <Sarvatt> I wish this --no-add-needed crap waited until after squeeze released so we didn't have hundreds of modified packages
[21:01] <RAOF> Hm.  It looks like Xmu should at least have a requirement on Xt; it's headers call Xt functions in #defines.
[21:11] <RAOF> Man, I'm glad that Xmu is able to handle systems with 6-bit bytes.
[21:13] <jcristau> Sarvatt: i'd be ok with reverting these changes fwiw
[21:14] <jcristau> a bit sad, but meh.
[21:18] <RAOF> As I mentioned above, I think the dropping of the Xt requires is wrong; the headers have #defines which use Xt symbols.  The other drops still look correct.
[21:18] <jcristau> ok
[21:21] <RAOF> Can I commit that to debian-unstable?
[21:23] <RAOF> Hm.  Why does libxmmu not ship any headers at all?
[21:24] <RAOF> Bah.  Because dependency chain.
[21:25] <jcristau> headers are in libxmu-headers iirc
[21:25] <RAOF> Yeah, found that.
[21:30] <Sarvatt> looks like xless is the only one that'll be fixed by that so far
[21:30] <RAOF> Possibly Xt needs an X11 requires? :)
[21:31] <RAOF> Alternatively, a lot of build systems have wrong dependencies.
[21:32] <jcristau> also something we're patching out..
[21:32] <RAOF> Yeah, I'm checking Xt now
[21:32] <Sarvatt> most things fail at x11 before hitting the xt failure so it probably fixes part of lots more
[21:33] <jcristau> Xt without Xlib doesn't really make sense, so would probably not hurt to put it back
[21:33] <jcristau> dunno about sm
[21:34] <Sarvatt> 136 ftbs with  libX11.so.6: could not read symbols: Invalid operation
[21:35] <Sarvatt> hmm those are --as-needed failures aren't they
[21:35] <Sarvatt> --no-add-needed shows up with the undefinied reference errors on http://udd.debian.org/cgi-bin/ubuntu_ftbfs.cgi
[21:37] <RAOF> Yup, there we go.  Xt uses XMapWindow in a #define in one of its public headers, hence needs -lX11
[21:40] <RAOF> And now, for libsm
[21:41] <jcristau> libSM seems only used for a SmcConn member in Xt's SessionShellPart
[21:42] <RAOF> Oh, I was only looking for X11 references in Xt!
[21:48] <RAOF> And libSM doesn't use any libICE symbols in it's headers; the dropped Requires is correct.
[21:51] <RAOF> jcristau: Are those Requires fixes acceptable for debian-unstable, or debian-experimental, or shall we take an Ubuntu delta?
[21:52] <jcristau> -unstable works
[22:04] <Sarvatt> so the libSM .pc change should go upstream possible and then the smproxy ice addition to PKG_CHECK_MODULES is the only one that'd be needed out of the series I guess
[22:04] <Sarvatt> or we can just patch that :)
[23:34] <Sarvatt> RAOF: fixed as in it was only reported against earlier lucid and I haven't seen any other reports about it, I'm not completely sure
[23:35] <Sarvatt> bah, wrong channel sorry
[23:35] <RAOF> Sarvatt: I'm pretty sure it got fixed by not using the drm renderer on nouveau :)
[23:35] <Sarvatt> well it would fall back to that same behavior if we ditched the vesafb junk :)
[23:36] <RAOF> :)
[23:39] <Sarvatt> what it looks like to me currently is: vesafb loads, picks 640x480x8 or whatever, plymouth loads framebuffer renderer and starts using that, hands off to drmfb and gets resized up to native but plymouth is still drawing to the lower color framebuffer. that's all conjecture though
[23:40] <Sarvatt> will try forcing a different mode next time i reboot to see
[23:43] <RAOF> Good plan; I'll do the same.
[23:45] <Sarvatt> oh - [    1.673571] vesafb: mode is 640x480x32, linelength=2560, pages=0
[23:46] <Sarvatt> can't remember how to get the good logs out of plymouth I used to figure out what renderer backend it was using a long time ago..
[23:47] <Sarvatt> ah plymouth:debug and its in /var/log/