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

[Pali RohÃr]

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@xxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part.