Hi Chris, Thank you for the two patches. I agree that Bamboo touch doesn't have to follow TPC code since it doesn't have one finger model. I have no problem for you to merge the in and out routines together.
I will apply your changes into the next release. For kernels older than 2.6.30, I can not go with the synaptics-way since there are features that I have to support, at least for TPC. Other than that, I am open for suggestions. In fact, it is the wcmUSB.c code that I'd like to see a patch from you. Basically, I'd like to see the _MT_ events cover the existing xxxTAP features in wacom_drv.so as close as possible. Ping On Wed, Mar 17, 2010 at 8: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
