[haiku-development] Re: Joysticks in Haiku
- From: "Carwyn" <cdj1000@xxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 17 Mar 2011 20:55:41 +0000
> 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
>
>
Michael,
I can tell you don't like the USBKit idea :-), i'll try a couple of
ideas with your suggestions in mind. Sorry for the short reply, but i
do get what your saying.
Carwyn
Other related posts:
