On Thu, Jul 28, 2011 at 8:08 PM, Oliver Neukum <oneukum@xxxxxxx> wrote: > Am Donnerstag, 28. Juli 2011, 18:08:26 schrieb David Herrmann: >> The wiimote has an internal accelerometer which can report data to the host. >> Userspace may now write to a new sysfs file to make the driver enable >> accelerometer reporting. This is not enabled by default to reduce power >> consumption of the wiimote. Accelerometer data is reported every few >> milliseconds and thus consumes much bluetooth bandwidth which costs much energy >> of the wiimote. >> By writing 0 to the sysfs file, accelerometer reporting is disabled again. > > This is an odd interface. Why can't you request the accelerometer data when > a device file dedicated to the accelerometer is opened? The API consists of sysfs and an input device. There is no way to be able to see when accelerometer data is requested. Of course, I could use ->open() callback on the input-layer. However, many use cases do not require accelerometer data and bluetooth traffic is increased heavily when accelerometer reports are enabled. For instance if you only need button-reports, then one package per button press is transmitted. With accelerometer reports, every 5ms a package is transmitted. And the battery of the wiimote is quite small... I could create multiple input interfaces, one for button data, one for accelerometer, one for IR etc. however, how can userspace know which one is for which interface BEFORE opening it? It could open all of them and close the ones it doesn't need, but is that better than having a sysfs attribute? I can see the problem with my approach. If multiple applications use the wiimote and one disables the accelerometer, then the other application has it also disabled. However, what other API would be more appropriate here? A char-dev would make the interface very easy but I tried to avoid cdevs and ioctl()s since I was told so. > Regards > Oliver Regards David -- 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
