=== dandrader is now known as dandrader|afk | ||
cnd | Satoris, how's the bug reporting script going? | 14:08 |
---|---|---|
* bregma sips | 14:14 | |
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:15 |
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:16 |
cnd | ugh | 14:17 |
tvoss | :) | 14:17 |
bregma | feel free to tackle those | 14:17 |
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:18 |
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:21 |
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:28 |
bregma | 'swhat I did | 14:32 |
cnd | bregma, the good news is that all the geis tests pass on behemoth | 14:32 |
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:33 |
bregma | maybe 1 out of 3 subsequent runs without a rebuild | 14:34 |
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:35 |
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:36 |
=== dandrader|afk is now known as dandrader | ||
cnd | heh | 14:37 |
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:39 |
cnd | it could be that there is some stale state carried over from one test to the next? | 14:40 |
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:41 |
cnd | so accepting and rejecting touches will fail | 14:42 |
cnd | I don't know why it doesn't always fail though... | 14:42 |
cnd | oh, because it doesn't actually accept or reject touches | 14:43 |
cnd | when geis is closed and the client connection closes, the X server is rejecting the touches automatically I bet | 14:44 |
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:45 |
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:46 |
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:47 |
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:49 |
bregma | I don't see a GeisDeviceTests::SetUp(), am I missing something? | 14:50 |
cnd | yeah, I was reading it wrong | 14:56 |
cnd | bregma, I think the code is correct | 14:57 |
cnd | I need to think of why else it would fail... | 14:57 |
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, ? | 14:59 |
cnd | I can't get the three touch window decorations to show up | 15:00 |
cnd | or move the window | 15:00 |
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:01 |
dandrader | cnd, for direct device? | 15:02 |
cnd | yeah | 15:02 |
dandrader | cnd, touches always come in device coordinates, right? | 15:03 |
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:04 |
dandrader | yet another thing to be documented in geis API: in what coordinate system touch points come | 15:05 |
cnd | yeah | 15:06 |
cnd | bregma, does that seem right to you? we should be sending direct touch position in screen coords? | 15:06 |
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:09 |
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:11 |
bregma | really, it absolutely needs to be documented somewhere | 15:12 |
cnd | yeah | 15:13 |
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:14 |
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:16 |
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 | 15:40 |
=== dandrader is now known as dandrader|lunch | ||
=== dandrader|lunch is now known as dandrader | ||
dandrader | bregma, is the current geis implementation capable of sending events with more than one GeisGroup? | 18:39 |
bregma | the library is, I don;t thing the grail back end is | 18:40 |
dandrader | hmm, ok | 18:41 |
bregma | it's not that it's not capable, I just don't think grail will do that ... I could be wrong | 18:47 |
=== dandrader is now known as dandrader|afk | ||
=== dandrader|afk is now known as dandrader | ||
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:38 |
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:39 |
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:40 |
bregma | you're going to have trouble if you;re trying to subscribe to the root window, unity has already grabbed gesture there | 20:51 |
ah- | i'm using gnome shell | 21:04 |
ah- | and gestures don't work in unity either | 21:05 |
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:06 |
bregma | geistest -w 0xdeadbeef | 21:07 |
ah- | ah great, thanks | 21:09 |
ah- | somehow ginn was already running | 21:09 |
bregma | you can go to "startup applications" and disable it | 21:10 |
cnd | ah-, if you have the utouch daily ppa installed, it runs by default | 21:11 |
ah- | that explains it cnd | 21:12 |
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:17 |
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:18 |
ah- | this results in this log: http://nopaste.me/paste/9093497654f8898592beca | 21:19 |
bregma | maintenance on ginn has fallen behind | 21:23 |
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:24 |
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:25 |
ah- | for touchegg? | 21:26 |
cnd | sure | 21:26 |
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:27 |
ah- | ok, i'll do that | 21:28 |
bregma | we do accept contributions if you have a fix, though | 21:29 |
ah- | well if i happen to fix it i'll surely send a patch | 21:31 |
cnd | :) | 21:31 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!