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

From: Pali RohÃr
Date: Mon Jan 02 2017 - 12:32:05 EST


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.