linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Peter Hutterer <peter.hutterer@who-t.net>
Cc: "Pali Rohár" <pali.rohar@gmail.com>,
	"Bastien Nocera" <hadess@hadess.net>,
	"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
	"Ivaylo Dimitrov" <ivo.g.dimitrov.75@gmail.com>,
	"Sebastian Reichel" <sre@kernel.org>,
	"Mauro Carvalho Chehab" <mchehab@osg.samsung.com>,
	"Chuck Ebbert" <cebbert.lkml@gmail.com>,
	"Henrik Rydberg" <rydberg@euromail.se>,
	linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] input: Add disable sysfs entry for every input device
Date: Sat, 17 Feb 2018 22:19:14 +0100	[thread overview]
Message-ID: <20180217211914.GB9640@amd> (raw)
In-Reply-To: <20180109020424.GC29886@jelly>

[-- Attachment #1: Type: text/plain, Size: 2334 bytes --]

Hi!

> > > > So, do you mean to implement this "disable" action as ioctl for
> > > > particular /dev/input/event* device (instead of sysfs entry)?
> > > 
> > > Yes, so the device can be powered down without the device node being
> > > closed and made unavailable. I don't know whether that's something
> > > that's already possible for all cases, but there's already
> > > opportunistic in a lot of drivers and subsystems.
> > > 
> > > This opens up a whole new wave of potential problems, but it's a more
> > > generally useful mechanism, I would think.
> > 
> > Ok. How should API for this ioctl looks like? And do you have an idea
> > for name of that ioctl?
> > 
> > Dmitry, what do you think about it? It is acceptable for you?
> 
> first: sysfs files are pretty terrible because writing to them requires root
> and we don't have the benefit of logind. so for any sysfs toggle expect
> a nicely integrated userspace solution to be less than optimal.

Well, you can chmod / chown sysfs files.

> besides: 99% of the above is figuring out the policy *when* to disable the
> device. disabling it is trivial by just closing the evdev nodes and tbh I
> don't think we (in userspace) should care about whether the device is
> powered down or now, it should be the default assumption that it is powered
> down when not in use.
> 
> for the cases where you must keep the device open but you don't want events, 
> EVIOCSMASK is likely the best solution. improving the kernel so it powers
> down the device when the mask excludes all events (and there are no other
> listeners) could be an interesting task.

But yes, that sounds like an idea.

BTW in the meantime, someone added this to pmos wiki... this should
solve some of my problems.

Best regards,
								Pavel



FILE=~/.screenoff
if [ -f $FILE ]; then
 xinput set-prop 8 "Device Enabled" 1
 xinput set-prop 6 "Device Enabled" 1
 xinput set-prop 9 "Device Enabled" 1
 xset dpms force on
 rm ~/.screenoff
else
 xinput set-prop 8 "Device Enabled" 0
 xinput set-prop 6 "Device Enabled" 0
 xinput set-prop 9 "Device Enabled" 0
 xset dpms force off
 touch ~/.screenoff
fi
					

    
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

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

  reply	other threads:[~2018-02-17 21:19 UTC|newest]

Thread overview: 20+ 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
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 [this message]
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=20180217211914.GB9640@amd \
    --to=pavel@ucw.cz \
    --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=pali.rohar@gmail.com \
    --cc=peter.hutterer@who-t.net \
    --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;
as well as URLs for NNTP newsgroup(s).