linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Henrik Rydberg <rydberg@euromail.se>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Peter Hutterer <peter.hutterer@who-t.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
	Mika Kuoppala <mika.kuoppala@nokia.com>,
	Benjamin Tissoires <tissoire@cena.fr>,
	Stephane Chatty <chatty@enac.fr>,
	Rafi Rubin <rafi@seas.upenn.edu>,
	Michael Poole <mdpoole@troilus.org>
Subject: Re: [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2)
Date: Thu, 20 May 2010 12:46:17 +0200	[thread overview]
Message-ID: <4BF512F9.5010607@euromail.se> (raw)
In-Reply-To: <20100520071158.GC8080@core.coreip.homeip.net>

Dmitry Torokhov wrote:
>>>> Will all drivers with ABS_MT_TRACKING_ID use slots? if not, how can I know
>>>> in advance if a device may use slots or not?
>>> Eventually, this might become true, but you are pointing at one of the weaker
>>> points of the current setup. There is no bit field for the EV_SYN events, so
>>> there is no way to know in advance if SYN_MT_SYNC or SYN_MT_SLOT is used. This
>>> could quite possibly be added to the EVIO interface. Meanwhile, the method I use
>>> is to detect the first SYN_MT_SLOT and select parser based on that information.
>> I'd really prefer if there was some way to detect this. While I'm not quite
>> sure how the matching X drivers would look like it's likely that the setups
>> will be different for drivers that support slots and those that don't.
>> e.g. those that don't have slots simply send events as valuators, those that
>> do may split into multiple devices.
>>
>> Doing this at runtime - after the device has been set up is...tricky.
>>
> 
> Right, I think we should try our hardest to allow userspace base
> protocol decoding decisions on device capabilities and not the event
> datastream. What about moving from SYN_MT_SLOT to ABS_MT_SLOT? I think
> it makes more sense since it is not a simple marker but carries data
> (slot number).

I agree, it both makes sense and resolves two issues. Will change.

Cheers,
Henrik


  reply	other threads:[~2010-05-20 10:46 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-18 20:10 [PATCH] input: mt: Introduce MT event slots (rev 3) Henrik Rydberg
2010-05-18 20:10 ` [PATCH 2/2] input: mt: Document the MT event slot protocol (rev2) Henrik Rydberg
2010-05-19  2:37   ` Peter Hutterer
2010-05-19 12:12     ` Henrik Rydberg
2010-05-20  0:13       ` Peter Hutterer
2010-05-20  7:11         ` Dmitry Torokhov
2010-05-20 10:46           ` Henrik Rydberg [this message]
2010-05-20 10:40         ` Henrik Rydberg
2010-05-24  4:58           ` Peter Hutterer
2010-05-24  6:07             ` Ping Cheng
2010-05-24 10:03               ` Henrik Rydberg
2010-05-24 15:59               ` Dmitry Torokhov
2010-05-24 17:06                 ` Ping Cheng
2010-05-24 17:21                   ` Dmitry Torokhov
2010-05-24 17:33                     ` Ping Cheng
2010-05-24 17:48                     ` Henrik Rydberg
2010-05-24 18:04                       ` Dmitry Torokhov
2010-05-24 19:19                         ` Henrik Rydberg
2010-05-19 22:43   ` Ping Cheng
2010-05-19 23:34     ` Rafi Rubin
2010-05-20  0:13       ` Ping Cheng
2010-05-20  0:26         ` Rafi Rubin
2010-05-20  0:51           ` Ping Cheng
2010-05-20  1:03             ` Rafi Rubin
2010-05-20  4:18               ` Ping Cheng
2010-05-20  0:21       ` Peter Hutterer
2010-05-20  0:34         ` Rafi Rubin
2010-05-20  7:08     ` Henrik Rydberg
2010-05-20 22:19       ` Ping Cheng
2010-05-20 22:48         ` Henrik Rydberg
2010-05-21  3:35           ` Ping Cheng
2010-05-21 15:19         ` Rafi Rubin
2010-05-21 15:40           ` Ping Cheng
2010-05-21 21:25             ` Henrik Rydberg
2010-05-22  3:10               ` Ping Cheng
2010-05-24  5:25               ` Peter Hutterer
2010-05-24  5:48                 ` Ping Cheng
2010-05-24  6:15                   ` Peter Hutterer
2010-05-24  9:49                     ` Henrik Rydberg

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=4BF512F9.5010607@euromail.se \
    --to=rydberg@euromail.se \
    --cc=akpm@linux-foundation.org \
    --cc=chatty@enac.fr \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mdpoole@troilus.org \
    --cc=mika.kuoppala@nokia.com \
    --cc=peter.hutterer@who-t.net \
    --cc=rafi@seas.upenn.edu \
    --cc=tissoire@cena.fr \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).