| Message ID | 1482660296-8432-1-git-send-email-pali.rohar@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi > &dev_attr_properties.attr, > + &dev_arrr_disable.attr, Typo here. After fixing that, Tested-by: Nikita Yushchenko <nikita.yoush@cogentembedded.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
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) > -- 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
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 -- 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
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.
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.
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. -- 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
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 -- 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
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. -- 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
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.
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
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.
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)?
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. -- 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
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. -- 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
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. -- 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
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?
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 > -- 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
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 -- 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
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
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 -- 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
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)
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(+)