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.
