From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Nocera Subject: Re: [RFC PATCH] input: Add disable sysfs entry for every input device Date: Tue, 03 Jan 2017 12:21:21 +0100 Message-ID: <1483442481.2420.12.camel@hadess.net> References: <1482660296-8432-1-git-send-email-pali.rohar@gmail.com> <1483370825.2420.8.camel@hadess.net> <201701021809.58943@pali> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Return-path: Received: from slow1-d.mail.gandi.net ([217.70.178.86]:40859 "EHLO slow1-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758042AbdACLbH (ORCPT ); Tue, 3 Jan 2017 06:31:07 -0500 In-Reply-To: <201701021809.58943@pali> Sender: linux-input-owner@vger.kernel.org List-Id: linux-input@vger.kernel.org To: Pali =?ISO-8859-1?Q?Roh=E1r?= Cc: Dmitry Torokhov , Sebastian Reichel , Pavel Machek , Mauro Carvalho Chehab , Chuck Ebbert , Henrik Rydberg , Ivaylo Dimitrov , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org 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.