[01:54] cnd: yes, that would be the simple and I believe correct solution (aclocal --install --force will overwrite with a fresh copy if it's available) [08:49] With dandrader's Unity and newest Grail everything works except three finger spread. [08:49] It's a bit laggy and the movement is overly sensitive. [08:50] The first one is an issue of Unity and/or GL drivers. [08:53] Four finger taps don't work in Unity 2D, but did they ever? === MacSlow is now known as MacSlow|lunch [11:28] Whoah, on my laptop three finger drag is crazy accelerated. [11:28] Ahah, because it sums up the movements of all fingers. [11:29] This may be related to why three finger spread does not work. === MacSlow|lunch is now known as MacSlow === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [14:15] Satoris, bregma, dandrader: standups! (tvoss is unavailable) [14:15] continuing the review of https://code.launchpad.net/~chasedouglas/utouch-grail/touch-states/+merge/99410 [14:15] Testing new Grail & stuff under various circumstances. [14:15] one bug left: working on #944822 (post-hoc device additions to subscriptions) [14:15] Results in the backlog. [14:15] I'm going to be trying to find a bug in the current grail code :), and doing my own performance review [14:16] cnd has O(n^2) performance [14:16] Satoris, thanks for the testing [14:16] Np. The spread thing is the biggest issue ATM. [14:17] Satoris, yeah, spread needs fixing [14:17] I can't get it to fire either [14:17] but it's obviously a good sign that grail doesn't have any bugs it seems [14:18] if we can't find a bug we'll have to make a decision on whether to include the touch states changes in precise [14:18] Why are the gesture names missing in https://bugs.launchpad.net/utouch-geis/+bug/853958 [14:19] Satoris, I've not looked at the code myself yet... [14:19] an attribute of "gesture name" makes no sense in GEISv2 [14:20] GEISv1 chooses one at random, it still mkes no sense but stop people from complaining [14:21] if you need to find out of a gesture belongs to a specific class, you need to call geis_frame_is_class() [14:22] There are still a couple of "failed to get previous touch value"s. [14:23] Satoris, yeah, I'm going to look at that today as well [14:23] it's a bug wholly in utouch-frame (or X) [14:23] utouch-frame-test-x11 shows the issue too [14:23] but only for my magic trackpad [14:23] it doesn't on behemoth's touchscreen [14:24] Failed to get previous value makes perfect sense for a tap, though. It is instantaneous, after all. [14:24] Though in practice it probably isn't. [14:29] cnd: preferably Skype today, is that ok? [14:29] Satoris, sure [14:29] Excellent, see you then. [14:33] cnd, are you going to implement that daily build fix for frame and grail or shall I (I probably have more bandwidth for it) [14:34] bregma, I planned on it, but if you have some spare moments feel free [14:34] I probably won't get to it for another couple hours [14:34] K [15:01] tvoss, good presentation :) [15:01] cnd, thanks :) my fingers are bleeding :) [15:01] heh [15:02] cnd, not literally :) [15:02] biab === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [15:34] tvoss, any ideas why jenkins tests are failing when the device is a trackpad? [15:34] tvoss, would it be possible to save the /tmp/Xorg.gtest.log file as part of the jenkins build output? [15:34] then we'd have a better idea why some tests may fail [15:34] cnd, otp [15:35] ok [15:38] dandrader, is AtomicRecognizer::ProcessTouches instead of CollectNewTouches good for you? [15:38] cnd, shouldn't be much of a problem, let me check [15:39] cnd, yes [15:40] cnd, quite interesting that all tests pass for amd64 [15:40] tvoss, oh... [15:40] I've been running i386 tests [15:40] it would be really handy to get the log file [15:40] yeah, grail is green for amd64 [15:41] cnd, checking for the logfile [15:41] it could just be a difference in which packages are installed? [15:42] cnd, hmmm, no, both vm's are configured equal [15:46] cnd, script altered, build triggered [15:46] great === dandrader is now known as dandrader|lunch [16:37] bregma, I just reviewed your frame daily builder fix [17:33] bregma, tvoss, dandrader|lunch, so the touch accounting does not seem to fix any functional bugs [17:33] I think it may fix some unbounded memory growth, but we don't have good tests for checking that yet [17:34] it's a pretty big change, so I'd like some feedback on whether we should push it into precise at this stage [17:34] pros: more maintainable touch state accounting [17:34] may fix memory growth issues [17:35] it's definitely a big change, if it does not fix anything I would be hesitant for precise [17:35] cons: big change late in the cycle affecting larg area of code [17:35] we can always branch utouch-grail at this point and apply it to trunk [17:36] I also tend to think that we may be able to resolve unbounded memory growth with a few ERASE_TOUCH fixes in the current code [17:36] so if it is an issue the resolution may not be too difficult [17:37] it should definitely go in eventually, but let's hear what the other guys say about precise... no rush until beta freeze is off, right? [17:37] bregma, correct [18:59] * cnd finished his self-evaluation \o/ === dandrader|lunch is now known as dandrader [19:05] It's a big change but on the other hand it's a rather simple one. [19:07] dandrader, you have an interesting definition of simple :) [19:07] I gather you mean conceptually it's simple [19:07] simple meaning that it's mostly a refactoring mapping one-to-one the existing functionality [19:08] no new features [19:08] yeah [19:09] I'm torn because it's not really a necessary bug fix, but I believe it makes the code easier to read, understand, and maintain [19:09] I don't really want to get a week or a month into the 12.04 release and realize that we really do need it [19:10] and we have many tests that ensure things are still working properly and no memory is being leaked [19:12] * cnd -> lunch, biab [19:13] dandrader, I just realized we have a meeting in 17 minutes [19:13] would you like to have it now? [19:23] ah, that's true [19:23] sure [19:23] mumble? [19:24] cnd, ^ [19:24] dandrader, sounds good [20:34] dandrader, any luck with synaptics? [20:34] it's up and running now [20:35] is unity working any better? [20:35] gimme a few minutes [20:35] k [20:39] forgot that I have to get it from that ppa [20:44] dandrader, I know why the pinch to maximize/unmaximize is broken [20:44] there's a behavior change [20:44] I'll make a patch and test it out [20:45] great. patch for utouch-grail? [20:45] bregma, if you have an opinion on commits for white space fixes, please reply soon [20:45] dandrader, no, unity [20:45] the behavior change is intended [20:45] the pinch radius used to be given in device units [20:46] but that's really not very useful [20:46] the device units vary greatly among devices, and resolutions reported by devices may be non-existent or incorrect [20:46] so now we report the pinch radius as a ratio of the current radius to the gesture start radius [20:48] cnd, would be great to have it documented in geis.h :) [20:48] this behavior change is pretty big, but I think it's necessary [20:48] well, it's not a function of geis [20:48] it's a function of the backend [20:48] we could document it in the geis header, what is expected depending on the backend [20:48] but does the geis client has any knowledge on the backend used? [20:49] I'm guessing it can query it [20:49] bregma? [20:50] it's kinda odd the a geis client has to if{}else{} his code according to the backend used... [20:50] s/the a/that a [20:51] yeah [20:51] it's not the best solution [20:51] we could make the geis layer report the attrs in device units again [20:51] but it would be a step backwards... [20:52] couldn't it always be "as a ratio of the current radius to the gesture start radius"? [20:52] dandrader, what do you mean? [20:53] cnd, I already commented on the whitespace issue [20:53] I mean having the geis layer always reporting the attributes in those more useful units [20:53] bregma, ok, just checking if there's anything more you wanted to add [20:54] dandrader, that's essentially what it does now [20:54] it only reports the ratio [20:54] in the past it reported device coordinate units [20:55] and why can't we make that behavior backend-independent? [20:55] so that we can document it and users rely on it [20:55] * dandrader is confused [20:55] we currently only have one real back end [20:55] dandrader, well, making it backend independent would mean making the old, obsolete, no longer available xcb backend use the ratio too [20:55] there's really no use for updating the xcb backend [20:56] (the dbus back end should be invisble) [20:56] if it's documented, though, any future back end will need to reproduce the behaviour somehow [20:56] (think: Windows, iOS) [20:56] dandrader, the xcb backend was only ever available in ubuntu, as far as distros go [20:57] so it's really really dead now [20:57] bregma, good point [20:57] bregma, and isn't that a good thing? or could that be impossible? [20:57] I'm thinking one big task that must be completed first in the Q cycle is full API documentation, behavior documentation, and architecture documentation [21:02] dandrader, I think bregma is just saying that going forward we need to document it and stick to it [21:02] now that we really may attempt to work cross-platform, cross-distro, etc. [21:03] we picked the wrong units the first time and we learned, and now we need to standardize going forward [21:14] dandrader, if I give you a small patch to make pinch work, would you mind applying it to your tree again? [21:14] http://paste.ubuntu.com/902870/ [21:15] np [21:15] sorry, my wife just came home and told me about her day (priorities)... yes, I mean we need to document it and stick to it, we needed better documentation for M, let alone Q [21:16] :) [21:16] heh [21:17] bregma, luckily, Maverick is out of support on april 10th [21:18] I guess I can close that outstanding geis bug then [21:18] cnd, try that: 1- slide 3 fingers on the touchpad like crazy to that you start dragging a window 2- about ~ 1 sec later let a 4th finger on the trackpad [21:18] s/to that/so that [21:19] what I get is the dash showing up == a 4-touches tap gesture came up [21:20] dandrader, so I'm moving a window with 3 touches [21:20] and then I put a 4th down? [21:20] and continue moving? [21:21] no. put a 4th down a lift it [21:21] while the other 3 remain down [21:21] dandrader, so essentially do a tap with a 4th finger? [21:22] cnd, yes! :) [21:22] ok, so it shows the dash when I do that [21:22] :) [21:22] so we got ourselves a new bug! [21:22] which is expected behavior with how we have architected the stack [21:23] the question is: did we architect it wrong [21:23] or do we need to fix unity [21:23] or even: is it really a bug? [21:24] this is actually behavior that tracks way back while we were developing the very first version for maverick [21:24] it was behavior requested by sabdfl himself :) [21:25] not saying that means we shouldn't change it [21:25] implicitly leaving the subject of a sentence off doesn't work as well over irc... [21:26] I'm not saying that means we shouldn't change it [21:26] I put 3 fingers down, move them around like crazy, then I tap with a fourth finger, while the first 3 stay put <= that can't be a 4-touches tap! [21:26] I designed the new utouch architecture to mimic the old architecture unless I thought it was obviously wrong, like the pinch units [21:27] I can't say that I can think of a reason we should make this act like a 4 touch tap [21:27] and when we switch to geis v2 and the regular recognizer it will be more obvious what is going on [21:28] though that will require matching up touch ids [21:28] which we could do here just as easily [21:28] dandrader, to sum up my thoughts: we should keep track of the touches of a gesture [21:28] if a tap includes touches of a previous gesture, we should not honor it [21:29] one problem in my example is that 3 out of the 4 fingers that comprise that 4-touches tap have moved way beyond the movement threshold for a tap [21:30] dandrader, yes, but then you left them stationary during the "tap" [21:30] and they also have been down for way too much time to configure a tap [21:31] the timeout is calculated from when the gesture starts [21:31] which is when the fourth touch goes down [21:34] for a tap gesture, timeout should be from the start time of its oldest touch [21:35] dandrader should stop leaving :) [21:37] dandrader, you should stop leaving in the middle of a conversation :) [21:38] dandrader, the problem with your approach is that it doesn't allow the flexibility of someone who *does* feel that it should be a four touch tap to receive the gesture [21:39] I don't like the idea of taking away a potential use case for everyone when the alternative is to tell some people to just filter out gestures they don't want [21:40] my x-chat lost its window decoration. had to restart it [21:41] that sounds like it hurts :) [21:41] restarting compiz has its problems :) [21:41] heh [21:41] compiz bug, I believe [21:41] the thing is: what's the definition of a tap/ [21:41] for me it's when you quickly lay down an lift a finger [21:42] to a 4-touches tap would be when you quickly lay down and lift *4* fingers [21:42] not just one [21:43] s/to a 4/so a 4 [21:43] yes, but that's not the only possible definition [21:44] a tap could be defined as when going to a specific number of touches and then leaving that number of touches within a specified interval [21:44] the initial and end states are undefined and can be anything [21:46] In the use case I described earlier. I think if there would be a tap gesture there it would be a 1-touch tap (containing only the 4th finger). [21:47] that would come and go while the 3-touches drag is still going on [21:47] that in a non-atomic recognizer [21:47] then you've got multiple simultaneous gestures on a trackpad [21:48] though that would be one appropriate response for a touchscreen [21:48] dandrader, I guess my thinking is that this is a policy question [21:48] "what is the definition of a multi-touch tap" [21:48] and we can try to define the policy in the utouch stack [21:48] or we can give all the info to the client and ask them to enforce whatever policy they want [21:51] I didn't really get what you meant by policy there, but that sounded like you want the client to do at least part of the work of gesture recognition... [21:51] yes and no [21:51] for me, a robust gesture system provides the client with gestures [21:52] or should we have two kinds of tap gestures? [21:52] and the client decides which ones apply for the given context [21:53] according to my definition of a tap. what should a client have to do to get it? [21:53] if they just listen to N-touch taps, then they don't have to do anything [21:54] if they are more complex, and listen to M-touch gestures and N-touch taps, where N > M [21:54] then they should check if the N-touch tap gesture is comprised only of touches who begin as part of the gesture [21:55] unfortunately, geis v1 doesn't expose all the grail slices of a gesture, so that approach won't work here [21:55] but we can find a work around as a stop-gap measure [21:56] GEISv1 exposed all the touches of each gesture [21:56] bregma, yes, but not all the "slices" [21:56] to give an example [21:56] you have a two touch tap [21:56] hmm... If the geisv2 version of Unity doens't have this issue then here's our ticket to get the geisv2 refactoring on board :D [21:56] in geis v1 and geis v2 without tentative events, you will receive only one geis event [21:57] dandrader, heh, we can more easily work around the issue in geis v1 than by moving to geis v2 [21:57] dandrader, I'm inclined in general to write this one specific bug off as won't fix, anyways :) [21:57] i.e. unsupported [21:58] if the work to make it function 100% correctly would be large [22:05] bregma, dandrader: if you're still around, I'm leaning toward merging the touch accounting branch [22:05] I think dandrader is in agreement [22:06] bregma, do you have a strong objection? [22:06] I'm still open to change my thoughts if you feel strongly [22:29] the more I think about it, the more strongly I feel that now would be the best time to merge it [22:30] interesting :) [22:32] I think it's a slightly better architecture and if we have to maintain the code over the lifetime of the LTS release, it should go in now [22:33] my only reservation is that it is not a trivial change and does not fix any bugs, so technically it does not quality for going in to precise at this point in the release cycle [22:34] agred [22:34] agreed* [22:34] I think the pros outweigh the cons [22:37] me too [22:41] there's a very well defined period of silence in grail right after I start a 3 or 4 touches gesture. but that doesn't happen with 2 touches. any ideas? (I would like to blame synaptics, as usual) [22:41] dandrader, you normally won't receive two touch gestures... [22:41] I have no problem bending the release rules a little if you're confident the change does no harm and dandrader is favourably inclined [22:41] cnd, that's what output looks like http://paste.ubuntu.com/902989/ [22:43] dandrader, what gesture were you performing? [22:44] cnd, any 3 or 4 fingers movement [22:44] dandrader, if you cross the drag threshold before the 300 ms timeout, it should immediately start sending events [22:44] and for the two touch gestures, I just followed your instructions on how to remove interference from x stuff via synclient and xinput set-prop [22:44] if you just lay your fingers there for 300 ms, it will wait [22:45] ahh, ok [22:45] I don't know what the difference would be [22:47] that silence period is what causes the jumps in my gestures [22:47] hmm [22:47] like the launcher jumping to its final position on a 4-touches drad [22:47] drag [22:47] I don't get it here [22:49] dandrader, you're running synaptics now? [22:49] yes [22:49] cool [22:49] dandrader, so when the gesture crosses the threshold for the subscription, it should flush the slices [22:49] so that's where I would start debugging [22:49] to see why slices aren't being flushed [22:50] dandrader, I have a hard time believing you should still be working today, though :) [22:50] addict [22:51] I had a looong lunch break today. had to go to the bank, fetch my repaired bike from the shop, etc [22:51] * cnd fears we are all pots calling the kettle black :) [22:52] dandrader, I wouldn't worry too much if it's a one-time issue, btw [22:52] if you average 40 hrs a week, with a couple hours of variation, you're fine :) [22:54] besides, you need to put in the after-hours work on all your hobby projects [22:55] heh