Hi, On Mon, Aug 28, 2017 at 02:08:54PM -0700, Roderick Colenbrander wrote: > On Fri, Aug 25, 2017 at 1:45 AM, Bastien Nocera <hadess@xxxxxxxxxx> wrote: > > On Thu, 2017-08-24 at 16:11 -0700, Roderick Colenbrander wrote: > >> From: Roderick Colenbrander <roderick.colenbrander@xxxxxxxx> > >> > >> This new property can be set on input devices to blacklist them > >> from getting picked up by joydev. This is meant for devices, which > >> pass joydev its heuristics, but for which there is no good generic > >> way of updating the heuristics. > > > > I can't make sense of that last sentence, and the possessive for > > "heuristics" (here and below in the documentation) is, IMO, > > unnecessary. > > > >> Signed-off-by: Roderick Colenbrander <roderick.colenbrander@xxxxxxxx> > >> --- > >> Documentation/input/event-codes.rst | 9 +++++++++ > >> include/uapi/linux/input-event-codes.h | 1 + > >> 2 files changed, 10 insertions(+) > >> > >> diff --git a/Documentation/input/event-codes.rst > >> b/Documentation/input/event-codes.rst > >> index a8c0873..ae8c546 100644 > >> --- a/Documentation/input/event-codes.rst > >> +++ b/Documentation/input/event-codes.rst > >> @@ -356,6 +356,15 @@ can report through the rotational axes (absolute > >> and/or relative rx, ry, rz). > >> All other axes retain their meaning. A device must not mix > >> regular directional axes and accelerometer axes on the same event > >> node. > >> > >> +INPUT_PROP_JOYDEV_IGNORE > >> +------------------------ > >> + > >> +The joydev interface uses heuristics to determine whether it should > >> expose an > >> +input device through joydev. Some devices pass its heuristics, but > >> don't > >> +make sense to expose. In some cases the generic heuristics can be > >> updated, > >> +but in other cases this is not easy. The INPUT_PROP_JOYDEV_IGNORE > >> flag can > >> +be set by drivers to explicit request blacklisting by joydev. > > > > The "don't make sense to expose" is not what we're trying to do here > > though. The problem is rather that "we used not to show this device > > through joydev, but programs using joydev are limited and usually not > > updated so we should only show what we used to". > > > > Thanks, I will change the wording. Originally I wrote it like this, > because I thought joydev applications could not determine at all which > axes were being used except for 'an axis number' and for that reason > thought that the match function had some heuristics (e.g. filtering > out touchpad devices and others), making sure a joystick has buttons > etcetera. I wasn't aware of JSIOCGAXMAP, which does allow applications > to get more information about a device, but you can't easily determine > if something is e.g. a motion sensor device you would need to do a > string compare on known strings or make assumptions if you see a > device with axes, but no buttons. Sorry for the delay, but exposing the internal kernel decisions to userspace is not something that we need to do. Why would userspace care to see this in device properties? Also, this whole thing puts knowledge of interfaces into the drivers, and driver should not care at all what interfaces kernel might implement. Do drivers need to be aware that there is SysRq handler? Or that on some versions of ChromeOS there is a handler that bumps up CPU frequency in response to user activity? If you really want to stop joydev from attaching to some devices then the decision should go in joydev itself, not spread across multiple drivers. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
