XInput: Comments on core and further steps

[Juan Jose Gonzalez]

On 02/15/2016 03:29 PM, Aric Stewart wrote:
> Hi Juan,
>
> On 2/15/16 2:37 AM, Juan Jose Gonzalez wrote:
>> Thanks for the attachment. In your code you seem to enumerate the
>> available devices only once when you load the driver. XInput does not
>> have any methods to open and close devices, it just provides methods to
>> listen for key events and to poll the state of individial device slots.
>> Therefore, the detection of newly connected controllers must be done by
>> the backend continuously in order to be able to "connect" new slots as
>> soon as devices become available. In the evdev backend I was listening
>> for newly connected input devices, so RegisterDeviceNotification is, as
>> you said, the way to go for the HID backend. Until that is ready, what
>> do you think of running your detection code periodically in a separate
>> thread, for example every 2s? Do you think that would cause a lot of
>> overhead?
>>
> Maybe on DLL initialization?  (DllMain) That will catch all the devices that are plugged in at wine startup, just like all the other current gamepad implementations. I don't know if we want to have a detection thread, it just feels messy to me. 
I didn't know the other gamepad implementations only enumerated the
gamepads at startup. We could go with that for XInput until
RegisterDeviceNotification is ready. Is DllMain a good idea? I'm not
very savvy about windows (or wine) internals, but my understanding was
that DllMain should only do very basic initialization. I think the
enumeration should happen when the API is first accessed. That's what my
implementation is currently doing.
> True, But anyone who is going to use an Xbox controller has installed
> some sort of a driver for it. A driver that very likely makes is look
> like a HID device to the operating system. I plug in my Xbox 360
> controller into my mac, with the 3rd party driver for it, and I get a
> HID device that reports 15 buttons (Usages 0x1 - 0xf) and 6 of Axes(Z,
> Rz, X, Y, Rx, Ry) . Interestingly the dpad is reported as 4 buttons
> and not a hatswitch. The A buttons is usage 0x1, B is 0x2, X is 0x3, Y
> is 0x4 and so on... I could dump the HID descriptor for it but the
> question becomes is that just this drivers interpretation? On linux if
> you install the xbox driver what elements does that report? I know the
> Linux Input does not give you access to lower level things like usage
> pages and the like, but we will need to tackle all that with the wine
> HID minidriver for Linux Input for any controller. 
I've attached the output of a small program I created to implement the
mappings in the XInput evdev backend. It shows the available event types
and codes for my wireless Xbox 360 controller. I'm using xboxdrv with
the --mimic-xpad option, so I guess the xpad module would yield the same
results.

In the hid minidriver, we could inject some custom usage page, with info
about the current minidriver, into the descriptors of devices emulated
from evdev and similar non-hid interfaces. This would allow us to
differentiate between different sources in the XInput code, allowing for
different mappings per hid minidriver.

-------------- next part --------------
evdev device opened at "/dev/input/event12"
  - Name: Microsoft X-Box 360 pad
  - ID: bus 0 vendor 0 product 0
  - Phys: (null)
  - UID: (null)
  - Event type 0 (EV_SYN)
  - Event type 1 (EV_KEY)
    - Event code 304 (BTN_SOUTH)
    - Event code 305 (BTN_EAST)
    - Event code 307 (BTN_NORTH)
    - Event code 308 (BTN_WEST)
    - Event code 310 (BTN_TL)
    - Event code 311 (BTN_TR)
    - Event code 314 (BTN_SELECT)
    - Event code 315 (BTN_START)
    - Event code 316 (BTN_MODE)
    - Event code 317 (BTN_THUMBL)
    - Event code 318 (BTN_THUMBR)
  - Event type 3 (EV_ABS)
    - Event code 0 (ABS_X)
      - Axis (0) Value (0) Min (-32768) Max (32767) Res (0)
    - Event code 1 (ABS_Y)
      - Axis (1) Value (0) Min (-32768) Max (32767) Res (0)
    - Event code 2 (ABS_Z)
      - Axis (2) Value (0) Min (0) Max (255) Res (0)
    - Event code 3 (ABS_RX)
      - Axis (3) Value (0) Min (-32768) Max (32767) Res (0)
    - Event code 4 (ABS_RY)
      - Axis (4) Value (0) Min (-32768) Max (32767) Res (0)
    - Event code 5 (ABS_RZ)
      - Axis (5) Value (0) Min (0) Max (255) Res (0)
    - Event code 16 (ABS_HAT0X)
      - Axis (16) Value (0) Min (-1) Max (1) Res (0)
    - Event code 17 (ABS_HAT0Y)
      - Axis (17) Value (0) Min (-1) Max (1) Res (0)
  - Event type 21 (EV_FF)
    - Event code 80 (FF_RUMBLE)
    - Event code 81 (FF_PERIODIC)
    - Event code 82 (FF_CONSTANT)
    - Event code 87 (FF_RAMP)
    - Event code 88 (FF_SQUARE)
    - Event code 89 (FF_TRIANGLE)
    - Event code 90 (FF_SINE)
    - Event code 91 (FF_SAW_UP)
    - Event code 92 (FF_SAW_DOWN)
    - Event code 93 (FF_CUSTOM)
    - Event code 96 (FF_GAIN)