On Wed, Dec 07, 2005 at 11:02:14PM +0100, Eric Pouech wrote:
Thanks Eric for the reply.
- i this an approach, that would be acceptablefor wine? so if i start on
something like this, is there a chance it would be submitted to the tree - or is there a problem in terms of "wine does not work like this and we would ignore such an approach"
- is the sound-system of wine with its lots of implementations a place
to get ideas for such a change; or is this totally off, because the user only chooses one driver to use (instead of: only build the driver if appropriate and then let each driver search for hardware)
there are several questions:
- share as much as possible code between dinput and winmm (you have to
choose which one could call the other)
- how to abstract the interfaces: ddk is your friend. for the winmm
part, check the include/mmddk.h, and dlls/winmm/joystick (the joystick driver). there's in it all what you need (google will help too).
- from the MM experience, don't recreate a separate driver for each
known HW or interface, but rather stick everything in a single driver, and handle the complexity here
if i get you right from what i have now seen in the dinput code it would be best to do the following:
- check also winmm out for the joystick relevant drivers * see if there is support for both kind of joysticks * see if there is support for multiple devices - put all the logic how to access the joystick hardware away from dinput.dll and utilize winmm - extend the support for multiple devices, for the parts where it is not yet working
thinks that are _no_good_idea_: - create a proper driver (not in the windows driver sense but for internal use only)