> 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