On Mon, Nov 28, 2016 at 5:53 AM, Jiri Kosina <jikos@xxxxxxxxxx> wrote: > On Wed, 23 Nov 2016, Roderick Colenbrander wrote: > >> > We probably all agree that sending Acc/Gyro data across the joystick >> > interface is not the best thing in the world, so I would have some doubts >> > about whether spinning up another separate interface is quite the 'correct >> > thing' either. >> > >> > A while back I did some 'tinkering' on the SixAxis to see if 'we' could >> > use the IIO interface to report accelerometer data. >> > https://patchwork.kernel.org/patch/6589061/ > > Roderick, > > would you have any input on this aspect? I haven't really been actively > involved in the discussion last year, but my gut feeling is that IIO would > be the best suited interface for this. > > Thanks, > > -- > Jiri Kosina > SUSE Labs > Hi Jiri, Thanks for your response as well. From a technical side IIO is promising and we experimented with it a bit as well. From a more practical and business side I'm not the biggest fan. Let me explain a bit and work out something which would ideally work for everyone involved. On the technical side, IIO was made for expressing many kinds of sensors and our gamepads could be supported as well. The integration with the HID side would be a bit tricky as the input report is shared with general input data, so buffering, locks etcetera are needed, but this is an implementation detail. The main concern for us is software support in consumer platforms, which we often deal with. These open or closed platforms have good infrastructure for the Linux input frameworks, adding some other system while of course technically feasible is just not possible in practice. There is a strong preference there for standard evdev. Some platforms use IIO behind the scenes for sensors e.g. Android. Taking Android as example, it seems to access most sensors through a vendor specific HAL implementation, which can bubble up accelerometers, gyroscopes and many other kind of sensors. We looked over public code for some of these devices and the sensor list reported through this HAL seems to be static just based on what is built-in into a particular device. For a gamepad hot-plugging is common and at least on so wouldn't work (don't think the framework handles this concept yet either), while this is handled fine for evdev. I see similar challenges on other platforms we may potentially deal with. Desktop Linux is probably the easiest, though libraries like SDL2 and others need to gain support at some point. I definitely see IIO as an interesting platform, but across platforms the user space side is really not there even on a popular platform like Android. As a company we may end up using this driver on on various consumer devices (and older kernels), so I'm not a fan of IIO for framework / legacy related reasons. We would like to maintain a single code base, which is among the reasons we contribute to this driver, wanting to avoid custom proprietary solutions, which don't scale. I'm not sure what the best path forward is. Maybe we could consider supporting both e.g. through a kernel configuration option. This could be forward and backwards compatible. Thanks, -- Roderick Colenbrander Senior Manager of Software Engineering Gaikai Inc, a Sony Interactive Entertainment Company -- 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
