On Thu, Jan 6, 2011 at 10:53 AM, Ping Cheng <pingli...@gmail.com> wrote: > On Thu, Jan 6, 2011 at 6:56 AM, Chris Bagwell <ch...@cnpbagwell.com> wrote: >> On Wed, Jan 5, 2011 at 6:49 PM, Ping Cheng <pingli...@gmail.com> wrote: >>> Ok, I see the connection between the two patches. That's why 1/2 is >>> the first ;). >>> >>> I reviewed patch one again last evening. With the current kernel >>> events reported by wacom_wac, it is fine for both protocols (generic >>> and 4) since we don't send touch data when pen is in prox. If we send >>> both pen and touch data, as in wacom_w8001, I don't think we want to >>> initialize touch with in-prox pen data since touch only shares (x,y) >>> with pen. For example, touch does not have side switches (buttons 2 >>> and 3), while most styli do. If the other tool is out-prox, i.e. only >>> (x,y) is non-zero, it might be ok. >>> >>> I think we need a tool type and in-prox check before initializing the >>> incoming new tool. What do you think? >> >> It looks to me we are OK. When sending PEN and TOUCH data in Single >> Touch way (ABS_X/Y/PRESSURE) then we surely do want to initialize to >> previous tools value during switch. So the discussion is limited to >> what to do for non-common items. >> >> All current generic and protocol 4 devices appear to set to zero these >> uncommon items on kernel side when the pen tool goes out of proximity. >> It doesn't always set to zero for common values but thats OK and >> thats why this patch exists so it knows what previous starting point >> is. >> >> Long term, I really think this has to be a kernel side solution >> although there are a couple of ways to solve basic issue on that side. >> If we try to address this on application side, we will eventually >> resort to the tablet_id type checks to figure how to mask I feel. >> >> We can develop hard codd masks for each BTN_TOOL_* and only memset() >> items not in mask when switching tools. For example, switching from >> BTN_TOOL_PEN to BTN_TOOL_FINGER would memset() BTN_STYLUS as you >> mention but switching from BTN_TOOL_FINGER to BTN_TOOL_PEN or from a >> BTN_TOOL_PEN to another BTN_TOOL_PEN would not mask BTN_STYLUS. >> >> The problem with this approach can be seen when switching from >> BTN_TOOL_PEN->BTN_TOOL_FINGER->BTN_TOOL_PEN. If you memset() >> BTN_STYLUS on app side and kernel does not do same then you've forever >> lost a kernel value during transition. Apps won't see the button >> press if user brings stylus in proximity with it already pressed. >> Luckly, kernel is masking out BTN_STYLUS and so no need to duplicate >> on app side. >> >> Will two tools of same types every need two different masks? For >> example, will BTN_TOOL_PEN sometimes have just BTN_STYLUS and other >> times have BTN_STYLUS&&BTN_SYTLUS2? Then we are restoring to >> tablet_id or serial # lookups to detect this in user land. >> >> All the information to do this masking is already in kernel side so we >> should make use of it and mask there instead of hardcoding in apps. >> And from my kernel code reviews, I think we already are for all expect >> protocol 5's. >> >> It may be better to develop a new interface in kernel so that it can >> send a mask for current tool so applications can know what >> keys/abs/rel's are valid for the current BTN_TOOL_* when it switches. >> But it doesn't seem strictly needed at this exact moment. > > I see your point. I'll ack the patchset so more people can test it.
Thanks. > > I think the only event that we need the previous status is (x,y). Pressure as well. It also falls in to your next part though. > For > ST events, there is an IOCTL to retrieve last sync'd events posted > from the kernel. We discussed if the same support should be extended > for MT or not last June at LKML. The end result was: (x,y) is so > dynamic, i.e., changes almost all the time, there is no need for the > support. Good to know. I may have not been subscribed back then. I have been thinking about a future patch to xf86-input-wacom that on startup will prime the values of tool_type/proximity/x/y/pressure with those ioctl's you mention. This will allow moving work around logic at *end* of each sync windows to single time up front when xf86-input-wacom starts up... but now I need to think about this some more for MT since same ioctl's do not exist. I am worried less about x/y/pressure but much more on how rare it is for MT logic to send ABS_MT_TRACKING_ID. On startup, I'm thinking it may become important to find all pre-existing tracking ID's for all slots... In mean time, todays end-of-sync-window work around should still mostly work for this corner case, I think. Chris > > Since we didn't need to retrieve (x,y), I didn't bother to find the > exact ioctl call for ST. > > Ping > ------------------------------------------------------------------------------ Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
