Windows Precision Touchpad support

Windows Precision Touchpad support

[Michael Leuchtenburg]

I have been trying to figure out how to get palm detection working on
my new Dell XPS 13 9343. It has a Windows Precision Touchpad (PTP)
compliant touchpad; I think it's a Synaptics rebrand. DLL0665:01
06CB:76AD UNKNOWN; that 06CB definitely indicates it's Synaptics under
there.

I've been trying to figure out if it's not sending information along
that could be used to determine if a touch is intentional or
unintentional or if the Linux drivers - either kernel or userspace -
just don't support what it's sending. PTP devices must send at least
"confidence", which is used to indicate that a touch is not a finger.
They may also send width and height which could be used for detection.
It doesn't look like confidence is supported by Linux currently.

In trying to figure this out, I looked at the HID descriptor and
noticed that it's not reporting itself as a PTP but rather as a mouse.
This is actually as expected for an PTP compliant device which hasn't
been initialized fully - according to
https://msdn.microsoft.com/en-us/library/windows/hardware/dn467314(v=vs.85).aspx
devices are supposed to use the Mouse Collection for input reporting
until the input mode is set to touchpad, after which they're supposed
to switch to the Windows Precision Touchpad Collection.

It looks like the hid-multitouch driver generally doesn't set the
input mode on devices to MT_INPUTMODE_TOUCHPAD (0x3). By default it
sets it to MT_INPUTMODE_TOUCHSCREEN (0x2) in mt_probe. It does also
set it to MT_INPUTMODE_TOUCHAD (0x3) in mt_touch_input_mapping, though
I haven't traced through to see if that actually gets written out to
the device or is just used by the driver to determine how to interpret
various events.

Have I missed something? Is it actually being initialized to PTP mode
and rdesc just isn't being updated? That would probably lead to
misinterpreting some events since the event collections are very
different, so it seems unlikely. Is there some condition under which
it does get initialized to PTP mode?

If I'm right and this mode just isn't supported currently, is anyone
working on this functionality? I'd rather not duplicate effort.

Cheers,
Michael

Re: Windows Precision Touchpad support

[Benjamin Tissoires]

Hi Michael,

On Sat, Mar 28, 2015 at 6:11 PM, Michael Leuchtenburg
<michael@slashhome.org> wrote:
> I have been trying to figure out how to get palm detection working on
> my new Dell XPS 13 9343. It has a Windows Precision Touchpad (PTP)
> compliant touchpad; I think it's a Synaptics rebrand. DLL0665:01
> 06CB:76AD UNKNOWN; that 06CB definitely indicates it's Synaptics under
> there.
>
> I've been trying to figure out if it's not sending information along
> that could be used to determine if a touch is intentional or
> unintentional or if the Linux drivers - either kernel or userspace -
> just don't support what it's sending. PTP devices must send at least
> "confidence", which is used to indicate that a touch is not a finger.
> They may also send width and height which could be used for detection.
> It doesn't look like confidence is supported by Linux currently.

Oh. It looks like I should have spent more time looking into this
spec. I did not notice that Confidence know has a palm rejection
meaning. Sigh. For touchscreens, this used to be that until the bit is
set, the touch might not be an actual touch...

>
> In trying to figure this out, I looked at the HID descriptor and
> noticed that it's not reporting itself as a PTP but rather as a mouse.
> This is actually as expected for an PTP compliant device which hasn't
> been initialized fully - according to
> https://msdn.microsoft.com/en-us/library/windows/hardware/dn467314(v=vs.85).aspx
> devices are supposed to use the Mouse Collection for input reporting
> until the input mode is set to touchpad, after which they're supposed
> to switch to the Windows Precision Touchpad Collection.
>
> It looks like the hid-multitouch driver generally doesn't set the
> input mode on devices to MT_INPUTMODE_TOUCHPAD (0x3). By default it
> sets it to MT_INPUTMODE_TOUCHSCREEN (0x2) in mt_probe. It does also
> set it to MT_INPUTMODE_TOUCHAD (0x3) in mt_touch_input_mapping, though
> I haven't traced through to see if that actually gets written out to
> the device or is just used by the driver to determine how to interpret
> various events.

Well, we do not export the mouse collection, so I can guarantee that
we are using the PTP collection :)
You can also be sure by checking at the input node, by running
evemu-record, and you'll see that we forward the raw touches (like a
touchscreen), and not the relative axes (like any plain mouse).

>
> Have I missed something? Is it actually being initialized to PTP mode
> and rdesc just isn't being updated? That would probably lead to
> misinterpreting some events since the event collections are very
> different, so it seems unlikely. Is there some condition under which
> it does get initialized to PTP mode?

