josystick driver layer and support of multiple devices of one kind

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

josystick driver layer and support of multiple devices of one kind

Christoph Frick-2
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



attachment0 (169 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: josystick driver layer and support of multiple devices of one kind

Eric Pouech-2
>
> 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



Reply | Threaded
Open this post in threaded view
|

Re: josystick driver layer and support of multiple devices of one kind

Christoph Frick-2
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


Reply | Threaded
Open this post in threaded view
|

Re: josystick driver layer and support of multiple devices of one kind

Daniel Remenak
On 12/14/05, Christoph Frick <[hidden email]> 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