On Mon, Oct 18, 2010 at 9:57 PM, Ping Cheng <pingli...@gmail.com> wrote: > 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. >
The comments were added to help reader for non-MT case. For example, the memset() is there for simple case of user using PEN and then flipping to ERASER. Protocol 5 devices are the hard part because when switching from PEN to ERASER its possible that PEN used channel 1 and ERASER switches to channel 0. So memset() is easier then tracking this change and doing memcpy(). Maybe I should add this example to be clearer why I added it? The TODO and FIXME are some issues I wanted to track to resolve eventually which probably lead you to thinking its MT related. I think your comments are better discussed in context of patch 5. Do you mind replying to that one? Here is my answer though. The intent of patch #5 is to not require BTN_0 .. BTN_3 to be isolated by EV_SYN or serial #'s or BTN_TOOL_FINGER or anything else. The code just knows those are for the PAD device and routes them to appropriate channel. Adding an EV_SYN to isolate button presses in wacom_wac.c may slightly simplify xf86-input-wacom changes required but I don't think its worth it for a few reasons. 1) Standard touchpad's do send button presses combined with touch events. I'd rather not worry about how isolating them affects things like click-and-drag if user decides to route Bamboo Finger device to xf86-input-synaptics. 2) When we add MT packet processing we will need the concepts in patch #5 of being able to call wcmEvent() for channels 0 and 1 within a single EV_SYN context. So may as well do it for PAD case as well. 3) Non-wacom tablets will send pad button presses and stylus events in single sync window so patch #5 gets us 90% of way to handling these tablets (need to address comment I added around BTN_TOUCH in wcmUSB.c for those devices though). Chris ------------------------------------------------------------------------------ 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
