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. I think the only event that we need the previous status is (x,y). 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. 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
