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
Signed-off-by: Pali Rohár <[email protected]>
---
drivers/input/input.c | 35 +++++++++++++++++++++++++++++++++++
include/linux/input.h | 4 ++++
2 files changed, 39 insertions(+)
diff --git a/drivers/input/input.c b/drivers/input/input.c
index d95c34e..9f0da7e 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -430,6 +430,9 @@ void input_event(struct input_dev *dev,
{
unsigned long flags;
+ if (unlikely(dev->disabled))
+ return;
+
if (is_event_supported(type, dev->evbit, EV_MAX)) {
spin_lock_irqsave(&dev->event_lock, flags);
@@ -457,6 +460,9 @@ void input_inject_event(struct input_handle *handle,
struct input_handle *grab;
unsigned long flags;
+ if (unlikely(dev->disabled))
+ return;
+
if (is_event_supported(type, dev->evbit, EV_MAX)) {
spin_lock_irqsave(&dev->event_lock, flags);
@@ -1389,12 +1395,41 @@ static ssize_t input_dev_show_properties(struct device *dev,
}
static DEVICE_ATTR(properties, S_IRUGO, input_dev_show_properties, NULL);
+static ssize_t input_dev_show_disable(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct input_dev *input_dev = to_input_dev(dev);
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", input_dev->disabled ? 1 : 0);
+}
+static ssize_t input_dev_store_disable(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct input_dev *input_dev = to_input_dev(dev);
+ int disable;
+ int ret;
+
+ ret = kstrtoint(buf, 0, &disable);
+ if (ret)
+ return ret;
+
+ if (disable != 0 && disable != 1)
+ return -EINVAL;
+
+ input_dev->disabled = disable;
+ return count;
+}
+static DEVICE_ATTR(disable, S_IRUGO | S_IWUSR, input_dev_show_disable, input_dev_store_disable);
+
static struct attribute *input_dev_attrs[] = {
&dev_attr_name.attr,
&dev_attr_phys.attr,
&dev_attr_uniq.attr,
&dev_attr_modalias.attr,
&dev_attr_properties.attr,
+ &dev_arrr_disable.attr,
NULL
};
diff --git a/include/linux/input.h b/include/linux/input.h
index a65e3b2..e390b56 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -117,6 +117,8 @@ struct input_value {
* @vals: array of values queued in the current frame
* @devres_managed: indicates that devices is managed with devres framework
* and needs not be explicitly unregistered or freed.
+ * @disabled: indicates that device is in disabled state and kernel drop
+ * all events from it
*/
struct input_dev {
const char *name;
@@ -187,6 +189,8 @@ struct input_dev {
struct input_value *vals;
bool devres_managed;
+
+ bool disabled;
};
#define to_input_dev(d) container_of(d, struct input_dev, dev)
--
1.7.9.5
Hi
> &dev_attr_properties.attr,
> + &dev_arrr_disable.attr,
Typo here.
After fixing that,
Tested-by: Nikita Yushchenko <[email protected]>
On Tuesday 03 January 2017 12:21:21 Bastien Nocera wrote:
> On Mon, 2017-01-02 at 18:09 +0100, Pali Rohár wrote:
> > 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.
>
> There's usually a display manager in between the application and the
> input device.
But that is not always truth. In some cases there are applications which
opens input device directly.
> Whether it's X.org, or a Wayland compositor. Even David's
> https://github.com/dvdhrm/kmscon could help for console applications.
That kmscon needs KMS, right? So it would not work on hardware which do
not have KMS drivers.
--
Pali Rohár
[email protected]
On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote:
> I don't doubt that the use cases should be catered for, I essentially
> did that same work without kernel changes for GNOME. What I doubt is
> the fuzzy semantics, the fact that the device is kept opened but no
> data is sent (that's not power saving), that whether users are revoked
> or should be revoked isn't clear, and that the goal is basically to
> work around stupid input handling when at the console. When running a
> display manager, this is all avoided.
>
> If this were to go through, then the semantics and behaviour needs to
> be better explained, power saving actually made possible, and make sure
> that libinput can proxy that state to the users on the console. Or an
> ioctl added to the evdev device to disable them.
So, do you mean to implement this "disable" action as ioctl for
particular /dev/input/event* device (instead of sysfs entry)?
--
Pali Rohár
[email protected]
On Tue, 2017-01-17 at 12:07 +0100, Pavel Machek wrote:
>
<snip>
> We'd really like it to work on plain old text console, too, because
> that's what
> I'm using on n900, and with old maemo userspace, because that's what
> everyone
> else uses.
>
> You mentioned you think X.org can do this kind of device disabling
> (and powersave).
> Would you have an idea how to activate that? I'd like to disable
> touchscreen
> and most of the buttons when the device is "in the pocket".
You need to change the "Device Enabled" property in X. What this does
depends on which Xorg driver it uses.
On Tue, 2018-01-02 at 22:48 +0100, Pali Rohár wrote:
> On Tuesday 03 January 2017 12:21:21 Bastien Nocera wrote:
> > On Mon, 2017-01-02 at 18:09 +0100, Pali Rohár wrote:
> > > 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/9
> > > > > 2
> > > >
> > > >
> > > > 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.
> >
> > There's usually a display manager in between the application and
> > the
> > input device.
>
> But that is not always truth. In some cases there are applications
> which
> opens input device directly.
Which is why I said "usually", and not "always".
> > Whether it's X.org, or a Wayland compositor. Even David's
> > https://github.com/dvdhrm/kmscon could help for console
> > applications.
>
> That kmscon needs KMS, right? So it would not work on hardware which
> do
> not have KMS drivers.
Except that the use cases are getting smaller and smaller. At one
point, it might become easier to carry that patch in your tree, for
your use case.
It's not useful on desktop Linux, it's not useful for Android or Chrome
OS. It seems it's only really useful for the console when there's no
way to use a display manager between the console subsystem and the
"UI".
At this point I'd ask whether whatever is consuming those buttons can't
be modified instead of the kernel. You'd even get the benefit of being
able to close devices and save some power.
On Tue, 2018-01-02 at 22:54 +0100, Pali Rohár wrote:
> On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote:
> > I don't doubt that the use cases should be catered for, I
> > essentially
> > did that same work without kernel changes for GNOME. What I doubt
> > is
> > the fuzzy semantics, the fact that the device is kept opened but no
> > data is sent (that's not power saving), that whether users are
> > revoked
> > or should be revoked isn't clear, and that the goal is basically to
> > work around stupid input handling when at the console. When running
> > a
> > display manager, this is all avoided.
> >
> > If this were to go through, then the semantics and behaviour needs
> > to
> > be better explained, power saving actually made possible, and make
> > sure
> > that libinput can proxy that state to the users on the console. Or
> > an
> > ioctl added to the evdev device to disable them.
>
> 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.
On Wednesday 03 January 2018 02:47:29 Bastien Nocera wrote:
> On Tue, 2018-01-02 at 22:54 +0100, Pali Rohár wrote:
> > On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote:
> > > I don't doubt that the use cases should be catered for, I
> > > essentially
> > > did that same work without kernel changes for GNOME. What I doubt
> > > is
> > > the fuzzy semantics, the fact that the device is kept opened but no
> > > data is sent (that's not power saving), that whether users are
> > > revoked
> > > or should be revoked isn't clear, and that the goal is basically to
> > > work around stupid input handling when at the console. When running
> > > a
> > > display manager, this is all avoided.
> > >
> > > If this were to go through, then the semantics and behaviour needs
> > > to
> > > be better explained, power saving actually made possible, and make
> > > sure
> > > that libinput can proxy that state to the users on the console. Or
> > > an
> > > ioctl added to the evdev device to disable them.
> >
> > 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?
--
Pali Rohár
[email protected]
On Thu, Jan 05, 2017 at 01:48:08PM +0100, Pali Roh?r wrote:
> On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote:
> > On Wed, 2017-01-04 at 09:43 +0200, Ivaylo Dimitrov wrote:
> > >
> > > On??3.01.2017 13:21, Bastien Nocera wrote:
> > > > On Mon, 2017-01-02 at 18:09 +0100, Pali Roh?r wrote:
> > > > > 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/9
> > > > > > > 2
> > > > > >
> > > > > > 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.
> > > >
> > > > There's usually a display manager in between the application and
> > > > the
> > > > input device. Whether it's X.org, or a Wayland compositor. Even
> > > > David's
> > > > ?https://github.com/dvdhrm/kmscon could help for console
> > > > applications.
> > > >
> > >
> > > I think the use cases are not clearly explained, will try to:
> > >
> > > 1. Imagine you have a mobile phone, with a touchscreen, a slide?
> > > keyboard, a keyboard-slide sensor, a proximity sensor and a couple of?
> > > GPIOs, set-up as gpio keys. And you want to carry that phone in your?
> > > pocket, without being worried that it will pick-up an incoming call by?
> > > itself while in the pocket, so:
> > >
> > > - slide keyboard is closed, you "lock" the phone before put it in your?
> > > pocket - in that state, touchscreen and most of the gpio-keys should be?
> > > "disabled", so no touches are registered waking-up the device without need.
> > > - a call comes, proximity gets "enabled", but TS should stay disabled as?
> > > proximity detects "the phone is in a pocket"
> > > - you get your phone out of your pocket - proximity detects no more?
> > > obstacles, so now TS has to be enabled giving you a chance to pick up?
> > > the incoming call.
> > >
> > > "disabling" of gpio-keys is clear, but how to make TS and proximity?
> > > inactive when needed? Sure, touches can be simply ignored (by using?
> > > xinput "Device Enabled" 0 on x11), same for proximity, but keep in mind?
> > > this is a battery-operated device, so we don't want CPU wake-ups with no?
> > > need.
> >
> > I'm pretty certain that the libinput or evdev Xorg drivers would close
> > the underlying device?so that it can go into power save.
>
> When they close evdev device? At least I need to explicitly call xinput.
yeah, because setting that property is the way to tell X that we don't need
to listen for events on that device. so we close the fd. libinput has the
"send events" API which does the same in most cases.
the only other way to tell X that you don't care about events from devices
is to VT-switch away, then we also close all fds.
Cheers,
Peter
> And Xorg and libinput are not only applications/libraries which uses
> linux evdev. There are more...
>
> E.g. in case of N900 there is mce which is not doing it.
>
> > FWIW, your example is incomplete, as you'd probably want the
> > touchscreen to be usable even if the keyboard is folded in by pressing
> > the power button, and using the touchscreen only.
>
> Maybe with combination of ambient light sensor for detection if phone is
> in pocket or not...
>
> > > 2. The same device, "locked", but this time with slide keyboard opened:
> > >
> > > - both keyboard and TS should be "disabled" so no touches neither key?
> > > presses wake-up the system. Only the power-button (or some other,?
> > > doesn't matter) should be enabled to activate the device.
> >
> > Which is what disabling the device in Xorg should do.
>
> You are expecting here that only Xorg is used... which does not have to
> be truth (and in more cases really is not).
>
> > > There are more use-cases similar to the above as well as use-cases for?
> > > laptops, but I hope you're getting the idea.
> > >
> > > Also, the interface to "disable" an input devices should be independent?
> > > to whether you use X11, wayland or your application draws directly to?
> > > the framebuffer.
> >
> > I implemented behaviour similar to those at the session level, using D-
> > Bus to gather data from the various sensors and peripherals. In
> > addition, it also knows about the state of the display, which you
> > wouldn't have available at another level. This also means that it works
> > as expected for multi-user setups (which I understand isn't your
> > concern).
> >
> > I don't doubt that the use cases should be catered for, I essentially
> > did that same work without kernel changes for GNOME. What I doubt is
> > the fuzzy semantics, the fact that the device is kept opened but no
> > data is sent (that's not power saving), that whether users are revoked
> > or should be revoked isn't clear, and that the goal is basically to
> > work around stupid input handling when at the console. When running a
> > display manager, this is all avoided.
> >
> > If this were to go through, then the semantics and behaviour needs to
> > be better explained, power saving actually made possible, and make sure
> > that libinput can proxy that state to the users on the console. Or an
> > ioctl added to the evdev device to disable them.
>
> --
> Pali Roh?r
> [email protected]
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On Wed, Jan 03, 2018 at 10:31:33AM +0100, Pali Roh?r wrote:
> On Wednesday 03 January 2018 02:47:29 Bastien Nocera wrote:
> > On Tue, 2018-01-02 at 22:54 +0100, Pali Roh?r wrote:
> > > On Wednesday 04 January 2017 15:37:35 Bastien Nocera wrote:
> > > > I don't doubt that the use cases should be catered for, I
> > > > essentially
> > > > did that same work without kernel changes for GNOME. What I doubt
> > > > is
> > > > the fuzzy semantics, the fact that the device is kept opened but no
> > > > data is sent (that's not power saving), that whether users are
> > > > revoked
> > > > or should be revoked isn't clear, and that the goal is basically to
> > > > work around stupid input handling when at the console. When running
> > > > a
> > > > display manager, this is all avoided.
> > > >
> > > > If this were to go through, then the semantics and behaviour needs
> > > > to
> > > > be better explained, power saving actually made possible, and make
> > > > sure
> > > > that libinput can proxy that state to the users on the console. Or
> > > > an
> > > > ioctl added to the evdev device to disable them.
> > >
> > > 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.
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.
right now, I really question the need for another ioctl.
Cheers,
Peter
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
On Sat, Feb 17, 2018 at 10:19:14PM +0100, Pavel Machek wrote:
> 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.
and that's what I meant by "less than optimal" :)
you're either chmodding, or suid, or any of the other solutions that aren't
really good in the long run.
> > 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
xinput can resolve device names, using device ids is likely to cause upset.
http://who-t.blogspot.com/2016/07/xinput-resolves-device-names-and.html
Cheers,
Peter