On Wed, Feb 10, 2010 at 7:23 AM, Chris Bagwell <[email protected]> wrote: > On Wed, Feb 10, 2010 at 12:33 AM, Ping Cheng <[email protected]> wrote: >> On Tue, Feb 9, 2010 at 8:05 PM, Chris Bagwell <[email protected]> wrote: >>> Can someone double check following logic issue? There happens to be >>> two places in log files below were first fingers Y values are same as >>> second fingers Y values on kernel side. In those cases, it looks like >>> this same value is not sent to X driver. >>> >>> While fingers were in proximity, it meant channel 1 kept its older Y >>> value. When first coming in to proximity, it meant Y was at a zero >>> value (from a memset() it seems) and some events got discarded because >>> less then 3 events were received. >> >> If everything works properly (all data are different), channel 0 would >> keep finger one data, channel 1 would keep finger 2 data, and channel >> 2 would kees pad data, if the tablet has a pad. If there are >> duplicated data, only the first one will be received by X driver as we >> discussed before. >> >> In the case you described above, I think we need to copy the first >> finger data to channel 1 (i.e., duplicate channel 1 with channel 0's >> data) to avoid zeros. Please test this solution to see how it works. > > If I go this route then it can't tell difference between case when > channels X/Y values were meant to be the same and case when it just > hasn't changed from previous value; resulting in unwanted jumps in the > mismatch case. I think this code could be tricky to do on X side and > unable to get 100% right.
I see your point. We can not tell if the second set would be the same or not before we got it. So, this is not a good workaround. > If there are enough bits in these overlapping values, how about we > encode the channel # in the values to force them always unique? X can > mask those out blindly and be somewhat backwards compatible with older > kernels. There probably aren't enough bits for that though. I don't like this solution since it affects other tablet. A local/specific solution like the one below would be more efficient and easy to maintain. > If not that then maybe this. At least for duplicate fingers and their > X/Y/pressure values, the second finger doesn't need to be so accurate > I think so I could +/- 1 to values in kernel when I detect duplicates. Let's go with this one. Please add comments to the code where you +/- 1. Let's use idx to make it universal for both fingers. What do you think? Please test this solution and share your result with us. If this solution works, I will remove the filter that I added to the X driver before I post -10. With all this changes in progress, -10 release would most likely have to be postponed. Ping ------------------------------------------------------------------------------ SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
