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)