<div dir="ltr"><div><div>Todd,<br></div><br>Generic device input may be too complicated to put it into Wayland protocol. For example, take Razer Hydra controller:<br><a href="http://www.blogcdn.com/www.engadget.com/media/2011/06/20110608-14231532--img9348-1307559434.jpg" target="_blank">http://www.engadget.com/2011/06/08/razer-totes-hydra-sticks-and-6400dpi-dual-sensor-mice-to-e3-2011/</a><br>
<br></div>There are 2 USB connected controllers for each hand, each with 6 DOF information for 3D position and 3D rotation information. I programmed it for a 3D environment rather than games. Each controller sends you a quaternion to extract the data. On top of it, the output is noisy, so you'd want to add filters to integrate the noise out. <br>
<br>The last thing I'd want is to have a middleman between the USB port and my processing code that messes around with rotation matrices and introduces delays. I think it is reasonable to limit the protocol to mice like devices only. As long as the protocol allows 2 mice simultaneously in the system (which they do), IMHO, the rest of the processing is better placed within your own code.<br>
<div><div class="gmail_extra"><br></div><div class="gmail_extra">Nick<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Apr 20, 2013 at 9:38 AM, Todd Showalter <span dir="ltr"><<a href="mailto:todd@electronjump.com" target="_blank">todd@electronjump.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>On Sat, Apr 20, 2013 at 12:20 PM, Daniel <<a href="mailto:danlist@terra.es" target="_blank">danlist@terra.es</a>> wrote:<br>
<br>
> This is useful for desktop software too. I'm thinking of Stellarium or<br>
> Google Earth, where moving the mouse is expected to move the<br>
> environment, not the pointer itself.<br>
<br>
</div> "Games" is really perhaps shorthand here; there are a lot of tools<br>
and so forth that have similar behavior and operating requirements to<br>
games, but aren't strictly games per se. If you have an architectural<br>
walkthrough program that lets you navigate a building and make<br>
alterations, that's not really something you'd call a game, but it is<br>
operating under many of the same constraints. It's more obvious in<br>
things using 3D, but even the 2D side can use it in places.<br>
<br>
I could easily see (for example) wanting to be able to do drag &<br>
drop within a window on a canvas larger than the window can display;<br>
say it's something like dia or visio or the like. I drag an icon from<br>
the sidebar into the canvas, and if it gets to the edge of the canvas<br>
window the canvas scrolls and the dragged object (and the pointer)<br>
parks at the window edge.<br>
<br>
It's useful behavior. I can definitely see why adding it to the<br>
protocol makes things more annoying, but I've a strong suspicion it's<br>
one of those things that if you leave it out you'll find that down the<br>
road there's a lot of pressure to find a way to hack it in.<br>
<div><br>
Todd.<br>
<br>
--<br>
Todd Showalter, President,<br>
Electron Jump Games, Inc.<br>
</div><div><div>_______________________________________________<br>
wayland-devel mailing list<br>
<a href="mailto:wayland-devel@lists.freedesktop.org" target="_blank">wayland-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br>
</div></div></blockquote></div><br></div></div></div>