<html>

  <head>

    <meta http-equiv="content-type" content="text/html; charset=utf-8">

  </head>

  <body text="#000000" bgcolor="#FFFFFF">

    Hi,<br>

    <br>

    I got a bit stuck and would like to hear your opinion on the XInput

    HID backend, specifically on the mappings, i.e. the code that

    "accepts" a certain device based on its properties and then maps its

    buttons and axes to XInput buttons and axes.<br>

    <br>

    As long as the mappings are fixed, i.e. are not supposed to be

    extended or edited by the user, everything can be compiled into

    xinput1_3.dll. However, I would like to provide a "xinput.cpl"

    control panel node for xinput similar to "joy.cpl", where the user

    can not only test the XInput gamepads, but also manage the

    XInput-HID backend mappings. The first part can be accomplished by

    using xinput1_3.dll. However, in order to load and persist different

    mappings, the second part requires access to the functions that

    serialize and deserialize the mappings. It also needs some way of

    getting raw capabilities and changes in HID devices in order to be

    able to create new mappings.<br>

    <br>

    Here are some possible ways of solving it:<br>

    <ul>

      <li>Extend xinput1_3.dll with the required management functions

        and add a "wine/xinput_hid_mgmt.h" or similar header that

        declares those methods. xinput.cpl could then simply use

        xinput1_3.dll to perform all management functions. I'm not sure

        if this would break anything due to the additional exports in

        the dll.<br>

      </li>

      <li>Extract the mapping load and store logic into a separate

        "xinputhid.dll" or similar. I this case both xinput1_3.dll and

        xinput.cpl would access this library to load and store mappings.</li>

      <li>Move the xinput core and backends into a driver and let

        xinput1_3.dll access it via IOCTLs. I believe this is the way it

        works on windows, although there doesn't seem to be any freely

        available documentation regarding the internal architecture. The

        XInput-HID backend could then create its own kernel object as a

        management interface, which could be accessed by xinput.cpl.

        This would have the added effect of having a single instance

        managing the xinput devices if several programs are running at

        the same time, which mimics the behavior of windows.</li>

    </ul>

    <p>What do you think would be the best option? Is there another way

      I haven't mentioned?<br>

    </p>

    <p>- Juan<br>

    </p>

  </body>

</html>