On Thu, Feb 3, 2011 at 12:10 PM, Ping Cheng <pingli...@gmail.com> wrote: > On Wed, Feb 2, 2011 at 9:05 PM, Chris Bagwell <ch...@cnpbagwell.com> wrote: >> On Wed, Feb 2, 2011 at 5:54 PM, Ping Cheng <pingli...@gmail.com> wrote: >>> On Tue, Feb 1, 2011 at 6:44 PM, Chris Bagwell <ch...@cnpbagwell.com> wrote: >>>> Been out of action with a cold. Trying slowing to get back online. >>> >>> Sorry to hear that. Hope you are getting "warmed up" here ;). >> >> ha. :-) > > You have definitely warmed up ;). Hope it won't get hot this round ;-). > >>>> I still think that Tablet PC should send BTN_TOOL_DOUBLETAP even >>>> though its not going to send BTN_TOOL_FINGER (same as ntrig). But this >>>> can be considered a safety net of sorts on X side since it works even >>>> if you send it. >>> >>> I know your point. But we do not post BTN_TOOL_DOUBLETAP in >>> wacom_w8001.c. I'd like to make it consistent for Wacom devices. Does >>> this make sense to you? >> >> This next comment is for kernel behaviour; not this patch. This patch >> seems fine and lets us be flexibly during kernel discussions. > > I was aiming at the kernel driver too. The reason I submit this patch > here before the kernel one is to discuss the types with you "locally" > first. I want to make sure we are on the same page about the format. > >> I still maintain my past comment that wacom_wac.c's TPC behaviour is >> easy to decide. Its 1 input device with stylus+eraser and 1 input >> device with run-of-the-mill touchscreen behaviour. It should go out >> of its way to be run-of-the-mill (including sending DOUBLETAP) and not >> go out of its way to be consistent with wacom_w8001.c. That is >> limiting its application for no benefit to end user. > > 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. Benefit of sending DOUBLETAP: Since aligns with touchscreen events, works with all pre-existing touchscreen apps that understand 2-finger gestures via DOUBLETAP. 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. > >> 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. > >> 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
