[haiku-development] Re: Joysticks in Haiku
- From: "Carwyn" <cdj1000@xxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Fri, 18 Mar 2011 01:46:15 +0000
> 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.
I understand what you mean and have seen the changes you have made for
Quirky devices, this is clever idea and it should work, i can't test
it yet as the Xbox 360 controller is not added when connected, when
it's connected the usb_hid's usb_hid_device_added is not called. I've
found that the Xbox 360 controller is returned as B_UNSUPPORTED in the
file src/add-ons/kernel/bus_managers/usb/Device.cpp in the function
status_t Device::ReportDevice. The reason being as far as i understand
your code is that because the controller has the following rogue info,
Class .................. 0xff (Vendor specific)
Subclass ............... 0xff
Protocol ............... 0xff
Max Endpoint 0 Packet .. 8
USB Version ............ 0x0200
Vendor ID .............. 0x045e
Product ID ............. 0x028e
Product Version ........ 0x0110
Possible Kludge if(vendor_id == 0x045e && product_id == 0x028e) class =
0, subclass = 0 etc. I haven't tested this filthy kludge by the way
yet.
You may have to add a kludge for this device and change the class,
subclass etc to the correct values for your code when this vendor id
etc is found, i don't think your a kludge type of person though. If
your not then we just forget about the Xbox 360 controller.
> 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).
Ok, this sounds interesting. What do you recommend i should work on
in relation to joysticks, gamepads etc. I may sound like i know what
i'm talking about :-), but my knowledge of the USB isn't that great.
> 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.
>
Hey, you weren't being harsh, you guys have worked hard to get Haiku
where it is today and things must be done correctly. You don't want
zombies like me coming out of the woodwork and eating your code :-0.
Carwyn
Other related posts:
