| Satoris | Unity 2D's dash not showing is _not_ caused by the gesture stack. I can verify that it does get the gestures, but the Dash visibility toggling code does not do what it is supposed to. | 07:41 |
|---|---|---|
| === MacSlow is now known as MacSlow|lunch | ||
| === MacSlow|lunch is now known as MacSlow | ||
| cnd | dandrader, bregma, tvoss: standups! | 14:15 |
| * bregma sips some cold dark-roasted Sumatran | 14:15 | |
| tvoss | working on chromium patch, https://code.launchpad.net/~thomas-voss/utouch-frame/generic-backend and #950974 | 14:15 |
| bregma | just fixed #973539, writing a good test case (hopefully) | 14:15 |
| cnd | I'm *still* working on bug 974887, which involves many nasty hairy issues in the server when touchscreen pointer emulation is performed | 14:15 |
| bregma | I don't like touching hairy issues | 14:16 |
| cnd | here's the gist: | 14:16 |
| cnd | you have two touches in sequence, down up down up | 14:16 |
| cnd | both are grabbed by a touch grab | 14:16 |
| dandrader | I'm rebasing my s/geisv1/geisv2 refactoring on unity gestures code on top of my changes done for https://bugs.launchpad.net/unity/+bug/978378 | 14:16 |
| cnd | the second touch is rejected before the first touch | 14:16 |
| cnd | while both touches can be pointer emulated, we can't send pointer events for touch 2 before touch 1 | 14:17 |
| dandrader | then I'll continue working on looking at what's missing on unity 3d gestures | 14:17 |
| cnd | dandrader, I'm sorry I haven't had a chance to test your unity fix yet | 14:17 |
| cnd | I hope to finish off the bug I'm working on this morning | 14:17 |
| cnd | and then I'll get to testing it | 14:17 |
| dandrader | cnd, ok | 14:18 |
| bregma | cnd, do you know if is there a directive in xorg.conf to force the server to NOT load an extension? | 14:18 |
| cnd | bregma, which extension? | 14:19 |
| cnd | I don't know anything off the top of my head | 14:19 |
| cnd | man xorg.conf | 14:19 |
| bregma | yeah, I'm doing that but asking is quicker, if you know the answer | 14:19 |
| bregma | I want to disable the XInput extension to test what happens when uTouch is used against a server that does not have it | 14:20 |
| bregma | that bug is reported frequently, we need to handle it gracefully | 14:20 |
| cnd | bregma, whoa, I don't think that's possible | 14:20 |
| cnd | I think there are some extensions that are not optional | 14:20 |
| cnd | and XI is one of them | 14:20 |
| bregma | well, I can test against no server at all, the code path is almost the same | 14:21 |
| bregma | but not identical | 14:21 |
| cnd | bregma, you could also patch the server to not advertise it? | 14:21 |
| bregma | not worth it for a simple regression test | 14:21 |
| cnd | yeah | 14:22 |
| bregma | as far as uTouch is concenrned, no server and no XI2.2 are pretty much the same thing | 14:22 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| === tvoss is now known as tvoss|early_dinn | ||
| === dandrader is now known as dandrader|lunch | ||
| === tvoss|early_dinn is now known as tvoss | ||
| cnd | so many bugs I'm encountering when using a touchscreen... | 17:37 |
| tvoss | cnd, ping | 17:46 |
| cnd | tvoss, pong | 17:46 |
| tvoss | cnd, finished pimpl'ing of the generic backend, unit tests pass: https://code.launchpad.net/~thomas-voss/utouch-frame/generic-backend | 17:46 |
| cnd | cool | 17:47 |
| tvoss | cnd, next step: port over the x backend, or should I go for documenting the code and start porting the x backend after that? | 17:48 |
| cnd | tvoss, documentation should be done first, methinks | 17:48 |
| cnd | it also helps one notice holes in implementations :) | 17:48 |
| tvoss | cnd, no problem, will tackle that first | 17:48 |
| cnd | tvoss, I think we might want to rename the includes as <utouch/backend/*> | 17:49 |
| tvoss | cnd, yeah, do you think we should rename generic to something like legacy? | 17:49 |
| cnd | tvoss, why legacy? | 17:50 |
| tvoss | cnd, I think due to my bad understanding of english ;) | 17:50 |
| tvoss | let me give leo a try | 17:50 |
| cnd | tvoss, legacy in this context would mean something kept around from the past | 17:50 |
| cnd | like a compatibility layer | 17:51 |
| tvoss | cnd, ack ... and totally misleading :) stick with generic then? | 17:52 |
| cnd | tvoss, I think we might want to structure this as src/v2/backend/<backend framework implementation> and src/v2/backends/<backend implementations> | 17:52 |
| cnd | ? | 17:52 |
| cnd | oh wait, I'm wrapping my head around this the wrong way | 17:52 |
| cnd | hmm | 17:53 |
| tvoss | cnd, but the structure is fine for me | 17:54 |
| cnd | tvoss, what I'm thinking is that the generic backend implementation should be part of the main implementation | 17:54 |
| cnd | right now you have a generic backend on top of the main implementation | 17:54 |
| cnd | so it sits beside the current X backend | 17:54 |
| cnd | instead, should we move the generic backend code into the main implementation itself? | 17:55 |
| tvoss | yeah, like a well-defined interface to the underlying implementation | 17:55 |
| cnd | yeah | 17:56 |
| tvoss | awesome | 17:56 |
| cnd | the idea really is that we are creating a public api for the frame backend, which is currently private | 17:58 |
| tvoss | indeed, encouraging people to "port" frame in terms of custom backends | 17:59 |
| tvoss | cnd, do you have any feedback from jorge regarding the uds sessions? | 18:06 |
| cnd | tvoss, they are scheduled | 18:06 |
| cnd | I'll forward you the email | 18:06 |
| tvoss | cnd, thanks | 18:06 |
| === dandrader|lunch is now known as dandrader | ||
| dandrader | cnd, I'm starting to think that fixing this drag timeout issue in unity is more important than porting it to geisv2 api | 18:45 |
| cnd | dandrader, the fix merely entails exposing the threshold and timeout configuration through geis | 18:46 |
| cnd | you can ask bregma for details on how to do it | 18:46 |
| cnd | it should be simple | 18:46 |
| cnd | grail already has an API for setting the configurations | 18:46 |
| dandrader | cnd, is the "flick" gesture type working or is it deprecated? | 18:49 |
| cnd | dandrader, it was an attempt to make a flick or a hold gesture possible with the old architecture | 18:50 |
| cnd | I don't think there's any reason it shouldn't still work, but it may be better to do it on the client side of geis | 18:50 |
| cnd | bregma? | 18:50 |
| cnd | I think I'm down to one last issue in the server, but it's very intermittent | 19:02 |
| cnd | I can't seem to nail it down | 19:02 |
| dandrader | cnd, should we expose those gesture configurations only in geisv2 or also in geisv1? | 19:03 |
| cnd | dandrader, I think only in geis 2 | 19:03 |
| cnd | it's not worth the effort in geis 1 | 19:03 |
| dandrader | ok. so the fix for that in unity will carry along with it the port for geisv2 api :) | 19:04 |
| bregma | I don;t think flick has been tested in a very long time | 19:07 |
| bregma | ... the geis v1 configuration is a passthrough to the geis v2 configuration, the only extra work is in setting up the test cases (test cases are about 500% of the work involved in most tasks) | 19:08 |
| === tvoss is now known as tvoss|gftd | ||
| cnd | dandrader, this isn't a fix for a bug in precise is it? | 19:18 |
| cnd | it's needed for future gesture work, correct? | 19:18 |
| dandrader | cnd, it's in precise | 19:19 |
| cnd | dandrader, so what is the bug, and why do we need to configurations? | 19:19 |
| bregma | the door is rapidly swinging closed for precise | 19:19 |
| dandrader | if you put 3 fingers over a window, wait a second or so, and then start dragging them the window will stay put since the drag gesture has timed out | 19:19 |
| cnd | dandrader, there are two resolutions: | 19:20 |
| cnd | 1. Won't fix | 19:20 |
| cnd | 2. use the info from the touch gesture events instead | 19:20 |
| cnd | I'm fine with either, tbh | 19:20 |
| cnd | people who want to move their windows are very likely to begin moving them as soon as they touch them | 19:21 |
| dandrader | I think it would be silly to have this limitation | 19:21 |
| cnd | dandrader, yes, I don't think we should have the limitation either, but it's not a huge deal imo | 19:22 |
| dandrader | it's not huge, sure | 19:22 |
| cnd | and I think it's worked this way for multiple releases, so it's not a regression either | 19:22 |
| dandrader | but it's not a rare situation either, I think | 19:22 |
| cnd | dandrader, sometimes you have to cut your losses and hope to fix things in the next release :) | 19:23 |
| cnd | it's only 6 months away :) | 19:23 |
| cnd | btw, I'm going to try your unity branch right now | 19:23 |
| cnd | argh, nux changes again | 19:27 |
| cnd | wait a minute... | 19:28 |
| cnd | it's trying to in include Nux/Nux.h | 19:29 |
| cnd | but all the nux -dev packages are namespaced like Nux-2.0/Nux.h | 19:29 |
| cnd | how is this supposed to compile? | 19:29 |
| cnd | dandrader, do you have /usr/include/Nux? | 19:30 |
| dandrader | the path is [...]/Nux-2.0/Nux/Nux.h | 19:31 |
| cnd | ahh | 19:31 |
| cnd | so in my build configuration it isn't looking in the right place for some reason | 19:31 |
| dandrader | you might want to rm * -rf build and run cmake again | 19:32 |
| cnd | I just did a clean checkout and cmake configuration | 19:32 |
| cnd | nothing would have changed | 19:32 |
| dandrader | did it find nux at all? | 19:33 |
| cnd | I resolved it | 19:36 |
| cnd | I did what you said :) | 19:36 |
| cnd | because cmake failed once because I was missing a dep | 19:36 |
| cnd | so I installed the dep and reran it | 19:36 |
| cnd | but apparently rerunning cmake doesn't produce the same result as a clean cmake run | 19:37 |
| dandrader | yeah, cmake seems to do a lot of caching | 19:38 |
| * bregma keeps studiously silent | 19:39 | |
| cnd | yeah, that's it's point, but if it caches it needs to do so correctly :) | 19:39 |
| bregma | woo-hoo, I got a jenkins failure mail for the first time evarr | 19:39 |
| cnd | yay | 19:40 |
| bregma | make[3]: *** No rule to make target `/src/xorg-gtest-all.cpp', needed by `libgtest_geis_a-xorg-gtest-all.o'. Stop. | 19:41 |
| bregma | hmmmm | 19:41 |
| cnd | bregma, sounds like an out of date aclocal macro | 19:42 |
| cnd | the gtest prefix isn't being set properly | 19:42 |
| cnd | bregma, oh right | 19:43 |
| cnd | this was an issue in the pbuilder-jenkins setup | 19:43 |
| cnd | check the build log for it attempting to install some dependencies | 19:43 |
| cnd | like xorg-gtest | 19:43 |
| cnd | it is probably trying to install libxorg-gtest0, which doesn't exist anymore | 19:44 |
| cnd | I remember hitting this issue with grail | 19:44 |
| cnd | dandrader, I'm hitting bugs in the x server with your branch again, so it'll be a bit before I can get back to you... | 19:50 |
| dandrader | ok | 19:52 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| cnd | I'm getting really annoyed with pointer emulation bugs | 20:57 |
| cnd | however, this new bug looks to be a compiz bug | 20:58 |
| bregma | yay, play pass the bug | 21:03 |
| cnd | oo, it is a bug in the unity gesture code | 21:06 |
| cnd | I think it's always been there | 21:06 |
| cnd | and my X fixes have activated it from being dormant to being a real issue | 21:06 |
| cnd | dandrader, when gestures start, they call pushGrab | 21:07 |
| cnd | when they end, they call releaseGrab | 21:07 |
| cnd | removeGrab I mean | 21:07 |
| cnd | when I do a three touch drag, I see a pushGrab for both pinch and drag | 21:07 |
| cnd | but I only see removeGrab when the pinch finishes | 21:07 |
| cnd | I'm not sure yet if the drag gesture finish isn't being sent, or if there's some other issue | 21:08 |
| dandrader | cnd, and what does the missing removeGrab causes | 21:09 |
| dandrader | ? | 21:09 |
| cnd | dandrader, the compiz grab grabs the X pointer | 21:09 |
| cnd | so now the pointer is grabbed, which means only compiz sees any pointer motion | 21:09 |
| cnd | it looks like the code is ok though | 21:10 |
| cnd | so this could end up being a bug in the server after we unravel it all | 21:10 |
| dandrader | the gesture recognition parameters (timeout and threshold), should they be exposed via GeisSubscription or GeisGestureClass? | 21:13 |
| cnd | bregma ^^? | 21:14 |
| cnd | dandrader, found the bug in the GestureEngine | 21:15 |
| * dandrader listens | 21:15 | |
| cnd | so in EndDrag(), we check if the drag gesture id is valid | 21:17 |
| cnd | however, it merely checks if the id is non-zero | 21:17 |
| cnd | the first gesture has an id of 0, so this is clearly wrong | 21:17 |
| cnd | we don't really need to check _drag_id | 21:19 |
| cnd | checking _drag_window is enough | 21:19 |
| dandrader | its "empty" value should be -1 instead of 0 | 21:19 |
| cnd | dandrader, even then that isn't quite right | 21:20 |
| cnd | a gesture id is an unsigned value, and -1 is valid, IIRC | 21:20 |
| dandrader | ? | 21:20 |
| cnd | well, -1 means 0xffffffff | 21:21 |
| cnd | so it would be valid, after a really long time | 21:22 |
| dandrader | _drag_id in an int | 21:22 |
| dandrader | s/in/is | 21:22 |
| dandrader | although it should probably be an unsigned int, to match the geis definition. in which case -1 wouldn't be possible | 21:23 |
| cnd | then it's wrong | 21:23 |
| cnd | yeah | 21:23 |
| cnd | so there's no "invalid" gesture id | 21:23 |
| cnd | but that's ok :) | 21:24 |
| cnd | I have a patch! | 21:24 |
| dandrader | good | 21:24 |
| cnd | dandrader, http://paste.ubuntu.com/925516/ | 21:24 |
| cnd | _drag_window is maintained properly throughout the code | 21:25 |
| cnd | so checking it alone is good enough | 21:25 |
| cnd | dandrader, now for the bad news | 21:25 |
| cnd | your changes don't seem to have affected my ability to interact with objects even though some touches are outside their bounds | 21:26 |
| cnd | I'll see if I can figure it out | 21:26 |
| dandrader | cnd, but the corresponding unit test is passing! :) | 21:27 |
| cnd | heh | 21:27 |
| cnd | dandrader, so the device is NULL | 21:28 |
| dandrader | ah... that's it | 21:28 |
| cnd | and thus it falls over to going the indirect device route | 21:28 |
| dandrader | yes | 21:28 |
| dandrader | so geisv1 is not providing device info? | 21:29 |
| cnd | or the unity code isn't handling things right | 21:29 |
| cnd | in FindCompWindow, the frame->deviceid seems wrong | 21:30 |
| cnd | it's 0xe310, a rather high value for an incremented value, IIRC | 21:30 |
| cnd | it is getting the value from geis | 21:32 |
| cnd | oh, it is likely right | 21:37 |
| cnd | it's the lower 16 bits of the UFDevice value, which is a pointer | 21:37 |
| cnd | so the devices array in the gesture engine is empty | 21:40 |
| dandrader | cnd, geisv1 is not calling any of the callbacks provided via geis_input_funcs() | 21:40 |
| cnd | ok | 21:41 |
| dandrader | s/geis_input_funcs/geis_input_devices | 21:41 |
| cnd | bregma, geis bug! | 21:41 |
| dandrader | :) | 21:41 |
| * cnd builds a debug version of geis | 21:44 | |
| cnd | it looks like devices that existed at start up are not handled | 21:53 |
| cnd | when I add my magic trackpad, the callbacks work | 21:57 |
| bregma | that's odd | 21:59 |
| cnd | bregma, when I try geistest it doesn't print out all the connected devices like it used to | 21:59 |
| cnd | I made sure to use -w <window id> | 21:59 |
| cnd | however, it always errors out with error in geis_init... | 22:00 |
| cnd | I guess that's the real bug with geistest | 22:00 |
| bregma | hmm, I wonder what could possibly have changed | 22:00 |
| bregma | I will have to look at it later tonight, then | 22:02 |
| bregma | gotta run, back later.... | 22:03 |
| cnd | dandrader, do you have a good idea on how to test the DragEnd() fix? | 22:04 |
| cnd | so we can propose it | 22:05 |
| dandrader | cnd, of course | 22:05 |
| dandrader | cnd, test/test-gesture-engine has mocks for Compiz stuff | 22:06 |
| cnd | ok | 22:06 |
| cnd | I'm so glad that bug was a simple issue in compiz | 22:07 |
| dandrader | hopefully just a matter of doing count++ for each pushGrab call received and count-- for each removeGrab received and then checking if count ==0 in the end | 22:07 |
| cnd | I was shouting expletives at my computer | 22:07 |
| cnd | I'm very tired of the mess that is pointer emulation for touchscreens | 22:08 |
| cnd | dandrader, so I should add a grab counter in CompScreenMock? | 22:11 |
| dandrader | cnd, I don't see why not | 22:12 |
| cnd | ok | 22:12 |
| cnd | I'm trying to figure out how all this works :) | 22:13 |
| cnd | dandrader, does this look right? http://paste.ubuntu.com/925597/ | 22:13 |
| dandrader | maybe you would want to do the grab/remove counting per GrabHandle | 22:16 |
| cnd | hmm | 22:16 |
| dandrader | having a hash that maps a GrabHandle to its grab/remove count | 22:17 |
| dandrader | In my tests I couldn't reproduce the missing removeGrab. I wonder if using a touchscreen instead of a trackpad makes any different. | 22:20 |
| cnd | dandrader, there's only a list of grabs | 22:21 |
| cnd | it's not per grab handle | 22:21 |
| cnd | so a grab count should be correct | 22:21 |
| dandrader | even better | 22:21 |
| cnd | dandrader, check if your gesture id for your drag is 0? | 22:21 |
| cnd | that's the only way to trigger the bug | 22:21 |
| dandrader | ah, right. that's a tough one. the very first drag I do gets id 1 (probably the touch gesture got the id 0) | 22:27 |
| dandrader | but well, I'm done for the day | 22:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!