[haiku-development] Re: Joysticks in Haiku
- From: "mmlr@xxxxxxxx" <mmlr@xxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 18 Mar 2011 21:47:08 +0100 (CET)
Hi all
On March 18, 2011 at 10:38 AM "Stephan Aßmus" <superstippi@xxxxxx> wrote:
> Am 18.03.2011 07:48, schrieb Adrien Destugues:
>> For devices advertising themselves as HID, I think everything will go
>> fine at the driver side if done right. The good way is to have a single,
>> generic HID driver, handling tablets, mouses, joysticks, keyboards,
>> anything else, in the same driver. This way, a weird device may have
>> some keyboard buttons, some knobs and some mouse axis, and still work
>> out of the box.
Yes, that is how usb_hid has been built from the ground up. Specific class
drivers handling devices they know are logically related (i.e. grouping the
modifiers and keys to logical keyboards, grouping x and y axis with buttons to
mice, gamepads, joysticks...) with a fallback to basic devices made up of the
individual components. If just some keys are found, a keyboard will be created,
even if it actually isn't a keyboard but some other kind of device (a remote,
phone, extended mouse or whatever). This is for example what happens with my
keyboard, it actually exposes two keyboards, the one for the actual keyboard and
the other for the multimedia buttons it comes with. If axis are found mice will
be created for them (motion sensors, dpads for example). The idea behind it
being that if it has axis, at least you can do something with it (i.e. move the
cursor) or if some keys or buttons are present you can hook them up to some
action. It would've worked the same for gamepads, their axis controlling the
mouse cursor, but it didn't because unit scaling and absolute data handling
being incomplete. That's why they made the cursor move to a corner and getting
stuck there. The basic idea behind it is still sound though.
>> The problem is then mapping all this to input_server events. We want
>> mouse to move te pointer on screen, and keyboard to type letters. But
>> what to do with strange devices that are neither keyboard or mouse ?
>> Where to send the input then ?
And that's the point where we need that extended input framework. Axis can
always be mapped to mouse movement and keys and buttons to keyboard events. But
the framework outlined earlier (or more appropriately making the existing
framework available to userland applications) would allow applications to
enumerate devices that don't have a representation in the existing API and
aren't / can't be used through the input_server. It would make sense to create a
preference panel based on that framework to allow a user to "group" some
controls logically (with certain such groups coming pre-configured for known
devices) so that the buttons do the expected things and all...
> Last night I was plugging my Logitech Wireless mice, which has some
> extra buttons, into my girlfriends Mac for the first time. That prompted
> the OS to display a keyboard configuration wizzard, where it wanted me
> to press the key to the right of the left shift key... :-)
Not that surprising as it likely made the buttons available as a keyboard and
the configuration wizard intended to find the right keymap for it. Of course it
could've been so clever as to check for a certain minimum amount of keys before
assuming a standard keyboard.
The exact same (sans the keymap configuration) would happen under Haiku btw. If
you plug that mouse in and it has keys (consumer usage page most likely) they
will be made available as a keyboard. You can't use them to type, because their
usage doesn't cover the normal keyboard keys, but you can assign them using the
shortcuts preference.
> I guess there may always be strange situations like this, but hopefully
> they can be kept to a minimum with some fuzzy logic in the driver.
Exactly, for example a "keyboard" with only like 5 keys isn't likely going to be
a good match for a normal keymap. If it actually does expose the keys with the
consumer usage page and not with the one keyboards usually use then this
information can be used to determine it is not keyboard for normal text input as
well.
Regards
Michael
Other related posts:
