[01:02] bryceh: Revised mesa with better changelog, debian changelog in source.changes, and actual building on i386 is up on cooperteam.net. [01:05] RAOF, awesome thanks [01:06] Oh, and perhaps incidentally, it also works ;) [01:06] RAOF, btw the previous mesa had been failing to build [01:06] # Also get rid of other files which aren't installed. Do not [01:06] # use -f to ensure we notice disappearing files: [01:06] set -e; for file in dri/usr/include/GL/glfbdev.h dri/usr/include/GL/glu.h dri/usr/include/GL/glu_mangle.h dri/usr/include/GL/mesa_wgl.h dri/usr/include/GL/osmesa.h dri/usr/include/GL/vms_x_fix.h dri/usr/include/GL/wglext.h dri/usr/include/GL/wmesa.h dri/usr/lib/libGL.so dri/usr/lib/pkgconfig/gl.pc usr/include/GL/glext.h usr/include/GL/glfbdev.h usr/include/GL/gl.h usr/include/GL/gl_mangle.h usr/include/GL/glxext.h usr/include/ [01:06] v/pkgconfig/gl.pc ; do rm debian/tmp/$file; done [01:06] rm: cannot remove `debian/tmp/usr/lib/i686/cmov/libGL.so': No such file or directory [01:06] make: *** [binary-arch] Error 1 [01:06] dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 [01:06] E: Failed autobuilding of package [01:06] bryceh: Yeah, that's what I fixed for i386. [01:06] hadn't had a chance to investigate it yet though. Will try again with your new package [01:06] if you were to build that package on amd64 it would have built just fine :) [01:07] It's becaues Debian build i686 swrast packages on i386 and we don't. [01:07] Or even because. [01:08] huh interesting [01:08] dpkg-source: info: upstream files that have been modified: [01:08] mesa-7.10.1~git20110215.cc1636b6/src/mesa/drivers/dri/common/dri_util.c [01:08] mesa-7.10.1~git20110215.cc1636b6/src/mesa/drivers/dri/radeon/radeon_bocs_wrapper.h [01:08] Yeah. From debian's cherry-picks. [01:09] Debian cherry-picks into the debian diff, and I think we should too. [01:09] It means the cherry-picks get automatically dropped when they get included in the upstream tarball. [01:12] Hm. Sam's out at work. I'll have to make my *own* coffee this morning! [01:16] heh [01:16] I will be joining you in a cup, even though it's after 5pm [01:31] go little processor go, let's get this mesa built [01:32] I could throw up binaries if you wanted. [01:35] nah it just finished [01:35] might not be a bad idea in the future though [01:36] otoh can't hurt to doublecheck the build [01:37] I'm installing libgl1-mesa-dri_7.10.1~git20110215.cc1636b6-0ubuntu1_i386.deb libgl1-mesa-glx_7.10.1~git20110215.cc1636b6-0ubuntu1_i386.deb libgles2-mesa_7.10.1~git20110215.cc1636b6-0ubuntu1_i386.deb [01:38] anything else worth putting in for testing purposes? [01:38] well, lets start with this... rebooting [01:39] ... [01:39] * RAOF is too slow :) [01:43] metacity looks fine... [01:44] ew, unity looks like trash [01:45] What card? [01:45] RV770 [01:46] actually it was fine after I did a screen refresh [01:46] guessing it's a dual-head issue, since only the left screen showed it [01:47] Ah, yeah, entirely possible. [01:47] (it redrew the left portion of the screen in the middle of the screen) [01:47] anyway, otherwise so far so good [01:47] Nux is easily confused about where things should be. [01:47] also to be honest I'm not sure that effect might have been there previously [01:47] Apart from, I presume, alt-tab still segfaulting in mipmap generation code :) [01:47] oh yeah lemme try that [01:48] (Still segfaulted here, and also did so on master, so I'm quite confident that yours will segfault too ;)) [01:48] Oh. That looks ominous! [01:49] yep sure did [01:49] also, left screen weirdness reproduces 2-for-2 [01:49] Is there any dynamic xrandr happening? [01:49] fonts are all stretched out [01:50] Is gdm cloned, and on login unity starts before g-s-d sets up the spanned desktop? [01:50] * RAOF doesn't see that, possibly because g-s-d sets up the second head before unity has got far enough to care. [01:50] gdm is not cloned [01:51] Although it sounds exactly like what happens when I plug or unplug a second head. [01:51] I set up side-by-side dual head and set as system default [01:51] so login prompt appears only on the left screen [01:51] but [01:51] I have a bunch of apps that start up in my .xprofile [01:51] and I've found they sometimes will initiate prior to the window manager being "done" loading [01:52] so I get fun things like xchat not having the themed decorations, and gnome-terminal windows that shift around once the panels launch [01:53] goodness unity is buggy [01:54] if the launcher is over a gnome-terminal session, gnome-terminal appears to steal the mouse events [01:54] I should possibly take up Jason's call and do the (apparently pretty easy) dynamic xrandr integration stuff. [01:54] Hm, that doesn't happen here :) [01:55] fwiw I'm also running apw's 2.6.38-4-generic pre-release kernel thingee, although that probably doesn't matter [01:55] (however now plymouth works all of a sudden) [01:56] Heh! [01:56] RAOF, bryceh: an update: I've got touch events integrated into the pointer event stream properly now [01:56] after redoing most of the stack [01:56] cnd: Yay! [01:56] ironically for ~1-2 min boot it displays the ubuntu logo for barely 1 sec [01:56] I'm now just fixing up touch event handlin [01:56] g [01:57] the code is a bit of a mess right now, so once I have it working I need to clean it up a little [01:57] cnd: I think it's a fair call that Xserver 1.10 is not being released today; when do you want to incorporate Xi 2.1?L [01:57] but it will still be hairy when it's ready to go, probably early next week [01:57] cnd, so I take it you wouldn't like to hear that the unity guys want us moved back to xserver 1.9 so -nvidia will work? [01:57] bryceh, (!)? [01:57] as in, roll back for natty? [01:58] or roll back just for right now? [01:58] I had heard the nvidia drivers still worked, but there was some politics with abi versioning and the distro [01:58] cnd, just kidding (although they did ask...) [01:58] gah! [01:58] if you can't tell, I'm a bit on edge... [01:59] [01:59] been working the last 11 days straight [02:00] and I've been bashing my head against the wall trying to figure out pointer grabs :) [02:00] took me three days to figure it out [02:00] there can't be many people in the world who understand it... [02:00] The few, and the proud. [02:00] I'd venture a guess of only 3 now :) [02:01] I can't say I'm very proud [02:01] I'm very afraid [02:01] that kinda describes a lot on the XInput side of things [02:01] afraid that any time there's a bug in xinput now, I'll have to handle it :) [02:02] yay! [02:02] I'm not sure that should be a fear so much as a certainty. [02:02] :( [02:02] ok, it's 9 PM here and I think things are headed in the right direction [02:03] so I'm going to call it quits for the evening [02:03] night cnd [02:03] bryceh, RAOF: btw, when would you say is drop dead date for getting stuff into ubuntu before feature freeze? [02:03] I'm aiming to have things ready on monday, but just in case [02:04] Absolutely drop-dead? Probably wednesday evening, my time. [02:04] RAOF, ok, hopefully it doesn't come to that :) [02:04] btw, I'll be dropping X MT support for trackpads... [02:05] I just don't think the protocol makes sense for trackpads as it is [02:05] so it'll sadly just be touchscreens that get all the gooey xi 2.1 stuff [02:05] If push comes to shove I can do another FF firedrill. [02:05] RAOF, I don't think anyone wants that again :) [02:05] hmm, I probably should focus on wayland for a few days and get some stuff updated there before FF [02:06] Yeah, probably a winner. [02:06] Hm. I wonder if “doesn't absolutely suck when plugging in monitors” would be regarded as a Unity feature :) [02:07] RAOF, the real question is do we have any recourse when it does? [02:07] I mean, aside from classic ;-) [02:07] Well, that would be a slam-dunk FFe I guess. [02:12] Does this work now that I'm no longer strnduping a random memory address? Lets ask Science! [02:15] * apw wonders if others have noticed as sudden change in brightness control, i think i am getting 3 brightness changes for each key press ... confirmed there is only on press in the input stream [02:15] RAOF, I'm going to call this mesa good. I've run several gl-ish things and am satisfied it's not going to bugger children. Any last minute regrets? [02:15] RAOF, does unity dump core for you if you plug a wide monitor into your intel kit? if i end up with more than 2k width it just exits [02:16] bryceh: I haven't thought of any regrets yet :) [02:16] alrighty here we go [02:17] apw: I “happily” get above 2k width (modulo the crazy positioning), but this is a GM45 which has a nice big texture limit. [02:17] Canonical should sponsor me a couple of nice big monitors so I can test other, non-laptop things :) [02:18] yeah i hear its a texture limit [02:19] compiz probably shouldn't dump core, but it also probably won't work. [02:19] it should refuse to start up in such a case [02:19] Unless dx feels like making compiz use RandR 1.4 where available. [02:20] At which point it actually *could* work, as long as no head is individually > any of the texture limits. [02:20] * RAOF suspects RandR 1.4 support is *way* down the TODO. [02:20] so it sounds like there no plan to fix this? [02:21] that common platforms will be working, plug in a projector and blam [02:21] Does metacity kick in nicely? [02:21] nope you end up dead in the water with no window manager, well last i checked [02:21] If nothing else, that should be fixed. [02:21] [ubuntu/natty] mesa 7.10.1~git20110215.cc1636b6-0ubuntu1 (Accepted) [02:22] * apw sighs, one more thisn to test [02:22] Woot! Now that I'm not trying to copy a random piece of memory as a file path this works :) [02:22] bryceh, more fun coming down the pipe? [02:24] Well, it will at least allow nvidia users to test unity :) [02:25] ohh that reminds me, i am seeing corruption on scroll in gnome-terminal, sort of foreground stippling over the text [02:25] alright that's enough unity for me [02:25] have been for some time, known? [02:25] apw, yep new mesa snapshot [02:25] heh fun fun fun [02:26] apw, funny you should ask, I just went through a bunch of terminal corruption bugs today [02:26] hopefully that -4 kernel will be accepted tommrrow, seems i missed the AAs today [02:26] crap, forgot to test that with unity [02:26] apw, anyway so far there are 3 different terminal corruption bugs we know about (all different) [02:26] i see it come and go on scroll up, and at times i have felt it was 'repeatable' such that a scroll down where available would reverse it [02:27] heh, then till some of those are gone i'll assume its known :) [02:27] is that a compiz issue or more mesa-ery [02:28] my guess would be you're having this one - https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/717114 [02:28] Launchpad bug 717114 in xserver-xorg-video-intel (Ubuntu) "[i945gm] Screen Corruption with new Xorg stack with terminal programs (affects: 4) (dups: 1) (heat: 22)" [Medium,Incomplete] [02:29] apw, at this point we don't know what's to blame. I posted some questions to the bug to help narrow it down [02:29] apw, any thoughts or insights you can share might help (e.g. maybe you can help rule out the kernel as a suspect) [02:30] yeah see them [02:30] offhand I'm going to guess we have some mesa issues, and I'm curious if raof's new mesa I just uploaded will help [02:30] i'd say its improved, is less reproducible recently [02:31] i've been ignoring it, i'll try and get a feel for how often i really see it [02:31] and then try out the older kernel [02:33] bryceh, i assume you know what it looks like. i have it right now in a wndow where scrolling down one shows it, one more and its ok again and reversing through the same 3 lines seems the same [02:34] apw, here's what I'm guessing - https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/710961/+attachment/1831040/+files/Still-Present.png [02:34] Launchpad bug 710961 in xserver-xorg-video-intel (Ubuntu) "[i945gm] Screen Corruption with new Xorg stack (dup-of: 717114)" [Undecided,Incomplete] [02:34] Launchpad bug 717114 in xserver-xorg-video-intel (Ubuntu) "[i945gm] Screen Corruption with new Xorg stack with terminal programs (affects: 4) (dups: 1) (heat: 22)" [Medium,Incomplete] [02:34] looking closly at it, the 'dammage' is actually a ghost of what was on that line before the scroll, about half the lines vertically have not been cleared [02:36] apw, is this with compiz or without? (Classic Desktop w/out effects?) [02:36] its more pronnounced than that, but the same range, exactly two lines of fookage each time it occurs [02:36] this is with unity, compiz [02:37] the example there is also exactly two lines of text which are bust [02:37] Hm. That looks a bit like the damage bug that got fixed in -1ubuntu6. [02:37] alright lemme restart into unity and try reproducing it myself [02:38] RAOF, i updated earlier today, whats that version of so i can check [02:38] xserver-xorg-video-intel; it's quite old, though, so you almost certainly already have it. [02:39] 2:2.14.0-1ubuntu9 [02:39] bryceh, i find that its normally most obvious in a long less [02:39] i also note its pretty much output specific [02:40] ie if you see it on a couple of lines of a less output, it willl be there again if you scroll [02:40] a few pages away and back to the same point [02:41] That's a bit strange. I don't think there's anything Xy that should do that sort of caching except for the glyph cache. [02:43] And that doesn't look like glyph cache corruption. [02:45] hmm, not seeing anything weird with xterm+less+kern.log or gnome-terminal+less+kern.log [02:46] well, with xterm I notice the border seems messed up [02:46] ah not messed up, just transparent. Weird. [02:47] compiz shadow is really irritating [02:47] RAOF, ok this corruption is definatly in the window, it can be covered and exposed and its still in there [02:48] apw do you see it *only* with terminals or does it show up in any other client apps? [02:48] e.g. scrolling slashdot.org in firefox [02:48] i have never notices any corruption of anything else no [02:49] not for launchpad pages for instance which i use almost as much [02:49] Hm. (a) why is the crda regulatory daemon setting my zone to FR, (b) my, aufs is generating a lot of dmesg backtraces. [02:50] hmm, unity is significantly more tolerable with gnome-panel manually launched [02:50] xterm doesn't seem to be having any troubles here. [02:50] yeah no corruption for me either [02:51] apw, what video driver, -intel? [02:51] http://people.canonical.com/~apw/misc/corruption.png [02:51] intel yes [02:51] this is a N450 netbook [02:51] oh you know what, I override the default terminal theme stuff [02:51] That looks like it's reasonably easy to generate? [02:52] N450 means... i945? [02:53] note that the shadowing is clearly text which is not on the window, but has been visible recently [02:53] 00:02.0 VGA compatible controller: Intel Corporation N10 Family Integrated Graphics Controller [02:54] The shadowing? You mean, the interleaved text? That looks like it's from quite nearby in the buffer. [02:54] apw: grep "intel(0): Chipset:" /var/log/Xorg.0.log? [02:54] yeah its from nearby but not the page above or below [02:54] [ 13.397] (--) intel(0): Chipset: "Pineview GM" [02:55] yeah even with default theme, not reproducing on -ati / rv770 [02:55] Not reproducing on GM45 [02:55] although this is with the new mesa and your -rc4 kernel [02:56] Ok. g33 [02:56] Ah, that's why unity hates big screens, too. [02:57] (For you). [02:57] yeah a very very common platform, we need to replace all those macs in design with soemthing normal people have [02:57] so they get some pain from these kinds of bugs [02:57] mm, this is new: [02:57] [ 685.163321] [drm:subconnector_show] *ERROR* Unable to find subconnector property [02:57] [ 685.163349] [drm:select_subconnector_show] *ERROR* Unable to find select subconnector property [02:57] [ 685.222891] [drm:subconnector_show] *ERROR* Unable to find subconnector property [02:57] [ 685.222917] [drm:select_subconnector_show] *ERROR* Unable to find select subconnector property [02:58] * RAOF wonders idly how hard it would be to port compiz to RandR1.4 to stop apw bitching :) [02:59] Hm. If I reboot my irc bouncer and flip the bios switch I can also have access to an i915-driven GPU. [03:00] RAOF, my plan is to offer my laptop to our leader for a presentation and see how long it takes to get fixed after it explodes [03:00] :) [03:01] bryceh, well none of the code which produces that error is new ... so hrm [03:01] apw: does it go away if you move the mouse to the top left of the screen? :) [03:01] Sarvatt, which ? [03:01] apw: Bigger question is would you still be around to find out? [03:02] apw: the corruption, sorry [03:02] ScottK, heh indeed [03:03] Sarvatt, heh no, i get a nice unity launcher pop over it, but no change in the corruption [03:03] also curious if it happens on .37 [03:03] ah alrighty, saw one case of a corruption problem with a fix just posted on the intel-gfx list but they said it went away when the mouse was in the top left [03:04] now that is somewhat odd fix is it not? [03:04] yeah .37 is my next test [03:05] nah they fixed it properly, that was just a symptom the guy had [03:05] http://permalink.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/2949 [03:05] 2.6.38 is proving to be all kinds of "fun" on intel [03:06] tell me about it [03:07] ok back ... on .37 ... the triple brightness issue is still here so i can ignore that as a kernel issue [03:11] its hard to prove a negative, but i've done more wibbling to reproduce it, i managed to reproduce it 3-4 times in the same period on .38, nothing so far on .37 [03:13] mm interesting [03:13] Oh, hurrah. [03:14] apw, btw while we have your attention... any updates on the -intel/vesafb conflicts (bug #702090)? the bugs keep rolling in daily on that one [03:14] Launchpad bug 702090 in xserver-xorg-video-intel (Ubuntu Natty) (and 4 other projects) "i965gm GPU lockup if vesafb is left loaded (EIR: 0x00000010 PGTBL_ER: 0x00000100) - *ERROR* EIR stuck: 0x00000010, masking (affects: 36) (dups: 25) (heat: 287)" [High,Triaged] https://launchpad.net/bugs/702090 [03:14] bryceh, not had a chance to fiddle with the ordering there [03:14] mr watson and i were meant to get together to discuss it this week and its nto yet happened hrm [03:16] apw: if 2.6.38-rc1 works too you might want to try https://patchwork.kernel.org/patch/571511/ and https://patchwork.kernel.org/patch/572241/ [03:17] how the heck does it work without those ! [03:19] <3 2.6.38 so far [03:20] broadcom fail in it invalidated 3 days of hibernate testing here, i'm grumpy :) [03:21] broadcom is always fail [03:23] apw: those commits are in drm-intel-next too, not sure when you guys build those? could just check in the morning [03:26] we rebuild at 10am utc i think it is [03:28] ahh awsome that 'skip FDI & PCH enabling for DP_A' fix looks to be on the intel fixes branch, so i assume destined for .38 [03:29] ok EOD'ing [03:29] apw, btw looks like your kernel solved my nfsv4 woes, thanks [03:29] yay for new kernels [03:31] Yay! I can now actually interact with the grub menu on my radeon system now! [03:33] Oh, bother. My evergreen card doesn't have *any* acceleration without KMS, so I can't test the ums fallback. [03:41] Whoops. Moderately easy to crash firefox with WebGL [04:02] How big a NOT E6510 do you need to have in the bug title before users with E6510 hardware stop posting on it? :) [05:37] strange, my gnome-terminal sessions all froze up and my music started repeating the same broken lyrics over and over in a loop [05:37] oh wait, I'm listening to techno, it's supposed to sound like that [06:57] RAOF, I tried on my i945 dell mini... [06:57] RAOF, gnome-terminal doesn't show the corruption [06:58] RAOF, weirdly, I launched xterm and got a >frozen< xterm window. No cursor, completely unresponsive. [07:04] hi. does anyone know about ubuntu's x with intel chipsets not sending out XRRNotifyEvents to clients? [07:04] it seems to work with xorg-edgers, but not with the stock X in maverick [07:06] bryceh: I'll have the switch-to-gallium stuff ready an hour or so after making, then eating dinner. [07:10] hyperair, first I've heard of it, but I don't really deal with maverick bugs [07:11] RAOF, sounds good; ping me when it's ready [07:11] bryceh: hmm strange. basically i plug in a monitor into the VGA port, and only after manually polling the hardwrae with XRRGetScreenResources does the event come in [07:11] bryceh: but that X call causes X11 to hang momentarily [07:12] I have X dying and respawning, is there a way of getting more detailed logs from what is killing it as Xorg.0.log has nothing about errors [07:13] lilstevie, I'd look in /var/log/gdm for errors [07:13] also Xorg.0.log.old [07:13] unfortunantly doesnt give me any errors [07:14] lilstevie, ok then start X up in gdb run it to a crash and then gather a full backtrace [07:14] k [07:15] actually probably easier to start X and then attach gdb to it (pidof X to get X's pid, then run gdb /usr/bin/Xorg, and then attach ) [07:15] see http://wiki.ubuntu.com/X/Backtracing for more tips [07:15] X on its own doesnt crash [07:15] just doesnt work [07:16] hyperair, well the automatic XRR kernel events stuff is fairly new, it may just be a missing feature from maverick [07:16] bryceh: ah, so it's a kernel events thing? is this a new feature in the kernel, or in X, or somewhere else? [07:16] lilstevie, I don't know what you mean by "doesn't work" [07:16] hyperair, yeah [07:16] hyperair, new kernel drm feature [07:16] bryceh: the screen backlight flashes on then off again [07:16] okay, that narrows down my search a bit, thanks =) [07:17] http://pastie.org/1577791 <- this is Xorg.0.log.old [07:17] hyperair, I'm not sure if the kernel bubbles the event up to X and then that passes it to clients, or if clients listen directly for kernel events [07:18] bryceh: no, the clients get it via some XRR stuff [07:18] hyperair, if X passes things along it's conceivable the X we shipped in maverick simply lacked the feature, but I wasn't paying attention to X during maverick so raof would be the one to ask [07:18] okay thanks. [07:18] RAOF: ^^ =D [07:19] hyperair: It requires kernel events (which *were* in Maverick) to be picked up by the DDX and forwarded to X; I'm not sure if the latter was in Maverick. [07:20] lilstevie, oh you're not running natty? [07:20] bryceh: no maverik [07:20] maverick [07:21] lilstevie, dunno then, you might have something misconfigured, hard to say [07:21] trying to port to a new device [07:21] but struggling to figure out what is broken [07:21] you're right though that it's not crashing, just exiting. the log seems to be complaining about input device stuff [07:22] hm [07:22] hard to make any guesses without more info, you could try http://askubuntu.com [07:22] RAOF: oh so kernel events were in maverick, i.e. kernel <= 2.6.35? [07:22] RAOF: what's DDX? [07:22] the nexus S has the same SoIC and that seems to work with x [07:22] DDX is the X driver [07:23] so that would be like xserver-xorg-video-intel as opposed to the intel driver inside the kernel [07:23] hyperair, https://wiki.ubuntu.com/X/Glossary [07:24] bryceh: thanks [07:24] RAOF: i'm trying to look in the kernel git log for the introduction of this whole hotplug kernel events thing so i can figure out how new a kernel i need. [07:34] wow http://www.semiaccurate.com/2011/02/15/atom-dead-strangled-slowly-intel/ [07:34] harsh! [07:34] "The other major problem facing Atom is software, especially drivers. Intel has a track record in making graphics drivers that are simply unmatched in the world of chipmaking. I can honestly say that I can not think of a single company that has made drivers as badly as Intel for as long, even if you take the awful hardware into account. Even a blind dog occasionally finds a bone, unless they work for Intel making graphics driv [07:34] ers." [07:34] lol [07:34] but true [07:35] hyperair: Hm. I may have had it backwards; the DDX component may have been there but the kernel component not :) [07:36] RAOF: nah, i just tried upgrading to xorg-edgers on this computer and it suddenly started workgin [07:36] Sarvatt, ^^ you'll find that link an interesting read I think [12:14] Dear lord, mesa. Do you *really* need to take that long to build? [12:15] maybe we should get rid of some (all?) of the osmesa packages [12:17] Or at least build only one. [12:18] I'm sure the user of the 16bit renderer will be *devastated* [12:19] Of course, it doesn't help that I'm doing an i386 and amd64 build in parallel. [12:19] heh [12:19] what are those osmesa-stuff for, anyway? [12:23] It's an offscreen software rasteriser, from what I gather. [12:24] As for what anyone *uses* that for… well, mesa-dev@ attests to there being at least one dev who notices when it breaks. [12:25] heh, ok [12:30] bryceh, tjaalton: Radeon gallium transition stuff is in http://cooperteam.net/Packages ; build order is mesa -> xserver with -ati going whenever. [12:32] Note: Due to mesa taking forever to build I haven't actually tested building the xserver against that mesa in a clean chroot. [12:32] RAOF: ok, so mesa is good to upload? [12:33] and xserver too, since the build-dep is bumped [12:33] It should be good to upload. [12:34] yeah they all are [12:34] But it's not thoroughly tested here. [12:34] bah, it's the weekend anyway :) [12:34] soon [12:34] In some places sooner than others :) [12:34] right, so Sarvatt and bryceh can fix the pieces that are left behind :) [12:35] I'll throw the binaries up on cooperteam, too; save you some bulid time. [12:36] ok, thanks [12:36] I'm trying to make some sense to this "xinput1 broken" -bug.. [12:36] but, after the break-> [12:38] Now with bonus binaries. [12:38] And with that, bed. [12:51] ok, lets try mesa then (don't have radeon) [12:55] wat, there's no menu in mumble anymore? [12:56] +h [12:56] duh [14:18] bryceh, there? === seb128_ is now known as seb128 [16:34] bryceh, let me know if you are around, I want to discuss about the retracers [16:34] I stopped those to investigate that xorg retracing issue but I would need an xorg crash to be submitted to be able to do that === apachelogger_ is now known as apachelogger [17:51] bryceh, I did a ppa-purge of xorg-edgers (which I should have done a while ago...) [17:51] but now my keyboard doesn't work anymore.. [17:51] any ideas? [17:52] do you have evdev installed? [17:52] I've debugged in the server, and I know that key events are getting generated [17:52] ok [17:52] tjaalton, yes, still installed [17:52] but they seem to get filtered out? [17:52] in _XkbFilterXF86Private [17:52] I don't know anything about how keyboard events work... [17:53] I'm just wondering if there's some magical change to stuff in xorg-edgers [17:53] nobody does, it's all black magic [17:53] xorg-edgers doesn't have much, maybe the ppa-purge removed something vital [17:53] well, there's stuff but still [17:54] but filtering sounds odd [17:57] though it sounds what's happening with mumble (XI1 app) [17:57] +like [17:57] yeah, but this isn't even generating core events... [17:57] hm [17:57] I'm going to try to purge my xorg-unstable ppa [17:57] then reinstall it [18:07] hmm, still no luck [18:07] I'm going to apt-get dist-upgrade and reboot [18:07] oh you aren't on current natty? [18:07] I am [18:07] k [18:07] but I haven't updated in a few days [18:07] yeah that shouldn't make a difference.. [18:07] I know [18:08] but I figure if I'm screwing up the machine [18:08] I might as well go all the way :) [18:08] right :) [18:19] grr... still nothing [18:28] cnd: you've seen the mumble bug? shouldn't XI1 apps continue working just as before with XI2, or do they need to be ported over? [18:29] tjaalton, I have seen it, haven't had time to investigate [18:29] they should continue to work as normal [18:29] so it's a bug [18:29] yeah [18:30] best to file it upstream then and discuss it there [18:34] tjaalton: I wonder if it has to do with input methods [18:34]