From: "Pali Rohár" <pali.rohar@gmail.com>
To: Bastien Nocera <hadess@hadess.net>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>,
Sebastian Reichel <sre@kernel.org>, Pavel Machek <pavel@ucw.cz>,
Mauro Carvalho Chehab <mchehab@osg.samsung.com>,
Chuck Ebbert <cebbert.lkml@gmail.com>,
Henrik Rydberg <rydberg@euromail.se>,
Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] input: Add disable sysfs entry for every input device
Date: Mon, 2 Jan 2017 18:09:58 +0100 [thread overview]
Message-ID: <201701021809.58943@pali> (raw)
In-Reply-To: <1483370825.2420.8.camel@hadess.net>
[-- Attachment #1: Type: Text/Plain, Size: 2051 bytes --]
On Monday 02 January 2017 16:27:05 Bastien Nocera wrote:
> On Sun, 2016-12-25 at 11:04 +0100, Pali Rohár wrote:
> > This patch allows user to disable events from any input device so
> > events
> > would not be delivered to userspace.
> >
> > Currently there is no way to disable particular input device by
> > kernel.
> > User for different reasons would need it for integrated PS/2
> > keyboard or
> > touchpad in notebook or touchscreen on mobile device to prevent
> > sending
> > events. E.g. mobile phone in pocket or broken integrated PS/2
> > keyboard.
> >
> > This is just a RFC patch, not tested yet. Original post about
> > motivation
> > about this patch is there: https://lkml.org/lkml/2014/11/29/92
>
> Having implemented something of that ilk in user-space (we
> automatically disable touch devices when the associated screen is
> turned off/suspended), I think this might need more thought.
How to implement such thing in userspace? I think you cannot do that
without rewriting every one userspace application which uses input.
> What happens when a device is opened and the device disabled through
> sysfs, are the users revoked?
Applications will not receive events. Same as if input device does not
generates events.
> Does this put the device in suspend in the same way that closing the
> device's last user does?
Current code not (this is just RFC prototype), but it should be possible
to implement.
> Is this not better implemented in user-space at the session level,
> where it knows about which output corresponds to which input device?
How to do that without rewriting existing applications?
> Is this useful enough to disable misbehaving devices on hardware, so
> that the device is not effective on boot?
In case integrated device is absolutely unusable and generates always
random events, it does not solve problem at boot time.
But more real case is laptop with closed LID press buttons and here it
is useful.
--
Pali Rohár
pali.rohar@gmail.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2017-01-02 17:11 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-25 10:04 [RFC PATCH] input: Add disable sysfs entry for every input device Pali Rohár
2016-12-30 16:13 ` [RFC] " Nikita Yushchenko
2017-01-02 15:27 ` [RFC PATCH] " Bastien Nocera
2017-01-02 17:09 ` Pali Rohár [this message]
2017-01-03 11:21 ` Bastien Nocera
2017-01-04 7:43 ` Ivaylo Dimitrov
2017-01-04 14:37 ` Bastien Nocera
2017-01-05 12:48 ` Pali Rohár
2018-01-09 1:51 ` Peter Hutterer
2018-01-02 21:54 ` Pali Rohár
2018-01-03 1:47 ` Bastien Nocera
2018-01-03 9:31 ` Pali Rohár
2018-01-09 2:04 ` Peter Hutterer
2018-02-17 21:19 ` Pavel Machek
2018-02-18 22:50 ` Peter Hutterer
2017-01-17 11:07 ` Pavel Machek
2018-01-03 1:38 ` Bastien Nocera
2018-01-02 21:48 ` Pali Rohár
2018-01-03 1:43 ` Bastien Nocera
2017-01-02 16:44 ` David Herrmann
2017-01-02 17:31 ` Pali Rohár
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=201701021809.58943@pali \
--to=pali.rohar@gmail.com \
--cc=cebbert.lkml@gmail.com \
--cc=dmitry.torokhov@gmail.com \
--cc=hadess@hadess.net \
--cc=ivo.g.dimitrov.75@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@osg.samsung.com \
--cc=pavel@ucw.cz \
--cc=rydberg@euromail.se \
--cc=sre@kernel.org \
/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