[haiku-development] Re: Joysticks in Haiku
- From: "Michael Lotz" <mmlr@xxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Thu, 17 Mar 2011 23:26:15 +0100
Hi again
> I can tell you don't like the USBKit idea :-), i'll try a couple of
> ideas with your suggestions in mind.
Not the USBKit idea per se, but more the fallback to device specific
drivers in general.
I think I see where you're coming from, i.e. the XBox controller being
non-conforming, therefore "requiering" a specific driver. The thing is,
I think it'd make more sense to actually turn it the other way. Instead
of writing a device specific driver and reimplementing most of the
logic that is already in usb_hid, one could simply describe the data
format coming from the XBox controller with a valid HID report
descriptor and inject that into the driver when that specific device is
encountered. This way the whole driver logic, interface to the upper
layers and transfer management can still be leveraged.
Indeed the usb_hid driver will need to be reworked, moving the HID part
into a generic kernel module (or into userland, for example into the
input_server) and the USB specific parts only being a data provider.
This will be necessary to use Bluetooth HID for example and would also
allow for arbitrary other data providers, making it possible to put
more exotic devices or legacy devices behind the same framework (as
that framework can then be exposed to applications to make them not
depend on mouse input, keyboard input, BJoystick, tablet, etc. but
instead allowing them to just enumerate the available inputs (and
outputs for that matter). This would of course not replace the existing
input handling because most applications won't really care about those
extended features (mostly games or software with special needs would).
That's how usb_hid is structured already anyway. The USB specific part
is isolated in the driver and HIDDevice parts, the actual HID handling,
decoding the descriptor and the report handling is generic and can
easily be applied to other sources (or compiled in userland as with
hid_decode).
> Sorry for the short reply, but i do get what your saying.
No problem, I can see that my reply was maybe a little harsh, I just
wanted to make absolutely clear what the "vision" is and that the USBKit
plus specific driver approach wouldn't really go in the that direction.
I had started to describe how you could possibly add fixed descriptors
to replace the ones on broken device, but then I simply went ahead and
added such a mechanism in r41017. Quite probably this should be enough
to get devices working that supply a "problematic" report descriptor by
adding them to the list with a fixed descriptor that describes the
actual data arriving. Such a descriptor has to be hand crafted right
now, but it's quite possible that other projects already have such
crafted ones (I haven't reasearched at all) and the HID parser could
easily be extended to generate report descriptors as well.
Regards
Michael
Other related posts:
