2009/12/16 Philippe Houdoin <philippe.houdoin@xxxxxxxxx>: > Joysticks being input devices and, in USB case, an HID device like any > other, it make sense to indeed start from Michael's usb_hid (and his > generic HID parser module...) to add a missing "USB Joystick" input > device add-on. > > Beware, though, as BeOS BJoystick API was designed around a polling > mechanism, while input server is about broadcasting messages. Yes, you're right. While, for example, mouse input device add-on polls for state, it then sends messages while appropriate (state has changed from last time). Well, I think one way could be to buffer last values in BJoystick and simply return them in Get(...) methods. This will of course introduce some lag. BJoystick has SetMaxLatency method which, I suppose, could be used to adjust mentioned polling interval through Control interface. Advantage of this method would be to introduce alternative, event based joystick handling. This is what SDL has AFAIK. They implement both methods and event based one is marked as preferred. > Still regarding BJoystick API, I've already an enhancement to propose: > support more than 32 buttons, the limit in BeOS R5. > Yes, I know, it sounds weird, but many HOTAS joystick & throttle > combos actually have more than 32 buttons per HID device. > My Saitek X52 Pro for instance publish 38 buttons for instance... It would be an enhancement to BJoystick's "Enhanced Mode" :) As you probably know GetButtonValues returns buttons state as uint32 sized variable with bit mask of pressed buttons, so don't know if it's possible without breaking compatiliblity. But if that event based handling is going to happen it could be seen as future and preferred method, implementing more or enhanced features. That would eventually leave BJoystick as compatibility layer. Don't know how well it all would work in the real world though :) Anyway, please tell me what you think. This is for anyone interested :) > Your future tester ;-). Hopefully ;) Regards, Krzysiek