No, I think you misread the report descriptors. There should be at
least 2 collections, one for the mouse and one for the raw touchpad.
We do not change the report descriptors in hid-multitouch so it should
still be there.

>
> If I'm right and this mode just isn't supported currently, is anyone
> working on this functionality? I'd rather not duplicate effort.

The chromium guys just got their MT_TOOL_PALM patch merged in Dmitri's tree:
https://git.kernel.org/cgit/linux/kernel/git/dtor/input.git/commit/?h=for-linus&id=a736775db683174269c65c7c5cc8e5ee534e7681

I don't know if they plan to make hid-multitouch aware of it, but that
seems legitimate to me.
You are welcome to work on such patches :)

Cheers,
Benjamin

Re: Windows Precision Touchpad support

[Michael Leuchtenburg]

Hi Benjamin,

On Sat, Mar 28, 2015 at 8:09 PM, Benjamin Tissoires
<benjamin.tissoires@gmail.com> wrote:
> Hi Michael,
>
> On Sat, Mar 28, 2015 at 6:11 PM, Michael Leuchtenburg
> <michael@slashhome.org> wrote:
>> I have been trying to figure out how to get palm detection working on
>> my new Dell XPS 13 9343. It has a Windows Precision Touchpad (PTP)
>> compliant touchpad; I think it's a Synaptics rebrand. DLL0665:01
>> 06CB:76AD UNKNOWN; that 06CB definitely indicates it's Synaptics under
>> there.
>>
>> I've been trying to figure out if it's not sending information along
>> that could be used to determine if a touch is intentional or
>> unintentional or if the Linux drivers - either kernel or userspace -
>> just don't support what it's sending. PTP devices must send at least
>> "confidence", which is used to indicate that a touch is not a finger.
>> They may also send width and height which could be used for detection.
>> It doesn't look like confidence is supported by Linux currently.
>
> Oh. It looks like I should have spent more time looking into this
> spec. I did not notice that Confidence know has a palm rejection
> meaning. Sigh. For touchscreens, this used to be that until the bit is
> set, the touch might not be an actual touch...

That's based only on the description at
https://msdn.microsoft.com/en-us/library/windows/hardware/dn467314(v=vs.85).aspx
saying "Set when a contact is too large to be a finger". I don't know
if there's a more detailed spec somewhere; if there is, I haven't
found it yet. It's strange that the sense would be inverted for
touchpads vs touchscreens.

Looking at the reports from events in debugfs, I do see confidence set
to 0 when I use my palm and to 1 when I use a finger, so it seems like
it would be useful for unintentional touch detection. Sadly no width,
so user-driven tuning won't be possible. Too bad since it definitely
doesn't catch all sorts of palm touches that I tested.

>>
>> In trying to figure this out, I looked at the HID descriptor and
>> noticed that it's not reporting itself as a PTP but rather as a mouse.
>> This is actually as expected for an PTP compliant device which hasn't
>> been initialized fully - according to
>> https://msdn.microsoft.com/en-us/library/windows/hardware/dn467314(v=vs.85).aspx
>> devices are supposed to use the Mouse Collection for input reporting
>> until the input mode is set to touchpad, after which they're supposed
>> to switch to the Windows Precision Touchpad Collection.
>>
>> It looks like the hid-multitouch driver generally doesn't set the
>> input mode on devices to MT_INPUTMODE_TOUCHPAD (0x3). By default it
>> sets it to MT_INPUTMODE_TOUCHSCREEN (0x2) in mt_probe. It does also
>> set it to MT_INPUTMODE_TOUCHAD (0x3) in mt_touch_input_mapping, though
>> I haven't traced through to see if that actually gets written out to
>> the device or is just used by the driver to determine how to interpret
>> various events.
>
> Well, we do not export the mouse collection, so I can guarantee that
> we are using the PTP collection :)
> You can also be sure by checking at the input node, by running
> evemu-record, and you'll see that we forward the raw touches (like a
> touchscreen), and not the relative axes (like any plain mouse).
>>
>> Have I missed something? Is it actually being initialized to PTP mode
>> and rdesc just isn't being updated? That would probably lead to
>> misinterpreting some events since the event collections are very
>> different, so it seems unlikely. Is there some condition under which
>> it does get initialized to PTP mode?
>
> No, I think you misread the report descriptors. There should be at
> least 2 collections, one for the mouse and one for the raw touchpad.
> We do not change the report descriptors in hid-multitouch so it should
> still be there.

