I've been trying to make a XInput Gamepad from one of my ST-boards...

The way Windows sets the drivers up is driving me crazy, I'm deleting registry entries and un-installing from device manager.

I'm unable to make Windows recognize my spoofing attempts when cloning the Logitech F310, it's all the same descriptors and all...

On Linux and on AROS my spoofing is ok, but not on Windows 7

I've put a serial port on my ST-board and this is what we get on AROS when trying to get the bitmask:

Parse req->bmRequest 0xc1 (Device to Host)
Parse req->bRequest 0x01
Parse req->wValue 0x0100
Parse req->wIndex 0x0000
Parse req->wLength 0x0014
USB_REQ_RECIPIENT_INTERFACE:
USB_REQ_TYPE_STANDARD:
USBD_StdItfReq->USBD_OK;

That's this code calling:

psdPipeSetup(nch->nch_EP0Pipe, URTF_IN|URTF_VENDOR|URTF_INTERFACE, 0x01, 0x0100, 0x00);

do {
ioerr = psdDoPipe(nch->nch_EP0Pipe, ep0buf, 20);
} while(ioerr);

On windows on the other hand I get this and then the board hangs:

Parse req->bmRequest 0xc1 (Device to Host)
Parse req->bRequest 0x01
Parse req->wValue 0x0100
Parse req->wIndex 0x0005 <- Notice this!
Parse req->wLength 0x0014
USB_REQ_RECIPIENT_INTERFACE:
USB_REQ_TYPE_STANDARD:
USBD_StdItfReq->

I think they deliberately mess things up (or my ST-board code is messed), I can sometimes get the spoofing board be recognized by windows if I insert the REAL F310 board before and try enough times, but then Windows just uses the registry keys to set the gamepad up.

I sort of remember it now, but it had totally slipped my mind...

I haven't had too much time on these two past days, nightshift at the monkeygarden...

I'm setting up stm32 board as xinput gamepad, but the usb code on it wasn't just a few mouse clicks on stm32cubemx software.

I have a hunch on the xinput descriptor, but I will need to check it with that st board.

Quote:
i second that. :thumbsup:


@Dizzy: as a small reminder (just in case it slipped)

@DizzyOfCRN

Nice progress! Keep up the good work!

Had to do a usb trace on windows to make sure that the analog channel doesn't get more bits with some iorequest, but the results are the same as with the arosx.class debug call

I'm sorry but I could never accept such an offer, thanks for the offer anyway, it is a generous one.

Dizzy: If you like a wireless XBox controller to test with reciver I get you one for free. pm me your address and I send to you. I don't demand anything but if something good comes out if it is great :)

And after doing that we can see that the analog values are the same on both bytes, only 8-bits and most significat bit can change depending on direction.

for the positive direction:
EPIn: 01 01
EPIn: 03 03
EPIn: 04 04
EPIn: 06 06
EPIn: 07 07

for the negative direction (only most significant bit set on the other)
EPIn: 00 00
EPIn: fc 7c
EPIn: fb 7b
EPIn: f9 79
EPIn: f7 77
EPIn: f6 76

EDIT:

Had to check my code, but it really is so...
mybug(1, ("EPIn: %02lx %02lx\n", buf[7], (buf[6]&0x7f)));

So the analog values are really coarse and nothing even close to being 16-bit values. Would be a nightmare to design mass produced item that has 16-bit ADC, just the signal to noise ratio would make it un-makeble ( did I just invent a word... :) )

Oookkay...

Going in the negative direction we get this:
EPIn: 00 80 -> EPIn: ff 7f

The least significant byte never leaves the realms of 7-bits, it's 0x7f to 0x00 for the negative direction.

For the positive direction we get this:
EPIn: 00 80 -> EPIn: 01 81

It does continue to count to 0xff, but never pass that, so it also stays in the 7-bit world, we can just leave the highest bit of the least significant byte to zero always.

Highest bit would then tell if the direction is negative or it is positive.