Re: [w3c/gamepad] Should fire events instead of using passive model (#4)

Greetings!

First of all, forgive any seeming angst - I have been struggling with this for the last year and have just now been pointed to this list.

==========================

I started reading this last night and I'm reading "gamepad this", "gamepad that", "animation loop", "use in game context" and I ended up going "Blast it all - ***NO***!!" <slams hand down on table, scaring wife half to death>

I decided to wait until today to reply so that I was less annoyed. . . :wink:

=========================

IMHO, the largest part of the issue here is the concept that these are **GAME** devices, not **USER INPUT** devices, and the whole emphasis on this being a **GAME** pad has not allowed it to be used as well as it can be in the broader user interface/input device context.

Here's an example from the thread that discusses if placing the "game" pad behind a secure context doesn't do more harm than good.
https://github.com/w3c/gamepad/issues/145#issue-823328742

Along with my response:
https://github.com/w3c/gamepad/issues/145#issuecomment-1007953832

As I say there, the big issue is the thinking being limited by thinking of the device as a game device which demands respect for the animation frame and such like.

Again, IMHO, the first thing we should do is stop talking about it as a ***GAME*** controller and start thinking about it as a ***USER INPUT DEVICE*** that, like mice and keyboards, can be used for games, but actually has a much broader use-case.

======================

My use-case is that of a robot-controller.&nbsp; I want to use the joystick interface to control various actions of a GoPiGo-3 robot running a flask/werkzeug server on a Raspberry Pi, and use a browser on a different device to control it as a FPV joystick controlled robot.

My problem is that - as a polled device - I end up generating vast amounts of data that is absolutely useless and swamps my robot's limited server resources..&nbsp; To solve this I have to either limit the amount of data sent by looping on the browser, (which causes the browser to stall), or waste the limited processing power of the robot to filter out what's important from a stream of messages repeating every v-Sync &mu;seconds.

What I really need is for the joystick interface to behave more like the mouse's interface - I want to know "did something happen"?&nbsp; And that capability already exists within the existing interface as the gamepad's time_stamp data item is already programmed to remain constant ***until something happens***.

I can probably simulate this behavior by going behind the scenes, capturing interface messages, and creating my own shim to process what the joystick is doing - but that's SOOOO 1980's.&nbsp; I should not have to dive into the browser and do the equivalent of capturing the INT-19 vector so I can capture and control joystick events the way programmers had to capture and control mouse events in the 1980's.

Once something happens, give me the entire gamepad object data-frame that is already being generated by the existing API.&nbsp; Once I have that, I can massage the data to do whatever I want.

Here's my wish-list:
1.  Generate a generic "something happened" event that returns the entire joystick data-frame as it already exists.&nbsp; If a joystick axis is noisy, I can filter that within the event handler.

Nice to haves:
1. Allow me to mask-out certain buttons and/or axes so they don't generate events.
2. Allow me to specify the precision of the axis data.&nbsp; (*i.e.* Instead of &plusmn;0.xxxxxxxxxxxx, I can ask for &plusmn;0.xxx precision.)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/gamepad/issues/4#issuecomment-1007968069
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/gamepad/issues/4/1007968069@github.com>