5 ms·

I think you're oversimplifying things a bit. Yes, a lot of HID have a concept of a simple button press/click/action which you can abstract away, but there are m

by dtech 10y ago

I think you're oversimplifying things a bit. Yes, a lot of HID have a concept of a simple button press/click/action which you can abstract away, but there are many actions that don't directly map to that: function keys, lights, analog inputs (i.e. thumbstick), rumble. And then you have the devices which don't really map to buttons like trackpads, draw tablets, face/eye tracking and Wii Mote-like devices. Your argument is a bit like saying it's stupid we have all these Graphics API's, it should be unified a long time ago since all they do is set pixels on a monitor to a certain color.

clarry 10y ago
Function keys are still just keys, there is nothing special about them. If anything, the problems are caused precisely because of people thinking like you, thinking that some input is somehow very special when it really isn't. That's how we got where we are. Yes, I focused on buttons only, because that is the lowest bar (and we've yet to cross that). Yes, I am fully aware that there are other kinds of inputs. We've had "analog" inputs for decades. Sliders, joysticks, sensors, etcetra. There is nothing difficult about them. All we need is a driver to understand the inputs, optionally identify them with a name, symbol, intended purpose or default function and other metadata, and export through an API that allows applications to easily map things to arbitrary inputs. And allow the user to filter inputs at a lower level; for example, if he finds that input device 6 has a nice input 17 that takes values in the range [0 to 255] that he'd like to treat as a binary input that reads high in [0 to 126] range and otherwise low, that should again be possible and very easy to do as long as the underlying API is sane. Rumble and force feedback, keyboard leds, gpios in output mode, etc. are outputs, which could be exposed through a similar, arbitrarily mappable mechanism. We've had all these for decades, and we've yet to cross the lowest bar of making all simple buttons bindable everywhere through a uniform API. It is not hard, nobody just wants to do it (at a low level, USB HID comes surprisingly close! But then it has its struggles, what with the default keyboard mode that requires a bitfield for modifiers and bytes for other scancodes), and in the name of compatibility, we just keep piling hacks on top of legacy. And my mouse's thumb buttons are still useless most of the time.
- buzzybee 10y ago
  The standard already exists in the pro audio world, and it's called MIDI. It supports on and off events with velocity, controllers with ranges, multiple channels, real-time synchronization, sequencing, daisy-chaining, full-duplex bidirectional behavior. And every once in a long while a game appears that supports MIDI input for whatever reason. I once made a Pong paddle prototype with my phone running a MIDI controller app, sending modulation wheel data to the computer to move the paddle around. As well, drivers can turn game controllers into MIDI devices. The thing that's missing is that manufacturers and developers just aren't on the same page here - the protocols exist, and with pretty good software support, even(there's a Web MIDI, and MIDI for phones in various forms). The major modes of incompatibility - e.g. velocity ranges that are biased and need remapping, unconventional behaviors around SysEx messages - are well-known. It's just a little bit unaesthetic that a game controller would send a "Note On" to press a button when it isn't doing anything with notes, really. And it doesn't map to the tradition of arcade hardware being a simple memory-mapping of button state, but I doubt most game controllers now are doing that internally. Regardless, game controllers don't send MIDI messages by default. And yeah, MIDI is old, and has a few hard design limits, and one could make a case for looking at another standard like Open Sound Control. But the basic problem of button mapping has been more than solved for a long time, so count me as one who is irritated at the idea that games are special here.
  - clarry 10y ago
    > And yeah, MIDI is old, and has a few hard design limits, and one could make a case for looking at another standard like Open Sound Control. Yeah, I was actually thinking of MIDI (and USB) when I wrote the above (I have a full size midi master keyboard next to my deskop). At a certain level, we have pretty much all we need, and if the limitations of MIDI were a problem for some input devices (and they arguably are), it'd still be quite easy to spec a system that allows just about any device imaginable. Again, USB HID spec comes really close. The real problem is just the lack of good, widespread, cross-platform APIs that steer applications into doing the right thing. Now we have APIs that encourage the application to look for keyboard events, then mouse events, then joystick events, and what else (and they implementations may lack support for other devices even if the underlying OS-level API made support a no-brainer). Instead, they should just look for events, any events that have an applicable type. (Whether implemented through callbacks or polling the state of interesting inputs is merely an implementation detail) Then the (optional) metadata can be used for establishing a default mapping. When the API is designed right, the user can always override any mapping with whatever he wants, or filter inputs to change the response of an analogue device, perhaps nonlinearizing it or coercing it to a binary input. And if the application provides its built-in input configurator, again using the well-designed API, the ability to bind anything to anything on anything just comes automatically. The application developer should never need to know that device 7 input 2 is actually wired to my belly button. :) And that the axes I use for aiming are actually sliders on my MIDI keyboard.

