On Fri, Dec 10, 2010 at 5:47 AM, Chris Bagwell <chris@xxxxxxxxxxxxxx> wrote: > On Fri, Dec 10, 2010 at 1:38 AM, Dmitry Torokhov > <dmitry.torokhov@xxxxxxxxx> wrote: >> On Thu, Dec 09, 2010 at 03:21:34PM -0600, Chris Bagwell wrote: >>> >>> For first point, your right that (123,78) is just a good "known >>> starting value" if a driver is going to use that concept because it >>> could be filtered just as easy as (0,0). >> >> I am afraid I did not explain myself well enough. (0,0) is valid >> coordinate, same as (123, 78). Thus, even if we try to make driver send >> (0,0, !touch), input core may suppress it and never deliver to >> userspace if last touching point happened to be also (0,0). Thus >> userspace should not rely on having coordinates reset I think. >> > > I had understood ya. What I meant is if a driver sends (0,0,!touch) > and a sync when switching tools then you do not need to buffer > previous values but instead can imply what previous values are. > Userland would still need to account for case of filtered events. Its > a memset() vs. a memcpy() when switching tools. Oh, I see your point. I think we need to add a sync statement to mark the end of the touch events. This is consistent with the existing behavior. Thank you for reviewing the patchset. Ping > Anyways, I'm not recommending any behavior; just letting you know > some existing assumptions on driver behavior. > > Thanks, > Chris > -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
