On Thu, Feb 3, 2011 at 2:09 PM, Chris Bagwell <ch...@cnpbagwell.com> wrote: > >> What limitation or benefit do we offer to application by not sending >> or sending DOUBLETAP? I think I fundamentally missed this part. > > Benefit of acting like touchscreen: Works with xf86-input-evdev and > any pre-existing touchscreen apps.
We agreed on this already. > Benefit of sending DOUBLETAP: Since aligns with touchscreen events, > works with all pre-existing touchscreen apps that understand 2-finger > gestures via DOUBLETAP. So, you mean without the actual (x,y) or even a bounding box, the apps can post gesture events via DOUBLETAP? That would limit the differentiation between 1FGT and 2FGT, I think. If you see applications using DOUBLETAP now, We'll add it. > Benefit of NOT sending DOUBLETAP: Nuetral for us. It neither helps > nor hurts xf86-input-wacom. It is negative/limitation for input > drivers that could have made use of DOUBLETAP though. No, it is not a problem for xf86-input-wacom. It is how we support other xf86-input drivers and the apps that want to talk to the kernel driver directly. As I said above, I have no problem to post DOUBLETAP if there are apps using it. Please share a few examples here. >>> I *think* I mentioned that I think wacom_w8001.c's current behaviour >>> is wrong and we should not follow it for TPC. Its trying to separate >>> events into two classes; similar to Protocol 4/5's stylus vs. mouse vs >>> pad classes. It uses ABS_X/ABS_Y for stylus and ABS_MT_ for touch. >> >> Yes, you mentioned that and I read it again ;). wacom_w8001.c reports >> ABS_X/ABS_Y for touch. It has to since it supports single touch >> devices. > > Can you point me at repo/branch that has latest acceppted wacom_w8001 > patches? I looked at a few places and could only find the pre-1FGT > version. It's in Linus' tree: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=drivers/input/touchscreen/wacom_w8001.c;hb=HEAD. I'll get to your other comments after you surf the code. Basically, I didn't post DOUBLETAP since I didn't see an use to it except in xf86-input-synaptics, which is not for touchscreen. It is good that I understand why you wanted DOUBLETAP. Hope you know why I didn't want to - I didn't want to post an event that no one needs it. Thank you, Ping >>> I think this approach is fundamentally wrong. It should be reporting >>> both stylus and touch (cursor emulation for touch) over ABS_X/ABS_Y >>> and then multi-touch events duplicated into ABS_MT*. >> >> It reports ABS_X/ABS_Y for 1FGT (has to) and 2FGT (for legacy client >> support) devcices. We discussed that a few rounds at linux-input. I >> thought you were happy with the decision. > > OK, thats great. I just haven't seen the final commit yet so thought > there were still at no ABS_X/ABS_Y for 2FGT. > >> >>> Until its at that point, I agree it makes no sense for it to report >>> BTN_TOOL_FINGER or BTN_TOOL_DOUBLETAP for wacom_w8001. I also realize >>> that the way I think wacom_w8001 kernel *should* behave would be >>> harder for xf86-input-wacom to work with; but only slightly. >> >> For wacom_w8001.c, BTN_TOOL_FINGER is needed to support ST. >> wacom_w8001.c supports 4 types of devices: pen-only, 1FGT and pen, >> 2FGT and pen, and 2FGT-only. Since pen and touch are on the same >> point, without BTN_TOOL_FINGER, there is no way for us to tell if the >> event is from touch or pen when both pen and touch are supported for >> the same device. I think I mentioned this more than once ;) > > Fair enough. But its hard to speak until I find the branch to review. > >> >> However, BTN_TOOL_DOUBLETAP is different. It doesn't provide any >> features except tell userland they are getting two contacts. For >> legacy support, we only need to worry about 1FGT. Or maybe I am >> missing something? > > Presumably, your doing pointer emulation for 2 finger touch in > wacom_w8001? I mean basically its reporting oldest touch in > ABS_X/ABS_Y values? Then one reason (among a few others) to send > DOUBLETAP is it informs userland to expect a jump in ABS_X/ABS_Y > values when lifting 1st finger before 2nd finger. > > This allows apps to make a choice. Does cursor stay were it was in > this case or jump immediately to 2nd finger location? Probably it was > in gesture mode and I'd hold cursor movement in this case until user > either retouches 1st figure or removes both. > > By NOT sending DOUBLETAP, your not helping or hurting > xf86-input-wacom. It can deal with it either way since its looking at > MT in this case and ignoring both FINGER and DOUBLETAP. > > But your also limiting user's design choices on how they can use > wacom_w8001 input with other applications... and limiting them for not > any reason I can see why. > > So my opposite question to you is why would you NOT want to send DOUBLETAP? > > Thanks, > Chris > >> >> I will not do anything "fundamentally wrong" before I get your >> approval ;). Trust me. >> >> Ping >> > ------------------------------------------------------------------------------ The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
