On Mon, Nov 14, 2011 at 2: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.
>
I made a mistake in my original mail: this has a *serial* ISDv4 sensor
with pen and two-finger touch, with the two being exposed on the same
event node. I just updated to the latest input-wacom module from git
(for a 2.6.39 kernel) and the behavior is slightly different: touch
works up until the pen is brought in proximity, at which point both
are useless. The attempted fix I mentioned continues to have the same
effect: pen only provides a single event when it enters prox, touch
always works fine (even after pen has entered prox).

I can try to install Linux 3.1 if you'd like.

> 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?
>
If you could provide me a patch to test, I'd be happy to see if it
works. I'm not entirely sure what needs to go where.

> Chris
>

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
Linuxwacom-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel

Reply via email to