On Sun, Oct 17, 2010 at 7:38 PM, <ch...@cnpbagwell.com> wrote:
> From: Chris Bagwell <ch...@cnpbagwell.com>
>
> There is an implied agreement between kernel drivers and
> user land to work around event filtering issues. Document
> our current approach.
>
> Also add some notes on issues/bugs that need to be addressed
> in future patches.
>
> Signed-off-by: Chris Bagwell <ch...@cnpbagwell.com>
> ---
> src/wcmUSB.c | 35 +++++++++++++++++++++++++++++++++++
> 1 files changed, 35 insertions(+), 0 deletions(-)
>
> diff --git a/src/wcmUSB.c b/src/wcmUSB.c
> index 131627c..b489be0 100644
> --- a/src/wcmUSB.c
> +++ b/src/wcmUSB.c
> @@ -1224,11 +1224,46 @@ static void usbParseEvents(InputInfoPtr pInfo)
> pChannel = common->wcmChannel + channel;
> dslast = pChannel->valid.state;
>
> + /* Because of input filtering, the kernel driver can not
> + * always force total set of data when new tool comes into
> + * proximity. Therefore, when new tool events are sent
> + * we must initialize all event values to same as previous
I don't think we need to get (x,y) for pad. Pad doesn't send motion
events. Peter has fixed/updated the XInput code to deal with this
case. Am I right, Peter?
We only need to send the buttons in relative mode, as we are doing
now. Adding an input_sync call after all MT data and before the pad
(keys) is what needed in the kernel driver. Then call input_sync again
after the pad/keys are sent. This way, most xf86-input-wacom code
stays the same.
The four buttons will still be sent by:
input_report_key(input, BTN_0, data[1] & 0x1);
input_report_key(input, BTN_1, data[1] & 0x2);
input_report_key(input, BTN_2, data[1] & 0x4);
input_report_key(input, BTN_3, data[1] & 0x8);
In xf86-input-wacom, we do not check on BTN_TOOL_FINGER. We check on
the existence of BTN_0 for pad and the group ends with input_sync. If
we want to keep the MSC_SERIAL call, we could do so too. This has the
minimal code change in both wacom_wac.c and xf86-input-wacom.
Maybe I am missing something. I will comment on patch 5 after I hear
from you for this one.
Ping
> + * tool to account for filtered events; for case when
> + * tools share events.
> + *
> + * To simplify things, we take advantage of fact kernel drivers
> + * force all values to zero when going out of proximity so we
> + * take a short cut and memset to align while going in-prox
> + * instead of tracking values of last tool that shares same
> + * events.
> + *
> + * TODO: The following discards data from drivers that send
> + * important non-zero data for current channel while out-of-prox.
> + * Adding "&& dslast.proximimty" to check would probably help
> + * this case.
> + * This also discards data for tablets that do not follow
> + * zero-on-out-prox rule. Adding a !WCM_PROTOCOL_GENERIC
> + * check ould probably help this case.
> + */
> if (!common->wcmChannel[channel].work.proximity)
> {
> memset(&common->wcmChannel[channel],0,sizeof(WacomChannel));
>
> /* in case the in-prox event was missing */
> + /* FIXME: Forcing in-prox will cause cursor
> + * jumps for drivers that send useful data
> + * while out-of-prox (WCM_PROTOCOL_GENERIC devices).
> + * This includes button presses on tablet for
> + * Bamboo touchpads.
> + *
> + * Probably, this logic was added to handle case of
> + * pen on tablet when x server first starts or before
> + * time we would process BTN_TOUCH event as replacement
> + * for missing BTN_TOOL_* event. The prior case
> + * is better handled elsewhere then each sync window
> + * and the later case needs to be imporved
> + * to know treat as BTN_TOOL_PEN instead of
> BTN_TOOL_DOUBLETAP.
> + */
> common->wcmChannel[channel].work.proximity = 1;
> }
>
> --
> 1.7.3.1
>
>
> ------------------------------------------------------------------------------
> Download new Adobe(R) Flash(R) Builder(TM) 4
> The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
> Flex(R) Builder(TM)) enable the development of rich applications that run
> across multiple browsers and platforms. Download your free trials today!
> http://p.sf.net/sfu/adobe-dev2dev
> _______________________________________________
> Linuxwacom-devel mailing list
> Linuxwacom-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
>
------------------------------------------------------------------------------
Download new Adobe(R) Flash(R) Builder(TM) 4
The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly
Flex(R) Builder(TM)) enable the development of rich applications that run
across multiple browsers and platforms. Download your free trials today!
http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________
Linuxwacom-devel mailing list
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
