Hi Mark,
I am happily impressed by your clear and thorough investigations. Let me try to answer your questions.
One question occurred to me related to your post - I know that a lot of the advantage to using USB is the Plug and Play nature of USB.
However if you were not planning to switch or remove the device, simply have it remaining plugged in (IOW simply using the same joystick or gamepad device all the time) and are sufficiently savvy, technically, to modify Config.Sys yourself manually, providing the /D: and /N: information, could input device support for a specific device be done through your USBECD driver?
Yes. That is the way how I implemented a.o. touch screen support for some
Wacom Bamboo models. The supporting program (without looking into the HID report descriptors) knows by heart what the actual input report format is and acts on it accordingly. That program allows to hotswap the device (only tested for the same model though).
Or are you referring to another specific Config.sys statement that would need to be added to address each device, to allow the input functions of the Joystick to be used? (essentially in the case of the Thrustmaster joystick I'm using it would be X-Y direction, enable 4 separate buttons, and a POV (Point of View switch)
Yes. That is the way how I implemented a.o. touch screen support for some
Wacom Intuos models. The supporting program (without looking into the HID report descriptors) knows by heart what the actual input report format is and acts on it accordingly. That program allows to hotswap the device (only tested for the same model though).
I ask because it sounds like you are referring to your driver not being able to provide a "hot swap" function, as opposed to not being able to address and use the device.
No. The reason is that each USBECD.SYS device driver grabs the first USB device that fulfils its config.sys specification. This way the proper USB device is connected to the proper supporting program i.e the one that knows how to handle this particular device.
Or are you thinking that since the infrastructure already exists, through GAMEVDD.SYS and GAMEDD.SYS, that adding the USB translation layer would be a better approach?
Hard to say. There is more to it. It is complicated. Personally I favor as much backwards compatibility as possible. Existing programs that do work with game port joysticks need, on modern system without game port, to work with USB joysticks. This is why I think that an additional interface from GAMEDD.SYS to USBHID.SYS is to be developed. I am under the impression that the current port of DOSBox for OS/2 does contain game port joystick support. I wonder if that has been done by means of accessing our GAME$ device driver or through direct i.e. non-emulated game port access (unlikely because hard to do).
The reason the discussion turned to DOSBOX is that, while the ArcaOS has no interface to use newer USB based gaming input devices (the current support as I understand it is centered on Gameport devices natively), DOSBOX does have the ability currently to address and use USB input devices if they conform to the parameters that were used originally with many of the old DOS games including:
2axis (supports two joysticks)
4axis (supports one joystick, first joystick used
4axis_2 (supports 2 joysticks),
fcs (Thrustmaster) 4 axis, 4 button with POV viewer
ch (CH Flightstick)
Understood. As mentioned before , one way to go would be via the generic USBCALLS interface. Another way could be via our to be modified GAMEDD.SYS i.e. GAME$ device driver. Yet another way could be through that additional USBGAME.SYS device driver.
People using DOSBOX under both Windows and Linux are doing this successfully with the newer USB input devices, using the existing built-in source code in DOSBOX, if the layout of controls is similar to one of the above configurations. Having that support available already in DOSBOX may mean not having to reinvent the wheel again related to creating a whole new DOS infrastructure to address USB input devices, as legacy games represents the majority of uses that a input device of this nature would be used for.
I am not sure what you are saying. Do you mean that, for DOSBox only, some shortcut solution would be acceptible limited to just those 5 devices? How about other SDL based games then?
Best regards,
Wim