> 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. Not specifically - but for the most part it shouldn't matter. We have interfaces like request_firmware() to load firmware and we have interfaces for input devices and for > 2) Is there a standard way to integrate user space components with > kernel side components. Use the standard kernel interfaces. If specific processing is needed in user space the to go into the kernel it needs to be such that those interfaces can be used in an open manner (this normally comes up with 3D graphics hardware rather than input), either by documenting the interface or providing an open implementation. > 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. The ektf2136 driver currently getting tidied up provides both. You can open it either as an input driver directly, or you can access raw event data in a documented for and do clever things with the data and feed it back to the input layer via uevent. > 6) Are there any other major design concerns? We have an initial mpu3050 driver which provides basic functionality (from Wistron/Intel), normal Linux practice would be to extend and improve that. > 7) Can an input device also have a character device interface for > proprietary customization. That depends what you mean and what for. Fundamentally there is no reason a device cannot present multiple interfaces although you might need to lock between them. > +Programming the chip using /dev/mpu > +---------------------------------- > +Programming of MPU3050 is done by first opening the /dev/mpu file and > +then performing a series of IOCTLS on the handle returned. The > IOCTL codes can +be found in mpu.h. Typically this is done by the > mllite library in user +space. Is this published with source or sufficient documentation for someone to write their own ? Note btw the usual expectation would be that the kernel driver uses request_firmware to load firmware as needed for that part of the process. -- 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