It's true, I do see ABS_X/Y and ABS_MT_POSITION_X/Y. You're right - I
was confused by the continued presence of the mouse collection. Which
I shouldn't have been, since there's one in MS's example, though at
the end rather than the beginning as it is for my device. Sorry, I'm
new to reading HID descriptors. I'm not sure how the driver is telling
it the right mode, but it seems to be. I don't ever see the driver
issuing an input mode feature report to the touchpad when I load
i2c_hid with debug=1, though. It could be that the firmware and
platform designers have special cased Linux in some way. Or I could be
misreading the logs. Regardless, it gets figured out somehow. I do
wonder if it might have a "PTP" and "actually talking to Windows PTP"
mode. The amount of other hardware on this system that has some
detection of Linux vs. Windows is remarkable, so Synaptics having some
special case for Linux wouldn't surprise me at all.

>>
>> If I'm right and this mode just isn't supported currently, is anyone
>> working on this functionality? I'd rather not duplicate effort.
>
> The chromium guys just got their MT_TOOL_PALM patch merged in Dmitri's tree:
> https://git.kernel.org/cgit/linux/kernel/git/dtor/input.git/commit/?h=for-linus&id=a736775db683174269c65c7c5cc8e5ee534e7681
>
> I don't know if they plan to make hid-multitouch aware of it, but that
> seems legitimate to me.
> You are welcome to work on such patches :)

I thought that was just for one particular piece of hardware that was
going to send that tool explicitly. I'll take a closer look at what
they're doing, thanks.

Cheers,
Michael

Re: Windows Precision Touchpad support

[Michael Leuchtenburg]

On Sun, Mar 29, 2015 at 11:23 AM, Michael Leuchtenburg
<michael@slashhome.org> wrote:
> Hi Benjamin,
>
> On Sat, Mar 28, 2015 at 8:09 PM, Benjamin Tissoires
> <benjamin.tissoires@gmail.com> wrote:
>> Hi Michael,
>>
>> On Sat, Mar 28, 2015 at 6:11 PM, Michael Leuchtenburg
>> <michael@slashhome.org> wrote:
>>> I have been trying to figure out how to get palm detection working on
>>> my new Dell XPS 13 9343. It has a Windows Precision Touchpad (PTP)
>>> compliant touchpad; I think it's a Synaptics rebrand. DLL0665:01
>>> 06CB:76AD UNKNOWN; that 06CB definitely indicates it's Synaptics under
>>> there.
>>>
>>> I've been trying to figure out if it's not sending information along
>>> that could be used to determine if a touch is intentional or
>>> unintentional or if the Linux drivers - either kernel or userspace -
>>> just don't support what it's sending. PTP devices must send at least
>>> "confidence", which is used to indicate that a touch is not a finger.
>>> They may also send width and height which could be used for detection.
>>> It doesn't look like confidence is supported by Linux currently.
>>
>> Oh. It looks like I should have spent more time looking into this
>> spec. I did not notice that Confidence know has a palm rejection
>> meaning. Sigh. For touchscreens, this used to be that until the bit is
>> set, the touch might not be an actual touch...
>
> That's based only on the description at
> https://msdn.microsoft.com/en-us/library/windows/hardware/dn467314(v=vs.85).aspx
> saying "Set when a contact is too large to be a finger". I don't know
> if there's a more detailed spec somewhere; if there is, I haven't
> found it yet. It's strange that the sense would be inverted for
> touchpads vs touchscreens.
>
> Looking at the reports from events in debugfs, I do see confidence set
> to 0 when I use my palm and to 1 when I use a finger, so it seems like
> it would be useful for unintentional touch detection. Sadly no width,
> so user-driven tuning won't be possible. Too bad since it definitely
> doesn't catch all sorts of palm touches that I tested.

I tested changing the quirk from MT_QUIRK_IS_VALID_ALWAYS to
MT_QUIRK_VALID_IS_CONFIDENCE and that seems to work.

