All of lore.kernel.org
 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: 49+ 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: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:13         ` Ping Cheng
2010-05-20  0:26         ` Rafi Rubin
2010-05-20  0:51           ` Ping Cheng
2010-05-20  0:51             ` Ping Cheng
2010-05-20  1:03             ` Rafi Rubin
2010-05-20  4:18               ` Ping Cheng
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:19         ` Ping Cheng
2010-05-20 22:48         ` Henrik Rydberg
2010-05-21  3:35           ` Ping Cheng
2010-05-21  3:35             ` Ping Cheng
2010-05-21 15:19         ` Rafi Rubin
2010-05-21 15:19           ` Rafi Rubin
2010-05-21 15:40           ` Ping Cheng
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  5:48                   ` Ping Cheng
2010-05-24  6:15                   ` Peter Hutterer
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 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.