[RFC PATCH] input: Add disable sysfs entry for every input device

[RFC PATCH] input: Add disable sysfs entry for every input device

[Pali Rohár]

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 <pali.rohar@gmail.com>
---
 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

Re: [RFC] input: Add disable sysfs entry for every input device

[Nikita Yushchenko]

Hi

>  	&dev_attr_properties.attr,
> +	&dev_arrr_disable.attr,

Typo here.

After fixing that,

Tested-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>

Re: [RFC PATCH] input: Add disable sysfs entry for every input device

[Bastien Nocera]

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.

What happens when a device is opened and the device disabled through
sysfs, are the users revoked?

Does this put the device in suspend in the same way that closing the
device's last user does?

Is this not better implemented in user-space at the session level,
where it knows about which output corresponds to which input device?

Is this useful enough to disable misbehaving devices on hardware, so
that the device is not effective on boot?

> 
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> ---
>  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)
>  

Re: [RFC PATCH] input: Add disable sysfs entry for every input device

[Pali Rohár]

[-- 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 --]

Re: [RFC PATCH] input: Add disable sysfs entry for every input device

[Bastien Nocera]

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. Whether it's X.org, or a Wayland compositor. Even David's
 https://github.com/dvdhrm/kmscon could help for console applications.

Re: [RFC PATCH] input: Add disable sysfs entry for every input device

[Ivaylo Dimitrov]

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/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. 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.

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.

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.

Ivo

Re: [RFC PATCH] input: Add disable sysfs entry for every input device

[Bastien Nocera]

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.

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.

> 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.

> 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.

Re: [RFC PATCH] input: Add disable sysfs entry for every input device

[Pali Rohár]

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.

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
pali.rohar@gmail.com

Re: [RFC PATCH] input: Add disable sysfs entry for every input device

[Peter Hutterer]

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
> pali.rohar@gmail.com
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [RFC PATCH] input: Add disable sysfs entry for every input device

[Pali Rohár]

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
pali.rohar@gmail.com

Re: [RFC PATCH] input: Add disable sysfs entry for every input device

[Bastien Nocera]

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.

Re: [RFC PATCH] input: Add disable sysfs entry for every input device

[Pali Rohár]

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
pali.rohar@gmail.com

Re: [RFC PATCH] input: Add disable sysfs entry for every input device

[Peter Hutterer]

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

Re: [RFC PATCH] input: Add disable sysfs entry for every input device

[Pavel Machek]

[-- 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 --]

Re: [RFC PATCH] input: Add disable sysfs entry for every input device

[Peter Hutterer]

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

Re: [RFC PATCH] input: Add disable sysfs entry for every input device

[Pavel Machek]

Hi!

> > > > 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.

> > 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.

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".

Best regards,
									Pavel

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

Re: [RFC PATCH] input: Add disable sysfs entry for every input device

[Bastien Nocera]

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.

Re: [RFC PATCH] input: Add disable sysfs entry for every input device

[Pali Rohár]

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
pali.rohar@gmail.com

Re: [RFC PATCH] input: Add disable sysfs entry for every input device

[Bastien Nocera]

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.

Re: [RFC PATCH] input: Add disable sysfs entry for every input device

[David Herrmann]

Hi

On Sun, Dec 25, 2016 at 11:04 AM, Pali Rohár <pali.rohar@gmail.com> 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
>
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> ---
>  drivers/input/input.c |   35 +++++++++++++++++++++++++++++++++++
>  include/linux/input.h |    4 ++++
>  2 files changed, 39 insertions(+)

Don't open the device, if you don't want events from it. Really.

I assume the reason behind this is that you don't know how to make
your user-space ignore devices. But with this patch in place, you now
end up with user-space trying to use the device, but not getting any
events. Anyone trying to debug this will go nuts because the setup
looks like the device is used, but ends up being muted.

I strongly recommend improving your user-space code to do what you
want it to do (meaning, make your user-space be configurable, if you
need this).

Btw., as a workaround, you can always disable input-drivers that you
don't want. Or you can run EVIOCGRAB on a device to get the same
effect as your patch.

Thanks
David

> 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH] input: Add disable sysfs entry for every input device

[Pali Rohár]

[-- Attachment #1: Type: Text/Plain, Size: 3265 bytes --]

On Monday 02 January 2017 17:44:38 David Herrmann wrote:
> Don't open the device, if you don't want events from it. Really.

There are existing applications which are doing it. This advice is good 
but not for past.

> I assume the reason behind this is that you don't know how to make
> your user-space ignore devices.

Yes.

And another reason is to disable particular keyboard in linux tty 
console.

> But with this patch in place, you now
> end up with user-space trying to use the device, but not getting any
> events.

Exactly. Same situation as if input device does not generate any event.

> Anyone trying to debug this will go nuts because the setup
> looks like the device is used, but ends up being muted.

Such argument can be used in any situation.

E.g. I own file on disk with executable bit and I cannot execute it. 
Looks like bug, but instead selinux policy.

Proper way is to fully document behaviour and configuration. Situation 
that somebody is something expecting and have not read needed 
documentation and already started something debugging is wrong.

> I strongly recommend improving your user-space code to do what you
> want it to do (meaning, make your user-space be configurable, if you
> need this).

Problem with integrated notebook keyboard which press some buttons in 
linux tty console cannot be fixed in user-space.

But, my original motivation about this disabling input devices is for 
tsc2005 touchscreen on Nokia N900.

There is existing userspace code for Nokia N900, some is closed & 
proprietary (so not possible to modify or change or fix) which already 
expects that kernel provide "disable" sysfs option for tsc2005 
touchscreen. But that sysfs entry was removed in commit 
5cb81d19bae47adcb073a5e5a3bc40dd252f239e and userspace stopped 
working...

Such problems are hard to fix now, but what we can see is that any 
userspace application can open input device and let it open for its own 
and process events which read. It is fully valid code and fully correct.

Just user and admin too cannot force kernel to stop sending events to 
application in specific cases when those events are either invalid or 
nor events which applications expect in current state.

And this is reason why I chose and suggest to have some option which 
"mute" input device. And which should be used when user knows that 
events should not be generated by input kernel driver or when nobody 
should read them.

> Btw., as a workaround, you can always disable input-drivers that you
> don't want.

No, you cannot. If you connect external PS/2 keyboard to notebook with 
broken integrated keyboard, then both devices are handled by one driver.

Also in some cases userspace application may expect that input device 
will exists and would not work without it. E.g. when you want to disable 
input device temporary, just when notebook LID is closed or when screen 
is locked (on touchscreen).

> Or you can run EVIOCGRAB on a device to get the same
> effect as your patch.

Next part is to implement runtime pm or autosuspend of device. So this 
will break pm. And also will break applications which grab device 
itself.

-- 
Pali Rohár
pali.rohar@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]