On Mon, Nov 14, 2011 at 3:08 PM, Chris Bagwell <[email protected]> wrote: > On Mon, Nov 14, 2011 at 4:40 PM, Chris Bagwell <[email protected]> wrote: >> On Mon, Nov 14, 2011 at 3:48 PM, Jason Gerecke <[email protected]> wrote: >>> On Sun, Jun 26, 2011 at 5:44 PM, Peter Hutterer >>> <[email protected]> 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 >>>>> <[email protected]> wrote: >>>>> > On Sat, Jun 25, 2011 at 01:05:52PM -0500, [email protected] wrote: >>>>> >> From: Chris Bagwell <[email protected]> >>>>> >> >>>>> >> 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 <[email protected]> >>>>> > >>>>> > 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 >
Saw this come through after sending the last one... Making a patch to do this is a definite improvement, though things still aren't quite right. It seems that any touch to the screen while the pen is in proximity will disable both pen and touch until the pen leaves proximity. It does sound like this plan *should* work though, so I'll continue poking around. Jason --- Day xee-nee-svsh duu-'ushtlh-ts'it; nuu-wee-ya' duu-xan' 'vm-nvshtlh-ts'it. Huu-chan xuu naa~-gha. ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Linuxwacom-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
