Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mysterycoder]

I'm a little confused about the purpose of the MacHIDManager and the MacInputManager. Is the MacHIDManager a WIP replacement for the MacInputManager? It seems like MacInputManager is there just to return some hard coded values and to instantiate MacHIDManager.

Initially I was looking at implementing joystick functionality for Macs, but I also noticed that the mouse and keyboard are both Carbon-based so I was thinking of working on expanding the already existing MacHIDManager.

[pjcast]

MacHID manager is for bridging the gab between the Carbon API and OIS's C++ API. The Input manager is mostly a factory creator (like Win32Inputmanager) and doesn't create joysticks directly or process them.

The HID stuff in OSX is early and only does enumerations of USB devices. And seemed to work well enough for my test joystick. I never did get to full creation and event polling.

[pjcast]

Actually, a few weeks ago I was motivated to work on the Carbon/HID API for OSX and started working on an Cocoa Application which was using OIS to enumerate devices and create them... was about to start making it interactive in the hopes of having a good test app on OSX for working with joysticks... Unfortunately, right after I started, my magsafe power cord decided to crap out (those things are expensive pieces of crap). Haven't felt like shelling out the 70$ for a new one just yet (instead been on vacation and purchasing some new guitar equipment). I wish I had that code available... I'll probably put a cord on order at the end of the week.

[mysterycoder]

That really stinks that it broke, that's a little bit much for a power cable. 
But that's great that you have code interfacing with Cocoa, I hope that will save me a lot of trouble.

I'm ready to get started with writing joystick code, but I'm a little confused about what controls what with Mac OSX.
If I'm understanding this correctly (I've only had my MBP for a few weeks):

• Carbon is being deprecated and will not receive 64-bit support
• The mouse and keyboard implementation currently uses Carbon directly for input
• The Joystick implementation will/does use the HID API for input
• The HID API can also get input from the mouse and keyboard, effectively deprecating the Carbon input API.
• We can replace the Carbon input code with the HID API, which supports both Carbon and Cocoa
• There is a choice between using the existing HID API and the new HIDManager in 10.5 (http://developer.apple.com/technotes/tn2007/tn2187.html)
• The old HID API will be deprecated in 10.6?

Are these all true?

Btw, the current enumeration code detects my Gravis GamePad Pro USB fine.

[pjcast]

I'm not sure about the depreciation of any APIs and that schedule. I'm also not sure if it is best to try to use the HID stuff for mouse/keyboard. For keyboard, you would loose unicode/text translations. For mouse, you would loose accelerations. At least, that is my guess, it may not be 100% true.

I think, to use OIS through Cocoa for mouse/keyboard, we could use Cocoa Mouse events - not positive though, as I haven't looked. I don't think the carbon stuff would be wise to use for mouse/keyboard with cocoa (if it even works at the same time).

[mysterycoder]

I think you can do Mouse Accelerations using HID, but you're right, I bet the integration will be better, I guess I'm just a little nervous about having to use Objective-C 
So are you planning on removing the Carbon stuff totally, or allowing users to enable it with a #define or something?

With the Joystick stuff, will there be a MacJoystick class and we integrate the MacHIDManager into that, or will it simply utilize the MacHIDManager?

Btw, could you list the Cocoa stuff you have done, so I don't overlap the areas you have done?

[pjcast]

The HID Manager class should be able to function as the JoyStick class, as well as supporting any other HID Type of devices we happen to want to control that way.

The only Cocoa part I got to was making a Cocoa application, tying in OIS (had to use it as a static lib, for some reason the dynlib was blowing up), getting the Event listeners tied into dumping messages to a Cocoa Textbox. I didn't touch OIS + Cocoa integration. Though, merging ObjectiveC with C++ is trivial, so it is just a matter of identifying how we can get keyboard/mouse messages from a Cocoa window handle (if possible).

[mysterycoder]

I've been looking into getting keyboard and mouse events from a cocoa window handle. The standard way of receiving these events is by inheriting from the NSResponder class, which most types of cocoa windows and objects do. It doesn't seem possible for OIS to be able to pluck these events from any arbitrary window. However, in addition to the main window of a cocoa application, it can also have a key window. This window receives all keyboard and mouse events, it's normally used for things like a Save As dialog. But I was thinking that we could abuse it a bit by making a hidden key window, and having it forward the events to OIS, although at this point I'm not sure if it is feasible or not. Are there any other solutions you've encountered?

[mysterycoder]

Just a note: the Carbon-based OIS Keyboard also works with Cocoa, I haven't setup a test for the mouse yet. Though I would still like to get a native solution.

[mysterycoder]

I know it might seem like I'm a bit all over the place, but I'm starting the joystick support.

This is my design/what I think you intended:
User -> InputManager(createObject) -> HIDManager(createObject) -> Creates MacJoyStick

For the types of objects that the HIDManager will handle, such as OISJoystick and OISTablet, the InputManager simply passes the call of createObject down the chain to the HIDManager.

Does this sound good?

[pjcast]

Just getting your feet wet.. I understand completely

Yes, the HIDManager was mostly meant to be a helper (like Linux's Joystick EventHelpers classes), not a direct manager really. The idea was that on startup, it would scan for all devices, enumerate them (like Linux / Windows do), then keep an open reference to them, or at least enough information to create the device on demand in an internal joystick/device list.

It would/could also contain the needed polling/event handling code.

[mysterycoder]

I've got the joystick code working, just have to clean everything up. 
Do you want me to just commit this or to send ya a patch first?

[pjcast]

You can commit directly (I believe you have access rights there). Just make sure, of course, you are committing to the v1_2 branch.

[mysterycoder]

Just tried to commit, I get a "Access denied: Insufficient Karma" error. I thought I had permissions too. 

[pjcast]

Insufficient karma is a typical warning, even I get. I'll take a look at the CVSROOT right now.