Dec. 14, 2005
3:29 a.m.
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) -- cu