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 :). ------------------------------------------------------------------------------ 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
