On Wed, 2017-08-23 at 16:57 -0700, Roderick Colenbrander wrote: > On Wed, Aug 23, 2017 at 2:04 AM, Bastien Nocera <hadess@xxxxxxxxxx> > wrote: > > <snip> > > 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 -- 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
