On Thu, Jun 30, 2011 at 07:18:17PM -0700, Nathan Royer wrote: > This files defines the userspace interface and how to integrate it into a > platform. > > Signed-off-by: Nathan Royer <nroyer@xxxxxxxxxxxxxx> > --- > > This is the first of many patch files for the inv_mpu driver in its current > state. This is our first time submitting this driver, so I expect there to be > a lot wrong with it, and expect to need to fix many things. > > The inv_mpu driver attepts to implement a Motion Processing Unit interface. As > a unit, an accelerometer, magnetometer, gyroscope, and/or altimiter data is > fused together to produce calibrated data and a quaternion. > > The inv_mpu driver interface is currently implemented as a misc device, but may > need to change to include both sysfs attributes and input devices. I think > that we will continue to need the ioctl interface, but many of the ioctls can > be replace by attributes and/or input devices. > > The mpu3050 has an i2c master interface designed to control an accelerometer > and a Digital Motion Processor (DMP) used to perform sensor fusion on the > gyroscope and accelerometer. This data is then read out of the mpu3050 fifo > and sent to userspace for distribution and optional propritary processing, such > as fusion with a compass to produce a 9 axis quaternion. > > Some question I have at the start are: > 1) Is there a master design or standard interface for Motion Processing > devices, specifically ones that do calibration, sensor fusion, and or have a > micro-controller to do some of this work. > 2) Is there a standard way to integrate user space components with kernel side > components. > 3) Should data be pushed back to the driver from userspace, and made available > as an input device or should it remain as a character device. > 4) Can a 4 element quaternion be added to input.h: > ABS_QUATERNION_1 ABS_QUATERNION_I ABS_QUATERNION_J ABS_QUATERNION_K > for <1, i, j, k> > 5) Should we instead use a rotation vector as defined in the Android sensor: > http://developer.android.com/reference/android/hardware/SensorEvent.html > 6) Are there any other major design concerns? Shouldn't you be using the iio subsystem for the kernel/user interface as I think it handles most of this for you already, right? > 7) Can an input device also have a character device interface for proprietary > customization. What do you mean by this? greg k-h -- 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
