[haiku-development] Re: Joysticks in Haiku
- From: "Michael Lotz" <mmlr@xxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 17 Mar 2011 02:59:12 +0100
Hi
> I've been doing some experimenting and have thought of an idea, how
> about using the USBKit from userland to get the info for joysticks,
> gamepads etc. Any thoughts on this idea?.
>
> I've tested my idea and can read a Gravis Gamepad Pro status and also
> a
> Xbox 360 controller using the USBKit InterruptTransfer function.
> Would
> this be an acceptable way to implement BJoystick etc at least for USB
> devices.
Sure, you could do that. You could even use the HID code compiled with
USERLAND_HID to parse the data and all. But really you don't gain
anything from that. For a static target as BJoystick with it's set of
features it is way easier to just implement the protocol between
BJoystick and the kernel driver, as has already been done in the
patches.
> This is done in linux's Xbox/Xbox360 USB Gamepad Userspace Driver
> which
> was made by Ingo Ruhnke. All that needs to be done is get the
> endpoint
> for the device and InterruptTransfer 32 bytes, and all the buttons,
> axes etc are available.
Please don't go there. The whole point of the HID standard is to
describe the data package in a generic way that you can have a single
generic "class driver" per device type, independent of implementation
details like button count and data layout inside the reports. Such
device specific userland drivers are a huge step backwards as they
basically dump that whole advantage and you need one specific driver
per device again. There are always those vendors that will require
specific drivers (due to ignorance, not technical merit) and those are
painful enough to deal with, no need to do that for all those compliant
devices that would otherwise just work.
Please take the time to get familiar with what HID is all about and how
it works. It is a working solution that can handle arbitrary hardware
configurations and use cases. If used to its fullest it can also
describe not only the data, but supply the metadata (how the inputs are
physical used) and provide output and other features in a generic way.
There is absolutely no need to reinvent that wheel, especially not
since there is already a fully working implementation that you can just
attach a comparably tiny bit of code to to get thousands of different
devices to work out of the box.
> I'll upload my code to haiku dev so someone can test it, i've only
> tested a wired Xbox 360 controller.
I've checked that code out with the link you provided in a follow up
mail, and it indeed does what I expected (i.e. use fixed, device
specific structures), so the above does fully apply.
A better solution for more flexible use of HID devices from userland
(as discussed on this list some time ago): The HID data structures
should be made available to a userland frontend similarly to how
BJoystick works, i.e. a userland class talking directly with the usb_hid
driver. The userland class would allow for the same enumeration (HID
collections and reports) as is possible inside usb_hid, but the reports
come from the driver in a preprocessed package. The userland frontend
would merely allow you to "subscribe" to certain data fields (as is
already the case in usb_hid anyway). The big difference to just getting
the raw data directly from userland (per USBKit) is that any number of
applications can use such a class in parallel without the need for
exclusive access to the device (since the devices and USB underpinnings
are fully abstracted), and since processing of the reports is only done
once on the kernel side this gives less overhead. It obviously also
allows to later just use that frontend for Bluetooth HID as well (which
is the same protocol just over Bluetooth), instead of having to rewrite
the drivers again with a "BluetoothKit".
Always to be kept in mind as well: A device doesn't necessarily just
consist of one report. Keyboards usually come with a report for the
basic keyboard stuff and then have a sperate report for fancy
multimedia keys. This helps keeping the individual reports smaller and
since not all reports are used at the same time generally avoids
needlessly long transfers. Another keyboard may come with an integrated
touchpad that has its own reports... Essentially a single physical
device can be multiple logical devices that work independently. It is
therefore critical that these can be used independently as well, hence
using a device exclusivly via direct USB transfers is not really a
workable solution.
Regards
Michael
Other related posts:
