[haiku-development] Re: Joystick support
- From: "Michael Lotz" <mmlr@xxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 16 Dec 2009 23:20:02
>>> I'd like to give it a try and implement joystick support in Haiku
> > > (for
>>> usb based devices in particular).
>>
>> I cannot give any reference right know but I am sure there is a
> > Joystick
>> USB driver implementation somewhere, I think from a Japaneese
> > developer
>> and
>> I must have the sources in some HD
> It's in the source :) but I think it's better to start of without it
> as
>
> Michael's usb_hid are doing the same thing so much will be
> duplication of
> code.
That driver used a subset of HID to specifically support joysticks. The
usb_hid driver does parse and provide an internal API to use full HID
devices. So whatever you do, don't build a new driver, add it as a *
Device/ProtocolHandler to usb_hid and use the internal API to make use
of the HID data.
But if you think along this line a bit further you will realize that
it's pretty pointless to add "joystick support". The only real use of
joystick support would be the legacy BJoystick API. Everything else
should not happen on the "this is a joystick, that is a gamepad, the
other one is some more complex other controller" level. HID was
invented to generically describe input (and output) devices so that you
don't have to do this categorization. If you read the specs it becomes
clear that the intention was that ultimately the client application
gets a nice way to extract data from devices and picks out what it
needs. Take a game where you control an airplane, the game just needs a
stream of x, y and maybe z coordinates. Whether they come from a
joystick, a data glove or even simply a mouse doesn't really matter.
The conclusion is that what should be implemented is a generic input/
output framework that pretty much just forwards what the usb_hid
internal API already provides to userland. Whether or not this goes
through the input_server or if it is a standalone class that directly
communicates with a device by the means of some ioctl protocol doesn't
matter either. This generic API then should allow an application to
enumerate what data fields are available and "subscribe" to them in
some way or another.
This framework then uses usb_hid and possible vendor specific protocols
to uniformly present "input/output" to the application. By designing it
along the lines of HID you can pretty much map any legacy device in
with very little effort. If you wanted to go the full distance you can
in the end also do the mouse/keyboard legacy drivers as backends to
this framework and the input_server just becomes a normal user of the
framework and enumerates the input devices to pick out keyboards/mice/
phones/whatever.
Regards
Michael
Other related posts:
