That patch is a little hard to read unless you apply it first. I've
attached the meet of the function here to read comments:
static void wacom_bpt_touch(struct wacom_wac *wacom, void *wcombo,
int force_out)
{
char *data = wacom->data;
int pressure1 = 0, x1 = 0, y1 = 0, pressure2 = 0, x2 = 0, y2 = 0;
int prox1 = 0, prox2 = 0;
static int old_prox1 = 1, old_prox2 = 1;
if (!force_out)
{
prox1 = data[3] & 0x80;
if (prox1)
{
pressure1 = (data[2] & 0xff);
x1 = wacom_be16_to_cpu ((unsigned char *)&data[3]) & 0x7ff;
y1 = wacom_be16_to_cpu ((unsigned char *)&data[5]) & 0x7ff;
}
prox2 = data[12] & 0x80;
if (prox2)
{
pressure2 = (data[11] & 0xff);
x2 = wacom_be16_to_cpu ((unsigned char *)&data[12]) & 0x7ff;
y2 = wacom_be16_to_cpu ((unsigned char *)&data[14]) & 0x7ff;
}
}
wacom_report_abs(wcombo, ABS_MT_TOUCH_MAJOR, prox1 != 0);
wacom_report_abs(wcombo, ABS_MT_POSITION_X, x1);
wacom_report_abs(wcombo, ABS_MT_POSITION_Y, y1);
wacom_input_mt_sync(wcombo);
wacom_report_abs(wcombo, ABS_MT_TOUCH_MAJOR, prox2 != 0);
wacom_report_abs(wcombo, ABS_MT_POSITION_X, x2);
wacom_report_abs(wcombo, ABS_MT_POSITION_Y, y2);
wacom_input_mt_sync(wcombo);
/* Normally, we send both fingers data on any finger change.
* Since input layer thinks its the same finger, its
* filtering can cause problems.
*
* The follow are things to address. When it says
* complete event will not be sent, it means
* that ABS_X/ABS_Y/ABS_PRESSURE as well as
* BTN_TOOL_DOUBLETAP/BTN_TOOL_TRIPLETAP may not
* be sent. ABS_MISC is almost never sent except
* for first finger event.
*
* Loss of finger events is especially noticeable when going
* out-of-prox and especially for finger 2.
* Its common for enough unwanted filtering
* to occur that X will only receive 2 events per-SYNC
* and discard the message.
*
* 1. Finger 1 in prox & Finger 2 out prox - No filtering
* issues but application must filter out duplicate
* out-of-prox events since input layer can not.
* 1.1 Finger 1 in prox & Finger 2 out prox - If
* previous interrupt had Finger 2 values same as
* new finger 1 values then finger 1 complete event will not
* be sent.
* 2. Finger 1 in prox & Finger 2 in prox - Filtering
* will not allow sending complete event data for finger 2
* when both fingers have same values.
* 2.1 Finger 1 in prox & Finger 2 in prox - If
* previous interrupt had Finger 2 values same as
* new finger 1 values then finger 1 complete event will not
* be sent.
* 3. Finger 1 out prox & Finger 2 in prox - No filtering
* issues but application must filter out duplicate
* out-of-prox events since input layer can not.
* 4. Finger 1 out prox & Finger 2 out prox - Second
* finger data would never send ABS_* events.
* Since only two events will be sent, X would discard always.
* 4.1 Finger 1 out prox & Finger 2 out prox - If
* previous interrupt was case #3 then complete event
* for finger 1 will not be sent but at least X doesn't
* discard this one.
*
* Since going out-of-prox causes so much unwanted
* filtering, special logic exists to catch case
* #4 and #4.1 and prevent sending out-of-prox if we already
* sent it in the past.
*/
if (prox1 || old_prox1 != prox1)
{
wacom_report_abs(wcombo, ABS_PRESSURE, pressure1);
wacom_report_abs(wcombo, ABS_X, x1);
wacom_report_abs(wcombo, ABS_Y, y1);
wacom_report_abs(wcombo, ABS_MISC, TOUCH_DEVICE_ID);
wacom_report_key(wcombo, BTN_TOOL_DOUBLETAP, prox1);
wacom_report_key(wcombo, BTN_TOUCH, prox1);
wacom_input_event(wcombo, EV_MSC, MSC_SERIAL, 1);
wacom_input_sync(wcombo);
}
else
{
/* MT docs require always sending a sync */
wacom_report_abs(wcombo, ABS_MISC, TOUCH_DEVICE_ID);
wacom_input_event(wcombo, EV_MSC, MSC_SERIAL, 1);
wacom_input_sync(wcombo);
}
old_prox1 = prox1;
if (prox2 || old_prox2 != prox2)
{
/* Two finger scrolls tend to have fingers on
* same X or Y axis or same pressure. That
* will get filtered out. Notice the +3 has
* work around. Of course, this just leads
* to other cases were its filtered out
* but gives preference to two finger scrolls.
*/
wacom_report_abs(wcombo, ABS_PRESSURE, pressure2+3);
wacom_report_abs(wcombo, ABS_X, x2+3);
wacom_report_abs(wcombo, ABS_Y, y2+3);
wacom_report_abs(wcombo, ABS_MISC, TOUCH_DEVICE_ID);
wacom_report_key(wcombo, BTN_TOOL_TRIPLETAP, prox2);
wacom_input_event(wcombo, EV_MSC, MSC_SERIAL, 2);
wacom_input_sync(wcombo);
}
old_prox2 = prox2;
}
On Wed, Mar 17, 2010 at 10:49 PM, Chris Bagwell <[email protected]> wrote:
> Hi Ping,
>
> So let me talk with code... I've attached two patches. The first is
> what you can apply to 2.6.27 kernel right now and should work same as
> today... Well, it adds back some logic you removed related to
> attempting to not send back-to-back out-of-prox events to work around
> issues this input layer filtering is causing; and gives some
> background why its needed.
>
> Next patch is what you would apply if you copy&pasted 2.6.27 kernel
> over to a new 2.6.30 directory. This new kernel would work with any
> existing version of wacom X input drivers and will work with an
> MT-aware X input driver as well... Probably would work with an
> MT-aware evdev as well.
>
> If you accept the concept for Tablet PC, I'd like to do Bamboo
> different but its the only way I can test the concepts right now and
> so why they are aligned.
>
> So I think your maintenance issues are addressed by having same code
> base between two kernels with maybe 20 new LOC in 2.6.30 (nothing
> deleted/modified). I did this with #if's in the 2.6.27 so that you
> can do diff's between 2.6.27 and 2.6.30 and they should always align
> except for #if and #endif statements related to MT. You may prefer to
> totally delete the code in 2.6.27 kernel.
>
> I hope that large comment in the patch shows how using non-MT ABS_*
> for 2 fingers is a dead end solution for Tablet PC's since there are
> so many cases were data can be lost. If we want to work bug free in
> pre-2.6.30 kernels, we'd need to do something drastic like one of my
> earliest patches which effectively disable kernel filtering... but I
> suspect this approach would never make it into linus' tree in which
> case all those non-MT ABS_* this patch set is sending in 2.6.30 are
> not of much value to applications since they are buggy values. I
> think a better alternative is to simply disable 2 finger support (only
> support 1st finger) in all kernels and even stop sending the non-MT
> ABS_* finger 2 data in 2.6.30 kernels.
>
> If we disable it, then we could start using the DOUBLETAP/TRIPLETAP
> like they are intended to be used and then these applications using
> pre-2.6.30 kernels can still detect 2 and 3 finger swipes... Just not
> exact locations... i.e. align with synaptics.
>
> Chris
>
> On Wed, Mar 17, 2010 at 3:43 PM, Ping Cheng <[email protected]> wrote:
>> Hi Chris,
>>
>> You made a valid argument for Bamboo touch. And I am willing to
>> compromise. I'll show my part of the picture before discussing what
>> to do next.
>>
>> (sorry Chris. I want to make sure Peter read this line in case he is
>> too busy to read the rest of the message) Peter, should
>> xf86-input-wacom support kernels older than 2.6.30? I would think it
>> should.
>>
>> Now back to you Chris. For tablet PC, I have to support kernels
>> between 2.6.24 to 2.6.29, which do not have _MT_ support. When I said
>> "backward compatible", I pretty much meant TPC. You don't need/want to
>> worry about TPC too much, I guess. So, let's keep TPC out of this
>> discussion.
>>
>> Since there is nothing in kernel.org for Bamboo touch yet, patches to
>> Linus for Bamboo touch could just support _MT_ events. The question is
>> "do we still want to support Bamboo touch for kernels older than
>> 2.6.30"? I think most users would say yes.
>>
>> Let's take care of the majority - the "yes" side. That means we need
>> an xxxTAP and _MT_ compatible wcmUSB.c for wacom_drv.so (I am talking
>> about both linuxwacom and xf86-input-wacom since they are all our
>> "kids" :).
>>
>> I know you would say "I've already had a patch for wcmUSB.c to support
>> both sets of events. Why cannot we just use it?" Here comes my
>> reason, in fact reasons, since I have two points to make :).
>>
>> 1. keeping xxxTAP and _MT_ support in separate routines would be
>> easier for those developers who don't have a TPC or don't care about
>> xxxTAP events to join us. They have less chance to break those code. I
>> am sure you agree with me that without testing a driver on the real
>> hardware, it is hard to see if we break the code or not, no matter how
>> reasonable our logic looks like. My thought is to check/retrieve event
>> key, as we did for TOOL_PEN etc, for _MT_ event from the device. If
>> _MT_ is defined, instead of calling usbParseEvent, we call
>> usbMTParseEvent (or something you like). So, _MT_ events will be
>> parsed separately from the beginning and xxxTAP events will be
>> ignored. Let me know if this is reasonable to you or not. If yes,
>> please give me a new patch. If not, I am all ears.
>>
>> 2. Keeping xxxTAP and _MT_ code separate is easier to maintain. I
>> know this sounds a bit of selfish. But, I am not the only maintainer,
>> am I :)?
>>
>> I have a few other comments inline. Please take a look.
>>
>> Ping
>>
>> On Wed, Mar 17, 2010 at 11:24 AM, Chris Bagwell <[email protected]> wrote:
>>> Late reply from myself as well. My main laptop died last week and
>>> I've been offline more then normal as I recover from that. Replies
>>> below.
>>>
>>> On Tue, Mar 16, 2010 at 12:40 AM, Ping Cheng <[email protected]> wrote:
>>>> Hi Chris,
>>>>
>>>> Sorry for my late reply. I was investigating a "decent" solution for MT
>>>> support. As you know backward compatibility is the major concern here.
>>>
>>> Is backwards compatibility really a concern in this case? It looks
>>> like tablet PC support got added around Oct. 2009 and only in
>>> developer releases of linuxwacom. It looks like tablet PC got merged
>>> to linux's tree around November 2009 so probably its in 2.6.33 which
>>> is a concern for compatibility reasons.
>>>
>>> But that original logic that made it into official kernel was
>>> fundamentally broken since it did not consider input filtering. I
>>> know exceptions are given to fix broken features... especially when a
>>> kernel blessed solution (multi-touch input) exists to fix the
>>> fundamental problem.
>>
>> It was all for the sake of TPC and for the support of older kernels.
>> Hope you are on the same page with me after reading my reply above.
>>
>>> Since Bamboo Pen&Touch support hasn't made it in any non-developer
>>> release yet, I'm assuming we have total freedom with it.
>>
>> You have freedom. But I don't since I have to support older kernels :).
>>
>>>> Replacing xxxTAP with _MT_ events at this stage requires both kernel and X
>>>> driver changes. Plus there are third party developers relying on us. Since
>>>> there are only two fingers, I think staying with xxxTAP is not too far off
>>>> the topic. To make events definition consistent for all tablet models, all
>>>> 2FGT touch devices will use xxxTAP. Future multi-touch devices will use
>>>> _MT_ event. wcmUSB.c will be redesigned to process those MT events in a
>>>> separate routine(s).
>>>
>>> I don't think third party apps are much a concern here because: 1) the
>>> old interface is broken and will show up in their app. Change to MT is
>>> proposing the solution to bugs they will see. 2) I don't think you
>>> were proposing implementing any real fixes to filtering issue for the
>>> xxxTAP events so apps that are forced to use xxTAP solution will
>>> always have use cases that have lost or invalid touch event data.
>>> Thats a dead end of app developers.
>>
>> I didn't make the call. The older kernels limited my options....
>>
>>> I had hopes that we would not have a wacom specific solution for these
>>> non-pen /dev/input/event's since users will expect them to have
>>> standard touchscreen/touchpad behavior. Ideally, we should stay as
>>> close to xf86-input-evdev's generic device expectations as possible
>>> for both tablet PC's and Bamboo P&T's.
>>
>> I like your word :). "Ideally", we don't need to do much in our
>> driver. Hopefully, we'll get there soon :).
>>
>>> There is not a lot of need to handle touch input events using
>>> xf86-input-wacom beyond the xxxTAP now-non-standard solution to
>>> exposing 2 finger data to input driver. I suspect it will be
>>> xf86-input-evdev that will have multi-touch support first (I mean
>>> exposing fingers to applications... not just the MPX stuff). We'd be
>>> wise to work with them for greatest-and-fastest user benefits.
>>
>> xf86-input-wacom may not need to worry about kernels older than 2.6 30
>> (this is a call for Peter). But linuxwacom has to take care of those
>> older kernels. That is part of what I am paid for.
>>
>>> I recently sent a patch that could be made to support both MT and
>>> xxxTAP solution in kernel driver at same time. It works because MT
>>> input people considered backwards compatibility. Old apps will ignore
>>> MT events and just process old-but-broken ABS_X/Y/PRESSURE events.
>>> New MT-aware apps will disable ABS-X/Y/PRESSURE processing and only
>>> look at MT events. So you get best of both words, so to speak, except
>>> for need to send wasted events.
>>
>> Do you mean the patch you send to us (linuxwacom-devel) or to LKML or
>> somewhere else? I don't want to make a mistake here.
>>
>>> Even this is a little ugly because its using DOUBLETAP and TRIPLETAP
>>> in ways that I'm sure no generic application (xf86-input-evdev) would
>>> expect... but at least when evdev becomes MT-aware it has a chance of
>>> working with them.
>>
>> Yeah, I agree with you. But, we need a solution before X server (or
>> even kernel) catches up.
>>
>>> Anyways, my opinion is we should switch everything to MT... but your
>>> making the calls. :-)
>>
>> I know it is my call - it is my call for comments, suggestions, and
>> contributions :).
>>
>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Linuxwacom-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
