Input and games.

[Daniel Stone]

Hi,

On 20 April 2013 22:13, Nick Kisialiou <kisialiou at gmail.com> wrote:
> Generic device input may be too complicated to put it into Wayland protocol.
> For example, take Razer Hydra controller:
> http://www.engadget.com/2011/06/08/razer-totes-hydra-sticks-and-6400dpi-dual-sensor-mice-to-e3-2011/
>
> 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.
>
> 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.

I think with 6DoF-type devices, we really shouldn't try to do anything
clever with them, and pretty much just pass evdev input through.  The
only reason we created wl_pointer and wl_keyboard as they are is that
the compositor needs to interpret and intercept them, and clients
would all be doing more or less the same interpretation too.  For
complex devices where it's of no benefit to have the compositor
rewrite the events, I think we just shouldn't even try.

If the gamepad proposal was any more complex than it is now, I'd lean
towards just shuttling the raw data to clients rather than having our
own protocol.  But the proposal I've seen is pretty nice and it
definitely helps our gaming story (which is really quite poor now), so
that helps.

The one thing I think it's missing so far is physical controller gyro
measurements, e.g. for new PS3/PS4 controllers and the Wiimote.

Cheers,
Daniel

> On Sat, Apr 20, 2013 at 9:38 AM, Todd Showalter <todd at electronjump.com>
> wrote:
>>
>> On Sat, Apr 20, 2013 at 12:20 PM, Daniel <danlist at terra.es> wrote:
>>
>> > This is useful for desktop software too. I'm thinking of Stellarium or
>> > Google Earth, where moving the mouse is expected to move the
>> > environment, not the pointer itself.
>>
>>     "Games" is really perhaps shorthand here; there are a lot of tools
>> and so forth that have similar behavior and operating requirements to
>> games, but aren't strictly games per se.  If you have an architectural
>> walkthrough program that lets you navigate a building and make
>> alterations, that's not really something you'd call a game, but it is
>> operating under many of the same constraints.  It's more obvious in
>> things using 3D, but even the 2D side can use it in places.
>>
>>     I could easily see (for example) wanting to be able to do drag &
>> drop within a window on a canvas larger than the window can display;
>> say it's something like dia or visio or the like.  I drag an icon from
>> the sidebar into the canvas, and if it gets to the edge of the canvas
>> window the canvas scrolls and the dragged object (and the pointer)
>> parks at the window edge.
>>
>>     It's useful behavior.  I can definitely see why adding it to the
>> protocol makes things more annoying, but I've a strong suspicion it's
>> one of those things that if you leave it out you'll find that down the
>> road there's a lot of pressure to find a way to hack it in.
>>
>>                                                         Todd.
>>
>> --
>>  Todd Showalter, President,
>>  Electron Jump Games, Inc.
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
>
>
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>