On Fri, Jul 15, 2011 at 4:09 AM, Roald Frederickx <[email protected]> wrote: > Hi, > > I've created a fork of the driver for legacy serial protocol IV > tablets made by Julian Squires (more info can be found in older posts > in this mailing list, and at > http://cipht.net/2011/07/02/wacom_serial-initial-release.html).
Hi Roald, glad to see both serial protocol 4 and 5 are getting some attention. As part of this, I'm hoping you can contribute to the following new page started by Julian. http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Serial_Protocol_IV > > I have a question regarding implementing the two available channels in > protocol V. > > Currently, I just send all the tool data of a channel within a single > "sync window", together with the appropriate BTN_TOOL_* set to 1. > There is only one such BTN_TOOL_* per sync window. I don't explicitly > reset the other tool's BTN_TOOL_* to 0 in that window (because it can > still be in proximity at that moment). > Is this the proper way to implement it? I had a look at wacom_wac.c, > and that seems to follow the same approach, as far as I can tell. > Is there any way I can verify that both channels are working > correctly? What kind of behaviour should I expect, exactly? I haven't looked at your code yet but above sounds correct. The important part is to not have 2 transitions of BTN_TOOL_* in the same sync window. I mean something like BTN_TOOL_PEN goes from 0->1 and BTN_TOOL_MOUSE goes from 1->0 in same window. Its OK that both are 1 in same sync window because it will be, for example BTN_TOOL_PEN 1->1 and BTN_TOOL_MOUSE 0->1 and kernel event filtering will not send that BTN_TOOL_PEN. > > Note: I dont sent ABS_MISC (as requested for the generic > interface(?)), but I do send a MSC_SERIAL command every sync window > for the appropriate tool. It sounds like you've probably already seen these two pages then? http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Kernel_Input_Event_Overview http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Wacom_Protocol_Overview The only way xf86-input-wacom can currently handle 2 tools in proximity at same time is to use "protocol 5 events" as described in above wiki. So for now at least you will need to send that ABS_MISC along with MSC_SERIAL. A tablet declaring ABS_MISC support+tablet ID together is what xf86-input-wacom uses to detect its a protocol 5 device (multi-tool in proximity feature). >From that point on, the value in MSC_SERIAL is used to see which of 3 data structures to store the stylus/mouse puck tool's events in. So thats why you don't want 2 BTN_TOOL_* transitions in same sync window because both values will get stored in same data structure related to the single value of MSC_SERIAL. As the above wiki page describes, these tools don't really share events between tool types (stylus is absolute, mouse puck is relative, buttons on tablets don't re-use mouse puck button names) so there is no special logic in xf86-input-wacom for protocol 5 devices to deal with kernel event filtering when changing between tools in a new sync window. If 2 tools shared some events then during tool transition xf86-input-wacom would need to peak into the other tool's structure to account of kernel event filtering. To me, thats mostly what the ABS_MISC declaration is. Its a way kernel is informing xf86-input-wacom that its guaranteed no overlapping events between tool types. If you stick with same events used by wacom_wac.c protocol 5 devices then you'll get this same design and won't have to worry about modifying xf86-input-wacom to handle lost events. Another reason you'll need to use ABS_MISC/use protocol 5 events is related to the tablet and mouse puck buttons. Currently, the "generic" protocol understood by xf86-input-wacom routes all buttons except for BTN_STYLUS and BTN_STYLUS2 to the "PAD" device. So the mouse puck buttons would go to the wrong place. For protocol 5 event devices, its conceptually routed to PAD device for BTN_TOOL_FINGER and CURSOR device for BTN_TOOL_MOUSE but the MSC_SERIAL must be set right as well. There are many possible improvements to xf86-input-wacom were, for example, we could get rid of BTN_TOOL_FINGER requirement but the above is were we stand today if you want to get it working with only kernel driver updates. Since you can base on wacom_wac.cj protocol 5 devices, I'd go the purely kernel modification route. Chris > > If you want, you can have a look at the code at > http://github.com/RoaldFre/wacom_serial5 -- Note: it's still *very* > WIP and needs tidying up. > ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
