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 <pingli...@gmail.com> 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 <ch...@cnpbagwell.com> 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 <pingli...@gmail.com> 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 :). >
0001-Refactor-multi-touch-event-logic.patch
Description: Binary data
0002-Enable-multi-touch-support-for-2.6.30-kernels.patch
Description: Binary data
------------------------------------------------------------------------------ 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 Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
