[00:19] <RAOF> hyperair: What do you mean by "pixel perfect scrolling"?  You mean the smooth-scrolling that gtk3 gets?
[00:19] <hyperair> RAOF: yeah that
[00:20] <hyperair> RAOF: i just wrote a small test program that dumps out the delta_x/y that it receives via GDK_SMOOTH_SCROLL_MASK, and will test it otu the next time my scrolling freezes up
[00:20] <RAOF> I've noticed that it dies in evolution sometimes, but I chalked that up to evolution struggling on the challenging internet connection I have here.
[00:20] <hyperair> hmm
[00:20] <hyperair> in this case it dies in everything that uses Gtk3's GtkScrolledWindow
[00:22] <hyperair> the last time this happened, i ran an evince window in gdb and found that it was generating + and - delta_y events which were cancelling each other out
[00:22] <RAOF> Ah, right.
[00:22] <RAOF> Yeah, now noticed that.
[00:23] <hyperair> reloading the psmouse module fixes it
[00:24] <RAOF> http://paste2.org/p/1983874
[00:24] <RAOF> Ra raw.
[00:25] <RAOF> That's test-xi2 output.
[00:25] <RAOF> Looks like the raw valuator is fine, but the cooked valuator is stuck at -2147483648.00
[00:26] <hyperair> what's this cooked valuator?
[00:26] <RAOF> The thing that GTK listens to.
[00:26] <hyperair> hm
[00:27] <RAOF> ie: it's the value of the axis after any acceleration, processing, etc.
[00:29] <hyperair> i see
[00:45] <hyperair> Sarvatt: ping
[00:45] <hyperair> what's the gesture that's hooked up to opening the dash?
[00:49] <Sarvatt> hyperair: 4 finger tap
[00:51] <hyperair> hmm
[00:51] <hyperair> how does 2 finger scrolling end up as a 4 finger tap..
[00:51] <hyperair> and in the first place, how is utouch even working when the utouch patch has been disabled?
[00:53] <hyperair> RAOF: is it safe to bring up the 117_gestures.patch yet?
[00:53] <hyperair> perhaps that's the key to this
[00:55] <Sarvatt> 117_gestures.patch is obsolete after real multitouch
[00:56] <hyperair> i see
[00:56] <hyperair> i'm not getting "real multitouch" on my laptop though
[00:56] <hyperair> evince and eog no longer respond to pinch and rotate
[00:57] <hyperair> could you try disabling coasting and seeing if that helps?
[00:57] <hyperair> CoastingSpeed=0
[01:10]  * RAOF suspects integer overflow
[01:19] <RAOF> Yeah, something's overflowing.
[01:23] <Sarvatt> well that was fun, took 20 minutes to get into a unity 3d session again trying to restart lightdm, so much for staying off the pc on a sick day :)
[01:24] <RAOF> Sarvatt: You're sick?  Boo :(
[01:24] <Sarvatt> was just getting dumped back to the greeter, trying 0ubuntu5 out now
[01:24] <Sarvatt> odd thing is, i couldn't reproduce it in a guest session
[01:30] <RAOF> You've probably got an odd setting.
[01:30] <RAOF> Somewhere.
[01:31] <RAOF> hyperair: Have you filed a bug?
[01:33] <Sarvatt> i'll invalidate out the bug if i still dont notice it tomorrow
[01:34] <RAOF> hyperair: Also, I don't suppose you know whether the same problem occurs with evdev?
[01:34] <RAOF> Hm, actually, evdev can't duplicate it because it won't have a scroll valuator.  Bah.
[01:35] <hyperair> RAOF: you mean regarding the valuator?
[01:35] <hyperair> RAOF: i haven't filed a bug, actually. i was looking for a way to reproduce this
[01:35] <RAOF> Yeah.
[01:35] <hyperair> it randomly happens, but often enough to get annoying
[01:35] <RAOF> hyperair: Well, I'm pretty sure you'll be able to reproduce it by just continually 2-finger scrolling down.
[01:35] <hyperair> oh it's happened
[01:35] <hyperair> O_o
[01:41] <hyperair> hmm turns out that it's emitting GDK_SCROLL events with GDK_SCROLL_SMOOTH direction with delta_x=0 and delta_y=0
[01:45] <bjsnider> Sarvatt, turns out the 295.40 blob doesn't work on anything less than or equal to the g80, which is what the 8800gts.gtx have. that's a minor snafu
[01:48] <RAOF> hyperair: Yeah, that's exactly right.
[01:48] <RAOF> And if you check out xinput test-xi2, you'll find that the scroll events all have a valuator of -2147483648.00
[01:49] <RAOF> And it's *stuck* on that value, so delta_x is obviously 0.
[01:50] <hyperair> RAOF: no, delta_y
[01:50] <hyperair> delta_x is still working
[01:50] <RAOF> Bah, that's what I meant.
[01:51] <hyperair> heheh
[01:52] <hyperair> where's test-xi2 anyway?
[01:52] <RAOF> xinput test-xi2 $DEVICEID
[01:54] <hyperair> whoops, when i scroll on that window compiz detects it on the root window (i think) and switches the deskto
[15:54] <kklimonda> how are fglrx packages versioned? the amd driver on their website has version 12.3, but we are at 2:8.960
[15:54] <jcristau> "weirdly"
[15:55] <tjaalton> right
[15:55] <kklimonda> well, that I can see ;
[15:55] <kklimonda> ;)
[15:55] <tjaalton> the version we have is what the driver says it is. amd uses some year.release schema
[15:57] <kklimonda> tjaalton: that's.. confusing
[15:57] <kklimonda> people go to the amd website, see that their version is at 12.3 and go all like "omg, ubuntu drivers are so out of date - I have to update" and proceed to breaking their system
[15:59] <tjaalton> tseliot: maybe the fglrx package could mention the "marketing version" on the package description?
[15:59] <kklimonda> in all the time I've spent on my LoCo channel using upstream nvidia/amd drivers have been the biggest source of support questions
[15:59] <jcristau> it's all part of an evil plan to make people stop wanting to install those drivers
[16:00] <kklimonda> also, because people are sort of smart they know they have to remove all the packages with nvidia in the name to install upstream nvidia driver
[16:00] <kklimonda> and by doing that they remove nvidia-common which would prevent nvidia installer from installing the driver ;)
[16:00] <tjaalton> good for them
[16:00] <tjaalton> :)
[16:01] <kklimonda> and then they go their merry way telling others how bad Ubuntu is ;)
[16:01] <kklimonda> which isn't that good ;)
[16:01] <tjaalton> let's move that to jockey then
[16:01] <tjaalton> dunno
[16:03] <kklimonda> I'm pretty sure the battle is completely lost
[16:03] <kklimonda> a lot of new ubuntu users are so called "power users" from windows
[16:03] <kklimonda> and power users know exactly enough to destroy their systems ;)
[16:03] <kklimonda> (especially how to copy and paste random scripts from the web)
[16:04] <tjaalton> yes
[16:04] <tjaalton> with 'sudo' on every line
[16:09] <tseliot> tjaalton: do you think they would look for the driver version in the package description?
[16:09] <tjaalton> tseliot: where do they get the package version?-)
[16:10] <tseliot> tjaalton: either Jockey or update-manager, I'd say
[16:10] <tjaalton> doesn't it show the description too
[16:10] <tseliot> maybe Jockey does it
[16:10]  * tseliot can't remember
[16:11] <tseliot> update-manager does not
[16:12] <tjaalton> just leave it as is
[16:12] <tseliot> tjaalton: and that would require one more manual step in the packaging
[16:12] <tjaalton> software-center doesn't show it
[16:12] <tjaalton> no idea where the text is from
[16:14] <tseliot> P.S. marketing versions are crazy :P
[17:52] <JanC> kklimonda: s/power users/tweakers/   ;)
[17:55] <kklimonda> JanC: potatoe potato ;)
[18:09] <JanC> nah, lots of power users don't have time to tweak all day
[18:11] <JanC> although maybe that would only affect the frequency of breaking their system  ;)
[18:29] <mars> Hi everyone, quick question: I am trying to run intel_gpu_dump on Precise and found that the program is missing.  Was it renamed?
[18:57] <albert23> mars: you don't need it anymore. If the gpu hangs, it will dump contents automatically in /sys/kernel/debug/dri/0/i915_error_state
[19:18] <mars> albert23, that's what I thought, thanks
[20:06] <tjaalton> bryceh: was there a kernel build with drm-intenl-next-queued somewhere? I only see -next on the mainline ppa
[20:06] <tjaalton> -n
[20:08] <bryceh> tjaalton, yes
[20:09] <bryceh> since Intel renames their branch-to-test so frequently we decided to just give it our own naming, which is drm-intel-experimental
[20:09] <bryceh> currently that maps to daniel's drm-intel-next-queued
[20:09] <tjaalton> oh there it is
[20:09] <tjaalton> had to reload the page :)
[20:10] <bryceh> when they switch to drm-intel-proposed-next-testing-queued-really, we can just update the mapping :-)
[20:10] <tjaalton> yeah I noticed the discussion you had the other day :)
[20:19] <bryceh> hopefully if they change it again, we can catch it sooner
[20:20] <bryceh> seems this time it changed in january, but I only realized it this past week
[20:24] <tjaalton> jesse asked poolie to test it to see if it fixes bug 745112, that's why I was asking
[20:25]  * bryceh nods
[20:28] <bryceh> tjaalton, hey do you know offhand what package provides the scripts for dpkg-reconfigure keyboard-configuration?
[20:30] <tjaalton> bryceh: keyboard-configuration? :)
[20:30] <tjaalton> that's the package name being configured
[20:30] <bryceh> duh, ok thanks :-)
[20:31] <bryceh> oh, but source package is our old friend console-setup
[20:31] <tjaalton> yeah, ok
[20:33] <bryceh> bingo, found the bug :-) 
[20:39] <tjaalton> is it 985065?
[20:54] <bryceh> tjaalton, that's right
[22:15] <cnd> bryceh, as soon as I get a couple more reviewed-bys on my input patches from whot I plan to push a big SRU for xorg-server with them
[22:15] <cnd> it would help to have someone else on the ubuntu side double check the patches just for sanity
[22:16] <cnd> I have them all here: http://cgit.freedesktop.org/~cndougla/xserver/log/?h=input-fixes
[22:16] <cnd> they were all found as I was attempting to fix bug 974887
[22:17] <cnd> so basically, I'm giving you a heads up, and if you have some spare moments and feel like reviewing them ahead of time, please do
[22:17] <cnd> RAOF, you too
[22:18] <cnd> oh, I forgot to mention that I won't be including the last two commits because they would be ABI breaks and I don't think anyone will use them in precise
[22:19] <bryceh> cnd, ok, got a few plates in the air at the moment, but will review them when things calm down
[22:20] <cnd> thanks