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. 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. 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. 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. 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. 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 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. 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). Let me take above two items in to account and re-send a patch. Chris ------------------------------------------------------------------------------ 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
