All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Echtler <floe@butterbrot.org>
To: Peter Hutterer <peter.hutterer@who-t.net>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
	linux-input <linux-input@vger.kernel.org>,
	"modin@yuri.at" <modin@yuri.at>
Subject: Re: [PATCH 2/2] skip all blobs that are not touches
Date: Fri, 14 Jul 2017 11:28:03 +0200	[thread overview]
Message-ID: <7f9ca984-2798-b3f1-f61a-ac80e5b055b9@butterbrot.org> (raw)
In-Reply-To: <20170714082406.GA29703@jelly>


[-- Attachment #1.1: Type: text/plain, Size: 1861 bytes --]

On 14.07.2017 10:24, Peter Hutterer wrote:
> On Fri, Jul 14, 2017 at 09:54:03AM +0200, Florian Echtler wrote:
>> On Mon, 10 Jul 2017, Dmitry Torokhov wrote:
>>> On Mon, Jul 10, 2017 at 09:11:53AM +0200, Florian Echtler wrote:
>>>>
>>>> Related question: we first attempted to label non-touch objects as MT_TOOL_PALM,
>>>> but it looks like userspace (Xorg in particular) doesn't actually distinguish
>>>> between MT_TOOL_* types; is that correct?
>>>
>>> It really should, but I think Peter never got around implementing this.
>>>
>>> Also, I think it is a good idea to set touch major to max in this case.
>>> I believe that that will help clients that do no understand MT_TOOL_PALM
>>> to still do palm rejection.
>>>
>>> Peter?
>>
>> Would you consider merging v2 of the patch regardless of the Xorg situation?
>> Right now, it's a useful bugfix in any case, and we can deal with how to
>> represent blobs/palms/tokens later on.
> 
> sorry about the delay, bit chaotic here. libinput 1.8 was released a week or
> so ago and it supports MT_TOOL_PALM, so consider userspace ready for that. I
> also have patches to use major/minor for palm detection where appropriate
> which will hit git master (my) tonight.

Nevermind :-) Just to clarify, I can now set MT_TOOL_PALM on generic blob
objects, and they will still be available in userspace "on request", but will
not be considered as touch points?

Do you know how "legacy" xserver-xorg-input-evdev will handle this case?

And final question: the SUR40 also is able to identify specific patterns as
tokens (so-called "bytetags", see
https://github.com/floe/surface-2.0/blob/master/bytetag/bytetag.pdf ). What
would be a sensible way to expose these to userspace, too? Add another
MT_TOOL_TOKEN type?

Thanks & best regards, Florian
-- 
SENT FROM MY DEC VT50 TERMINAL


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2017-07-14  9:28 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-09 18:54 [PATCH 1/2] add additional reverse-engineered information Florian Echtler
2017-07-09 18:54 ` [PATCH 2/2] skip all blobs that are not touches Florian Echtler
2017-07-09 21:41   ` Dmitry Torokhov
2017-07-10  7:11     ` Florian Echtler
2017-07-10 18:11       ` Dmitry Torokhov
2017-07-14  7:54         ` Florian Echtler
2017-07-14  8:24           ` Peter Hutterer
2017-07-14  9:28             ` Florian Echtler [this message]
2017-07-14 22:13               ` Peter Hutterer
2017-07-09 21:40 ` [PATCH 1/2] add additional reverse-engineered information Dmitry Torokhov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7f9ca984-2798-b3f1-f61a-ac80e5b055b9@butterbrot.org \
    --to=floe@butterbrot.org \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=modin@yuri.at \
    --cc=peter.hutterer@who-t.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.