>>>
>>> In trying to figure this out, I looked at the HID descriptor and
>>> noticed that it's not reporting itself as a PTP but rather as a mouse.
>>> This is actually as expected for an PTP compliant device which hasn't
>>> been initialized fully - according to
>>> https://msdn.microsoft.com/en-us/library/windows/hardware/dn467314(v=vs.85).aspx
>>> devices are supposed to use the Mouse Collection for input reporting
>>> until the input mode is set to touchpad, after which they're supposed
>>> to switch to the Windows Precision Touchpad Collection.
>>>
>>> It looks like the hid-multitouch driver generally doesn't set the
>>> input mode on devices to MT_INPUTMODE_TOUCHPAD (0x3). By default it
>>> sets it to MT_INPUTMODE_TOUCHSCREEN (0x2) in mt_probe. It does also
>>> set it to MT_INPUTMODE_TOUCHAD (0x3) in mt_touch_input_mapping, though
>>> I haven't traced through to see if that actually gets written out to
>>> the device or is just used by the driver to determine how to interpret
>>> various events.
>>
>> Well, we do not export the mouse collection, so I can guarantee that
>> we are using the PTP collection :)
>> You can also be sure by checking at the input node, by running
>> evemu-record, and you'll see that we forward the raw touches (like a
>> touchscreen), and not the relative axes (like any plain mouse).
>>>
>>> Have I missed something? Is it actually being initialized to PTP mode
>>> and rdesc just isn't being updated? That would probably lead to
>>> misinterpreting some events since the event collections are very
>>> different, so it seems unlikely. Is there some condition under which
>>> it does get initialized to PTP mode?
>>
>> No, I think you misread the report descriptors. There should be at
>> least 2 collections, one for the mouse and one for the raw touchpad.
>> We do not change the report descriptors in hid-multitouch so it should
>> still be there.
>
> It's true, I do see ABS_X/Y and ABS_MT_POSITION_X/Y. You're right - I
> was confused by the continued presence of the mouse collection. Which
> I shouldn't have been, since there's one in MS's example, though at
> the end rather than the beginning as it is for my device. Sorry, I'm
> new to reading HID descriptors. I'm not sure how the driver is telling
> it the right mode, but it seems to be. I don't ever see the driver
> issuing an input mode feature report to the touchpad when I load
> i2c_hid with debug=1, though. It could be that the firmware and
> platform designers have special cased Linux in some way. Or I could be
> misreading the logs. Regardless, it gets figured out somehow. I do
> wonder if it might have a "PTP" and "actually talking to Windows PTP"
> mode. The amount of other hardware on this system that has some
> detection of Linux vs. Windows is remarkable, so Synaptics having some
> special case for Linux wouldn't surprise me at all.

I just realized my mistake here - the debug output of i2c_hid is
frequently cut off. I was depending on it being accurate. That led to
me thinking the report descriptor contained only the mouse collection
at first, but it in fact contains all of the collections. Then in
mt_touch_input_mapping the touchpad collection is recognized and the
input mode is set appropriately. There is a deceptively incomplete
comment there saying "Model touchscreens providing buttons as
touchpads", but that's not all the following code does.

It is actually set to MT_INPUTMODE_TOUCHPAD in mt_touch_input_mapping,
and I now see how it's writing it as that debug line, at least, is not
too long.

Michael

>>>
>>> If I'm right and this mode just isn't supported currently, is anyone
>>> working on this functionality? I'd rather not duplicate effort.
>>
>> The chromium guys just got their MT_TOOL_PALM patch merged in Dmitri's tree:
>> https://git.kernel.org/cgit/linux/kernel/git/dtor/input.git/commit/?h=for-linus&id=a736775db683174269c65c7c5cc8e5ee534e7681
>>
>> I don't know if they plan to make hid-multitouch aware of it, but that
>> seems legitimate to me.
>> You are welcome to work on such patches :)
>
> I thought that was just for one particular piece of hardware that was
> going to send that tool explicitly. I'll take a closer look at what
> they're doing, thanks.
>
> Cheers,
> Michael

Re: Re: Windows Precision Touchpad support

[Mario Limonciello]

Hi Michael,

On 03/29/2015 10:23 AM, Michael Leuchtenburg wrote:
>
> It's true, I do see ABS_X/Y and ABS_MT_POSITION_X/Y. You're right - I
> was confused by the continued presence of the mouse collection. Which
> I shouldn't have been, since there's one in MS's example, though at
> the end rather than the beginning as it is for my device. Sorry, I'm
> new to reading HID descriptors. I'm not sure how the driver is telling
> it the right mode, but it seems to be. I don't ever see the driver
> issuing an input mode feature report to the touchpad when I load
> i2c_hid with debug=1, though. It could be that the firmware and
> platform designers have special cased Linux in some way. Or I could be
> misreading the logs. Regardless, it gets figured out somehow. I do
> wonder if it might have a "PTP" and "actually talking to Windows PTP"
> mode. The amount of other hardware on this system that has some
> detection of Linux vs. Windows is remarkable, so Synaptics having some
> special case for Linux wouldn't surprise me at all.
I checked with some of the team on this recently.  There is a pin that 
is brought high or low based on whether the device should try to come up 
in PTP mode.  If it fails to come up in PTP mode it will fall back to a 
non-PTP mode but then you are using it over a completely different 
interface (PS2).

It's not a matter of some special Linux/Windows detection.


I was curious though, did you make more luck on palm rejection with the 
confidence bit?