josystick driver layer and support of multiple devices of one kind

[Christoph Frick]

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)

-- 
cu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 163 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20051207/caf7b293/attachment-0001.pgp