by dtech 10y ago

clarry 10y ago

Function keys are still just keys, there is nothing special about them. If anything, the problems are caused precisely because of people thinking like you, thinking that some input is somehow very special when it really isn't. That's how we got where we are. Yes, I focused on buttons only, because that is the lowest bar (and we've yet to cross that). Yes, I am fully aware that there are other kinds of inputs. We've had "analog" inputs for decades. Sliders, joysticks, sensors, etcetra. There is nothing difficult about them. All we need is a driver to understand the inputs, optionally identify them with a name, symbol, intended purpose or default function and other metadata, and export through an API that allows applications to easily map things to arbitrary inputs. And allow the user to filter inputs at a lower level; for example, if he finds that input device 6 has a nice input 17 that takes values in the range [0 to 255] that he'd like to treat as a binary input that reads high in [0 to 126] range and otherwise low, that should again be possible and very easy to do as long as the underlying API is sane. Rumble and force feedback, keyboard leds, gpios in output mode, etc. are outputs, which could be exposed through a similar, arbitrarily mappable mechanism. We've had all these for decades, and we've yet to cross the lowest bar of making all simple buttons bindable everywhere through a uniform API. It is not hard, nobody just wants to do it (at a low level, USB HID comes surprisingly close! But then it has its struggles, what with the default keyboard mode that requires a bitfield for modifiers and bytes for other scancodes), and in the name of compatibility, we just keep piling hacks on top of legacy. And my mouse's thumb buttons are still useless most of the time.

buzzybee 10y ago
The standard already exists in the pro audio world, and it's called MIDI. It supports on and off events with velocity, controllers with ranges, multiple channels, real-time synchronization, sequencing, daisy-chaining, full-duplex bidirectional behavior. And every once in a long while a game appears that supports MIDI input for whatever reason. I once made a Pong paddle prototype with my phone running a MIDI controller app, sending modulation wheel data to the computer to move the paddle around. As well, drivers can turn game controllers into MIDI devices. The thing that's missing is that manufacturers and developers just aren't on the same page here - the protocols exist, and with pretty good software support, even(there's a Web MIDI, and MIDI for phones in various forms). The major modes of incompatibility - e.g. velocity ranges that are biased and need remapping, unconventional behaviors around SysEx messages - are well-known. It's just a little bit unaesthetic that a game controller would send a "Note On" to press a button when it isn't doing anything with notes, really. And it doesn't map to the tradition of arcade hardware being a simple memory-mapping of button state, but I doubt most game controllers now are doing that internally. Regardless, game controllers don't send MIDI messages by default. And yeah, MIDI is old, and has a few hard design limits, and one could make a case for looking at another standard like Open Sound Control. But the basic problem of button mapping has been more than solved for a long time, so count me as one who is irritated at the idea that games are special here.
- clarry 10y ago
  > And yeah, MIDI is old, and has a few hard design limits, and one could make a case for looking at another standard like Open Sound Control. Yeah, I was actually thinking of MIDI (and USB) when I wrote the above (I have a full size midi master keyboard next to my deskop). At a certain level, we have pretty much all we need, and if the limitations of MIDI were a problem for some input devices (and they arguably are), it'd still be quite easy to spec a system that allows just about any device imaginable. Again, USB HID spec comes really close. The real problem is just the lack of good, widespread, cross-platform APIs that steer applications into doing the right thing. Now we have APIs that encourage the application to look for keyboard events, then mouse events, then joystick events, and what else (and they implementations may lack support for other devices even if the underlying OS-level API made support a no-brainer). Instead, they should just look for events, any events that have an applicable type. (Whether implemented through callbacks or polling the state of interesting inputs is merely an implementation detail) Then the (optional) metadata can be used for establishing a default mapping. When the API is designed right, the user can always override any mapping with whatever he wants, or filter inputs to change the response of an analogue device, perhaps nonlinearizing it or coercing it to a binary input. And if the application provides its built-in input configurator, again using the well-designed API, the ability to bind anything to anything on anything just comes automatically. The application developer should never need to know that device 7 input 2 is actually wired to my belly button. :) And that the axes I use for aiming are actually sliders on my MIDI keyboard.