On Wed, Dec 22, 2010 at 1:57 PM, Chris Bagwell <ch...@cnpbagwell.com> wrote: > On Tue, Dec 21, 2010 at 5:32 PM, Ping Cheng <pingli...@gmail.com> wrote: >> On Mon, Dec 20, 2010 at 5:59 PM, <ch...@cnpbagwell.com> wrote: >>> From: Chris Bagwell <ch...@cnpbagwell.com> >>> >>> Kernel side input event filtering forces user land to track previous >>> tools values when switching to new tools. Sending new-but-duplicate >>> values for new tool would cause confusion. >>> >>> At one time, all wacom's sent zero values when going out of proximity >>> which allowed xf86-input-wacom to take a short cut and memset() values >>> when entering proximity. This is not true of all drivers any more. >>> >>> Change to initialize current tools values based on previous tools value; >>> which is only needed when tools use a new channel. >> >> I didn't test it yet (lack of time). Just to throw some random thoughts here. >> >> I feel we only need to initialize x and y with previous (x,y) since >> the chance of other fields, if there are any, such as buttons and >> wheels, that have the exact same values for different tools is small. >> If we initialize all of them, we are introducing an state that is not >> correct for the new device. >> >> Take a pen with wheel and one without for example. If the first pen >> with wheel rolled up while the second one came in, we would assigned a >> wheel value to the second one although the second pen does not even >> have a wheel on it. Similiar things may happen between pen and touch. >> > > Thanks for feedback. An initial reply: > > My review of kernel side tells me that the kernel driver is cleaning > up (sending zeros) when going out of proximity so there is no reason > for memset() in user land side.
No, I am not objecting your removal of memset. I was talking about if we should reuse the whole sync'ed packet or not. > So for example of pen with ABS_WHEEL and switching to pen without > ABS_WHEEL, reusing previous tools ABS_WHEEL value should be OK because > it was set to zero when first pen when out of proximity. Sorry I did not say it clearly. My example assumes that both tools are in prox, i.e. the first tool is in while the second one showed up (Intuos and Intuos2 support this case). > My stance is if kernel is not totally cleaning up then its a major bug > on that side that needs to be fixed. We should always be able to use > something like evtest to take a snapshot of current tool values and > get an accurate state. It is not a kernel issue. > If a BTN_TOOL_PEN is in proximity and reporting a value for ABS_WHEEL > then that better be a good ABS_WHEEL value and not some stale value > from tool that was in proximity before it. Relying on memset() to > mask stale data is not good. Agree. And they are good values, I hope (bet? ;). > After further kernel code review, this patch can get confused for I1 > and I2 where two tools can be in proximity (DUALINPUTS). Even for > these devices, we really should be starting from previous values of > previous tool but it looks like kernel side is leaving some tool > specific values dangling. Why? > One can argue that kernel driver is working correct here. If its firm > definition that BTN_TOOL_MOUSE can never send BTN_STYLUS and a > BTN_TOOL_PEN can never send BTN_LEFT then I guess its technically OK > to leave both at real states while both are in proximity and not just > at values relative to last tool reported (I mean I guess its OK that > evtest can show snapshot values of BTN_TOOL_MOUSE=0, BTN_TOOL_PEN=1, > BTN_LEFT=1, BTN_STYLUS=1 and user land must account for that strange > looking state). I guess we have to have a common ground between the kernel and X driver, right? > I guess I need to still account for this needed masking in > xf86-input-wacom using either old memset() solution or some other form > of masking based on tool type. I am bit lost for this paragraph. > Also, your point on buttons is valid since its also a form of 2 tools > in proximity at same time (BTN_STYLUS buttons vs. BTN_LEFT pad > buttons). Yes, all my comments are based on the assumption that we have two tools working. > Let me take above two items in to account and re-send a patch. Thank you. Hope we are on the same page now. 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
