On Wed, 3 Aug 2011, David Herrmann wrote: > >> There is also the other side. Sending data to the wiimote. 4 LEDs can > >> be set, the rumble motor can be enabled/disabled and audio data can be > >> streamed. I think my current approach to use sysfs attributes for the > >> LEDs > > > > Depending on what exactly it is you may try registering LEDs as LED > > class devices. Having a sysfs attribute to light one of 4 leds is an > > option too. > > I already looked at the API. Although the 4 LEDs of the wiimote can > only be switched on/off (no brightness modulation) I think I could > register 4 led_classdev structures. This would also allow software > blinking. Yes, I'd prefer that as well. > >> and RUMBLE motor is ok? I can't figure out any better way here. > > > > One of the input devices should be registered as ForceFeedback device > > (or you create a separate FF input device). > > Ok, I will add that. Perfect, thanks. You can find quite some examples of force feedback implementations even in drivers/hid as well, to gain some inspiration. > >> Reference-counting doesn't make sense. If multiple devices use them, > >> then they will always have conflicts, however, it still works. > >> Audio streaming is not yet implemented, but I think I could register > >> an alsa device so this needs not to be discussed here. > >> > >> > >> Currently I think Interface #2 would be the best way but I don't want > >> to spend time implementing that if you tell me it isn't acceptable. > >> Any comments on this are appreciated. > > > > I believe you should try presenting physical objects as input devices so > > I'd try presenting wiimote (with optional motion+ events) as one device > > and accessory (nunchuck, classic extension) as another device. > > Yes, but the problem is, that this would enable all peripherals of the > wiimote, even though userspace may not need them. But if that is the > recommended way, I will implement it. Is there any problem with that? I could potentialy imagine unnecessary power consumption (assuming that the peripherals that are not enabled are in some lower state, right?). Anything else? Thanks a lot for your work on the driver, David. -- Jiri Kosina SUSE Labs -- 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
