hiho
i did recently some patches to mostly make joystick_linuxdinput.c handle things more like joystick_linux.c. the main thing, that i dont like on this work, is the fact, that i am just copy-and-paste code from one end to another. i assume someone started back then the joystick_linuxdinput part and if there where changes at either one of them they where not done (or not all the time) also in the other file.
also if i have understood this correctly there is no support for multiple joysticks of one kind at least in the joystick_linuxdinput part (i can not confirm this, because i had for now a js-joystick and a event-wheel - but a event-joystick is on the way). for many game-types it is much likely, that the users want to use more than one input-device (e.g. use the wheel and the pedals from two different manufactures, use the pedals from your wheel with your flight stick, use two gamepads, ...) and its most likely that such a device is nowadays a usb device poping up in /dev/input. if the current implementation works fine with more than one js/event-driven joystick - so let me know; my windows/dinput knowledge ist zero and i have not the hardware to test it yet.
so my point: i want to make the joystick_... interface to be more abstract. so to bring the code, that is common for the js and event into one common part and then utilize implementations of a interface for each js and event based joysticks. with this step it would make sense to also allow the "driver" (i call it that way now) to report the joysticks that are available and so have support for multiple joysticks. a split like this would also allow an easier integration of e.g. joystick support for OSX or other opteration systems that handle joysticks in another way then unix/linux does.
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)
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+
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)
On 12/14/05, Christoph Frick frick@sc-networks.de 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
-
Christoph Frick -
Daniel Remenak -
Eric Pouech