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. > 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. > 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. > 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 ;) 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? I will not do anything "fundamentally wrong" before I get your approval ;). Trust me. Ping ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
