On Mon, Nov 14, 2011 at 4:40 PM, Chris Bagwell <ch...@cnpbagwell.com> wrote: > On Mon, Nov 14, 2011 at 3:48 PM, Jason Gerecke <killert...@gmail.com> wrote: >> On Sun, Jun 26, 2011 at 5:44 PM, Peter Hutterer >> <peter.hutte...@who-t.net> wrote: >>> On Sun, Jun 26, 2011 at 07:40:35PM -0500, Chris Bagwell wrote: >>>> On Sun, Jun 26, 2011 at 7:31 PM, Peter Hutterer >>>> <peter.hutte...@who-t.net> wrote: >>>> > On Sat, Jun 25, 2011 at 01:05:52PM -0500, ch...@cnpbagwell.com wrote: >>>> >> From: Chris Bagwell <ch...@cnpbagwell.com> >>>> >> >>>> >> We really need to add hooks to query pre-existing device state when >>>> >> input driver starts up because slot ID is almost never sent when >>>> >> touching 1 finger to screen. >>>> >> >>>> >> In mean time, it makes sense to default device_type to most likely >>>> >> value of TOUCH (the T in MT) for this function used only by MT >>>> >> devices. >>>> >> >>>> >> The default of zero is causing some events to be filtered mistakenly. >>>> >> >>>> >> Signed-off-by: Chris Bagwell <ch...@cnpbagwell.com> >>>> > >>>> > Merged 1/4 and this one for now, see my comments to 2/4 for the rest. >>>> > >>>> > Cheers, >>>> > Peter >>>> >>>> Can you verify you meant 2/4 and 4/4 were merged? 2/4 is the simple >>>> debug statement. >>> >>> yes, sorry. I meant 2 and 4 were merged. They arrived out-of-order in my >>> inbox so I got the numbers mixed up. >>> >>> Cheers, >>> Peter >>> >> >> I was finishing my final round of testing in preparation for 0.12.0 >> when I noticed this commit caused the pen and touch tools on my MT USB >> ISDv4 tablet PC to quit working. At first I thought it might be >> because setting device_type before the loop causes it to never >> execute, but fixing that still results in the pen having issues (touch >> starts working again though). >> >> Chris, can you remember any details about the device filtering >> problems this patch was fixing? I'm considering reverting this patch >> for 0.12 but would like to have a little more information before doing >> that. >> > > Reverting it would break Bamboo's and generic MT touchscreens. The > basic issue is easy to reproduce on touch only devices. > > Are you using an upstream kernel driver for MT ISDv4? Is this a comb > pen+touch on same USB interface (hid-wacom)? I might be able to give > some suggestions if I know how device is sending events. > > The MT Slot ID has to start at something and that something is zero. > Majority of time your going to use 1 finger on screen which maps to > Slot ID of zero and so you can assume it will be rare to see a Slot ID > received inside xf86-input-wacom. > > The current code works around that by always assuming MT devices are > most likely touch devices. If its a combo MT+pen device and that pen > doesn't send Slot ID's then I can see how that would break things. > > For Bamboo MT devices and generic MT touchscreens (without combined > Pen on same device), it will work fine to move this logic out of > normal event loop and do it once during init phase. > > Would that change have side affect to fixing your issue? >
Looking at the usbInitTool function closer, it looks like there was a basic issue that needs to be fixed for MT+pen that even reverting the patch won't fix. It required a BTN_TOOL_* or ABS_MT_ every sync window or we'd get hard coded invalid ID of zero... and filtering makes those events rare. We should pass in the previous device_type and if no new type is found, return the previous value... Except in the special case were the previous value was zero. Then we can default to TOUCH_ID. Since BTN_TOOL_PEN doesn't have the same zero value issue as ABS_MT_SLOT_ID, I think its safe to default to TOUCH_ID. Chris ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
