[07:41] <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.
[14:15] <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:16] <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:17] <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:18] <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:19] <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:20] <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:21] <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:22] <cnd> yeah
[14:22] <bregma> as far as uTouch is concenrned, no server and no XI2.2 are pretty much the same thing
[17:37] <cnd> so many bugs I'm encountering when using a touchscreen...
[17:46] <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:47] <cnd> cool
[17:48] <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:49] <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:50] <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:51] <cnd> like a compatibility layer
[17:52] <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:53] <cnd> hmm
[17:54] <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:55] <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:56] <cnd> yeah
[17:56] <tvoss> awesome
[17:58] <cnd> the idea really is that we are creating a public api for the frame backend, which is currently private
[17:59] <tvoss> indeed, encouraging people to "port" frame in terms of custom backends
[18:06] <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:45] <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:46] <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:49] <dandrader> cnd, is the "flick" gesture type working or is it deprecated?
[18:50] <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?
[19:02] <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:03] <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:04] <dandrader> ok. so the fix for that in unity will carry along with it the port for geisv2 api :)
[19:07] <bregma> I don;t think flick has been tested in a very long time
[19:08] <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:18] <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:19] <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:20] <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:21] <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:22] <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:23] <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:27] <cnd> argh, nux changes again
[19:28] <cnd> wait a minute...
[19:29] <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:30] <cnd> dandrader, do you have /usr/include/Nux?
[19:31] <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:32] <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:33] <dandrader> did it find nux at all?
[19:36] <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:37] <cnd> but apparently rerunning cmake doesn't produce the same result as a clean cmake run
[19:38] <dandrader> yeah, cmake seems to do a lot of caching
[19:39]  * 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:40] <cnd> yay
[19:41] <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:42] <cnd> bregma, sounds like an out of date aclocal macro
[19:42] <cnd> the gtest prefix isn't being set properly
[19:43] <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:44] <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:50] <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:52] <dandrader> ok
[20:57] <cnd> I'm getting really annoyed with pointer emulation bugs
[20:58] <cnd> however, this new bug looks to be a compiz bug
[21:03] <bregma> yay, play pass the bug
[21:06] <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:07] <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:08] <cnd> I'm not sure yet if the drag gesture finish isn't being sent, or if there's some other issue
[21:09] <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:10] <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:13] <dandrader> the gesture recognition parameters (timeout and threshold), should they be exposed via GeisSubscription or GeisGestureClass?
[21:14] <cnd> bregma ^^?
[21:15] <cnd> dandrader, found the bug in the GestureEngine
[21:15]  * dandrader listens
[21:17] <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:19] <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:20] <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:21] <cnd> well, -1 means 0xffffffff
[21:22] <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:23] <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:24] <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:25] <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:26] <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:27] <dandrader> cnd, but the corresponding unit test is passing! :)
[21:27] <cnd> heh
[21:28] <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:29] <dandrader> so geisv1 is not providing device info?
[21:29] <cnd> or the unity code isn't handling things right
[21:30] <cnd> in FindCompWindow, the frame->deviceid seems wrong
[21:30] <cnd> it's 0xe310, a rather high value for an incremented value, IIRC
[21:32] <cnd> it is getting the value from geis
[21:37] <cnd> oh, it is likely right
[21:37] <cnd> it's the lower 16 bits of the UFDevice value, which is a pointer
[21:40] <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:41] <cnd> ok
[21:41] <dandrader> s/geis_input_funcs/geis_input_devices
[21:41] <cnd> bregma, geis bug!
[21:41] <dandrader> :)
[21:44]  * cnd builds a debug version of geis
[21:53] <cnd> it looks like devices that existed at start up are not handled
[21:57] <cnd> when I add my magic trackpad, the callbacks work
[21:59] <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>
[22:00] <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:02] <bregma> I will have to look at it later tonight, then
[22:03] <bregma> gotta run, back later....
[22:04] <cnd> dandrader, do you have a good idea on how to test the DragEnd() fix?
[22:05] <cnd> so we can propose it
[22:05] <dandrader> cnd, of course
[22:06] <dandrader> cnd, test/test-gesture-engine has mocks for Compiz stuff
[22:06] <cnd> ok
[22:07] <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:08] <cnd> I'm very tired of the mess that is pointer emulation for touchscreens
[22:11] <cnd> dandrader, so I should add a grab counter in CompScreenMock?
[22:12] <dandrader> cnd, I don't see why not
[22:12] <cnd> ok
[22:13] <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:16] <dandrader> maybe you would want to do the grab/remove counting per GrabHandle
[22:16] <cnd> hmm
[22:17] <dandrader> having a hash that maps a GrabHandle to its grab/remove count
[22:20] <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:21] <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:27] <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