On Sat, Apr 27, 2013 at 10:23 AM, nerdopolis <bluescreen_aven...@verizon.net> wrote:
> What about rumblepads? How would the protocol control the rumblepad in some > controllers? I think rumble is beyond the scope of the proposed gamepad protocol. The problem is that (at least in my experience) whereas many controllers have some form of rumble, the actual physical rumble hardware has very little in common between devices. Some things have linear motors, some have rotary motors. Some have both. Or multiples of one or the other. Some (like the wiimote, IIRC) aren't actually rumble per se, and are actually a speaker you stream sound to at low bit rates. The other problem (at least to me) is that rumble flows in the opposite direction from input; in the gamepad protocol I'm proposing, all the data is flowing from the hardware through the server to the application. Rumble runs the other way. Rumble in general is far more akin to sound playback than it is to input; you're basically feeding a control stream to an actuator. Beyond that, at least with some gamepads, the rumble hardware is subject to restrictions; in particular, at least one bit of kit I've worked with that's still in circulation doesn't get enough power over the controller cable to run all of the rumble motors at the same time, and if you turn too much on the board-level logic in the gamepad can start acting wonky. So, the short version of my answer is (1) I think rumble is a totally different problem domain that wants its own protocol, and (2) I'm not sure there's enough commonality or sanity in rumble hardware to build a useful protocol. Todd. -- Todd Showalter, President, Electron Jump Games, Inc. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel