[14:08] <cnd> Satoris, how's the bug reporting script going?
[14:14]  * bregma sips
[14:15] <cnd> I'm going to be trying to fix jenkins build issues with xorg-gtest, then moving on to a bunch of x fix reworking for upstream comments
[14:16] <bregma> which xorg-gtest issues?
[14:16] <cnd> dandrader|afk, Satoris, tvoss: standups!
[14:16] <cnd> bregma, same you mentioned yesterday
[14:16] <tvoss> interviews, jenkins work (utouch-* builds and tests again) and #950974
[14:16] <cnd> can't find the sources
[14:16] <bregma> that's fixed
[14:16] <cnd> bregma, how?
[14:16] <bregma> we fixed it about an hour ago
[14:16] <cnd> ahh cool
[14:16] <Satoris> Being sick.
[14:16] <tvoss> cnd, an issue with an old pkgconfig
[14:16] <bregma> tvoss refreshed the package
[14:16] <cnd> good
[14:16] <tvoss> apt-get install --reinstall did the trick
[14:16] <bregma> now we get the usual transient failures
[14:17] <cnd> ugh
[14:17] <tvoss> :)
[14:17] <bregma> feel free to tackle those
[14:18] <bregma> I guess I can do the configuration options in geis today
[14:18] <cnd> yay
[14:18] <bregma> is there a list of what needs to be configured?  a bug maybe?
[14:21] <bregma> I have: drag threshold, pinch timeout, pinch threshold, drag timeout, rotate threshold, rotate timeout, tap threshold, tap timeout
[14:21] <dandrader|afk> reading about touch ownership and touch grabs. improving the port of unity gestures code to geisv2  api
[14:28] <cnd> bregma, that looks like it's it, but you can check the grail docs if you want
[14:28] <cnd> look at the UGSubscriptionProperty list
[14:32] <bregma> 'swhat I did
[14:32] <cnd> bregma, the good news is that all the geis tests pass on behemoth
[14:33] <cnd> the bad news is that all the geis tests pass on behemoth
[14:33] <bregma> all the geis tests pass on my machines, at least the first time
[14:34] <bregma> maybe 1 out of 3 subsequent runs without a rebuild
[14:35] <cnd> hmm
[14:35] <bregma> depending on the phase of the moon and of the markets are rising or falling
[14:35] <cnd> it's weird that it fails on both amd64 and i386 in jenkins
[14:36] <bregma> I had the amd64 build pass that fail point and fail on a bug in the test case
[14:36] <bregma> I pushed in a fix for the test case and then it failed on the transient error
[14:37] <cnd> heh
[14:39] <cnd> bregma, in geis2/gtest_devices.cpp you create a no-atomic geis
[14:39] <cnd> but you don't ever accept or reject the touches
[14:39] <cnd> the gestures I mean
[14:40] <cnd> it could be that there is some stale state carried over from one test to the next?
[14:41] <cnd> oooh
[14:41] <cnd> I might see the issue
[14:41] <cnd> in GTestGeisFixture::SetUp(), it advertises XI 2.2 support
[14:41] <cnd> in GeisDeviceTests, it doesn't
[14:41] <cnd> GeisDeviceTests::SetUp() that is
[14:42] <cnd> so accepting and rejecting touches will fail
[14:42] <cnd> I don't know why it doesn't always fail though...
[14:43] <cnd> oh, because it doesn't actually accept or reject touches
[14:44] <cnd> when geis is closed and the client connection closes, the X server is rejecting the touches automatically I bet
[14:45] <bregma> I intercept the XClose call errors, the failing call is coming from elsewhere
[14:45] <cnd> the failing call is an XIAllowEvents
[14:45] <cnd> which is used to accept/reject touches
[14:46] <cnd> so when it fails, it is actually making accept/reject requests
[14:46] <dandrader> cnd, did the fix for https://bugs.launchpad.net/unity/+bug/978378 work after that device reporting bug on geisv1 was fixed?
[14:46] <cnd> dandrader, oh right, let me check
[14:46] <cnd> bregma, I bet that intermittently grail is not recognizing the gesture
[14:47] <cnd> and it then rejects the touches
[14:47] <cnd> but that rejection fails because the client hasn't advertised XI 2.2 support
[14:49] <cnd> huh... I'm not getting any gestures any more
[14:49] <cnd> it could be due to my X changes...
[14:49] <cnd> argh
[14:50] <bregma> I don't see a GeisDeviceTests::SetUp(), am I missing something?
[14:56] <cnd> yeah, I was reading it wrong
[14:57] <cnd> bregma, I think the code is correct
[14:57] <cnd> I need to think of why else it would fail...
[14:59] <cnd> dandrader, four touch tap works
[14:59] <cnd> I think maybe your code broke something
[14:59] <cnd> will check
[14:59] <dandrader> cnd, ?
[15:00] <cnd> I can't get the three touch window decorations to show up
[15:00] <cnd> or move the window
[15:01] <cnd> dandrader, it looks like the coordinates are in device coords instead of screen coords
[15:01] <cnd> so FindCompWindowAtPos doesn't find any window
[15:02] <dandrader> cnd, for  direct device?
[15:02] <cnd> yeah
[15:03] <dandrader> cnd, touches  always come in device coordinates, right?
[15:04] <cnd> so grail gives you both
[15:04] <cnd> the question is what geis does?
[15:04] <cnd> I think geis may only give one of them
[15:04] <cnd> and for direct devices, it should be giving screen coords now
[15:05] <dandrader> yet another thing to be documented in geis API: in what coordinate system touch points come
[15:06] <cnd> yeah
[15:06] <cnd> bregma, does that seem right to you? we should be sending direct touch position in screen coords?
[15:09] <bregma> hasn;t this been discussed many times?
[15:09] <cnd> probably
[15:09] <cnd> but it seems we still haven't completely resolved everything
[15:11] <bregma> I believe the resolution was that direct devices give screen coordinates and indirect devices give device coordinates (as in, the input device, not the display device containing the pointer)
[15:12] <bregma> really, it absolutely needs to be documented somewhere
[15:13] <cnd> yeah
[15:14] <cnd> though to be completely accurate, direct devices are in window coordinates
[15:14] <cnd> which for unity's case is the same as screen coords
[15:14] <cnd> since it's on the root window
[15:14] <cnd> dandrader, would you be happy to tackle this?
[15:16] <dandrader> yes
[15:16] <cnd> biab
[15:16] <dandrader> cnd,  but if the touch points of a direct device are in window coordinates why they don't  hit anything in FinCompWindowAtPos()?
[15:40] <cnd> dandrader, that's the problem
[15:40] <cnd> they aren't in window coords right now
[15:40] <cnd> they are in screen coords
[15:40] <cnd> sorry, they are in device coords right now
[18:39] <dandrader> bregma, is the current geis implementation capable of sending events with more than one GeisGroup?
[18:40] <bregma> the library is, I don;t thing the grail back end is
[18:41] <dandrader> hmm, ok
[18:47] <bregma> it's not that it's not capable, I just don't think grail will do that ... I could be wrong
[20:38] <ah-> i'm having problems with multitouch on a macbook pro 6,2, gestures don't work, both geistest and ginn say "error subscribing to gestures"
[20:39] <ah-> is filing a bug against utouch the right way to report this?
[20:39] <ah-> full geistest output: http://nopaste.me/paste/18998271854f888cc2d99a9
[20:39] <ah-> this has changed quite a lot during the last weeks, but multitouch never really worked
[20:40] <ah-> a few days i'd get this error, then it would subscribe to gestures but not actually recognize them and then after the next dist-upgrade i got the same error again
[20:51] <bregma> you're going to have trouble if you;re trying to subscribe to the root window, unity has already grabbed gesture there
[21:04] <ah-> i'm using gnome shell
[21:05] <ah-> and gestures don't work in unity either
[21:06] <bregma> well, the error subscribing to gestures is almost certainly because there's already a gesture grab on the root window -- geistest without arguments tries to grab the root window
[21:06] <bregma> try running geistest with a different window (xwininfo can give you the window ID)
[21:07] <bregma> geistest -w 0xdeadbeef
[21:09] <ah-> ah great, thanks
[21:09] <ah-> somehow ginn was already running
[21:10] <bregma> you can go to "startup applications" and disable it
[21:11] <cnd> ah-, if you have the utouch daily ppa installed, it runs by default
[21:12] <ah-> that explains it cnd
[21:17] <ah-> i still have problems with gesture recognition with ginn
[21:17] <ah-> using this wishes.xml: http://nopaste.me/paste/4613804954f8897d9aad04
[21:17] <ah-> the gesture outputting j works fine, the one listening on finish doesn't work
[21:18] <ah-> a few days ago i got the sources for ginn with apt-get source and added a few more debug messages
[21:18] <ah-> to version ginn-0.2.5+r89+p14~precise1 to be precise
[21:19] <ah-> this results in this log: http://nopaste.me/paste/9093497654f8898592beca
[21:23] <bregma> maintenance on ginn has fallen behind
[21:24] <ah-> any other way to get a swipe to trigger a key press in gnome shell?
[21:24] <ah-> touchegg doesn't work either
[21:24] <ah-> it segfaults, but i think there's already a bug filed against it
[21:25] <cnd> ah-, you may want to run with GRAIL_DEBUG=-1 and/or GEIS_DEBUG=3
[21:25] <cnd> then you can attach the log to a bug report
[21:25] <cnd> and we can try to figure out what went wrong
[21:26] <ah-> for touchegg?
[21:26] <cnd> sure
[21:27] <cnd> and for ginn
[21:27] <cnd> we can at least make sure that the underlying utouch stack is working properly
[21:27] <cnd> but note that we don't develop touchegg, and we don't really support ginn much
[21:28] <ah-> ok, i'll do that
[21:29] <bregma> we do accept contributions if you have a fix, though
[21:31] <ah-> well if i happen to fix it i'll surely send a patch
[21:31] <cnd> :)