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