You are right, I forgot about hid.class patching lowlevel.library's ReadJoyPort and SetJoyPortAttrsA functions. It only takes over ports 0-3 though, so port numbers from 4 could still be used by XInput as long as they are below JP_ANALOGUE_PORT_MAGIC (1<<16) and the patches are installed after hid.class. That being said most software is hard coded for ports 0-3, so this would have a limited use for backwards compatibility purposes :(

I'm at work right now and can't check it, but it might be that the lowlevel.library is patched by not the hid.class but by it's device object, might be wrong on this.

If it is so then it's no wonder that it isn't easy to set multiple usb gamepads/joysticks to lowlevel as every device might try and patch the lowlevel.library in turn...

If it is so then the patching code should move to the hid.class object itself and iniated only once. Some sort of middle man would then be required to pass to the hid.class what ever the hid.class device object wants to send it.

Let's take that again...

Hid.class and others would pass the information to a middle man that patches itself to lowlevel.library and merges the data together and spoofs as lowlevel.library calls.

Thanks!

I will have to see if it's possible to set also the XInput device to spoof on lowlevel.library, but the hid.class already patches the library. Can't patch multiple times, last patch wins...

You can find the autodocs in the MorphOS SDK:
http://morphos-team.net/downloads

I couldn't find information about the sensors.library, is it available somewhere?

My 4 free days from work is almost finished, 4:30 tomorrow morning it's back to the sweatshop for the next 6 days...

Quote:
I think it would be better to use an existing API (as long as it's not AmigaInput, yuck!). Implementing the controller subset of sensors.library from MorphOS would work for me. It allows for event driven and polled use too.
That being said the two-port lowevel.library interface should have a higher priority, for backwards compatibility.

Quote:

Not quite. Both HID and XInput gamepads can be read using sensors.library. I'm not sure if XInput gamepads work through lowlevel.library (I've never tried this, since I have no such device).

As I've based the arosx.class on simplemidi.class then there already is code in place to insert input events to input.device... But who would define what events are sent? No Commodore anymore to define codes for the buttons and axises

"arosx.class" -> "input.device" -> "some library for easy input.device handling" -> "game"

"some library for easy input.device handling" would also place rumble effect events on "input.device" and "arosx.class" could pick them from there...

I really don't have any idea on how to proceed...

If only xinput devices would work with the new api I don't have problem with that, but it should be compatible with lowlevel, or classic input.
I know the classic stuff is stupid to configure for multible controllers, but I guess it could be fine that only 1 controller is supported that always go for port 1 anyway.

I guess mapping classic with the new lib to different ports might be difficult?

I tried lot's of hid devices and it seams to always be problems unless you are only out for classic 2-3 button joystick and even with classic controllers it is sometimes not possible to configure the buttons and some controllers does not even take me to the config window. They are simply not recoginzed by the hid interface as a controller and it does not help to try to force the class.

All this said it is better to be fully compatilbe with one controller that is easy to find like the xbox controller than making some mess out of lot's not working and others half way working etc.

For my distro "AspireOS" I simply would put in the hardware page that xbox controllers is what is working and others not recommended.

For MorphOS it is 2 APIs right?
The original (lowlevel.lib) for hid.class
and sensors.lib for xinput?

Sure what BSzili recommend would be the perfect solution.