Re: [PATCH v2 0/3] Input/HID: joydev fixes for motion sensors

On Wed, Aug 23, 2017 at 5:08 PM, Bastien Nocera [off-list ref] wrote:

On Wed, 2017-08-23 at 16:57 -0700, Roderick Colenbrander wrote:

quoted

On Wed, Aug 23, 2017 at 2:04 AM, Bastien Nocera [off-list ref]
wrote:

quoted

<snip>

quoted

quoted

I'm not sure I fully understand the problem you're trying to solve.

Is it "old software which relies on joydev is too basic to allow
selecting the correct joystick device"? Or "some system components
are
picking up the joypad's accelerometer like it inferred the screen's
positioning"?

The problem is more like the first. Joydev is too basic to allow
applications to determine they are dealing with a motion sensor
device
(axes are just numbers from its perspective). Due to recent hid-sony
restructure, its motion sensors are now picked up by joydev as it
passes joydev its heuristics.

We felt that no motion sensors should probably get picked up by the
legacy joydev interface as it caused issues for legacy applications
(and users reported issues to me). Originally we proposed filtering
in
joydev based on just 'INPUT_PROP_ACCELEROMETER' as it has similar
filters to filter out touchpad device and others. Discussion on that
patch led to the composite device discussion as Dmitry felt that the
ability to use a standalone motion sensor device as a joystick could
potentially make sense.

In which case a INPUT_PROP_JOYDEV_IGNORE property would be much much
more descriptive of what you want to achieve with this patchset, and
avoids confusion.

I think that INPUT_PROP_COMPOSITE might have its place (and it would be
useful to have supported in toolkits, or wayland compositors), but not
for this purpose.

I'd say repurpose the whole patchset around INPUT_PROP_JOYDEV_IGNORE
and we can look into a more complete INPUT_PROP_COMPOSITE with ioctl()
and co.

Cheers

That sounds like a good idea. The only downside is that this flag
would also get exposed to user space, but I guess that could be okay.