[00:00] <bryceh> I did a diff between the upstream 1.11 git tree's include/ dir and ours (before applying debian/patches):  http://paste.ubuntu.com/913875/
[00:01] <bryceh> didn't spot any commonalities with your valgrind output.  mostly it's cnd's touch bits
[00:02] <cnd> RAOF, valgrind ioctl warnings are either: correct, or they need wrappers to tell valgrind how they really work
[00:02] <cnd> RAOF, I just added wrappers for the uinput ioctls to the precise valgrind
[00:03] <cnd> you might be interested in doing the same for drm?
[00:03] <RAOF> cnd: Apparently upstream already has; in the libdrm sources - we just need to build-depend on valgrind to get those intrinsics added.
[00:03] <cnd> RAOF, that seems odd
[00:04] <cnd> the fixes should be in the valgrind sources
[00:04] <cnd> I suspect libdrm is either really fixing the issues, or just papering over them
[00:06] <RAOF> Ah, no; what it's doing is using some intrinsics to annotate stuff for valgrind - VALGRIND_MAKE_MEM_DEFINED(bo_gem->gtt_virtual, bo->size) and such.
[00:06] <RAOF> I think they've *also* fixed an issue or two.
[00:07] <cnd> RAOF, ahh, that looks like it makes some sense for drm
[00:08] <cnd> drm is funny in how it uses memory :)
[00:09] <cnd> RAOF, btw, the ioctl warnings at device init time are red herrings again, I'm fairly certain
[00:09] <RAOF> Hm.
[00:09] <cnd> the evdev ioctls probably need wrappers too
[00:10] <cnd> just like the uinput ones
[00:10] <cnd> valgrind assumes that all ioctls take an argument, and the argument is a pointer to valid userspace memory
[00:10] <RAOF> There don't seem to be any suspicious writes, which is annoying.
[00:11] <cnd> you have to manually tell it if a specific ioctl either: doesn't pass an argument, or passes an argument by value
[00:12] <RAOF> But, given I can reproduce this easily, I guess it's time to go poking around in the core.
[00:12] <RAOF> To the bat-gdb!
[00:12] <cnd> RAOF, what trackpad are you thrashing on?
[00:12] <RAOF> A synaptics one.
[00:12] <cnd> RAOF, thrashing with one finger?
[00:12] <RAOF> Two finger scrolling was the last thing I reproduced it with.
[00:13] <cnd> RAOF, does xinput list a touch class for your touchpad?
[00:14] <cnd> hooray! a one-liner in the server fixes compiz touchscreen interactions
[00:15] <RAOF> cnd: Hm, how do I get xinput to do that?
[00:15] <cnd> RAOF, xinput list <device name|id>
[00:15] <RAOF> Hm.
[00:15] <RAOF> EBADATOM
[00:15] <RAOF> For some reason that fails.
[00:16] <cnd> I've started seeing that too...
[00:16] <cnd> it's next on my list of bugs :)
[00:16] <cnd> I was hoping it was just me
[00:17] <RAOF> It reports 8 classes though, from which I think you can work out if there'll be a pair of touch classes or not.
[00:17] <cnd> RAOF, install utouch-frame-tools
[00:17] <cnd> then run utouch-frame-test-x11 <window>
[00:17] <cnd> where window is some window other than the root window
[00:17] <cnd> it will spit out all devices that have touch classes
[00:19] <RAOF> Two touches
[00:19] <RAOF> http://paste2.org/p/1965826
[00:21] <cnd> ok
[00:21] <cnd> cool
[00:21] <cnd> so what you are seeing could be multitouch related
[00:21] <cnd> once I fix this bug, I'll thrash on my magic trackpad to see if I can cause any misbehavior
[00:22] <cnd> RAOF, is this on a netbook or something else that is less performant?
[00:22] <RAOF> Nope, it's on my shiny sandybridge i5
[00:22] <RAOF> However, it's on my shiny sandybridge i5 while running under valgrind, so you may assume it is significantly non-performant :)
[00:27] <RAOF> And, as you might note in the valgrind backtrace, the initial SIGSEGV comes from the ErrorF in mieq saying “[mi] EQ overflowing”
[00:31] <cnd> RAOF, oh, you're running under valgrind
[00:31] <cnd> I'm guessing that you are hitting the queue overflow because it's so slow
[00:31] <cnd> is it crashing?
[00:32] <RAOF> Yes.
[00:32] <RAOF> Yeah, that's exactly what's happening.
[00:32] <RAOF> It's queue overflowing.
[00:32] <cnd> RAOF, oh, I bet you're hitting the same bug I was seeing yesterday :)
[00:32] <RAOF> But! It's SEGVing when trying to print the queue overflow.
[00:32] <cnd> if you hit ErrorF within signal context under valgrind
[00:32] <cnd> then it will segfault
[00:32] <cnd> I think sprintf is technically signal unsafe
[00:32] <RAOF> But only under valgrind?
[00:33] <cnd> it seems to work when not under valgrind
[00:33] <cnd> though that may mean that valgrind always crashes, while in real world it only crashes 1/1000 times
[00:33] <RAOF> Right.
[00:33] <RAOF> It is indeed not listed as signal safe
[00:34] <RAOF> This lacks awesome.
[00:34] <cnd> yeah...
[00:34] <cnd> I had to stop to look at other things
[00:34] <cnd> it should probably be brought up on xorg-devel at the very least though
[00:34] <RAOF> Yes.
[00:35] <cnd> RAOF, the sprintf is only used to print the timestamp in the X log
[00:35] <cnd> so we may be able to get away without it, with some manual number printing
[00:35] <cnd> when I commented the sprintf out, I didn't get the crash anymore
[00:36] <RAOF> Aha.
[00:38] <RAOF> Hm.
[00:38] <RAOF> Practically nothing done in ErrorF is signal-safe.
[00:39] <RAOF> fwrite: no, memcpy: no, fflush: no.
[00:39] <RAOF> Oooh, and if you're unlucky it'll try to realloc
[00:42] <RAOF> vsnprintf: no.
[00:42] <cnd> fun
[00:43] <cnd> RAOF, maybe there should be a separate code path for ErrorF if in signal context?
[00:43] <RAOF> Quite possibly.
[00:43] <cnd> don't attempt to do anything other than just write directly to the log file
[00:43] <cnd> actually, maybe a separate function altogether
[00:43] <RAOF> Yes.
[00:43] <cnd> and then in ErrorF, merely print "you're dumb" if in signal context
[00:43] <cnd> :)
[00:44] <cnd> because ErrorF attempts to print a vararg printf style message
[00:44] <cnd> which I think may be impossible without reimplementing vsprintf in signal safe code :)
[00:46] <RAOF> Probably, yes.
[00:46] <cnd> RAOF, bryceh, Sarvatt: I have a one-liner fix for compiz touchscreen interactions for xorg-server
[00:46] <cnd> any issues if I upload now?
[00:46] <RAOF> None from me.
[00:47] <cnd> fixes bug 972985
[00:47] <RAOF> Although what would be much more awesome is to just have a gorram input *thread* and stop futzing around in the SIGIO context.
[00:47] <cnd> heh
[00:47] <RAOF> We call *so much* code in that context.
[00:47] <RAOF> It's scary.
[00:47] <cnd> yeah
[00:48] <cnd> it seemed like we were so close too...
[00:48] <bryceh> cnd, pastebin the patch?
[00:48] <cnd> bryceh, 505_query_pointer_touchscreen.patch
[00:48] <cnd> oops
[00:48] <cnd> http://paste.ubuntu.com/913912/
[00:49] <cnd> I guess it's technically a two-liner :)
[00:53] <bryceh> cnd, ok; looking at event_get_corestate this effectively just ORs in mouse->touch->state if defined
[00:53] <cnd> bryceh, yep
[00:54] <bryceh> heh, you know what, this might fix an issue that I *just* saw about 3 minutes ago
[00:55] <bryceh> on my fujitsu touch screen, it responds to touch drag events, but if I just tap with my finger, nothing happens
[00:55] <cnd> bryceh, really?
[00:55] <bryceh> cnd, does that sound like this?
[00:55] <cnd> bryceh, what are you trying to tap?
[00:55] <cnd> are you trying to raise a window?
[00:56] <bryceh> yeah, or click buttons on the launcher
[00:56] <cnd> bryceh, btw, I still have a bug that is locking up the desktop after some touch interactions
[00:56] <cnd> I was hoping this would fix it for good, but apparently not
[00:56] <bryceh> drags work
[00:57] <bryceh> well sort of work.  the initial touch doesn't move the cursor, so you end up dragging offset
[00:57] <cnd> hmm
[00:58] <cnd> bryceh, oh, we just pushed up a fix in utouch-grail
[00:58] <cnd> touchscreens are quite broken without version 3.0.5
[00:58] <bryceh> ok.  I just updated a couple hours ago
[00:58] <cnd> without 3.0.5, grail was holding on to touches until they physically ended
[00:59] <bryceh> ok, I've got 3.0.4 installed, I'll try that
[00:59] <cnd> that sounds like the issue you are seeing
[00:59] <bryceh> fwiw, stylus and eraser work fine in gimp
[00:59] <bryceh> ok
[00:59] <cnd> good :)
[01:00] <cnd> so I see that my pointer lockup is a core passive button grab
[01:00] <cnd> I think there are issues in the compiz stack...
[01:00] <RAOF> Really?  Heaven forfend!
[01:00] <RAOF> :)
[01:00] <cnd> having peeked at their code today, I'm very afraid
[01:21] <Darxus> Same problems with my Radeon with the upstream kernel.  
[01:25] <RAOF> Darxus: Sarvatt was saying something about lack of radeon-kms in the -edgers packages earlier, but it's dropped off my backscroll.
[01:27] <Sarvatt> that was in xorg-edgers
[01:27] <Sarvatt> (which its not recommended to even use)
[01:28] <Sarvatt> until mesa 8.1 builds in there, its still going through automake changes breaking it every few days and i cant keep up so its on 8.0 branch
[01:28] <Sarvatt> which is the same as in precise
[01:29] <Sarvatt> wayland egl builds have been broken since the beginning of march for out of tree builds aka what the debian packages do
[01:33] <Sarvatt> every automake commit breaks something new because they always include $(top_srcdir) instead of $(top_builddir)
[01:36] <Sarvatt> like http://cgit.freedesktop.org/mesa/mesa/commit/?id=ca760181b4420696c7e86aa2951d7203522ad1e8 doing -I$(top_srcdir)/src/mapi ,but that ones fixed already
[01:41] <Sarvatt> Darxus: i'm going to push libdrm 2.4.33 and newer x-x-v-ati to x-updates tomorrow for precise, might as well be using that and not have screwed up input like you will in xorg-edgers if you're using that :)
[01:42] <Darxus> Sarvatt: I'm not using xorg-edgers.
[01:42] <Sarvatt> then again i dont know what problems you really have with radeon, might be assuming too much that you're using edgers because of RAOF :)
[01:42] <Darxus> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/971204
[01:44] <RAOF> Darxus: Sorry, I was confusing you with someone else.
[01:44] <Darxus> No problem.
[01:46] <Sarvatt> hmm how does grub-gfxpayload-lists have nothing but vmware added in it in precise, i know tjaalton added a bunch of systems to it
[01:49] <Sarvatt> all the systems added in the natty lists that were SRUed aren't there, hmm
[01:49] <Sarvatt> tjaalton: any idea whats going on there? surely those should be forward ported to later releases
[01:50]  * Sarvatt hopes nothing failed certification in 11.10 because it was dropped
[03:07] <bryceh> cnd, btw even after updating to 3.0.5, the fujitsu touchscreen still misbehavin
[03:07] <cnd> bryceh, describe what it's doing
[03:07] <cnd> I still see some issues here
[03:08] <bryceh> the pointer is at position x,y
[03:08] <bryceh> you touch at position x+100,y+100
[03:08] <bryceh> the pointer remains at x,y
[03:09] <bryceh> you drag your finger from x+100,y+100 to x+150,y+150
[03:09] <bryceh> the pointer moves from x,y to x+50,y+50 
[03:09] <cnd> whoa
[03:09] <cnd> that's weird
[03:09] <cnd> I've not seen that
[03:10] <bryceh> actually it's a bit worse
[03:10] <cnd> bryceh, it sounds like X thinks your touchscreen is a touchpad
[03:10] <cnd> bryceh, can you pastebin your x log?
[03:10] <bryceh> there is some scaling going on, so moving by +50/+50 moves pointer say +100/+80
[03:11] <bryceh> pastebin.ubuntu.com/914024
[03:12] <cnd> bryceh, it's using the wacom driver
[03:12] <cnd> I think it thinks your touchscreen is a tablet
[03:12] <cnd> so its behaving like it's a trackpad for pointing
[03:12] <bryceh> ah, hum
[03:13] <cnd> bryceh, I don't know if it's multitouch, but the only way to get the full touch experience would be to use the evdev driver
[03:13] <bryceh> it is multitouch, but it is a serial interface
[03:14] <cnd> bryceh, I think that means you have to use set_serial first
[03:14] <cnd> bdmurray was trying to get it to work
[03:14] <cnd> I don't know if he made it work out of the box in ubuntu though
[03:15] <bryceh> set_serial via xinput?
[03:15] <cnd> no, it's a separate utility
[03:15] <cnd> bryceh, http://www.murraytwins.com/blog/?p=103
[03:15] <bryceh> alright, well I'll mess with it more some day.
[03:16] <cnd> looks like I meant inputattach
[03:24] <Sarvatt> sucks most all touchscreens are wacom these days :(
[03:28] <cnd> or ntrig..
[04:21] <Sarvatt> cnd: xt3 and m6600 were the only ntrigs that ever shipped with ubuntu, everyone else switched to wacom in the past few years :(
[04:22] <Sarvatt> (since i started tracking it in 2010)
[04:24] <Sarvatt> x220 tablet, all lenovo W series touchscreens switched to wacom
[04:24] <Sarvatt> reviews of xt3 were saying it was a negative it still used "ntrig crap"
[04:30] <cnd> Sarvatt, the dell xps 15 and 17 are still available with it
[04:30] <cnd> but yeah, I don't blame them
[04:31] <cnd> I don't know why we can't get an atmel maxtouch touchscreen in an x86 laptop
[04:47] <tjaalton> Sarvatt: they worked with 3.0, so the quirks were only needed for 11.04
[11:41] <mornau> hi, i'm trying to get a copy of the linux 3.2.0-21.34 kernel build by/for xorg-edgers: https://launchpad.net/~xorg-edgers/+archive/ppa/+build/3379667
[11:42] <mornau> but i can't seem to find it in the repository.
[11:42] <mornau> is it still awaiting an upload?
[12:22] <ricotz> mornau, it should be available, try run "apt-get update" again
[12:25] <mornau> ricotz: i did this right before posting but there was no updated package available, yet. it worked this time, though. 
[12:25] <mornau> btw i'm gettnig this warning when installing the package: W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-1.fw for module r8169
[12:26] <mornau> i also got it for the current image (the last 3.2 kernel from the edgers repository), though, and it least for me networking isdoing fine.
[12:27] <ricotz> right, linux-firmware isnt updated to include the new firmware binaries
[12:28] <ricotz> Sarvatt, do you think it is safe and worth to put an update linux-firmware package in edgers too?
[14:10] <mornau> ricotz, Sarvatt: i'm on your linux-image 3.2.0-20.32 now, but DHCP issues remain: "dhclient: Error creating socket to list interfaces; Permission denied." this then results in: "NetworkManager[1520]: <info> (eth0): device state change: ip-config -> failed (reason 'ip-config-unavailable') [70 120 5]". also the libvirt-bin process keep getting terminated by apparmor and keeps respawning.
[14:11] <mornau> type=1400 audit(1333548406.883:1402): apparmor="DENIED" operation="create" parent=1 profile="/usr/sbin/libvirtd" pid=31996 comm="libvirtd" family="inet" sock_type="dgram" protocol=0
[14:12] <mornau> both doesn't happen with the oneiric linux image. i'm happy o file proper bug reports if that's of help. if so, please explain what to file those against.
[14:15] <ricotz> mornau, please try 3.2.0-21.34 first, note this is a plain rebuild of the current official precise kernel
[14:15] <ricotz> mornau, so you have a r8169 ethernet device and not having the updated firmware files seems to cause problems?
[14:16] <mornau> ricotz: sorry i pasted the wrong version there, i'm actually on 3.2.0-21.34 and the above report refers to this version (but also to 3.2.0-21.34)
[14:17] <mornau> ... but also to 3.2.0-20.32
[14:17] <ricotz> mornau, could you try https://launchpad.net/ubuntu/+source/linux-firmware/1.78/+build/3380028/+files/linux-firmware_1.78_all.deb
[14:19] <mornau> i do have a r8169 ethernet device. i would be surprised if this caused dhcp to fail but static ip assignment to work
[14:19] <mornau> i'm currently using static ip assignment
[14:19] <mornau> (i also have multiple NICs)
[14:20] <ricotz> mornau, the newer kernel seems to rely on the newer firmware and this might fix this problem
[14:20] <mornau> okay, i'll try with the firmware, thanks
[14:25] <Sarvatt> ricotz: no problems from me putting firmware in there
[14:26] <Sarvatt> thats really strange he's hitting that though, maybe libvirt's apparmor profile in oneiric doesn't work wth precise's kernel apparmor?
[14:26]  * Sarvatt has no clue about apparmor really
[14:27] <ricotz> Sarvatt, ok, -21.34 contains a lot appamor changes/fixes
[14:31] <ricotz> Sarvatt, i will copy the firmware package to the ppa
[14:32] <ricotz> Sarvatt, but this is probably a problem for lts-backports of the kernel too
[14:32] <ricotz> apw, hi ^
[14:41] <mornau> ricotz: i installed the firmware package you pointed me to, ran "sudo update-initramfs -u -k all", rebooted, to no effect.
[14:42] <mornau> # dpkg -l linux-firmware\* | grep ^ii ii  linux-firmware                                1.78                                                                         Firmware for Linux kernel drivers
[14:43] <mornau> hmm silly qwebirc, it eats line wraps. but i guess you know what this output should loook like.
[14:47] <mornau> i also reinstalled the kernel image and there were no more warnings about possibly missing firmware.
[14:49] <apw> ricotz, you saying there is a new dependancy between the kernel and firmware in precise?
[14:50] <apw> ricotz, there won't be a precise lts backport to lucid iirc
[14:50] <ricotz> mornau, i see, i am not that familiar with libvirt
[14:51] <ricotz> apw, ok, but i saw a similar issue with the 3.0 backport
[14:51] <ricotz> apw, .. complaining about missing nouveau firmware files
[14:52] <apw> ricotz, stupid backports, make life so difficult
[14:52] <ricotz> apw, so this also effects the oneiric ltsp backport
[14:52] <ricotz> *lts
[14:52] <apw> ricotz, could you file a bug against the kernel with the details
[14:52] <ricotz> apw, yeah, i know, another problem is also not having an updated linux-libc
[14:53] <mornau> ricotz: it's an issue with its apparmor profile, i guess. i don't need libvirt really so i just purged it. dhclient not working is a bit of a show stopper though. (so unless you want me to look into this more) i guess i'll just downgrade to the oneiric images until precise is released. thanks so far.
[14:55] <ricotz> mornau, yeah, might be the best to use the oneiric kernel then, sorry for the trouble
[14:58]  * Sarvatt would just purge apparmor instead :P
[14:59] <Sarvatt> looking at the apparmor bugs it looks like mismatched apparmor kernel and userspace breaks dhclient all the time though :(
[14:59] <Sarvatt> same bugs filed in maverick and natty
[15:00] <ricotz> so much for abi stability ;)
[15:00] <mornau> :))
[15:02]  * ricotz is surprisingly happy with 3.4rc1 so far
[15:02] <Sarvatt> and karmic and jaunty, thats a deep rabbit hole of a problem :)
[15:07] <mlankhorst> still on 3.2 here :)
[15:10] <apw> ricotz, linux-libc-dev being 'downrev' is deliberate as in theory at least the interfaces are backwards compatible
[15:10] <apw> therefore you want to build things for the oldest interface on the machine
[15:14] <ricotz> apw, hmm, i see, putting the kernel package in xedgers is mostly for this reason to have an updated linux-libc-dev
[15:14] <apw> ricotz, well in there you may be using newer things which need the newer interfaces for instance
[15:14] <ricotz> since it is expecting people using xedgers would use a newer kernel too
[15:15] <apw> ricotz, its all a bit of a mess.  actually we should not really offer a backport kernel, but a backport ppa for each release to contain this crap
[15:15] <ricotz> yeah, while having libdrm git and kernel git would fit more
[15:17] <ricotz> apw, having a ppa might lead to more inconsistencies while x-backports are starting next cycle
[15:17] <apw> ricotz, well i think i mean there needs to be one PPA for each source series destination series, with kernel, mesa, X etc in for that combination
[15:18] <ricotz> ah, i see
[15:18] <apw> there is no other safe way to do it imo, anyhow ... fun
[15:19] <ricotz> i think this should also get stricter tied together
[15:19] <ricotz> so wanting a newer x should suggest you a newer kernel
[15:20] <ricotz> (or even force you)
[15:20] <Sarvatt> ricotz: like having a new pocket for each backport series, and having the kernel be called linux and all of the x packages having the same names too? :P
[15:21] <ricotz> Sarvatt, yeah, this would be way easier to be maintained
[15:21] <Sarvatt> we're gonna get so much wrong namespacing all of x/mesa/libdrm the way lts backport kernels do
[15:21] <apw> Sarvatt, you describe Nirvana
[19:05] <cnd> bryceh, RAOF: just got a good valgrind trace on X :)
[19:05] <cnd> oh wait, it might be in the area where I was patching stuff in
[19:05] <cnd> for debugging :(
[19:11] <cnd> hmm, I think I found issues though
[19:12] <cnd> I don't know if people would see them outside of touchscreen cases though
[19:29] <bryceh> cnd, awesome
[19:31] <cnd> yeah, the way we look for pointer listeners for direct touch devices is all wrong right now
[19:31] <cnd> the code is looking at the wrong event masks
[19:31] <cnd> it's looking at the core event mask, but interpreting it as a pointer to an XI2 event mask
[19:31] <cnd> so it's all wrong
[19:50] <bryceh> cnd, is that something due to the mixed server stack, or a legit upstream bug?
[19:50] <cnd> legit upstream
[19:51] <cnd> it just hasn't been tested properly, basically
[19:52] <bryceh> ok
[20:50] <tjaalton> bryceh: the 'touchscreen is reset to relative mode' is likely a bug in g-s-d or so, since it's happening after login
[20:50] <tjaalton> bug 949097 was filed earlier
[20:51] <bryceh> friggin gnome
[20:52] <tjaalton> :)
[20:52] <bryceh> so yeah, then 973133 would be a dupe of that.  was just looking at that a bit ago
[20:52] <bryceh> is there a bug against g-s-d yet?
[20:53] <tjaalton> no, probably would be right to add it to the earlier bug, until it's clear the bug is there
[20:53] <tjaalton> since the login screen should be running g-s-d as well..
[20:55] <tjaalton> hmm
[20:55] <tjaalton> would be easy to test
[20:55] <tjaalton> by disabling the wacom plugin
[20:55] <Sarvatt> its not running g-s-d plugins though
[20:55] <tjaalton> right
[20:55] <tjaalton> realized that
[20:56] <tjaalton> actually, the bug might be that the touchscreen isn't actually reported as one by the kernel
[20:56] <tjaalton> but a tablet
[20:56] <tjaalton> where relative mode makes sense
[20:56] <tjaalton> hmm no
[20:57] <tjaalton> it should be in relative mode in the login screen as well then
[20:59] <tjaalton> bryceh: so, flip the wacom plugin off, org.gnome.settings-daemon.plugins.gsdwacom:active, and login again
[21:01] <bryceh> alrighty, is there a utility for turning it off, or a config file?
[21:02] <tjaalton> dconf-editor, or gsettings
[21:04] <tjaalton> gsettings set org.gnome.settings-daemon.plugins.gsdwacom active false
[21:04] <tjaalton> then 'get ... active' to check that it worked
[21:07] <bryceh> yep, that did the trick
[21:07] <bryceh> works properly on both login screen and logged in
[21:07] <tjaalton> whee
[21:07] <bryceh> stylus and eraser also working
[21:08] <tjaalton> yeah those should've worked before too
[21:08] <bryceh> they did, was just checking that they still did ;-)
[21:08] <tjaalton> hehe, right
[21:14] <cnd> bryceh, have you seen any bugs where people are attempting to perform a two touch tap on a trackpad and it is generating a middle button click instead of right?
[21:14] <cnd> olli ries, my manager, is seeing it
[21:14] <cnd> first, the defaults in X are wrong due to a distro patch from 2009 :)
[21:14] <cnd> but then gsd should be overwriting the config
[21:15] <cnd> which is why no one sees the issue
[21:50] <bryceh> cnd, not that I remember offhand, but I can take a quick scan
[21:50] <cnd> bryceh, this is the bug olli filed: https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/973784
[21:50] <cnd> it seems like something someone might toss in the X package bugs mistakenly
[21:53] <bryceh> bug 972125 maybe
[21:53] <bryceh> there's lots of reports of touchpads that just stop working entirely after thus and such
[21:54] <bryceh> bug 972727
[22:56] <cnd> ok, I got another patch for the xserver today :)
[22:56]  * cnd knocks down more bugs
[23:17] <bryceh> :-)