On Wed, Jan 19, 2011 at 12:46 PM, Chris Bagwell <ch...@cnpbagwell.com> wrote:
> On Wed, Jan 19, 2011 at 12:41 PM, Ping Cheng <pingli...@gmail.com> wrote:
>> On Tue, Jan 18, 2011 at 6:19 PM, Chris Bagwell <ch...@cnpbagwell.com> wrote:
>>>
>>>>> Is there driver your interested in?  Its difficult to talk in abstract.
>>>>
>>>> I'm moving the existing _TAP_ based USB TPC to _MT_ based format.
>>>> That's why I don't want to reuse _TAP_ again.
>>>
>>> OK. Thanks.  That clears up some things.  So this will be 2 input
>>> devices: 1) pen+eraser and 2) touchscreen (no pad buttons).
>>>
>>> For touchscreen device, it would be very much to your advantage to
>>> look just like pre-existing touchscreens.  So I agree that means no
>>> DOUBLETAP and for that matter no BTN_TOOL_FINGER from kernel side.
>>> The goal would be for xf86-input-evdev and xf86-input-wacom to both
>>> support equally.
>>
>> I had to sleep on this email to "dream" through :).
>>
>> I think we need BTN_TOOL_FINGER to report single touch events. That's
>> what we have discussed at LKML earlier for wacom_w8001. Dimitry told
>> us to use BTN_TOOL_FINGER for ST. And you agreed.
>
> The agreement wasn't in isolation.  It was to use BTN_TOOL_FINGER and
> a new ioctl() so user land can query to see the FINGER device is a
> touchscreen.  Are you adding support for that ioctl?
>
> If not then I recommend sticking with pre-existing standard and not
> sending BTN_TOOL_FINGER in TPC kernel driver so that xf86-input-wacom
> has enough info to know its an Absolute touchscreen and not relative
> touchpad like it assumes for Bamboo today.
>
> Please see hid_ntrig.c.  It and Wacom Tablet PC both present 2 input
> devices with same feature set on both.
>
> What it does on its touchscreen input is NOT declare BTN_TOOL_FINGER
> so applications can tell its an absolute mode touchscreen.  It does
> declare BTN_TOOL_DOUBLETAP though and sends it during 2-finger touch
> time periods (no affect on reported ABS_X/ABS_Y values which always
> track first touch).  It also sends MT events.
>
> This plays very nice with xf86-input-evdev and also should play very,
> very nice with current git xf86-input-wacom (correctly hotplugs,
> correctly sets WCM_2FGT, etc).
>
>> The updated
>> wacom_w8001.c uses BTN_TOOL_FINGER for ST now (merged in 2.6.38).
>
> wacom_w8001.c is special in that its muxing a pen tool and touch tool
> on same input device (a first as far as I know) so it was forced to
> send BTN_TOOL_FINGER to differentiate from BTN_TOOL_PEN; even if the
> new ioctl() to detect Absolute mode device wasn't ready to be
> implemented at same time.
>
> This means its pretty much a prerequisite that any X input driver and
> udev must understand this new ioctl() before they will correctly work
> with the wacom_w8001.c driver... and the driver has to add that
> ioctl() before it will be of use to these applications.
>
> BTN_TOOL_FINGER was added in the patch that added "single touch
> support" and not sending DOUBLETAP makes perfect sense for that case.
> Thats why I didn't mention anything during that review.
>
>>
>>> OK, I modify my opinion now slightly.  I suggest on kernel side you
>>> remove BTN_TOOL_FINGER and BTN_TOOL_DOUBLETAP (really, remove
>>> BTN_TOOL_DOUBLETAP and BTN_TOOL_TRIPLETAP).  On xf86-input-wacom, I
>>> recommend adding logic to usbProbeKeys()'s and specifically look for:
>>
>> Replacing  BTN_TOOL_DOUBLETAP with BTN_TOOL_FINGER and
>> BTN_TOOL_TRIPLETAP with MT format complies with what we have in
>> wacom_w8001.c.
>
> wacom_w8001 should not be the model for MT support because its never
> completely worked with any X input drivers.  If anything, the
> pre-existing MT driver hid_ntrig.c should be model.
>
>> It would be easier for us (at least for me) to explain
>> the drivers to other developers who plan to support both serial and
>> USB Tablet PC devices.
>
> For developers, I think its easiest to explain that Wacom's
> touchscreens input device works 100% like pre-existing touchscreen.
>
>>
>>> /* Detect touchscreens that support 2 finger touch */
>>> if (BTN_TOUCH && !BTN_TOOL_FINGER && ABS_MT_SLOT)
>>>  SET_BIT(keys,BTN_TOOL_FINGER&BTN_TOOL_DOUBLETAP);
>>>
>>> This will cause correct hotplugs to occur, correct WCM_2FG flags to be
>>> added, and align with our WCM_PROTOCOL_GENERIC requirements on keys.
>>
>> If we use BTN_TOOL_FINGER, we do not need to change anything for the
>> existing ST code. A check for ABS_MT_SLOT to replace
>> BTN_TOOL_DOUBLETAP is the only thing we need to add for WCM_2FG flag.
>
> I'm still confused on your intent on kernel side.  If you send
> BTN_TOOL_FINGER but not BTN_TOOL_DOUBLETAP your not like any
> pre-existing touchscreen and your not like any pre-existing touchpads
> and your not even simplifying xf86-input-wacom.  What is the benefit
> of being non-standard here?
>
> To align with existing touchscreen or touchpad is only 2 extra lines
> of code on either kernel side or xf86-input-wacom side depending on
> which of model chosen so I'm sure code size is not the issue your
> concerned with.
>
> input_mt_report_pointer_emulation() does all the dirty work now.  It
> only sends whatever BTN_TOOL_* you declare is supported.
>
> * Making TPC ntrig touchscreen-like requires adding 0 fake keys to
> xf86-input-wacom (I think it works OK without BTN_TOOL_FINGER) and has
> benefit of also detecting Absolute mode without resorting to
> tablet_id.  Kernel declares only BTN_TOOL_DOUBLETAP.
>
> * TPC hybrid way requires adding 1 fake key (DOUBLETAP) to
> xf86-input-wacom and has negative you must resort to tablet_id to
> detect 1FGT vs. 2FGT (ABS_MT_SLOT != 2FGT in MT standard).  Kernel
> declares only BTN_TOOL_FINGER in this case.
>
> * TPC touchpad-like requires adding no fake keys but slight negative
> in that you must have new ioctl() to correctly detect Absolute mode
> right or resort to tablet_id.  Kernel declares both BTN_TOOL_FINGER
> and BTN_TOOL_DOUBLETAP and adds new ioctl() to inform its absolute
> mode.
>
>> All GENERIC devices still share the same code. My goal is to let
>> common code cover as many hardware models as we can so we may deal
>> with less special cases.
>
>> Does this make sense?
>
> I think we are both on same page for common code. I think we are only
> a hand full of lines of code away from each other.  Its just I'm
> pushing for code to be so common that I can route an eGalax or ntrig
> touchscreen to xf86-input-wacom and a Wacom Tablet PC to
> xf86-input-evdev+XInput 2.1 MT patches.
>
> I'm afraid that not declaring DOUBLETAP may limit the wacom's applications.

All right. We had a bit offset there. I'll make another patchset and
consider using DOUBLETAP.

Thank you for your time. I didn't mean to make you spend so much effort on this.

Ping

------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Reply via email to