Re: [PATCH 1/4] Input: Add new property INPUT_PROP_JOYDEV_IGNORE

On Mon, Aug 28, 2017 at 03:02:16PM -0700, Roderick Colenbrander wrote:

On Mon, Aug 28, 2017 at 2:38 PM, Dmitry Torokhov
[off-list ref] wrote:

quoted

On Mon, Aug 28, 2017 at 02:35:15PM -0700, Roderick Colenbrander wrote:

quoted

On Mon, Aug 28, 2017 at 2:16 PM, Dmitry Torokhov
[off-list ref] wrote:

quoted

Hi,

On Mon, Aug 28, 2017 at 02:08:54PM -0700, Roderick Colenbrander wrote:

quoted

On Fri, Aug 25, 2017 at 1:45 AM, Bastien Nocera [off-list ref] wrote:

quoted

On Thu, 2017-08-24 at 16:11 -0700, Roderick Colenbrander wrote:

quoted

From: Roderick Colenbrander <roderick.colenbrander@sony.com>

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.

quoted

Signed-off-by: Roderick Colenbrander <roderick.colenbrander@sony.com>
---
 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

Correct user space should not have to be aware. Originally the patch
add a composite device flag, but that term was more loaded and needed
ioctls. That field would have made sense for user space, but this flag
not, we just piggy-backed on the the properties field in the
input_dev.

In my case of ds3/ds4 to fix old applications, I want to blacklist
joydev in some way, but joydev doesn't have access to enough
information except for INPUT_PROP_ACCELEROMETER which I think you felt
was not narrow enough in scope.

Would the solution be to add some new private quirks/flags field to
'struct input_dev', which joydev could use? Or is there another
solution you have in mind.

What kind of data joydev is missing? There is the input_id with bus,
vendor, product and version, device capabilities, plus you have full
access to the input device itself, so you can look up name, phys, etc.

Thanks.

--
Dmitry

Thanks for getting back so quickly. The input_dev has all the
information as you could do something with product / vendor ids, which
I wanted to avoid as there are 5 DS4 ids I need to handle and 2 DS3
ids. We still want to expose the 'gamepad' subdevice, but not the
motion device (INPUT_PROP_ACCELEROMETER), so it would be quite some
logic. Overall I thought it would be cleaner to not have this device
knowledge in joydev and maybe expose a new flag.

I believe conceptually this would be wrong, as it would push the
knowledge of existing interfaces into the drivers. So just use input ID
(and I guess you need to parse phys a bit to see which device you want
to handle and which to ignore).

Thanks.

-- 
Dmitry