Re: josystick driver layer and support of multiple devices of one kind
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
Re: josystick driver layer and support of multiple devices of one kind
On 12/14/05, Christoph Frick [EMAIL PROTECTED] wrote: - 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 WinMM under wine supports only /dev/js devices. It does support multiple devices, with some limitations. Under wine, winmm joysticks are hard mapped as JOYSTICKID1 to /dev/js0 and so on. It's possible to end up with ID1 usable and ID2 not, or vice versa. It's even theoretically possible to end up with neither ID1 nor ID2 usable if your joystick is connected to /dev/js2 or higher, although I'd rate the chances of that actually happening as slim to none. Dinput joysticks are even worse as far as multiple devices, since they just iterate through, take the first working one they find, and call it the wine joystick. If you want to make multiple joysticks work correctly you'll have to write quite a bit of new code, there's no way around it. - 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 Please be aware that the DInput devices (both abstractly and the current wine implementations) contain significant additional functionality that the multimedia devices do not. Using winmm as a base for dinput is probably not practical without significant reworking; it simply doesn't do enough. Force feedback comes to mind. I'm not sure quite what stick everything in a single driver, and handle the complexity here means, but there are a couple things to be aware of: 1. It should be possible to use more than one type of device simultaneously. E.g. I might have a /dev/js* device not registered by /dev/input/*, and a /dev/input/* device not registered by /dev/js*. I should be able to pick between them without hassle (e.g. they should both be reported to the application). DInput does this now, by having two separate drivers for /dev/js* and /dev/input/*. This may be even more important in the future with both joystick capabilities on other platforms (BSD, OSX, whatever), and with other interfaces on the various platforms (XInput, SDL, whatever). 2. The two extant dinput joystick backends are quite similar and have a lot of code duplication...this is what you noticed when you were moving stuff between them. Bear in mind that not all possible joystick backends will share as much code; /dev/js* and /dev/input/* were _designed_ at the kernel level to have similar interfaces. From experience writing code that uses FreeBSD's USB HID for joystick access, there is very little in common between it and the linux interfaces. XInput is even more different. --Daniel Remenak
Re: josystick driver layer and support of multiple devices of one kind
so my questions: - 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 A+ -- Eric Pouech
