On Thu, Feb 3, 2011 at 4:55 PM, Ping Cheng <pingli...@gmail.com> wrote:
> 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.
What do you know. I book marked something that doesn't point to HEAD.
That explains some things. :) I see the committed code now.
>
> 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.
So we are talking about 2FGT case since we are talking about
DOUBLETAP. Your declaring BTN_TOUCH and BTN_TOOL_FINGER for any touch
(I think). The only think I'm talking about is adding:
__set_bit(BTN_TOOL_DOUBLETAP, dev->keybit);
under "case 5" for 2FGT case. Since you are making use of:
input_mt_report_pointer_emulation(dev, true);
It automatically sends BTN_TOOL_FINGER vs. BTN_TOOL_DOUBLETAP at
correct time. It expects any sane pointer emulation should be
declaring DOULETAP/TRIPLETAP/QUADTAP based on finger count it can
detect and then it sends correct thing on your behave. It wasn't
really intended to bypass that step; just a "feature" that it could be
bypassed.
Chris
>
> 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
