linux-kernel - Re: [PATCH v3 11/13] HID: hid-multitouch: support for hovering devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 13 Nov 2012 19:08:55 +0100
From:	Benjamin Tissoires <benjamin.tissoires@...il.com>
To:	Henrik Rydberg <rydberg@...omail.se>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Jiri Kosina <jkosina@...e.cz>,
	Stephane Chatty <chatty@...c.fr>, linux-input@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 11/13] HID: hid-multitouch: support for hovering devices

On Tue, Nov 13, 2012 at 7:04 PM, Henrik Rydberg <rydberg@...omail.se> wrote:
> Hi Benjamin,
>
>> > Why [-1,1] here?
>>
>> At first, I only used [0,1]. However, it's still the same problem with
>> the information being kept between the touches:
>> if you start an application after having touched your device, you
>> normally have to ask for the different per-touche states to get x, y,
>> distance, pressure, etc...
>> However, this is not much mandatory because the protocol in its
>> current form ensures that you will get the new states of the axes when
>> a new touch occurs.
>
> Right, the stateful communication requires a full state read after
> opening the deivce, although in most cases this is not really
> necessary. This is no different for ABS_MT_DISTANCE, of course.
>
>> ABS_MT_DISTANCE is a little bit different here because the protocol
>> guarantees that once you get the "not in range" state through
>> tracking_id == -1, distance should be 1.
>> When the new touch of the very same slot occurs, you also have the
>> guarantee that distance is at 1 too.
>
> ABS_MT_DISTANCE is just another attribute of the slot, so it really is
> no different.
>
>> So basically, if you don't ask for the slot states, you will never get
>> that very first distance.
>
> Which will not be important either; as long as the slot is unused, it
> does not matter what the attributes of that slot are.

And if the slot is unused, but has been used since the plug of the
device, the state is kept between the touch.

>
>> I know that it's a user-space problem, but honestly, I don't want to
>> fix several user-space problems when we could fix it through the
>> protocol.
>>
>> I can see 2 solutions:
>> - set the range to: [0,1] and still sending -1 (or 2) for the invalid
>> distance value (if it's not clamped)
>> - set the range to: [0,2] and having: 0 for touch, 1 for hovering, and
>> 2 for not in range
>>
>> Does that make sense?
>
> I just do not see what problem you want to solve here.

I just intend to force the update of the distance value at the
beginning of the touch.
This is just to send a coherent state when the finger goes in range,
and to make sure that user-space application do not rely on the
undefined value (0) whereas the kernel thought it was set to 1.

Cheers,
Benjamin

>
> Thanks,
> Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/