On Mon, Nov 28, 2016 at 10:32 PM, Roderick Colenbrander <roderick@xxxxxxxxxx> wrote: > 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 Hi Jiri and others, Any suggestions on how to move forward? Thanks, Roderick -- 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
