> > > accel/bma150.c > > An input driver exists for that one. (cc'd Eric) > > [Two input drivers - bma023 which I posted covers it too ;)] > > > > # sensors - compass > > > compass/ak8975.c > > We have a driver for this (I posted a while back) > > > > compass/ak8972.c > > > > compass/ami30x.c > > AMI304 is identical to the AK8974 which we already have - Gram Hsieh > posted patches for this a while ago It seems that some sensors are in input and but that most are in iio. Obviously I don't want to dissent with both and put ours in misc, so how do we make this better? Should we work on cleaning this up. If so should we start moving the drivers that are in input to iio. If this is the right thing to do, I could start working on merging the current mpu3050 input interface and our misc interface to the iio interface. I'm still trying to wrap my head around the iio framework, but I think one of the things I need is a uinput like interface for iio (perhaps it exists, I just haven't figured it out yet). If the DMP is used, a buffer for the FIFO data would be created, and user space would be responsible to push the sensor data back to iio after sensor fusion and calibration. Without the DMP, each sensor driver would act independently providing their own raw data. We still need a way to read and write registers and DMP memory during runtime from user space. -- 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
