All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chase Douglas <chase.douglas@canonical.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benjamin Tissoires <benjamin.tissoires@gmail.com>,
	Henrik Rydberg <rydberg@euromail.se>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state
Date: Fri, 06 Jan 2012 10:56:46 -0800	[thread overview]
Message-ID: <4F0743EE.6080302@canonical.com> (raw)
In-Reply-To: <20120106181845.GA22653@core.coreip.homeip.net>

On 01/06/2012 10:18 AM, Dmitry Torokhov wrote:
> Hi Benjamin,
> 
> On Fri, Jan 06, 2012 at 07:00:22PM +0100, Benjamin Tissoires wrote:
>> Hi guys,
>> I read somewhere in the code of Android a comment in which they
>> complain about not being able to retrieve the slots states. So they
>> assume they are all at 0.
>> So this mechanism is good to have.
>> However, back in January 2011, Dmitry raised the problem that this
>> code was not thread safe.What happens if 2 applications ask for
>> different slots values (let say X.org and utouch-frame)?
> 
> 2 different processes should be fine; the problem would be if 2 threads
> of the same process share the same file descriptor. So far the rest of
> evdev copes just fine with multiple threads using the same fd (all
> operations are atomic in this regard), setting ABS_MT_SLOT before
> fetching the state break this property.

How is this any different than two threads trying to set a different
property, like the fuzz factor of an axis? This seems like something
that should be guarded by a lock in userspace, essentially.

-- Chase

  parent reply	other threads:[~2012-01-06 18:55 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-06 15:16 [PATCH v2] Input: evdev - Add EVIOC mechanism to extract the MT slot state Henrik Rydberg
2012-01-06 16:25 ` Chase Douglas
2012-01-06 18:00 ` Benjamin Tissoires
2012-01-06 18:00   ` Benjamin Tissoires
2012-01-06 18:18   ` Dmitry Torokhov
2012-01-06 18:55     ` Henrik Rydberg
2012-01-06 19:18       ` Henrik Rydberg
2012-01-06 19:34         ` Chase Douglas
2012-01-06 19:48           ` Henrik Rydberg
2012-01-06 20:02             ` Dmitry Torokhov
2012-01-06 20:14               ` Henrik Rydberg
2012-01-06 20:23                 ` Dmitry Torokhov
2012-01-06 20:30                   ` Henrik Rydberg
2012-01-06 20:03           ` Dmitry Torokhov
2012-01-06 18:56     ` Chase Douglas [this message]
2012-01-06 19:58       ` Dmitry Torokhov
2012-01-06 20:09         ` Chase Douglas
2012-01-06 20:17           ` Dmitry Torokhov
2012-01-06 20:44             ` Chase Douglas
2012-01-06 18:45   ` 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=4F0743EE.6080302@canonical.com \
    --to=chase.douglas@canonical.com \
    --cc=benjamin.tissoires@gmail.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rydberg@euromail.se \
    /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.