[08:26] <tjaalton> bryce: I'm tempted to use git for -intel.. since we need to pull in a number of commits from master for it to build
[08:27] <tjaalton> I've got mesa & libdrm ready, but intel needs some work still
[08:32] <bryce> tjaalton: I'd be disappointed to see that
[08:35] <tjaalton> ok then
[08:35] <tjaalton> merging by hand is not that straightforward, since grab-merge.sh doesn't work with experimental
[08:36] <tjaalton> well, it's MoM that doesn't, but anyway
[09:14] <tjaalton> libdrm & mesa uploaded
[09:23] <tjaalton> and intel too
[09:23] <bryce> \o/
[09:57] <tjaalton> Alexia_Death: what patch did you need to xorg-server?
[10:40] <soren> I'm running Jaunty on my laptop, and my X performance alternates between decent and abysmal. In the latter case, the mouse curser "jitters" somewhat when I move it around the screen, and X eats almost an entire CPU core. Disabling compiz didn't help at all.
[10:41] <soren> I would say it's decent around 15% of the time, and absolutely horrible the other 85% of the time.
[10:42] <soren> Oh, the graphics card is a intel 945, by the way.
[10:44] <tjaalton> soren: I've uploaded a new libdrm/mesa/intel, so report back if those are any better or worse
[10:51] <soren> tjaalton: When was this?
[10:53] <soren> tjaalton: Ah, 48 minutes ago, according to launchpad :)
[10:53] <soren> I'll wait a bit.
[10:53] <crevette> soren, 1 hour ago
[10:53] <soren> :)
[10:55] <tjaalton> right, it'll take a while since libdrm needs to be built & published first
[10:55] <soren> Right. I'll give the ones in xorg-edgers a chance until then..
[10:55]  * soren restarts X
[10:57] <tjaalton> hmm, I wonder if you are seeing bug 307306
[10:58] <tjaalton> lunch ->
[11:06] <soren> tjaalton: I've just taken gnom-epower-manager out of the equation, and it's still really, really slow.
[11:11] <tseliot> soren: what's the problem?
[11:12] <tseliot> or what are the symptoms?
[11:12] <tseliot> does killing the gnome-settings-daemon help?
[11:13] <soren> tseliot: Mouse pointer jitters as I move it around the screen, and performance is absolutely horrible.
[11:14] <soren> About 85% of the time.
[11:14] <tseliot> soren: kill the gnome-settings-daemon
[11:14] <soren> Right now, I'm experiencing the lovely 15% of the time, where everything is fine, so I'm trying to get some work done while it lasts :)
[11:14] <tseliot> upstream hasn't adopted my latest patches yet
[11:16] <tseliot> soren: or, if you want, you can apply the patch attached in comment 10 directly: http://bugzilla.gnome.org/show_bug.cgi?id=568160
[11:17] <soren> tseliot: Thanks for the hint. I'll look at it when it starts happening again.
[11:17] <tseliot> ok
[11:45] <tjaalton> sigh, missing comma in libdrm's debian/control
[11:47] <tjaalton> the result was that libdrm-dev didn't depend on the new linux-libc-dev
[11:50] <tjaalton> and why do the buildd's use an older version of xserver-xorg-dev..
[11:50] <tjaalton> would've thought they always fetched the latest one
[11:53] <tjaalton> hmm, actually it is the latest one
[11:53] <tjaalton> since I didn't upload the merge yet, duh
[12:32] <tjaalton> new synaptics merge uploaded
[12:55] <soren> tjaalton: The buildd's should always use the most recent version of everything.
[12:55] <tjaalton> soren: yes, it was my mistake
[12:55] <soren> Right, I just wanted to confirm anyway. :)
[12:57] <tjaalton> I'll remember now :)
[12:57] <tjaalton> too bad that the ports archs have an outdated kernel, so basically nothing will build on them until they are updated to .28
[12:58] <tjaalton> nothing X related.. drivers, server etc
[14:45] <tjaalton> tseliot: you aware of the nvidia bug where after a while (~days) of using compiz the contents of new windows are not refreshed?
[14:46] <tseliot> tjaalton: no, what bug is it?
[14:46] <tjaalton> I thought it was a bug fixed long ago, but still happens in 180.22 (was using 169.12 on hardy before..)
[14:46] <tjaalton> well, I just described it, but I guess no-one else is using a 30" monitor :)
[14:47] <tjaalton> so I guess the video memory is exhausted or something
[14:48] <tseliot> what resolution are you using?
[14:48] <tjaalton> 2560x1600
[14:48] <tjaalton> and sometimes when I unlock the screensaver, the whole screen is behaving like that. every redraw is painfully slow
[14:49] <tjaalton> but that can be fixed by visiting a vt briefly
[14:49] <tseliot> a memory leak, perhaps?
[14:50] <tjaalton> maybe
[14:50] <tseliot> also, can you try to reinstall nvidia-glx-VERSION and restart X
[14:50] <tseliot> ?
[14:51] <tjaalton> restarting X helps, but I don't think a reinstall is needed
[14:51] <tjaalton> guess I need to file this
[14:51] <tseliot> an update of X made the system very slow here, even without breaking direct rendering
[14:52] <tseliot> it's because of a bug which I have to fix
[14:52] <tjaalton> which bug?
[14:53] <tseliot> https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/309116
[14:54] <tseliot> it's easy to fix
[14:58] <tjaalton> ok
[15:13] <tjaalton> hmm, the nvidia problem might be due to "powermizer"
[15:40] <tseliot> powermizer?
[15:41] <tseliot> too bad it's closed source, otherwise I wouldn't mind fixing it myself
[15:41] <tjaalton> bug 270377 for instance
[15:41] <tjaalton> and several threads on nvnews
[15:42] <tjaalton> sigh
[15:42] <tjaalton> https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/270377
[15:43] <tjaalton> wrong package though
[15:45] <tseliot> tjaalton: did you subscribe Aaron Plattner to the bug
[15:45] <tseliot> ?
[15:45] <tjaalton> no
[15:45] <tjaalton> looks like he's well aware of it :)
[15:45] <tjaalton> at least should be
[15:46] <tjaalton> the driver could install the modprobe file to work around it
[15:46] <tseliot> :-/
[15:48] <tjaalton> duh, the amd64 buildd seems to be busy or broken somehow
[15:50] <tjaalton> busy it seems..
[15:50] <tseliot> what modprobe file?
[15:50] <tjaalton> a file to add options for the module
[15:51] <tjaalton> /etc/modprobe.d/*
[15:51] <tjaalton> https://bugs.edge.launchpad.net/ubuntu/+source/compiz/+bug/270377/comments/32
[15:53] <tseliot> does it affect only some specific models?
[15:53] <tjaalton> I don't know
[15:55] <tseliot> as I would like to implement some quirks module for Jockey sooner or later
[16:47] <tseliot> tjaalton: I've just tried my patch for the "nv" driver to add the support for my card and it works
[16:47] <tseliot> I'll send it to Aaron Plattner
[16:47] <tseliot> shall I also file a bug report about it on launchpad?
[16:48] <tseliot> just to keep track of things?
[16:54] <mnem0> tjaalton: I was hit by that intel waitForVBlank freeze bug and I had tested the "dont enable vblanks on disabled pipes" drm patch which worked great on my machine... but today when the .28-5 kernel installed my intel G45 machine got unbootable --> https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/320525
[18:01] <tjaalton> mnem0: checkint
[18:01] <tjaalton> uh
[18:01] <tjaalton> -ing
[18:02] <tjaalton> mnem0: uh.. .NEF
[18:02] <tjaalton> please attach only jpegs or so
[19:00] <mnem0> tjaalton: sry I converted it before but then I attached the wrong file.. I attached jpg as well now
[19:00] <mnem0> plus xorg logs and dmesg
[19:00] <mnem0> will check without usplash in a sec
 jdstrand: hmm
 bryce: failsafe mode does give me this:
 (EE) open /dev/fb0: No such file or directory
[19:18] <tjaalton> bryce: what's that?
[19:19] <bryce> jdstrand ran into that after upgrading to latest X bits (but not -intel)
[19:20] <bryce> he's run into a situation where it doesn't start up, and failsafe mode is also failing with corrupted screen
[19:20] <jcristau> logs or it didn't happen ;)
[19:20] <bryce> I suggested he update to the newest -intel
[19:21] <bryce> jcristau: heh
[19:21] <jdstrand> bryce: amd64 -instal is still in 'needs building'
[19:21] <bryce> jdstrand: price of admission is posting your Xorg.0.log[.old] files somewhere we can see them
[19:21] <jdstrand> -intel
[19:21] <tjaalton> the thing is that the other amd64 buildd is stuck with qt4-x11
[19:21] <tjaalton> so amd64 is left behind
[19:22] <bryce> tjaalton: do the changes require a rebuild of the driver (or maybe just -intel)?
[19:22] <jdstrand> I can post the logs, but it seems maybe I just don't have the necessary bits cause of poor upgrade timing
[19:23] <tjaalton> bryce: if it failed to build, then just retrying is enough
[19:23] <tjaalton> but "needs building" means that the queue is just too long
[19:24] <tjaalton> yellow(amd64 buildd) has been building qt4-x11 for three days now
[19:24] <bryce> tjaalton: no I mean, would using a new xserver/mesa with old -intel cause problems (e.g. ABI mismatches)?
[19:24] <tjaalton> I know for a fact that with the old intel and new libdrm X won't start
[19:24] <bryce> three days??
[19:24] <jdstrand> Xorg.0.log: http://paste.ubuntu.com/108701/
[19:25] <tjaalton> bryce: yes
[19:25] <bryce> tjaalton: aha
[19:25] <tjaalton> and without the new mesa compiz fails
[19:25] <jdstrand> Xorg.0.log.old: http://paste.ubuntu.com/108702/
[19:25] <tjaalton> but this is jaunty so I didn't feel like adding a bunch of Breaks :/
[19:26] <bryce> tjaalton: do you think it'd make any difference if he were to manually rebuild the old 2.5 -intel against the new X bits?  e.g. is it just ABI breakage, or API stuff too?
[19:26] <tjaalton> bryce: no idea.. I reported that upstream and they asked if 2.6 works. when it did, they closed the bug :)
[19:26] <tjaalton> better just grab the new source and build that
[19:27] <jdstrand> bingo!
[19:27] <tjaalton> yeah, the logfile matches mine
[19:27] <bryce> ok cool
[19:27] <tjaalton> mnem0: maybe the same issue for you then
[19:27] <jdstrand> bryce: apparently I did *not* downgrade libdrm2, just libdrm-intel1
[19:27] <bryce> jdstrand: aha, that could do it
[19:27] <jdstrand> bryce: I put both at 2.4.1-0ubuntu9 and it started
[19:28] <mnemo> aha, did you downgrade libdrm-intel1 by mistake or what happened?
[19:28] <jdstrand> \o/
[19:28] <tjaalton> that works
[19:28] <jdstrand> mnemo: both upgraded without the new -intel. during triage, I only downgraded the one
[19:28] <tjaalton> damn g-s-d keeps crashing on me
[19:30] <tjaalton> bryce: btw, the new mesa now uses vblank for intel, because the drm drivers were fixed. It means that we'll get a ton of bugreports saying 'glxgears showing only 50fps!!!1!' :P
[19:31] <bryce> awesome
[19:31] <tjaalton> it's been the default since 7.1, but it was fixed only recently (jbarnes)
[19:31] <tjaalton> so we had it disabled
[19:31]  * bryce nods
[19:31] <bryce> was wondering about that
[19:32] <bryce> keithp mentioned it to me a while back and wondered when it'd hit ubuntu :-)
[19:33] <tjaalton> I git-bisected it last summer
[19:33] <tjaalton> my laptop froze when the display was turned off
[19:33] <tjaalton> by the screensaver
[19:40] <bryce> tjaalton: do fps == refresh rate exactly now?
[19:40] <tjaalton> yes
[19:40] <jcristau> in general, fps <= refresh rate. in glxgears, it's ==
[19:40] <tjaalton> at least in glxgears
[19:40] <bryce> ok
[19:41] <bryce> so regarding the worry of user complaints I think it should be straightforward to explain
[19:41] <pwnguin> speaking of glxgears
[19:41] <bryce> if we see a lot of bug reports to this affect I can probably rig up an automated reply
[19:41] <tjaalton> bryce: yes; 'glxgears is not a benchmark'
[19:41] <bryce> er, s/affect/effect/
[19:41] <pwnguin> doesn't it require -iacknowledgethisisnotabnechmark option?
[19:41] <jcristau> glxgearsisnotabenchmarkkthxbye
[19:42] <jcristau> pwnguin: not anymore, sadly
[19:42] <pwnguin> jcristau: any reason not to put it back?
[19:42] <bryce> users don't appear to know what a benchmark is anyway
[19:42] <mnemo> could someone explain to me what it means to have vblank enabled versus disabled? and also why would that result in lower fps in glxgears? and finally who is that lower FPS count not a problem?
[19:42] <pwnguin> heh
[19:42] <bryce> lol
[19:42] <tjaalton> mnemo: you don't see the "extra" fps anyway
[19:42] <bryce> mnemo: sure
[19:43] <bryce> your monitor can only show a certain number of frames per second
[19:43] <pwnguin> vblank is the interrupt that tells the hardware a new frame can be drawn
[19:43] <bryce> this is called your "refresh rate"
[19:43] <mnemo> right vblank used to be when the electron beam returned to the other side of the screen or somethin right?
[19:43] <pwnguin> enabling vblank handling means you only need to render when a new frame is available to display
[19:43] <bryce> for LCD's, 60 hz is common
[19:43] <mnemo> rights to LCD is 60 FPS sort of?
[19:44] <pwnguin> when its disabled, the fps count is lying to you
[19:44] <bryce> so the xserver/-intel is now being **really clever** and timing its screen draws to match what your hardware is actually capable of
[19:44] <bryce> so if it were putting out 120fps, your monitor would only show every other one anyway
[19:45] <mnemo> aahh so with vblank enabled im actually saving some CPU by not wasting time rendering frames that wont be shown anyway?
[19:45] <pwnguin> matching fps to refresh rate should reduce power consumption
[19:45] <bryce> so why bother?  save some processor cycles and only send the ones that are actually going to get drawn
[19:45] <tjaalton> mm, dogfood
[19:45] <bryce> it's very cool
[19:45] <pwnguin> mnemo: well, it gets a bit complicated, but basically yes
[19:45] <mnemo> that seems like a very nice feature indeed
[19:45] <pwnguin> if look up double-buffering in wikipedia
[19:45] <bryce> but yeah this means glxgears is going to show much different fps measurements
[19:45] <pwnguin> s/if//
[19:45] <mnemo> mmkay makes sense
[19:45] <tjaalton> I actually get over a 1000 now without vblank :)
[19:45] <pwnguin> glxgears is a shitty measurement though
[19:46] <bryce> I think we can say if your glxgears fps match your monitor refresh rate, you're running optimally
[19:46] <tjaalton> on 965
[19:46] <pwnguin> glxgears numbers track "buffer clearing" speed
[19:46] <bryce> tjaalton: heh, you realize people are going to turn off vblank now, as a "performance improvement"  ;-)
[19:46] <pwnguin> ie how fast your hardware can clear out the old frame for a new one
[19:46] <tjaalton> bryce: I bet.. "here's my xorg.conf, you can use it"
[19:47] <bryce> it'll be worth chuckles
[19:47] <tjaalton> there were posts like that on nvnews.net.. showing everything like what modules to load and stuff
[19:47] <pwnguin> glxgears has no textures, barely any geometry, no lighting, or anything relevant to the apps users actually care about
[19:48] <pwnguin> you could probably replace glxgears with "grep (ati|nvidia|fglrx) /var/log/Xorg.0.log" and not lose any information
[19:49] <bryce> heh
[19:49] <bryce> we could be clever and hack glxgears to replace the printouts of xxx fps with % refresh rate
[19:50] <bryce> so it'd print 100% 101% 99% 100% ...
[19:50] <tjaalton> "don't touch the mouse!"
[19:50] <tjaalton> (to keep it ~100%)
[19:52] <bryce> ;-)
[19:54] <tjaalton> oh, aaronp posted on the "x-server breakage" forum thread, and confirmed that the next releases will support 1.6
[19:54] <bryce> yep, I saw a reply from him in one of the -nvidia bug reports saying similarly
[19:54] <bryce> I need to email them again... monday maybe
[20:36] <andersk> The most recent Jaunty updates caused two problems.  First, my touchpad is moving around the screen way faster than normal. 
[20:37] <andersk> And second, if I drag any window to any edge of the screen, it immediately jumps to the upper-left corner. 
[20:37] <andersk> (The latter occurs with Compiz only.) 
[20:37] <tjaalton> drag with the touchpad or same with the mouse?
[20:38] <andersk> With the touchpad.  Let me go find a mouse... 
[20:38] <tjaalton> there probably are some issues with the new synaptics
[20:38] <tjaalton> because some defaults have been changed
[20:39] <andersk> With the touchpad only.  So yeah, this points to a synaptics problem. 
[20:40] <tjaalton> ok, please file a bug against it
[20:40] <andersk> Will do. 
[20:40] <jcristau> maybe you could play with xinput to see which settings affect it
[20:42] <tjaalton> right, there are not many changes upstream since 1.0rc3
[20:47] <andersk> It looks like most synaptics bugs are being reported against the source package xserver-xorg-input-synaptics, even though it was renamed in Hardy to xfree86-driver-synaptics. 
[20:50] <tjaalton> yes, because it's called that in debian
[20:50] <tjaalton> but we "support" the old name too
[20:50] <tjaalton> well, the debian package really should be renamed to that
[20:50] <tjaalton> so in future it should be called x-x-i-synaptics again
[20:55] <jcristau> yeah xfree86-driver-synaptics doesn't make much sense anymore
[20:56] <tjaalton> especially as the git repo is called x-x-i-s
[20:56] <jcristau> it's to make sure you get confused
[20:56] <tjaalton> I have :)
[20:56] <jcristau> every time
[20:56] <tjaalton> you surely have the power to rename it?-)
[20:57] <andersk> bug 320639 
[20:57] <jcristau> i think i'd rather rename the source package than the git repo
[20:57] <tjaalton> jcristau: of course :)
[20:57] <tjaalton> andersk: thanks
[20:59] <pwnguin> what's the xorg.conf setting i need to re-enable zapping?
[20:59] <jcristau> pwnguin: Option "NoDontZap"
[20:59] <andersk> Option "DontZap" "False" in ServerFlags. 
[20:59] <pwnguin> ok
[20:59] <pwnguin> nouveau isn't quite to the point where i don't need it ;)
[21:00] <jcristau> (it's like Option "NoXaaNoOffscreenPixmaps" "false" all over again)
[21:00] <pwnguin> well, i agree with the idea
[21:01] <pwnguin> i just live more dangerously than is prudent
[21:01] <jcristau> i meant the fact that the option name has a negation in it
[21:01] <pwnguin> oh
[21:07] <_MMA_> I switched video cards (both nvidia) now I cant get X to start at all. Blew out my Xorg. Tried to use vesa in xorg. No screens found. Nothing. Is there some trick to get it to build the module again or something? DKMS?
[21:12] <tjaalton> either specify the BusID or take one out
[21:12] <tjaalton> oh
[21:12] <tjaalton> I misread :)
[21:12] <_MMA_> :P
[21:13] <bryce> _MMA_: you forgot to post a link to your Xorg.0.log ;-)
[21:13] <_MMA_> :P
[21:13] <_MMA_> I should note this is a SLI setup so it could have to do with the busID.
[21:14] <tjaalton> so you _do_ have two of them? yes you need the BusID with 8.10 or jaunty
[21:15] <_MMA_> tjaalton: Yeah. Went from 1 card (9 series) to 2 (both 7 series). Runnin' Intrepid.
[21:15] <_MMA_> I guess X wasn't as bullet proff as I thought. :P
[21:16] <tjaalton> the bug is upstream, but unfortunately not seeing much action
[21:16] <_MMA_> ouch
[21:16] <tjaalton> although it's on the list of blockers for xserver 1.6
[21:16] <tjaalton> (well, I added it)
[21:16] <_MMA_> I think I have the old xorg with both cards somewhere.
[21:17] <_MMA_> Thing is, the live disk gives me X. Im just trying to get, *something*
[21:17]  * _MMA_ pokes around.
[21:18] <tjaalton> livecd does? strange
[21:18] <tjaalton> it shouldn't
[21:20] <andersk> So here's another problem.  gnome-screensaver always fails to unlock the screen now. 
[21:20] <andersk> After I enter the correct password, gnome-screensaver-dialog sits there displaying "Checking..." 
[21:20] <andersk> And top shows that the CPU is spinning, with about 65% gnome-screensaver-dialog and 35% Xorg. 
[21:22] <tjaalton> works here
[21:31] <_MMA_> tjaalton: It was the BusID. Thanx for the reminder.
[21:50] <andersk> I've bisected the gnome-screensaver unlock problem to the gtk+2.0 2.14.5-1ubuntu2 -> 2.15.0-0ubuntu1 upgrade. 
[21:51] <tjaalton> I've got it too
[21:51] <tjaalton> that version of gtk+
[21:51] <andersk> Huh. 
[21:51] <tjaalton> maybe you are missing something..
[21:52] <tjaalton> which mirror?
[21:52] <andersk> archive.ubuntu.com 
[21:52] <tjaalton> ok, same
[22:02] <andersk> Aha, got it.  I can only reproduce with "export GTK_IM_MODULE=xim" in ~/.gnomerc. 
[22:06] <tjaalton> nice
[22:06] <tseliot> tjaalton: did you upload a new version of the synaptics driver?
[22:06] <tjaalton> tseliot: yes
[22:07] <tjaalton> some defaults have chagned
[22:07] <tseliot> I have noticed these 2 bug reports:
[22:07] <tjaalton> -nged
[22:07] <tseliot> https://bugs.launchpad.net/ubuntu/+source/xfree86-driver-synaptics/+bug/320632
[22:07] <tseliot> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-synaptics/+bug/320639
[22:07] <tseliot> I'll try the new driver tomorrow and if it bugs me I'll write a patch
[22:07] <tjaalton> ok
[22:08] <tseliot> tjaalton: oh and did you read about my patch for nv
[22:08] <tseliot> ?
[22:08] <tjaalton> yes, and saw that you posted it upstream
[22:08] <tseliot> what are we going to do about it?
[22:09] <tseliot> shall we include it as a patch in ubuntu or wait for a new release of nv?
[22:10] <tjaalton> a patch is fine
[22:10] <tseliot> and do you want me to file a bug report about it?
[22:10] <tjaalton> preferably yes
[22:10] <tjaalton> might get lost otherwise
[22:10] <tseliot> ok, good
[22:11] <tseliot> yes, it better if we keep track of the patch
[22:11] <tseliot> s/it/it's/
[22:12] <tjaalton> what the heck
[22:12] <tjaalton> DRI2 works, but I do get bigger fps than vblank with glxgears
[22:12] <tjaalton> this is with UXA
[22:13] <tjaalton> s/vblank/refresh-rate/
[22:13] <tseliot> how much is it?
[22:13] <jcristau> does it matter? :)
[22:13] <tseliot> or is it too fast?
[22:13] <tjaalton> well it should show ~50
[22:14] <tjaalton> but it's not
[22:14] <tjaalton> with EXA it does
[22:14] <tjaalton> but then I get no DRI2
[22:14] <jcristau> i'm not sure dri2 has a mechanism for vsync yet
[22:16] <tjaalton> probably so
[22:16] <tjaalton> oh well, EXA is the default anyway
[22:18] <andersk> I reported bug 320666 for gnome-screensaver and gtk+2.0. 
[22:18] <bryce> tjaalton: http://people.ubuntu.com/~bryce/totals.svg
[22:19] <tjaalton> bryce: wow :)
[22:20] <tjaalton> btw, we should probably move the -mouse/-kbd bugs over to evdev if they still apply
[22:21] <bryce> yep
[22:21] <bryce> how do we determine that they still apply?  ask users to retest jaunty?
[22:21] <tjaalton> something like that..
[22:22] <tjaalton> not that many of them
[22:22] <bryce> yeah
[22:22] <tjaalton> and some are likely misfiled
[22:22] <tseliot> tjaalton: here's my report with the patch: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-nv/+bug/320671
[22:23] <tjaalton> tseliot: ok thanks
[22:23] <bryce> there might also be some -evdev bugs misfiled against xkeyboard-config
[22:23] <bryce> I took out all the hotkey bugs from there and that cut it down a lot
[22:25] <tjaalton> yep
[22:39] <tjaalton> so unplugging a wacom tablet really kills the xserver
[22:40] <tjaalton> ..and that concludes my day, night!
[22:41] <bryce> night
[23:01] <Alexia_Death> tjaalton: It wont if you take the 0.8.2-2 (I hope, ping put a build swithc in that one)